On Mon, 2017-03-13 at 08:44 -0700, Eric Dumazet wrote: > On Mon, 2017-03-13 at 16:37 +0100, Petr Vorel wrote: > > Hi Eric, > > > > > > The proper work around is to enclose the napi_schedule() in a > > > > local_bh_enable()/local_bh_disable() pair. > > > > > Something like : > > > --- a/drivers/net/usb/r8152.c > > > +++ b/drivers/net/usb/r8152.c > > > @@ -3703,8 +3703,10 @@ static int rtl8152_resume(struct usb_interface > > > *intf) > > > napi_enable(&tp->napi); > > > clear_bit(SELECTIVE_SUSPEND, &tp->flags); > > > smp_mb__after_atomic(); > > > + local_bh_disable(); > > > if (!list_empty(&tp->rx_done)) > > > napi_schedule(&tp->napi); > > > + local_bh_enable(); > > > > Unfortunately this doesn't work. Code in r8152.c doesn't use > > local_bh_enable()/local_bh_disable(). I tried to lock it with > > spin_lock_bh()/spin_unlock_bh() and with mutex_lock()/mutex_unlock() > > but neither work. > > The local_bh_disable() / local_bh_enable() definitely is the right > answer to the issue you described. > > It does not matter what code in r8152.c currently does. > > https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/commit/?id=8cf699ec849f4ca1413cea01289bd7d37dbcc626
You also have to protect other napi_schedule(), like the ones in rtl_work_func_t() or rtl8152_post_reset()
