netdev - Re: interrupt moving and NAPI scheduling

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] [day] [month] [year] [list]

Date:	Thu, 15 May 2014 10:33:32 -0700
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	Zoltan Kiss <zoltan.kiss@...rix.com>
Cc:	netdev@...r.kernel.org, David Miller <davem@...emloft.net>,
	David Vrabel <david.vrabel@...rix.com>,
	xen-devel@...ts.xenproject.org,
	Ian Campbell <ian.campbell@...rix.com>,
	Wei Liu <wei.liu2@...rix.com>
Subject: Re: interrupt moving and NAPI scheduling

On Thu, 2014-05-15 at 17:26 +0100, Zoltan Kiss wrote:
> Hi,
> 
> Let me bump this question: how does the kernel make sure that if an 
> interrupt is moved away from CPU X to Y (e.g. by irqbalance), the NAPI 
> instance already scheduled on CPU Y won't race with the interrupt? I 
> mean the following scenario:
> 
> 1. instance calls napi_complete on CPU X
> 2. that removes the instance from the list
> 3. interrupt happens on CPU Y
> 4. "!test_and_set_bit(NAPI_STATE_SCHED, &n->state)" fails, as the bit is 
> still set
> 5. instance not added to the list therefore
> 6. napi_complete on CPU X clear the bit
> 
> My assumption is that when the interrupt moved, the kernel makes sure 
> the NAPI instance won't get scheduled on the old CPU, but I'm not sure 
> about it

Interrupts are supposed to be disabled at the time we call
napi_complete().

Some drivers are buggy.


--
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