From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 893983858C56; Mon, 2 May 2022 16:17:22 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 893983858C56 From: "adhemerval.zanella at linaro dot org" To: glibc-bugs@sourceware.org Subject: [Bug libc/29115] vfork()-based posix_spawn() has more failure modes than fork()-based one Date: Mon, 02 May 2022 16:17:22 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: libc X-Bugzilla-Version: 2.35 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: adhemerval.zanella at linaro dot org X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: security- X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: glibc-bugs@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Glibc-bugs mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2022 16:17:22 -0000 https://sourceware.org/bugzilla/show_bug.cgi?id=3D29115 --- Comment #1 from Adhemerval Zanella --- (In reply to Alexey Izbyshev from comment #0) > Modern vfork()-based posix_spawn() can be used as an efficient alternative > to fork()/exec() to avoid performance and overcommit issues. A common > expectation is that whenever posix_spawn() feature set is sufficient for > application needs of tweaking the child attributes, it can be used instead > of fork()/exec(). >=20 > However, it turns out that vfork() can have failure modes than fork() > doesn't have. One such case is due to Linux not allowing processes in > different time namespaces to share address space. >=20 > $ cat test.c > #include > #include > #include > #include > #include >=20 > int main(int argc, char *argv[], char *envp[]) { > if (getenv("TEST_FORK")) { > pid_t pid =3D fork(); > if (pid < 0) { > perror("fork"); > return 127; > } > if (pid =3D=3D 0) { > execve(argv[1], argv + 1, envp); > perror("execve"); > return 127; > } > } else { > int err =3D posix_spawn(0, argv[1], 0, 0, argv + 1, envp); > if (err) { > printf("posix_spawn: %s\n", strerror(err)); > return 127; > } > } > printf("OK\n"); > return 0; > } >=20 > $ gcc test.c >=20 > $ unshare -UrT ./a.out /bin/true > posix_spawn: Operation not permitted >=20 > (The actual clone() error is EINVAL, but it's reported incorrectly due to > bug 29109). >=20 > $ TEST_FORK=3D1 unshare -UrT ./a.out /bin/true > OK >=20 > I'm not aware of other failure modes, but more might appear in the future. >=20 > Does this qualify as a glibc bug? Should glibc's posix_spawn() > implementation, for example, retry with fork() on vfork() failure (which > would require a redesign of error reporting from the child process because > it currently relies on address space sharing)? >=20 > Or do applications are expected to deal with that somehow? In this case, > what is the recommended way to do that, given that it's not possible to > reliably detect "retriable" posix_spawn() failures? It is really annoying that kernel does not allow clone (CLONE_VM | CLONE_VF= ORK) with time namespace, however I am not the implications of allowing it (neit= her if this is feasible on current kernel architecture).=20=20 In any case, adding fork+exec fallback seems feasible, the only annoying ca= se is if glibc should detect a clone transient failure (for instance due some resource exhaustion) from a namespace filtering. We can always retry in case of clone failure, it should be really an exception and retrying will most likely suc= ceed in both cases. --=20 You are receiving this mail because: You are on the CC list for the bug.=