On Wed, 1 Mar 2017 01:22:40 +0100 Francois Romieu <rom...@fr.zoreil.com> wrote:
> David Miller <da...@davemloft.net> : > > From: Eric Dumazet <eric.duma...@gmail.com> > > Date: Mon, 27 Feb 2017 08:44:14 -0800 > > > > > Any point doing a napi_schedule() not from device hard irq handler > > > is subject to the race for NIC using some kind of edge trigger > > > interrupts. > > > > > > Since we do not provide a ndo to disable device interrupts, the > > > following can happen. > > > > Ok, now I understand. > > > > I think even without considering the race you are trying to solve, > > this situation is really dangerous. > > > > I am sure that every ->poll() handler out there was written by an > > author who completely assumed that if they are executing then the > > device's interrupts for that NAPI instance are disabled. And this is > > with very few, if any, exceptions. > > Shareable pci irq used to remind author that such an assumption was > not always right. Otoh it was still manageable as long as level only > triggered irq were involved. > When I had to deal with that in sky2, the best way was to have a single NAPI poll handler shared between both ports. Works well and avoids races in interrupt handling and enabling.
