From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 7E70A3858C51; Mon, 2 May 2022 16:55:59 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 7E70A3858C51 From: "izbyshev at ispras dot ru" 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:55:59 +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: izbyshev at ispras dot ru 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:55:59 -0000 https://sourceware.org/bugzilla/show_bug.cgi?id=3D29115 --- Comment #3 from Alexey Izbyshev --- > 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 spa= ce and the need to provide different VDSOs (for clock_gettime()) for processes= in separate time namespaces, but I haven't looked closely. > 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 cl= one > failure, it should be really an exception and retrying will most likely > succeed > in both cases. 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. > 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). Yes, I'm aware that glibc currently relies on address space sharing to pass= the error code, so adding an alternative error reporting would constitute most = of the fix. 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 pl= ace, glibc could add some knob to always enable it for users that need good posix_spawn() error reporting in such environments. --=20 You are receiving this mail because: You are on the CC list for the bug.=