From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 6F5B73858C50; Mon, 2 May 2022 17:17:00 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 6F5B73858C50 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 17:17:00 +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 17:17:00 -0000 https://sourceware.org/bugzilla/show_bug.cgi?id=3D29115 --- Comment #4 from Adhemerval Zanella --- (In reply to Alexey Izbyshev from comment #3) > > It is really annoying that kernel does not allow clone (CLONE_VM | > > CLONE_VFORK) > > with time namespace, however I am not the implications of allowing it > > (neither > > if this is feasible on current kernel architecture).=20=20 > >=20 > I suspect this restriction is due to the conflict of the shared address > space and the need to provide different VDSOs (for clock_gettime()) for > processes in separate time namespaces, but I haven't looked closely. >=20 > > In any case, adding fork+exec fallback seems feasible, the only annoying > > case 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 > > succeed > > in both cases. >=20 > I think it would be great if glibc provided such a fallback. I agree that > retrying once with fork() in case of *any* clone(CLONE_VM | CLONE_VFORK) > failure shouldn't hurt, but it should probably also be OK to skip retry on > ENOMEM and (paradoxically) EAGAIN because the caller has to deal with them > in any case. It makes sense indeed. >=20 > > Another issue is with fork+exec fallback it would require additional > > resources to communicate the possible error code from the helper process > > while running the prepare phase (as covered by tst-spawn3.c). >=20 > Yes, I'm aware that glibc currently relies on address space sharing to pa= ss > the error code, so adding an alternative error reporting would constitute > most of the fix. >=20 > One benefit of the alternative error reporting is that it would also work > correctly in environments where vfork() system call acts as fork() (i.e. > doesn't provide address space sharing), such as qemu-user. So if it's in > place, glibc could add some knob to always enable it for users that need > good posix_spawn() error reporting in such environments. We discussed this before and we moved to use shared memory to report errors exactly to avoid requiring another resource allocation (which adds even more failure paths). I am not very found in restoring it. --=20 You are receiving this mail because: You are on the CC list for the bug.=