lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Fri, 01 Jun 2007 09:22:20 +0200
From:	Eric Dumazet <dada1@...mosbay.com>
To:	"H. Peter Anvin" <hpa@...or.com>
CC:	Jens Axboe <jens.axboe@...cle.com>, linux-kernel@...r.kernel.org,
	cotte@...ibm.com, hugh@...itas.com, neilb@...e.de,
	zanussi@...ibm.com, Linus Torvalds <torvalds@...l.org>,
	hch@...radead.org
Subject: Re: [PATCH] sendfile removal

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 majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