Messages in this thread | | | Date | Wed, 13 Mar 2002 15:03:45 +0100 | From | Andrea Arcangeli <> | Subject | Re: 2.4.19pre2aa1 |
| |
On Wed, Mar 13, 2002 at 10:51:26AM -0300, Rik van Riel wrote: > On Wed, 13 Mar 2002, Andrea Arcangeli wrote: > > On Wed, Mar 13, 2002 at 08:30:55AM +0100, Andrea Arcangeli wrote: > > > { > > > clear_bit(BH_Wait_IO, &bh->b_state); > > > clear_bit(BH_Lock, &bh->b_state); > > > + clear_bit(BH_Launder, &bh->b_state); > > > smp_mb__after_clear_bit(); > > > if (waitqueue_active(&bh->b_wait)) > > > > actually, while refining the patch and integrating it, I audited it some > > more carefully and the above was wrong, > > It's complex.
The SMP kernel is complex, preempt+SMP is even more complex. If you find a design solution more simple or/and more efficient to be able to identify which locked buffers are just been submitted for I/O let me know ASAP, I can't think for a better/simpler one and the locking rules IMHO here are very simple, nothing remotely comparable to other parts of the kernel. Infact I think it is the simplicity of this fix that renders is so obviously right and why Andrew as well could reply to me this morning with an agreement that that is the right fix.
It is as simple as:
when a locked buffer is visible to the I/O layer BH_Launder is set
This means before unlocking we must clear BH_Launder, mb() on alpha and then clear BH_Lock, so no reader can see BH_Launder set on an unlocked buffer and then risk to deadlock.
I think it is very simple and clean. If you want to know something way more complex than that just ask or alternatively grep for:
grep preempt 2.5.7-pre1/kernel/sched.c
Andrea - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |