Le mardi 08 mars 2005 à 20:07 -0800, Joel Becker a écrit : > On Tue, Mar 08, 2005 at 03:54:04PM -0800, Badari Pulavarty wrote: > > > 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. > > Solaris, which does forcedirectio as a mount option, actually > will do buffered I/O on the trailing part. Consider it like a bounce > buffer. That way they don't DMA the trailing data and succeed the I/O. > The I/O returns actual bytes till EOF, just like read(2) is supposed to. > Either this or a fully DMA'd number 4 is really what we should > do. If security can only be solved via a bounce buffer, who cares? If > the user created themselves a non-aligned file to open O_DIRECT, that's > their problem if the last part-sector is negligably slower. > > Joel >
From a user's perspective, I tend to agree with Joel. A read going past EOF should IMHO return the data till EOF and reflect it in the return value. The penalty incured by the trailing part going buffered is the price to pay for not having a fully aligned file. I think doing otherwise would break read(2) semantics. Sébastien. ------------------------------------------------------ Sébastien Dugué BULL/FREC:B1-247 phone: (+33) 476 29 77 70 Bullcom: 229-7770 mailto:[EMAIL PROTECTED] Linux POSIX AIO: http://www.bullopensource.org/posix ------------------------------------------------------ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
