In reviewing fs/ext2/inode.c there seem to be a lot of places where error
conditions are not being checked. Particularly where "bh =" assignments are
occurring. Some of my messages show ASCII data in the "want=" portion of
the "attempt to access beyond" message. inode_getblk and block_getblk can
both return NULL but most of the calls to these functions in inode.c do not
check for this.
Also, in fs/buffer.c in the call "init_buffer" the bh->b_size and
bh->b_rsector are not initialized. So, if one of the "bh =" calls has an
error in inode.c then bh->b_rsector is quite likely to contain random data
and will (possibly) die on the next ll_rw_block call. In my case I was
doing gigabytes of ASCII i/o so I saw my ASCII data in the message (in hex
of course). In other cases the random value of bh->b_sector would allow the
ll_rw_block call to succeed possibly corrupting files (I've not seen any
corruption yet myself).
Hopefully, this all makes sense...just seems to me that inode.c and buffer.c
could use some cleaning up. I would initialize bh->b_rsector and bh->b_size
to some value that would ALWAYS be beyond end-of-device plus check for
errors on all the "bh =" calls.
________________________________________
Michael D. Black Principal Engineer
mblack@csi.cc 407-676-2923,x203
http://www.csi.cc Computer Science Innovations
http://www.csi.cc/~mike My home page
FAX 407-676-2355
-
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/