Messages in this thread | | | From | "Mike Black" <> | Subject | Possible inode.c problem for EXT2 | Date | Fri, 24 Sep 1999 11:07:18 -0400 |
| |
I (along with many others) have been experiencing some lockups, file corruption and "attempt to access beyond end of device" messages. The only common thread I've seen is that we all have EXT2 filesystems.
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/
| |