Re: [pseudo] [PATCH v2 0/2] close_range: implement it rather than return ENOSYS

Thanks!

>  That said, I couldn't see what pseudo_prefix_dir_fd actually helps with
> and I couldn't see why we need that...

I flagged it since it is held open and a close_range() sweep will wipe it
out. I hadn't checked if anything still reads it untill now. It seems like
it is just kept open and alive and the socket connection + fchdir() has
been moved to pseudo_localstate_dir_fd.

So, for the follow-up I'd purpose:

1/2: remove  pseudo_prefix_dir_fd
2/2: add pseudo_pwd_lck_fd and pseudo_util_evlog_fd to the descriptors
OP_CLOSEFROM and OP_CLOSE_RANGE step around

If you'd rather keep the fd, I'll drop the removal and add it to the
protected set in 2/2 instead.

Thanks for reviewing,
Baban.

On Thu, 16 Jul 2026 at 03:46, Richard Purdie <
[email protected]> wrote:

> On Thu, 2026-07-16 at 05:56 +0000, Babanpreet Singh wrote:
> > pseudo's close_range() wrapper has returned ENOSYS unconditionally since
> > 35433e6 ("ports/linux/guts: Add close_range wrapper for glibc 2.34").
> > systemd v260 deleted its /proc/self/fd fallback and treats a failure as
> > fatal, so under pseudo every fork+exec dies. That is [YOCTO #16339]. Full
> > story in v1:
> >
> >
> https://lore.kernel.org/yocto-patches/[email protected]/
>
> I had a quick look through this and it looks ok to me, thanks!
>
> > The v1 question about OP_CLOSEFROM stepping around five of pseudo's
> > descriptors while others exist (pseudo_prefix_dir_fd, pseudo_pwd_lck_fd,
> > pseudo_util_evlog_fd) still stands; happy to send a follow-up if that
> list
> > is short in both places.
>
> I had a quick look and yes, we should really be protecting these too.
>
> That said, I couldn't see what pseudo_prefix_dir_fd actually helps with
> and I couldn't see why we need that...
>
> Cheers,
>
> Richard
>