similar to: [libnbd PATCH v4 0/2] lib/utils: introduce async-signal-safe execvpe()

These patches have been pushed (f5a065aa3a9c..9075f68ffc8b); I'm posting them for visibility. Laszlo Laszlo Ersek (3): lib/test-fork-safe-execvpe.sh: generalize "run" to "run0" lib/test-fork-safe-execvpe.sh: cope with Alpine Linux / BusyBox limitations Revert "ci: skip "lib/test-fork-safe-execvpe.sh" on Alpine Linux" ci/skipped_tests

Per POSIX, execvp() is not safe to call in a child process forked from a multi-threaded process. We can now replace the execvp() call in the child process with a call to our fork-safe (async-signal-safe) variant. Prepare our internal execvpe context on the parent's construction path, use the context in the child, and release the context in the parent on the way out, regardless of whether the

V3 was here: <http://mid.mail-archive.com/20230215141158.2426855-1-lersek at redhat.com>. See the Notes section on each patch for the v4 updates. The series is nearly ready for merging: every patch has at least one R-b tag, except "socket activation: avoid manipulating the sign bit". The series builds, and passes "make check" and "make check-valgrind", at

On Tue, Mar 21, 2023 at 07:04:59AM +0100, Laszlo Ersek wrote: > On 3/20/23 20:41, Eric Blake wrote: > > On Sun, Mar 19, 2023 at 10:41:37AM +0100, Laszlo Ersek wrote: > >> This is version 4 of the following sub-series: > >> > >> [libnbd PATCH v3 09/29] lib/utils: introduce async-signal-safe execvpe() > >> [libnbd PATCH v3 10/29] lib/utils: add unit tests

On Tue, Mar 21, 2023 at 03:56:22PM +0100, Laszlo Ersek wrote: > On 3/21/23 15:05, Eric Blake wrote: > > On Tue, Mar 21, 2023 at 07:04:59AM +0100, Laszlo Ersek wrote: > >> On 3/20/23 20:41, Eric Blake wrote: > >>> On Sun, Mar 19, 2023 at 10:41:37AM +0100, Laszlo Ersek wrote: > >>>> This is version 4 of the following sub-series: > >>>> >

On Sun, Mar 19, 2023 at 10:41:37AM +0100, Laszlo Ersek wrote: > This is version 4 of the following sub-series: > > [libnbd PATCH v3 09/29] lib/utils: introduce async-signal-safe execvpe() > [libnbd PATCH v3 10/29] lib/utils: add unit tests for async-signal-safe execvpe() > > http://mid.mail-archive.com/20230215141158.2426855-10-lersek at redhat.com >

On 3/21/23 15:05, Eric Blake wrote: > On Tue, Mar 21, 2023 at 07:04:59AM +0100, Laszlo Ersek wrote: >> On 3/20/23 20:41, Eric Blake wrote: >>> On Sun, Mar 19, 2023 at 10:41:37AM +0100, Laszlo Ersek wrote: >>>> This is version 4 of the following sub-series: >>>> >>>> [libnbd PATCH v3 09/29] lib/utils: introduce async-signal-safe execvpe()

On 10/1/19 9:11 AM, Richard W.M. Jones wrote: > On Tue, Oct 01, 2019 at 08:24:33AM -0500, Eric Blake wrote: >>> +#else /* !HAVE_EXECVPE */ >>> + SET_NEXT_STATE (%.DEAD) >>> + set_error (ENOTSUP, "platform does not support socket activation"); >>> + return 0; >>> +#endif >> >> We probably ought to add a matching

V4 was here (incorrectly versioned on the mailing list as v3): <http://mid.mail-archive.com/20230323121016.1442655-1-lersek at redhat.com>. See the Notes section on each patch for the v5 updates. Laszlo Ersek (2): socket activation: generalize environment construction socket activation: set LISTEN_FDNAMES Richard W.M. Jones (2): common/include: Copy ascii-ctype functions from nbdkit

