Hi guys,
I have just written a simple module that creates two kernel threads which
do bread/brelse the same block (0) of the same device (hardcoded) in a
very busy fashion.
http://www.ocston.org/~tigran/helloworld/test1.c
What I observe by reading block 0 off SCSI ZIP drive is interesting.
The sequence of steps:
a) start the threads (insmod test1) with a disk in the drive with
expected data. Works ok.
b) remove the disk. Still works ok, because the data is in the buffer
cache and block device layer does not know the media has gone.
c) insert some other disk in the drive. Still works ok, i.e. returns the
old data in the buffer cache. A naive user might expect the correct data
but of course we can't get the correct data until one runs something like
fdisk to ioctl BLKRRPART which invalidates all the buffers on this
device.
d) now comes the interesting bit. Even after all the buffers have been
invalidated, those threads still continue happily reading and claiming
that the data is correct (i.e. as in the old disk).
Why? I thought once the disk has been inserted *and* the block device
layer has been informed e.g. by forcing BLKRRPART (I checked sd.c but
presumably other block devices do the same) the next bread() will return
the block of the new disk? Almost certainly a bug in my module :)
Regards,
Tigran.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Mar 04 2000 - 15:22:57 EST