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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
