netdev - Re: [PATCH 1/2] napi_synchronize: waiting for 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] [day] [month] [year] [list]

Date:	Thu, 18 Oct 2007 11:33:01 +1000
From:	Benjamin Herrenschmidt <benh@...nel.crashing.org>
To:	Stephen Hemminger <shemminger@...ux-foundation.org>
Cc:	"David S. Miller" <davem@...emloft.net>,
	Jeff Garzik <jgarzik@...ox.com>, netdev@...r.kernel.org
Subject: Re: [PATCH 1/2] napi_synchronize: waiting for NAPI

On Wed, 2007-10-17 at 18:26 -0700, Stephen Hemminger wrote:
> 
> Could you give a concrete example as to why it needs a smp barrier?
> The test_bit is going to get a consistent result. Are you worried about
> operations ordering before the test_bit()? In that case, one of those
> smp_mb__before_xxx functions is probably what is needed.

test_bit is just a read, without any ordering constraint. It can thus be
totally mixed with anything before.

we want to synchronize. Basically, make sure that whatever we did before
the call is visible to whatever we are synchronizing with (NAPI poll in
our case). That is, in our case, that a previous/concurrent NAPI poll
(that hasn't seen the effect of what we did before) is complete or any
new one will have seen that effect.

thus we need a barrier. At least a read barrier semantic to avoid the
test_bit to dance around and be speculated but I think a full barrier
also making sure that any previous store is visible before we preform
the read is also necessary in pretty much any usage scenario of this
function. I believe this is also a bug in synchronize_irq and possibly
even in napi_disable(). I sent a patch for synchronize_irq() a minute
ago.

Besides, it's not like this was a hot path :-)

Cheers,
Ben.

-
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