All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] rpmsg: virtio_rpmsg_bus: use dev_warn_ratelimited for msg with no recipient
@ 2021-09-28 13:29 Alexandru Ardelean
  2021-09-28 21:33 ` Bjorn Andersson
  2021-10-15 17:22 ` (subset) " Bjorn Andersson
  0 siblings, 2 replies; 5+ messages in thread
From: Alexandru Ardelean @ 2021-09-28 13:29 UTC (permalink / raw)
  To: linux-remoteproc, linux-kernel
  Cc: ohad, bjorn.andersson, mathieu.poirier, Alexandru Ardelean

From: Alexandru Ardelean <ardeleanalex@gmail.com>

Even though it may be user-space's fault for this error (some application
terminated or crashed without cleaning up it's endpoint), the rpmsg
communication should not overflow the syslog with too many messages.

A dev_warn_ratelimited() seems like a good alternative in case this can
occur.

Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
---
 drivers/rpmsg/virtio_rpmsg_bus.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/rpmsg/virtio_rpmsg_bus.c b/drivers/rpmsg/virtio_rpmsg_bus.c
index 8e49a3bacfc7..546f0fb66f1d 100644
--- a/drivers/rpmsg/virtio_rpmsg_bus.c
+++ b/drivers/rpmsg/virtio_rpmsg_bus.c
@@ -749,7 +749,7 @@ static int rpmsg_recv_single(struct virtproc_info *vrp, struct device *dev,
 		/* farewell, ept, we don't need you anymore */
 		kref_put(&ept->refcount, __ept_release);
 	} else
-		dev_warn(dev, "msg received with no recipient\n");
+		dev_warn_ratelimited(dev, "msg received with no recipient\n");
 
 	/* publish the real size of the buffer */
 	rpmsg_sg_init(&sg, msg, vrp->buf_size);
-- 
2.31.1


^ permalink raw reply related	[flat|nested] 5+ messages in thread

* Re: [PATCH] rpmsg: virtio_rpmsg_bus: use dev_warn_ratelimited for msg with no recipient
  2021-09-28 13:29 [PATCH] rpmsg: virtio_rpmsg_bus: use dev_warn_ratelimited for msg with no recipient Alexandru Ardelean
@ 2021-09-28 21:33 ` Bjorn Andersson
  2021-09-29  9:40   ` Alexandru Ardelean
  2021-10-15 17:22 ` (subset) " Bjorn Andersson
  1 sibling, 1 reply; 5+ messages in thread
From: Bjorn Andersson @ 2021-09-28 21:33 UTC (permalink / raw)
  To: Alexandru Ardelean; +Cc: linux-remoteproc, linux-kernel, ohad, mathieu.poirier

On Tue 28 Sep 08:29 CDT 2021, Alexandru Ardelean wrote:

> From: Alexandru Ardelean <ardeleanalex@gmail.com>
> 
> Even though it may be user-space's fault for this error (some application
> terminated or crashed without cleaning up it's endpoint), the rpmsg
> communication should not overflow the syslog with too many messages.
> 
> A dev_warn_ratelimited() seems like a good alternative in case this can
> occur.
> 

Is there anything a user could/should do when they see this entry in
their log?

It doesn't look very actionable to me, should we perhaps degrade it
further to just a dev_dbg()?

Regards,
Bjorn

> Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
> ---
>  drivers/rpmsg/virtio_rpmsg_bus.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/rpmsg/virtio_rpmsg_bus.c b/drivers/rpmsg/virtio_rpmsg_bus.c
> index 8e49a3bacfc7..546f0fb66f1d 100644
> --- a/drivers/rpmsg/virtio_rpmsg_bus.c
> +++ b/drivers/rpmsg/virtio_rpmsg_bus.c
> @@ -749,7 +749,7 @@ static int rpmsg_recv_single(struct virtproc_info *vrp, struct device *dev,
>  		/* farewell, ept, we don't need you anymore */
>  		kref_put(&ept->refcount, __ept_release);
>  	} else
> -		dev_warn(dev, "msg received with no recipient\n");
> +		dev_warn_ratelimited(dev, "msg received with no recipient\n");
>  
>  	/* publish the real size of the buffer */
>  	rpmsg_sg_init(&sg, msg, vrp->buf_size);
> -- 
> 2.31.1
> 

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH] rpmsg: virtio_rpmsg_bus: use dev_warn_ratelimited for msg with no recipient
  2021-09-28 21:33 ` Bjorn Andersson
