netdev - Re: [PATCH] usbnet: silence an unnecessary warning

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 11 Jan 2018 18:09:40 +0100
From:   Oliver Neukum <oneukum@...e.com>
To:     Bjørn Mork <bjorn@...k.no>
Cc:     davem@...emloft.net, netdev@...r.kernel.org
Subject: Re: [PATCH] usbnet: silence an unnecessary warning

Am Donnerstag, den 11.01.2018, 16:23 +0100 schrieb Bjørn Mork :
> Oliver Neukum <oneukum@...e.com> writes:
> 
> > 
> > That a kevent could not be scheduled is not an error.
> > Such handlers must be able to deal with multiple events anyway.
> > As the successful scheduling of a work is a debug event, make
> > the failure debug priority, too.
> > 
> > Signed-off-by: Oliver Neukum <oneukum@...e.com>
> > Reported-by: Cristian Caravena <caravena@...il.com>
> > ---
> >  drivers/net/usb/usbnet.c | 3 +--
> >  1 file changed, 1 insertion(+), 2 deletions(-)
> > 
> > diff --git a/drivers/net/usb/usbnet.c b/drivers/net/usb/usbnet.c
> > index d56fe32bf48d..1e0bbe23f95c 100644
> > --- a/drivers/net/usb/usbnet.c
> > +++ b/drivers/net/usb/usbnet.c
> > @@ -458,8 +458,7 @@ void usbnet_defer_kevent (struct usbnet *dev, int work)
> >  {
> >  	set_bit (work, &dev->flags);
> >  	if (!schedule_work (&dev->kevent)) {
> > -		if (net_ratelimit())
> > -			netdev_err(dev->net, "kevent %d may have been dropped\n", work);
> > +		netdev_dbg(dev->net, "kevent %d may have been dropped\n", work);
> >  	} else {
> >  		netdev_dbg(dev->net, "kevent %d scheduled\n", work);
> >  	}
> 
> Great!  But why do you drop the ratelimit?  This can be very noisy when
> it hits.  I'd like to keep it ratelimited.

Because this is now a debug output and if you need to debug you may need
to verify whether your kevent will be handled. So not getting either of the
messages would indicate a bug. Thus limiting the rate would defeat the purpose.

	Regards
		Oliver