When the put_bh() macro calls got added to fs/buffer.c's
end_buffer_io_async() they look like they got in slightly inconsistently.
If the code branches to still_busy it does:
put_bh(bh);
spin_unlock_irqrestore(&page_uptodate_lock, flags);
If the branch is not taken it does:
spin_unlock_irqrestore(&page_uptodate_lock, flags);
put_bh(bh);
I don't know which is correct...There's either a possible race if the put_bh()
should be inside the lock (although since it's decrementing bh_count I doubt
it's what would be causing my attempt to unlock an unlocked page) or else
there are a few instructions that can be moved outside the lock.
I've been hunting around on the web and saw some discussion in July
about async I/O races between Andrea and Linus. Are these resolved?
I'm running 2.4.9 on the machine in question (w/ and w/o kgdb) trying
to figure out what's going on. I'm going to try the latest pre patches
this weekend since the 2.4.10-pre's include a big merge against Andrea.
Tim
-
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/