Weekly edition	Kernel	Security	Distributions	Contact Us	Search
Archives	Calendar	Subscribe	Write for LWN	LWN.net FAQ	Sponsors

File descriptor handling changes in 2.6.27

Posted Aug 5, 2008 19:49 UTC (Tue) by nix (subscriber, #2304)
In reply to: File descriptor handling changes in 2.6.27 by mheily
Parent article: File descriptor handling changes in 2.6.27

closefrom() would only work if

1) it was a system call and thus could enforce atomicity

2) glibc took out a lock also taken by open(), dup(), et al, which means 
yet more locking around those functions, harming performance

If you're adding a new system call anyway, why not adjust things so that 
the *already existing* close-on-exec flag works properly, rather than 
adding more band-aids atop the system to compensate for the unreliability 
of the existing flag?

(Log in to post comments)

Posted Aug 6, 2008 21:58 UTC (Wed) by quotemstr (subscriber, #45331) [Link]

No!

Why would closefrom() need to be atomic? There is no race. After fork(), the new process only
has a *single* thread running.

Any race that required closefrom() to be atomic would also be a problem between the
closefrom() and the execve().

So no, closefrom does not need to be atomic.

File descriptor handling changes in 2.6.27

Posted Aug 6, 2008 22:37 UTC (Wed) by nix (subscriber, #2304) [Link]

Yeah, sorry, missed that. Still *everyone* who forks off a child needs to 
do it.

File descriptor handling changes in 2.6.27

Posted Mar 2, 2011 19:25 UTC (Wed) by gps (subscriber, #45638) [Link]

But closefrom() does need to be async-signal-safe so that it can safely be called after a fork().

Sadly it does not look like the Solaris implementation http://www.unix.com/man-page/All/3c/closefrom/ is safe which makes me wonder what the point of implementing it at all was...