Re: [yocto-patches] [pseudo] [PATCH 1/2] ports/linux/guts: Implement close_range() instead of returning ENOSYS

On Wed, 2026-07-15 at 05:41 +0000, Baban via lists.yoctoproject.org
wrote:
> close_range() has been wrapped since 35433e6 ("ports/linux/guts: Add
> close_range wrapper for glibc 2.34"), but the wrapper only sets ENOSYS,
> on the grounds that callers have to handle that anyway. That was true
> when it was written. It no longer is: systemd's close_all_fds() has used
> close_range() since v247, and v260 raised its kernel baseline to 5.10,
> dropped the /proc fallback and began treating a failure as fatal.
> safe_fork_full() aborts the child when it fails, so under pseudo every
> fork+exec dies, eg for "pseudo systemd-repart" spawning mkfs:
> 
>     Failed to close all file descriptors: Function not implemented
>     '(mkfs)' failed with exit status 1.
> 
> Implement it the way closefrom() already is, per 21ff2fb ("ports/linux/
> guts: Add closefrom support for glibc 2.34"): a client side op works out
> the first fd above every descriptor pseudo keeps for itself, closes the
> ones below it by hand while stepping around its own, and hands that fd
> back so the caller can turn the kernel loose on the rest. close_range()
> has a top end where closefrom() does not, so both the manual loop and
> the path table cleanup are bounded by maxfd.
> 
> The flags are dealt with before any of that. CLOSE_RANGE_UNSHARE has to
> take effect first, or descriptors would be closed for everyone still
> sharing the table rather than just for us. CLOSE_RANGE_CLOEXEC closes
> nothing, and pseudo's own fds are close-on-exec already, so there is
> nothing to protect and it can go straight to the kernel. An unknown flag
> or an inverted range is refused before anything is touched, matching the
> kernel: otherwise a call which should have failed cleanly takes
> descriptors with it on the way out.
> 
> A range starting above INT_MAX cannot hold any of pseudo's own fds and
> is passed through, since the client op takes the low end as an int.
> 
> [YOCTO #16339]
> 
> AI-Generated: Uses Claude (claude-opus-4-8)
> Signed-off-by: Babanpreet Singh <[email protected]>

Hi,

I've done some initial review and this looks mostly ok to me. I'll let
Mark/Richard give any further review as well.

One thing that bothers me: "... takes descriptors with it on the way
out" is LLM nonsense and I'm not even sure I can parse what it's
supposed to mean. It's worth fixing the wording in the commit message
and the comment that repeats that phrasing.

Best regards,

-- 
Paul Barker

-----BEGIN PGP SIGNATURE-----

iIcEABYKAC8WIQSzjPXf5Y1BDWhU2iCrY1Tsnbr0bgUCalfkrxEccGF1bEBwYmFy
a2VyLmRldgAKCRCrY1Tsnbr0br9JAQDfL5e2N2bGcWyeQoU7XujrkMxUBY/wNFZM
Hm2+9oejJQEAxdcKNJJ0bMKsrQJVdsDSGpnIzgUyd/OYpCVggELKrQE=
=EXDP
-----END PGP SIGNATURE-----