On 9/30/19 11:32 AM, Richard W.M. Jones wrote: > This adds new APIs for running a local NBD server and connecting to it > using systemd socket activation (instead of stdin/stdout). > > This includes interop tests against nbdkit and qemu-nbd which I > believe are the only NBD servers supporting socket activation. (If we > find others then we can add more interop tests in

On Tue, Mar 21, 2023 at 03:56:22PM +0100, Laszlo Ersek wrote: > > $ podman build -f ci/containers/alpine-edge.Dockerfile -t libnbd-alpine-edge > > $ podman run -it --rm --userns=keep-id -v .:/repo:z -w /repo libnbd-alpine-edge bash > > $ ./configure > > $ make check > > $ grep tmpd= lib/test-suite.log > > + tmpd=/tmp/tmp.EMgKeF > > $ /tmp/tmp.EMgKeF/bin/f

On 3/22/23 15:45, Laszlo Ersek wrote: > On 3/21/23 18:28, Eric Blake wrote: > >> it is indeed a bug in busybox now that POSIX is moving towards >> standardizing realpath, so I've filed it: >> https://bugs.busybox.net/show_bug.cgi?id=15466 > > I've found another busybox bug. > > The "/bin/sh" utility is provided by busybox as well (via the

On Wed, Mar 22, 2023 at 04:53:42PM +0100, Laszlo Ersek wrote: > The solution is that glibc *too* has a bug, and that bug hides the busybox bug. Namely, in glibc, going back to historical commit > > commit 6a032d81581978187f562e5533a32e0a6a3d352b (tag: cvs/libc-960210) > Author: Roland McGrath <roland at gnu.org> > Date: Sat Feb 10 10:00:27 1996 +0000 > > Sat Feb

On 3/21/23 18:28, Eric Blake wrote: > it is indeed a bug in busybox now that POSIX is moving towards > standardizing realpath, so I've filed it: > https://bugs.busybox.net/show_bug.cgi?id=15466 I've found another busybox bug. The "/bin/sh" utility is provided by busybox as well (via the usual symlinking). Per POSIX, if execvp(file, { argv[0], argv[1], ..., NULL })

v1 was posted here: https://www.redhat.com/archives/libguestfs/2019-September/thread.html#00337 v2: - Drop the first patch. - Hopefully fix the multiple issues with fork-safety and general behaviour on error paths. Note this requires execvpe for which there seems to be no equivalent on FreeBSD, except some kind of tedious path parsing (but can we assign to environ?) Rich.

On Thu, Aug 01, 2019 at 10:42:58PM -0500, Eric Blake wrote: > setenv() is not async-signal-safe and as such should not be used > between fork/exec of a multi-threaded app: if one thread is > manipulating the current environment (which may entail obtaining a > malloc() mutex) when another thread calls fork(), the resulting > child's attempt to use setenv() could deadlock or see a

On 3/22/23 11:24, Daniel P. Berrang? wrote: > On Tue, Mar 21, 2023 at 03:56:22PM +0100, Laszlo Ersek wrote: >> On 3/21/23 15:05, Eric Blake wrote: >>> On Tue, Mar 21, 2023 at 07:04:59AM +0100, Laszlo Ersek wrote: >>>> On 3/20/23 20:41, Eric Blake wrote: >>>>> On Sun, Mar 19, 2023 at 10:41:37AM +0100, Laszlo Ersek wrote: >>>>>> This is

On Tue, Feb 21, 2023 at 06:53:39PM +0100, Laszlo Ersek wrote: > > More in general, this lesson tells me that POSIX is effectively > irrelevant -- which is quite sad in itself; the bigger problem however > is that *nothing replaces it*. If the one formal standard we have for > portability does not reflect reality closely enough, and we need to rely > on personal experience with

On Wed, Feb 22, 2023 at 01:47:02AM +0100, Laszlo Ersek wrote: > On 2/21/23 20:32, Eric Blake wrote: > > On Tue, Feb 21, 2023 at 07:07:38PM +0100, Laszlo Ersek wrote: > > >> Well, given Daniel's comments meanwhile, it seems like the original > >> execvp() is something we shouldn't fret about. :/ > > > > glibc marks execvp() and exevpe() as

I'm pushing the first one as blatantly obvious. The second one is also simple enough, but not enough of a bug for me to push tonight. The third is something I noticed while working on sh, but is really more about docs vs. plugins in general. There, we could either change the code to match the docs (breaking backwards behavior for a plugin that set .errno_is_preserved=2) [what my patch did],