H. Peter Anvin a écrit :
Jens Axboe wrote:
I would personally argue that sendfile() blocking on an O_NONBLOCK
desriptor, as opposed to returning EAGAIN, is a bug, and a fairly
serious such.
I agree, but it's still a change in behaviour. Even if we consider the
app buggy (it is), can we potentially break it?
It depends on which app it is, of course. However, I think we have to
smoke that out the hard way. I don't think we should retain a bug in
the kernel just because some unknown app might depend on that bug --
taking that to the extreme we could never fix bugs at all...
As I said, this new non blocking feature on the input side (disk), is nice and
usefull. (For people scared by splice() syscall :) )
Just have to mention it is a change of behavior, and documentation probably
needs to reflect this change. "Since linux 2.6.23, sendfile() repects
O_NONBLOCK on in_fd as well"
My man page here says :
ERRORS
EAGAIN Non-blocking I/O has been selected using O_NONBLOCK and the
write would block.
EBADF The input file was not opened for reading or the output file
was not opened for writing.
EFAULT Bad address.
EINVAL Descriptor is not valid or locked, or an mmap()-like operation
is not available for in_fd.
EIO Unspecified error while reading from in_fd.
ENOMEM Insufficient memory to read from in_fd.
This implies O_NONBLOCK on the out filedesc, not the input one :)
-
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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
