Hello @Yoann Congal<mailto:[email protected]>,
Thanks for the review. Addressing your comments: * v2 will use the system: prefix in the patch title. * The Upstream-Status URL will be kept on a single line. * I'll drop the "refreshed as per codebase of v255" comment, since there is no functional delta worth calling out. On the justification, This isn't a pure cleanup - it fixes a boot-time race that we can reproduce deterministically and also have observed on our platform running Linux kernel 6.6 with systemd 255 (Yocto Scarthgap). Deterministic reproduction, independent of exec timing: Terminal A: while true; do mount -o remount /proc; done Terminal B: start/restart a service whose access_fd() check races against the ongoing procfs remount This reliably reproduces -ESRCH from access_fd(). We also see the same failure mode at real boot, correlated with systemd-remount-fs.service running in parallel with, or immediately before, another service's exec. We instrumented access_fd()/check_x_access() to pin down the exact failure point, and captured this alongside systemd's own (unmodified) log output: systemd[1]: sd: u=sys-kernel-tracing.mount, active_enter=3275058 systemd[1]: sd: [email protected], inactive_enter=3276766 [instrumentation added around access_fd()/check_x_access() for this investigation] check_x_access: returned ESRCH - proc task lookup failed; PID namespace mismatch or TGID thread owner exited: No such process [systemd output, immediately following] DEBUG: Failed to locate executable: /usr/lib/systemd/systemd-modules-load The first instrumented message identifies the root cause of the failure: pid_task() returns NULL during resolution of /proc/self/fd/<fd>. The second message is unmodified systemd output showing the resulting effect, namely that the executable lookup fails. Tracing the execution path (exec_invoke() -> check_x_access() -> access_fd() -> proc_fd_permission() -> pid_task()) shows that the unpatched access_fd() validates access by resolving a /proc path rather than operating directly on the file descriptor, leaving it vulnerable to races caused by concurrent procfs remounts or PID table changes. The upstream AT_EMPTY_PATH implementation avoids this dependency by performing the access check directly on the file descriptor via faccessat(), falling back to the legacy mechanism only on kernels that do not support AT_EMPTY_PATH. For that reason, we are requesting this backport as a fix for a reproducible race affecting service startup reliability, rather than as a cleanup-only change. I'll send v2 shortly with the requested updates. Thanks, Suresh H A ________________________________ From: Yoann Congal <[email protected]> Sent: 22 September 2026 17:22 To: Suresh H A - UpStream <[email protected]>; [email protected] <[email protected]>; Suresh H A <[email protected]> Cc: Suresh H A <[email protected]> Subject: Re: [OE-core] [scarthgap][PATCH] fs-util: try AT_EMPTY_PATH for access_fd() first Caution: "External email, be cautious especially with link(s), attachment(s) or QR code(s)". Hello, This is a patch for systemd, so the title should start with "systemd:". On Wed Sep 2, 2026 at 12:24 PM CEST, Suresh H A via lists.openembedded.org wrote: > From: Suresh H A <[email protected]> > > Backport a fix to try AT_EMPTY_PATH for access_fd() first What issue does this patch fix? > Fix is already available since systemd v257-rc1. > > Signed-off-by: Suresh H A <[email protected]> > --- > ...ry-AT_EMPTY_PATH-for-access_fd-first.patch | 37 +++++++++++++++++++ > meta/recipes-core/systemd/systemd_255.21.bb | 1 + > 2 files changed, 38 insertions(+) > create mode 100644 > meta/recipes-core/systemd/systemd/0023-fs-util-try-AT_EMPTY_PATH-for-access_fd-first.patch > > diff --git > a/meta/recipes-core/systemd/systemd/0023-fs-util-try-AT_EMPTY_PATH-for-access_fd-first.patch > > b/meta/recipes-core/systemd/systemd/0023-fs-util-try-AT_EMPTY_PATH-for-access_fd-first.patch > new file mode 100644 > index 0000000000..29dd86c850 > --- /dev/null > +++ > b/meta/recipes-core/systemd/systemd/0023-fs-util-try-AT_EMPTY_PATH-for-access_fd-first.patch > @@ -0,0 +1,37 @@ > +From 55453c9671934fc7ee369788eb0a1a9c8c850e8f Mon Sep 17 00:00:00 2001 > +From: Mike Yuan <[email protected]> > +Date: Mon, 20 May 2024 19:33:26 +0800 > +Subject: [PATCH] fs-util: try AT_EMPTY_PATH for access_fd() first > + > +Upstream-Status: Backport > +[https://ind01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fsystemd%2Fsystemd%2Fpull%2F32933%2Fcommits%2Fc675851d5fd503c1ae5d244f041d43ae9e3ab79b&data=05%7C02%7CSuresh.HA%40bmwtechworks.in%7C216323ca653b48458b8808df18a0018d%7C970fa6fd10314cc68c56488f3c61cd05%7C0%7C0%7C639256747628732198%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=7D7T33ZCYO013f%2Ft3%2FJyP7ATqYsT1o%2BtivCg8QVjdFw%3D&reserved=0<https://github.com/systemd/systemd/pull/32933/commits/c675851d5fd503c1ae5d244f041d43ae9e3ab79b>] Please don't split the line here. This patch comes from a PR titled "fs-util: several cleanups": Cleanups are not usually acceptable on stables. You will need to argue why we need to merge this patch. > +Comment: Patch is refreshed as per codebase of v255 I don't see any change with upstream. No need to add a comment like this if there is no meaningful change. > +Signed-off-by: Suresh H A <[email protected]> > +--- > + src/basic/fs-util.c | 8 ++++++++ > + 1 file changed, 8 insertions(+) > + > +diff --git a/src/basic/fs-util.c b/src/basic/fs-util.c > +index ee38e0266a..0f65af1a07 100644 > +--- a/src/basic/fs-util.c > ++++ b/src/basic/fs-util.c > +@@ -664,6 +664,14 @@ int unlink_or_warn(const char *filename) { > + int access_fd(int fd, int mode) { > + /* Like access() but operates on an already open fd */ > + > ++ if (faccessat(fd, "", mode, AT_EMPTY_PATH) >= 0) > ++ return 0; > ++ if (errno != EINVAL) > ++ return -errno; > ++ > ++ /* Support for AT_EMPTY_PATH is added rather late (kernel 5.8), so > fall back to going through /proc/ > ++ * if unavailable. */ > ++ > + if (access(FORMAT_PROC_FD_PATH(fd), mode) < 0) { > + if (errno != ENOENT) > + return -errno; You can either: - send a v2 with the missing justification for merging the patch - discuss it here first. Thanks, -- Yoann Congal Smile ECS
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#246599): https://lists.openembedded.org/g/openembedded-core/message/246599 Mute This Topic: https://lists.openembedded.org/mt/121049823/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
