linux-2.5.2-pre11/drivers/block/loop.c returned incorrect data
for reads from any loop device that was mounted on a block device,
such as a disk partition. The bug is the problem that I asked about
yesterday where do_bio_blockbacked in loop.c would transfer no data
because bio->bi_idx was nonzero (or, more precisely, always equal to
bio->bi_vcnt). Here is a test case that reproduces the problem:
#!/bin/sh
# testdev can be any existant device that has a first sector
# that is not all zeroes. We only need read access to it for this test.
testdev=/dev/discs/disc0/part1
set -e
dd count=1 if=$testdev of=/tmp/first_sector
losetup /dev/loop/0 $testdev
dd count=1 if=/dev/loop/0 of=/tmp/first_sector.loop
losetup -d /dev/loop/0
cmp /tmp/first_sector /tmp/first_sector.loop
It turns out that the value of bio->bi_idx is correct.
The "bio" variable in that routine refers to the I/O operation
on the underlying device (not the loop device), and the I/O
operation has completed when do_bio_blockbacked has been
called for a READ. do_bio_blockbacked should be looking at
rbh->bi_idx instead (rbh is the operation on /dev/loop/nnn,
which has not yet completed). I have attached a patch below
which does this, and I have verified that it fixes the test
case and have used it in mounting a filesystem as well.
By the way, there are plenty of other problems with
loop.c, such as the fact that it hangs my note book computer
in "disk I/O" (presumably to /dev/loop/0) every time it boots,
whereas I don't think I've seen that happen at all under 2.5.1-pre1
(although I have generally seen hangs about once every three weeks
since I went to an encrypted root).
--
Adam J. Richter __ ______________ 4880 Stevens Creek Blvd, Suite 104
[email protected] \ / San Jose, California 95129-1034
+1 408 261-6630 | g g d r a s i l United States of America
fax +1 408 261-6631 "Free Software For The Rest Of Us."
This does not affect the patch that I posted, but I wish to
update one remark that I made:
> By the way, there are plenty of other problems with
> loop.c, such as the fact that it hangs my note book computer
> in "disk I/O" (presumably to /dev/loop/0) every time it boots,
I must apologize for suggesting that that was another loop.c
bug. It turns out that this is a devfsd quirk that disappeared when I
updated to the latest devfsd (it has to do with recent kernels
using a different test to determine which processes are children of
devfsd).
Adam J. Richter __ ______________ 4880 Stevens Creek Blvd, Suite 104
[email protected] \ / San Jose, California 95129-1034
+1 408 261-6630 | g g d r a s i l United States of America
fax +1 408 261-6631 "Free Software For The Rest Of Us."