Re: [PATCH] 2.6.10 - direct-io async short read bug

From: Daniel McNeil
Date: Tue Mar 08 2005 - 20:01:19 EST


On Tue, 2005-03-08 at 11:18, Badari Pulavarty wrote:
> > Andrew, please don't apply the original patch. We shouldn't even attempt
> > to submit IO beyond the filesize. We should truncate the IO request to
> > filesize. I will send a patch today to fix this.
> >
>
> Well, spoke too soon. This is an ugly corner case :( But I have
> a ugly hack to fix it :)
>
> Let me ask you a basic question: Do we support DIO reads on a file
> which is not blocksize multiple in size ? (say 12K - 10 bytes) ?

> What about the ones which are not 4K but 512 byte multiple ? (say 7K) ?
>
> I need answer to those, to figure out how hard I should try to fix this.
>
> Anyway, here is ugly version of the patch - which will limit the IO
> size to filesize and uses lower blocksizes to read the file (since
> the filesize is only 3K, it would go down to 512 byte blocksize).

Badari,

Just to be clear, are you just asking about what we should support on a
DIO read that spans EOF?

For DIO reads past EOF the options are:

1. return EINVAL if the DIO goes past EOF.

2. truncate the request to file size (which is what your patch does)
and if it works, it works.

3. truncate the request to a size that actually works - like a multiple
of 512.

4. Do the full i/o since the user buffer is big enough, truncate the
result returned to file size (and clear out the user buffer where it
read past EOF).

Number 4 would make it easy on the user-level code, but AIO DIO might be
a bit tricky and might be a security hole since the data would be dma'ed
there and then cleared. I need to look at the code some more.

1 and 2 both seem valid and are better than returning the wrong result.

3 seems like it would confuse applications.

Thoughts?

Daniel





-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/