From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id AAA683858C2D; Mon, 2 May 2022 21:15:24 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org AAA683858C2D From: "carlos at redhat dot com" 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 21:15:24 +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: carlos at redhat dot com X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: adhemerval.zanella at linaro 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 21:15:24 -0000 https://sourceware.org/bugzilla/show_bug.cgi?id=3D29115 --- Comment #10 from Carlos O'Donell --- (In reply to Alexey Izbyshev from comment #7) > (In reply to Carlos O'Donell from comment #5) > > Either the kernel supports vfork or it doesn't. > >=20 > > A time namespace, or a seccomp filter are all the same problems, and we > > should return the error the userspace. > >=20 > > Adding code which will only be exercised in the event that a time names= pace > > is in use is going to result in increased long-term maintenance costs. > >=20 > > It also results in unexpected surprise behaviour when the developer runs > > under a time namespace e.g. more memory usage, different code paths tak= en > > etc. > >=20 > > Rather than add long-term maintenance and surprise developers my sugges= tion > > is to fail the posix_spawn. > >=20 > posix_spawn() failing and fork()/exec() not failing is also a surprise for > developers. Note that if users are expected to deal with this posix_spawn= () > failure, all language frameworks/libraries providing high level process > creation APIs will have to implement knobs to opt-out from posix_spawn(). > It's not clear to me that it's better than a potential performance problem > due to fork() when time namespaces are used. >=20 > We also don't know what other vfork() failure modes that fork() doesn't h= ave > may appear in the future. A fallback would cover them. That is a slipper slope fallacy. Those other failure modes haven't material= ized and so they do not matter to the conversation at hand. When we have other failure modes, and fork() can fail badly also as it consumes more memmory, maybe triggering OOM, we have other problems. Performance and expected semantics are an important part of an interface. Library and applications authors would not only have to change posix_spawn(= ) as a choice but also system() which may use vfork(), and maybe even clone (if = used with the right flags). All of this makes me suspect that blocking vfork is the wrong semantic. It needs to be enabled in the kernel otherwise the CRIU use case is *not met*. We can't add CLONE_NEWTIME and yet require all of userspace to move away fr= om vfork/clone which is the fastest and least-memory intensive way to clone a process. This change adds significant code to the implementation. Please involve the CRIU developers and see if this can't be solved in the kernel first. I have= n't seen any justification that there are blockers to this in the kernel. --=20 You are receiving this mail because: You are on the CC list for the bug.=