All of lore.kernel.org
 help / color / mirror / Atom feed
From: Babanpreet Singh <bbnpreetsingh@gmail.com>
To: yocto-patches@lists.yoctoproject.org
Cc: Richard Purdie <richard.purdie@linuxfoundation.org>,
	Mark Hatle <mark.hatle@amd.com>,
	Mark Hatle <mark.hatle@kernel.crashing.org>,
	Paul Barker <paul@pbarker.dev>,
	Randy MacLeod <randy.macleod@windriver.com>,
	Vincent Haupert <mail@vincent-haupert.de>,
	Babanpreet Singh <bbnpreetsingh@gmail.com>
Subject: [pseudo] [PATCH 0/3] closefrom/close_range: protect every pseudo fd, then drop one
Date: Sat, 18 Jul 2026 04:37:47 +0000	[thread overview]
Message-ID: <20260718043750.7-1-bbnpreetsingh@gmail.com> (raw)
In-Reply-To: <20260716055633.7-1-bbnpreetsingh@gmail.com>

This is the follow-up from the close_range v2 thread [1], in
the order Richard suggested and Mark agreed with there: protect the
whole set of descriptors first, then remove pseudo_prefix_dir_fd on
top as a separately revertable commit. This has been built on top of v2.

While writing a probe to demonstrate the missing protection I noticed
something: the sweeps can close a descriptor that is already on the
protect list. The startfd computation uses >, so a protected
descriptor exactly equal to the running startfd is stepped around by
neither the by-hand loop nor the kernel sweep. My understanding is
that the default layout reliably produces that case: pseudo moves its
own descriptors up with F_DUPFD from PSEUDO_MIN_FD, so the local
state fd and connect_fd end up on consecutive numbers and connect_fd
lands exactly on the computed startfd. If I am reading the history
right, this means every closefrom(3) under pseudo has quietly closed
the server connection since 21ff2fb in 2021, and it went unnoticed
because the client transparently reconnects on the next operation.
Patch 1 addresses that. Patches 2 and 3 are the protection and removal we
discussed on the thread.

To convince myself I tested with a probe that locates pseudo's descriptors
via /proc/self/fd, sweeps with close_range(3, ~0U, 0) or closefrom(3),
and checks what survived. On the v2 baseline:

  pwd lock fd (lckpwdf held) : fd 3  closed by sweep
  PSEUDO_PREFIX dir fd       : fd 20 closed by sweep
  server socket fd           : fd 22 closed by sweep

After patch 1 the socket survives, after patch 2 everything survives,
and after patch 3 the prefix descriptor no longer exists to need
protecting.

[1] https://lore.kernel.org/yocto-patches/20260716055633.7-1-bbnpreetsingh@gmail.com/

Babanpreet Singh (3):
  pseudo_client: step fully past pseudo's own fds when computing startfd
  pseudo_client: step around all of pseudo's own fds in
    closefrom/close_range
  pseudo_client: remove the unused pseudo_prefix_dir_fd

 doc/program_flow |  1 -
 pseudo.h         |  1 +
 pseudo_client.c  | 90 ++++++++++++++----------------------------------
 pseudo_client.h  |  1 -
 4 files changed, 27 insertions(+), 66 deletions(-)

-- 
2.43.0



  parent reply	other threads:[~2026-07-18  4:38 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-15  5:41 [pseudo] [PATCH 0/2] close_range: implement it rather than return ENOSYS Baban
2026-07-15  5:41 ` [pseudo] [PATCH 1/2] ports/linux/guts: Implement close_range() instead of returning ENOSYS Baban
2026-07-15 19:51   ` [yocto-patches] " Paul Barker
2026-07-15  5:41 ` [pseudo] [PATCH 2/2] tests: Add close_range() test Baban
2026-07-15 20:03   ` [yocto-patches] " Paul Barker
2026-07-16  5:56 ` [pseudo] [PATCH v2 0/2] close_range: implement it rather than return ENOSYS Babanpreet Singh
2026-07-16  5:56   ` [pseudo] [PATCH v2 1/2] ports/linux/guts: Implement close_range() instead of returning ENOSYS Babanpreet Singh
2026-07-16  5:56   ` [pseudo] [PATCH v2 2/2] tests: Add close_range() test Babanpreet Singh
2026-07-16 10:46   ` [pseudo] [PATCH v2 0/2] close_range: implement it rather than return ENOSYS Richard Purdie
2026-07-16 15:46     ` Babanpreet Singh
2026-07-16 16:55       ` Richard Purdie
2026-07-16 23:16         ` [yocto-patches] " Mark Hatle
2026-07-16 23:08     ` Mark Hatle
2026-07-18  4:37   ` Babanpreet Singh [this message]
2026-07-18  4:37     ` [pseudo] [PATCH 1/3] pseudo_client: step fully past pseudo's own fds when computing startfd Babanpreet Singh
2026-07-18  4:37     ` [pseudo] [PATCH 2/3] pseudo_client: step around all of pseudo's own fds in closefrom/close_range Babanpreet Singh
2026-07-18  4:37     ` [pseudo] [PATCH 3/3] pseudo_client: remove the unused pseudo_prefix_dir_fd Babanpreet Singh

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260718043750.7-1-bbnpreetsingh@gmail.com \
    --to=bbnpreetsingh@gmail.com \
    --cc=mail@vincent-haupert.de \
    --cc=mark.hatle@amd.com \
    --cc=mark.hatle@kernel.crashing.org \
    --cc=paul@pbarker.dev \
    --cc=randy.macleod@windriver.com \
    --cc=richard.purdie@linuxfoundation.org \
    --cc=yocto-patches@lists.yoctoproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.