@ 2021-09-29  9:40   ` Alexandru Ardelean
  2021-10-11  8:59     ` Alexandru Ardelean
  0 siblings, 1 reply; 5+ messages in thread
From: Alexandru Ardelean @ 2021-09-29  9:40 UTC (permalink / raw)
  To: Bjorn Andersson; +Cc: linux-remoteproc, LKML, Ohad Ben Cohen, Mathieu Poirier

On Wed, Sep 29, 2021 at 12:33 AM Bjorn Andersson
<bjorn.andersson@linaro.org> wrote:
>
> On Tue 28 Sep 08:29 CDT 2021, Alexandru Ardelean wrote:
>
> > From: Alexandru Ardelean <ardeleanalex@gmail.com>
> >
> > Even though it may be user-space's fault for this error (some application
> > terminated or crashed without cleaning up it's endpoint), the rpmsg
> > communication should not overflow the syslog with too many messages.
> >
> > A dev_warn_ratelimited() seems like a good alternative in case this can
> > occur.
> >
>
> Is there anything a user could/should do when they see this entry in
> their log?

Not really, no.
The userspace application would need to respawn, or some systemd (or
similar process manager) would need to respawn the application it
should recover the state, and communication should resume normally.
I think this message is good mostly as informative.

>
> It doesn't look very actionable to me, should we perhaps degrade it
> further to just a dev_dbg()?

It's not actionable unfortunately.
But I feel it is useful to have this message, until the application recovers.
Mostly to be informative.
A more robust mechanism would be to setup some counters, where we
count the number of missed messages.
And then access this counter via sysfs or something.

The problem is that a high-rate of dev_warn() (during failure),
temporarily increases system CPU usage & load-average, making the
recovery a bit slower, because systemd-journald is processing these
messages from the kernel.
So, dev_dbg() would definitely help, but would also require us to bump
the system log-level to see the messages.
And if they occur and we don't see them, it causes more questions and
debugging, because people won't know for sure what the issue is.

Ultimately, dev_dbg() or dev_warn_rate_limited() are both fine.
The goal is to avoid the temporary increase in CPU load.
I just wanted to state my arguments for dev_warn_ratelimite() :)

Thank you
Alex

>
> Regards,
> Bjorn
>
> > Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
> > ---
> >  drivers/rpmsg/virtio_rpmsg_bus.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/rpmsg/virtio_rpmsg_bus.c b/drivers/rpmsg/virtio_rpmsg_bus.c
> > index 8e49a3bacfc7..546f0fb66f1d 100644
> > --- a/drivers/rpmsg/virtio_rpmsg_bus.c
> > +++ b/drivers/rpmsg/virtio_rpmsg_bus.c
> > @@ -749,7 +749,7 @@ static int rpmsg_recv_single(struct virtproc_info *vrp, struct device *dev,
> >               /* farewell, ept, we don't need you anymore */
> >               kref_put(&ept->refcount, __ept_release);
> >       } else
> > -             dev_warn(dev, "msg received with no recipient\n");
> > +             dev_warn_ratelimited(dev, "msg received with no recipient\n");
> >
> >       /* publish the real size of the buffer */
> >       rpmsg_sg_init(&sg, msg, vrp->buf_size);
> > --
> > 2.31.1
> >

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH] rpmsg: virtio_rpmsg_bus: use dev_warn_ratelimited for msg with no recipient
  2021-09-29  9:40   ` Alexandru Ardelean
@ 2021-10-11  8:59     ` Alexandru Ardelean
  0 siblings, 0 replies; 5+ messages in thread
From: Alexandru Ardelean @ 2021-10-11  8:59 UTC (permalink / raw)
  To: Bjorn Andersson; +Cc: linux-remoteproc, LKML, Ohad Ben Cohen, Mathieu Poirier

