netdev - Re: [PATCH v2] usbnet: fix kernel crash after disconnect

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <1558432122.12672.12.camel@suse.com>
Date:   Tue, 21 May 2019 11:48:42 +0200
From:   Oliver Neukum <oneukum@...e.com>
To:     Kloetzke Jan <Jan.Kloetzke@...h.de>,
        "davem@...emloft.net" <davem@...emloft.net>
Cc:     "jan@...etzke.net" <jan@...etzke.net>,
        "linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [PATCH v2] usbnet: fix kernel crash after disconnect

On Do, 2019-05-16 at 07:10 +0000, Kloetzke Jan wrote:
> Am Montag, den 06.05.2019, 10:17 +0200 schrieb Oliver Neukum:
> > On So, 2019-05-05 at 00:45 -0700, David Miller wrote:
> > > From: Kloetzke Jan <Jan.Kloetzke@...h.de>
> > > Date: Tue, 30 Apr 2019 14:15:07 +0000
> > > 
> > > > @@ -1431,6 +1432,11 @@ netdev_tx_t usbnet_start_xmit (struct sk_buff *skb,
> > > >               spin_unlock_irqrestore(&dev->txq.lock, flags);
> > > >               goto drop;
> > > >       }
> > > > +     if (WARN_ON(netif_queue_stopped(net))) {
> > > > +             usb_autopm_put_interface_async(dev->intf);
> > > > +             spin_unlock_irqrestore(&dev->txq.lock, flags);
> > > > +             goto drop;
> > > > +     }
> > > 
> > > If this is known to happen and is expected, then we should not warn.
> > > 
> > 
> > Hi,
> > 
> > yes this is the point. Can ndo_start_xmit() and ndo_stop() race?
> > If not, why does the patch fix the observed issue and what
> > prevents the race? Something is not clear here.
> 
> Dave, could you shed some light on Olivers question? If the race can
> happen then we can stick to v1 because the WARN_ON is indeed pointless.
> Otherwise it's not clear why it made the problem go away for us and v2
> may be the better option...

Hi,

as Dave confirmed that the race exists, could you resubmit without
the WARN ?

	Regards
		Oliver