On Fri, 2007-10-19 at 12:20 +0800, Herbert Xu wrote: > > That's why I think this patch is in fact the only one that > solves all the races in this thread. The case that it solves > which the lock/unlock patch does not is the one where action > flows downwards past the clearing of IRQ_INPROGRESS. I missed > this case earlier. > > In fact this bug exists elsewhere too. For example, the network > stack does this in net/sched/sch_generic.c: > > /* Wait for outstanding qdisc_run calls. */ > while (test_bit(__LINK_STATE_QDISC_RUNNING, &dev->state)) > yield(); > > This has the same problem as the current synchronize_irq code.
The network stack always made be nervous with it's bitops use as locks. Any loop of test_bit() alone as a synchronisation method, without locks or barriers is, imho, inherently buggy. Ben. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
