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]

Date:   Tue, 21 May 2019 10:12:23 +0000
From:   Kloetzke Jan <Jan.Kloetzke@...h.de>
To:     "davem@...emloft.net" <davem@...emloft.net>,
        "oneukum@...e.com" <oneukum@...e.com>
CC:     "jan@...etzke.net" <jan@...etzke.net>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>
Subject: Re: [PATCH v2] usbnet: fix kernel crash after disconnect

Hi,

Am Dienstag, den 21.05.2019, 11:48 +0200 schrieb Oliver Neukum:
> 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 ?

Why not just take v1 of the patch?

  https://lore.kernel.org/netdev/20190417091849.7475-1-Jan.Kloetzke@preh.de/

The original version was exactly the same, just without the WARN_ON().
Or is it required to send a v3 in this case?

Regards,
Jan