On Monday May 13, sct@redhat.com wrote: > > The second case that can cause this is the one you are seeing, > involving block device IO in parallel with filesystem IO. That one > has always been there for block write IO (and in fact it's arguably > right for ext3 to oops if out-of-band writes are causing ext3's own > metadata to be written out-of-order), but as of 2.4.11, we now have > the page-cache/buffer-cache aliasing interactions which can cause ext3 > to see locked buffers even if you are only reading from the buffered > block device. I had a bit of a look at the block-device-reading code and it seems to me that there could be no (direct) interaction between this code that the code ext3 used to access inodes. When reading a block device the page cache is used and anonymous buffer_heads get allocated for each page. These have to be competely separate from the buffer_heads allocated for the buffer cache that ext3 uses. So a read on the block device could never make an ext3 buffer locked. Is there something obvious that I have missed?? In any case, thanks for the patch. It certainly looks like it should fix the problem, whatever the details of the cause are. NeilBrown