On Wed, Sep 29, 2021 at 12:40 PM Alexandru Ardelean
<ardeleanalex@gmail.com> wrote:
>
> On Wed, Sep 29, 2021 at 12:33 AM Bjorn Andersson
> <bjorn.andersson@linaro.org> wrote:
> >
> > On Tue 28 Sep 08:29 CDT 2021, Alexandru Ardelean wrote:
> >
> > > From: Alexandru Ardelean <ardeleanalex@gmail.com>
> > >
> > > Even though it may be user-space's fault for this error (some application
> > > terminated or crashed without cleaning up it's endpoint), the rpmsg
> > > communication should not overflow the syslog with too many messages.
> > >
> > > A dev_warn_ratelimited() seems like a good alternative in case this can
> > > occur.
> > >
> >
> > Is there anything a user could/should do when they see this entry in
> > their log?
>
> Not really, no.
> The userspace application would need to respawn, or some systemd (or
> similar process manager) would need to respawn the application it
> should recover the state, and communication should resume normally.
> I think this message is good mostly as informative.
>
> >
> > It doesn't look very actionable to me, should we perhaps degrade it
> > further to just a dev_dbg()?
>
> It's not actionable unfortunately.
> But I feel it is useful to have this message, until the application recovers.
> Mostly to be informative.
> A more robust mechanism would be to setup some counters, where we
> count the number of missed messages.
> And then access this counter via sysfs or something.
>
> The problem is that a high-rate of dev_warn() (during failure),
> temporarily increases system CPU usage & load-average, making the
> recovery a bit slower, because systemd-journald is processing these
> messages from the kernel.
> So, dev_dbg() would definitely help, but would also require us to bump
> the system log-level to see the messages.
> And if they occur and we don't see them, it causes more questions and
> debugging, because people won't know for sure what the issue is.
>
> Ultimately, dev_dbg() or dev_warn_rate_limited() are both fine.
> The goal is to avoid the temporary increase in CPU load.
> I just wanted to state my arguments for dev_warn_ratelimite() :)
>

Ping on this :)

> Thank you
> Alex
>
> >
> > Regards,
> > Bjorn
> >
> > > Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
> > > ---
> > >  drivers/rpmsg/virtio_rpmsg_bus.c | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/rpmsg/virtio_rpmsg_bus.c b/drivers/rpmsg/virtio_rpmsg_bus.c
> > > index 8e49a3bacfc7..546f0fb66f1d 100644
> > > --- a/drivers/rpmsg/virtio_rpmsg_bus.c
> > > +++ b/drivers/rpmsg/virtio_rpmsg_bus.c
> > > @@ -749,7 +749,7 @@ static int rpmsg_recv_single(struct virtproc_info *vrp, struct device *dev,
> > >               /* farewell, ept, we don't need you anymore */
> > >               kref_put(&ept->refcount, __ept_release);
> > >       } else
> > > -             dev_warn(dev, "msg received with no recipient\n");
> > > +             dev_warn_ratelimited(dev, "msg received with no recipient\n");
> > >
> > >       /* publish the real size of the buffer */
> > >       rpmsg_sg_init(&sg, msg, vrp->buf_size);
> > > --
> > > 2.31.1
> > >

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: (subset) [PATCH] rpmsg: virtio_rpmsg_bus: use dev_warn_ratelimited for msg with no recipient
  2021-09-28 13:29 [PATCH] rpmsg: virtio_rpmsg_bus: use dev_warn_ratelimited for msg with no recipient Alexandru Ardelean
  2021-09-28 21:33 ` Bjorn Andersson
@ 2021-10-15 17:22 ` Bjorn Andersson
  1 sibling, 0 replies; 5+ messages in thread
From: Bjorn Andersson @ 2021-10-15 17:22 UTC (permalink / raw)
  To: linux-remoteproc, Alexandru Ardelean, linux-kernel; +Cc: mathieu.poirier, ohad

On Tue, 28 Sep 2021 16:29:02 +0300, Alexandru Ardelean wrote:
> From: Alexandru Ardelean <ardeleanalex@gmail.com>
> 
> Even though it may be user-space's fault for this error (some application
> terminated or crashed without cleaning up it's endpoint), the rpmsg
> communication should not overflow the syslog with too many messages.
> 
> A dev_warn_ratelimited() seems like a good alternative in case this can
> occur.
> 
> [...]

Applied, thanks!

[1/1] rpmsg: virtio_rpmsg_bus: use dev_warn_ratelimited for msg with no recipient
      commit: 63b8d79916672d35069962d87d1540c534cb2438

Best regards,
-- 
Bjorn Andersson <bjorn.andersson@linaro.org>

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2021-10-15 17:23 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-09-28 13:29 [PATCH] rpmsg: virtio_rpmsg_bus: use dev_warn_ratelimited for msg with no recipient Alexandru Ardelean
2021-09-28 21:33 ` Bjorn Andersson
2021-09-29  9:40   ` Alexandru Ardelean
2021-10-11  8:59     ` Alexandru Ardelean
2021-10-15 17:22 ` (subset) " Bjorn Andersson

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.