Bug 29526

Sorry for the delay in getting to this...

Is closefrom() susceptible to interruption (EINTR)?

Is closefrom() async-signal-safe, i.e. safe to call after fork()?

Does closefrom() return int (with the same 0/-1 semantics as close()) on all platforms that support it?

It appears that Solaris and (Free|Net|Open)BSD have closefrom(), and AIX, Irix, NetBSD can implement it as fcntl(3, F_CLOSEM, 0).

(In reply to comment #1)
> Is closefrom() susceptible to interruption (EINTR)?
> 
> Is closefrom() async-signal-safe, i.e. safe to call after fork()?
> 
> Does closefrom() return int (with the same 0/-1 semantics as close()) on all
> platforms that support it?

Could someone from Solaris or *BSD please answer these?

Reverting apparently random/abusive priority, status, severity, keyword changes.

"thulani makhathini", don't do that. It's because of people like you that we can't have nice things.

Created attachment 133434 [details] [review]
Updated patch that applies to git master as of July 2017

> Is closefrom() susceptible to interruption (EINTR)?

NetBSD & OpenBSD document that it is, Solaris & FreeBSD do not.

> Is closefrom() async-signal-safe, i.e. safe to call after fork()?

That is not documented.

> Does closefrom() return int (with the same 0/-1 semantics as close()) on all
> platforms that support it?

It returns void on FreeBSD & Solaris:
https://www.freebsd.org/cgi/man.cgi?query=closefrom&sektion=2
http://docs.oracle.com/cd/E86824_01/html/E54766/closefrom-3c.html

But OpenBSD and netbsd return an int:
https://man.openbsd.org/closefrom
http://netbsd.gw.com/cgi-bin/man-cgi?closefrom++NetBSD-current

Comment on attachment 133434 [details] [review]
Updated patch that applies to git master as of July 2017

Review of attachment 133434 [details] [review]:
-----------------------------------------------------------------

::: dbus/dbus-sysdeps-unix.c
@@ +4374,5 @@
>  void
>  _dbus_close_all (void)
>  {
> +#ifdef HAVE_CLOSEFROM
> +  closefrom (3);

Given that it can fail with EINTR on some platforms, perhaps we should use it with TEMP_FAILURE_RETRY on those platforms?

(In reply to Alan Coopersmith from comment #6)
> > Is closefrom() susceptible to interruption (EINTR)?
> 
> NetBSD & OpenBSD document that it is, Solaris & FreeBSD do not.
> 
> > Is closefrom() async-signal-safe, i.e. safe to call after fork()?
> 
> That is not documented.

FreeBSD's sigaction(2) man page includes closefrom in the list of async-signal safe "Extension Interfaces".

https://www.freebsd.org/cgi/man.cgi?query=sigaction&sektion=2

OpenBSD’s equivalent sigaction(2) man page does *not* list closefrom(): https://man.openbsd.org/sigaction.2

So I suspect this patch might end up being FreeBSD-only.

---

However, the current Linux-specific code uses opendir() which is definitely not async-signal-safe, so there are already problems here. _dbus_close_all() is seemingly only used from code sections between fork() and exec() so it should really be async-signal-safe (as per `man 2 fork`).

Simon, is there some reason why _dbus_close_all() is not currently async-signal-safe on Linux? It was introduced in bug #35230, which didn’t seem to discuss the async-signal-safety aspects of being sandwiched between fork() and exec() at all.

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/dbus/dbus/issues/29.