lkml.org 
[lkml]   [2013]   [Oct]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v4 6/7] events: use get unused fd flag s(0) instead of get unused fd()
Hi,

Le 30.10.2013 21:20, Peter Zijlstra a écrit :
> On Wed, Oct 30, 2013 at 08:47:46PM +0100, Yann Droneaud wrote:
>> This patch replaces calls to get_unused_fd() with equivalent call to
>> get_unused_fd_flags(0) to preserve current behavor for existing code.
>>
>> The hard coded flag value (0) should be reviewed on a per-subsystem
>> basis,
>> and, if possible, set to O_CLOEXEC.
>
> And how am I supposed to know if that is 'possible'? You provide a
> total
> number of 0 useful clues on how to determine this.

Fair.

Short: Will it break kernel ABI ? If no, use O_CLOEXEC, if yes, use 0.

Long: If userspace expect to retrieve a file descriptor with plain old
Unix(tm)
semantics, O_CLOEXEC must not be the default, as it could break
some applications
expecting that the file descriptor will be inherited during
exec().

But for some subsystems, such as InfiniBand, KVM, VFIO, it make no
sense to have
file descriptors inherited since those are tied to resources that
will vanish
when a another program will replace the current one by mean of
exec(),
so it's safe to use O_CLOEXEC in such cases.

For others, like XFS, the file descriptor is retrieved by one
program and will
be used by a different program, executed as a child. In this case,
setting O_CLOEXEC
would break existing application, which do not expect to have to
call fcntl(fd, F_SETFD,
FD_CLOEXEC) to make it available across exec().

If file descriptor created by events subsystem are not tied to the
current process
resources, it's likely legal to use it in a different process
context, thus O_CLOEXEC
must not be the default.

Aside: If O_CLOEXEC cannot be made the default, it would be interesting
to think to extend
the API to have a (set of) function(s) taking a flags parameter
so that userspace can
set O_CLOEXEC if wanted. And I have a patch for this :)

PS: I like the title of this article: "Excuse me son, but your code is
leaking !!!" [1]
by Dan Walsh but one should probably read PEP-446 "Make newly
created file descriptors
non-inheritable" [2] instead since it has lot more background
information on file
descriptor leaking.

[1] http://danwalsh.livejournal.com/53603.html
[2] http://www.python.org/dev/peps/pep-0446/


Regards.

--
Yann Droneaud
OPTEYA

--
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/

\
 
 \ /
  Last update: 2013-10-30 22:41    [W:0.055 / U:0.572 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site