at least it's not security related :)
>
> > However, the bug is really in "generic_direct_IO()", and you should fix it
> > there, instead of avoiding to use it altogether.
> >
> > "generic_direct_IO()" should just get the device from "bh->b_dev (which is
> > filled in correctly by "get_block()".
>
> Oh, that's right, the patch becomes more simple (and works well).
> Is this patch OK?
yes it is.
Thanks and sorry for your troubles. BTW, if you read back my first post
about the blkdev-pagecache you'll notice I got bitten by the same bug
too and I had to reinstall the test-machine from scratch :). 2.4.10
didn't had such bug, but after integrating the direct-io with the blkdev
inode physical address space the bug seen the light again. I should have
fixed the below way since the first place, at that time there were two
functions anyways and so it was less obvious the below was the right fix
(previously I just did a one liner to fix it (s/dev/rdev/)).
> --- linux.vanilla/fs/buffer.c Mon Dec 10 21:13:10 2001
> +++ linux/fs/buffer.c Mon Dec 10 20:59:34 2001
> @@ -2003,12 +2003,12 @@
> {
> int i, nr_blocks, retval;
> unsigned long * blocks = iobuf->blocks;
> + struct buffer_head bh;
>
> + bh.b_dev = inode->i_dev;
> nr_blocks = iobuf->length / blocksize;
> /* build the blocklist */
> for (i = 0; i < nr_blocks; i++, blocknr++) {
> - struct buffer_head bh;
> -
> bh.b_state = 0;
> bh.b_dev = inode->i_dev;
> bh.b_size = blocksize;
> @@ -2034,7 +2034,7 @@
> blocks[i] = bh.b_blocknr;
> }
>
> - retval = brw_kiovec(rw, 1, &iobuf, inode->i_dev, iobuf->blocks, blocksize);
> + retval = brw_kiovec(rw, 1, &iobuf, bh.b_dev, iobuf->blocks, blocksize);
>
> out:
> return retval;
>
>
> -- gotom
Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/