On Wed, Feb 05, 2025 at 10:00:48AM -0800, Darrick J. Wong wrote:
> On Wed, Feb 05, 2025 at 11:37:00AM +1100, Dave Chinner wrote:
> > On Tue, Feb 04, 2025 at 01:26:13PM -0800, Darrick J. Wong wrote:
> > > From: Darrick J. Wong <djwong@xxxxxxxxxx>
> > >
> > > As mentioned in the previous patch, trying to isolate processes from
> > > separate test instances through the use of distinct Unix process
> > > sessions is annoying due to the many complications with signal handling.
> > >
> > > Instead, we could just use nsexec to run the test program with a private
> > > pid namespace so that each test instance can only see its own processes;
> > > and private mount namespace so that tests writing to /tmp cannot clobber
> > > other tests or the stuff running on the main system.
> > >
> > > However, it's not guaranteed that a particular kernel has pid and mount
> > > namespaces enabled. Mount (2.4.19) and pid (2.6.24) namespaces have
> > > been around for a long time, but there's no hard requirement for the
> > > latter to be enabled in the kernel. Therefore, this bugfix slips
> > > namespace support in alongside the session id thing.
> > >
> > > Declaring CONFIG_PID_NS=n a deprecated configuration and removing
> > > support should be a separate conversation, not something that I have to
> > > do in a bug fix to get mainline QA back up.
> > >
> > > Cc: <fstests@xxxxxxxxxxxxxxx> # v2024.12.08
> > > Fixes: 8973af00ec212f ("fstests: cleanup fsstress process management")
> > > Signed-off-by: "Darrick J. Wong" <djwong@xxxxxxxxxx>
> > > ---
> > > check | 34 +++++++++++++++++++++++-----------
> > > common/rc | 12 ++++++++++--
> > > src/nsexec.c | 18 +++++++++++++++---
> > > tests/generic/504 | 15 +++++++++++++--
> > > tools/run_seq_pidns | 28 ++++++++++++++++++++++++++++
> > > 5 files changed, 89 insertions(+), 18 deletions(-)
> > > create mode 100755 tools/run_seq_pidns
> >
> > Same question as for session ids - is this all really necessary (or
> > desired) if check-parallel executes check in it's own private PID
> > namespace?
> >
> > If so, then the code is fine apart from the same nit about
> > tools/run_seq_pidns - call it run_pidns because this helper will
> > also be used by check-parallel to run check in it's own private
> > mount and PID namespaces...
>
> I prefer to name it tools/run_privatens since it creates more than just
> a pid namespace.
I'm fine with that. It was only the "seq" part of the name that
triggered me.
> At some point we might even decide to privatize more
> namespaces (e.g. do we want a private network namespace for nfs?) and I
> don't want this to become lsfmmbpfbbq'd, as it were.
*nod*
-Dave.
--
Dave Chinner
david@xxxxxxxxxxxxx
