Re: [PATCH 1/2] napi_synchronize: waiting for NAPI

[Benjamin Herrenschmidt <benh@kernel.crashing.org>]

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.