linux-kernel - Re: [PATCH net v2 0/4] r8152: fix scheduling napi

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:   Wed, 25 Jan 2017 14:31:19 -0500 (EST)
From:   David Miller <davem@...emloft.net>
To:     hayeswang@...ltek.com
Cc:     netdev@...r.kernel.org, nic_swsd@...ltek.com,
        linux-kernel@...r.kernel.org, linux-usb@...r.kernel.org
Subject: Re: [PATCH net v2 0/4] r8152: fix scheduling napi

From: Hayes Wang <hayeswang@...ltek.com>
Date: Wed, 25 Jan 2017 16:13:17 +0800

> v2:
> Add smp_mb__after_atomic() for patch #1.
> 
> v1:
> Scheduling the napi during the following periods would let it be ignored.
> And the events wouldn't be handled until next napi_schedule() is called.
> 
> 1. after napi_disable and before napi_enable().
> 2. after all actions of napi function is completed and before calling
>    napi_complete().
> 
> If no next napi_schedule() is called, tx or rx would stop working.
> 
> In order to avoid these situations, the followings solutions are applied.
> 
> 1. prevent start_xmit() from calling napi_schedule() during runtime suspend
>    or after napi_disable().
> 2. re-schedule the napi for tx if it is necessary.
> 3. check if any rx is finished or not after napi_enable().

I think the fundamental issue is that since you can't stop URBs from
queueing up, you cannot properly synchronize NAPI and schedule polling
properly.

>From my perspective what happened here is you want GRO support, but it
comes at the expense of this extremely racey NAPI support which does
not at all achieve one of the main advantages of NAPI which is
interrupt mitigation.

It would have been so much better to implement a generic way for
drivers to get GRO support without NAPI, especially if their packet
feeding engine works the way that the USB networking drivers's do.