netdev - Re: [PATCH net] net: usbnet: fix softirq storm on suspend

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: <CACVXFVMEqF9+e10oRuTHjkKQOnPnJMXxapXZ9rYG9qWRpZPLKw@mail.gmail.com>
Date:	Tue, 4 Sep 2012 17:38:36 +0800
From:	Ming Lei <ming.lei@...onical.com>
To:	Bjørn Mork <bjorn@...k.no>
Cc:	netdev@...r.kernel.org, linux-usb@...r.kernel.org,
	Oliver Neukum <oneukum@...e.de>
Subject: Re: [PATCH net] net: usbnet: fix softirq storm on suspend

On Tue, Sep 4, 2012 at 3:49 PM, Bjørn Mork <bjorn@...k.no> wrote:
>
> That's easy:
>
> - Take any usbnet device supporting remote wakeup (and of course with a
>   minidriver supporting it as well),
> - enable autosuspend,
> - ip link set dev ethX/usbX/wwanX up
>
> And watch ksoftirqd/X use 100% of one of your CPU cores.
>
> I'd very much like to hear the details if you are unable to reproduce
> the bug using this simple test.

I have no such kind of devices, and can't reproduce the problem with
a cdc-ether gadget built by one omap3 beagleboard.

>> Once usbnet_terminate_urbs and netif_device_attach() are
>> completed, who will schedule tasklet to trigger rx_alloc_submit?
>
> That's a good question.  It sure would be nice if that never happened
> without waking the device first.  But there are just too many call sites
> for me to follow:

To be honest, your patch is correct, and I am just curious about
the reason why tasklet is scheduled after the device is suspended.

>
> bjorn@...i:/usr/local/src/git/linux$ grep tasklet_schedule drivers/net/usb/usbnet.c
>                 tasklet_schedule(&dev->bh);
>  * but tasklet_schedule() doesn't.  hope the failure is rare.
>                         tasklet_schedule (&dev->bh);
>         tasklet_schedule(&dev->bh);
>                 tasklet_schedule(&dev->bh);
>         tasklet_schedule (&dev->bh);
>                         tasklet_schedule (&dev->bh);
>                                 tasklet_schedule (&dev->bh);
>         tasklet_schedule (&dev->bh);
>                                 tasklet_schedule (&dev->bh);
>                         tasklet_schedule (&dev->bh);

Could you add some debug info inside the caller to see which one
cause the tasklet to be scheduled?


Thanks,
--
Ming Lei
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html