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 6, 2008 21:58 UTC (Wed) by quotemstr (subscriber, #45331)
In reply to: File descriptor handling changes in 2.6.27 by nix
Parent article: File descriptor handling changes in 2.6.27

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.

(Log in to post comments)

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