Re: [RFC PATCH 1/2] common/nfs: add management helpers

Re: [RFC PATCH 1/2] common/nfs: add management helpers

[Christoph Hellwig]

On Tue, Sep 08, 2026 at 07:22:26AM -0700, Darrick J. Wong wrote:
> > +# Start rpcbind if it is not already running.
> > +_start_rpcbind()
> > +{
> > +	rpcinfo -p localhost > /dev/null 2>&1 && return 0
> > +	rpcbind 2>> $seqres.full || _notrun "Cannot start rpcbind"
> > +	/usr/sbin/rpc.statd 2>> $seqres.full || _notrun "Cannot start rpc.statd"
> > +	/usr/sbin/rpc.idmapd 2>> $seqres.full || _notrun "Cannot start rpc.idmapd"
> > +	/usr/sbin/nfsdcld 2>> $seqres.full || _notrun "Cannot start nfsdcld"
> 
> Aren't these daemons usually configured as system services?
> 
> # service rpcbind start
> 
> etc?

They usually are, but doing that as part of a test feels wrong.
Adding the relevant maintainers and list.

> 
> > +}
> > +
> > +# Stop rpcbind.
> > +_stop_rpcbind()
> > +{
> > +	pkill rpcbind 2>/dev/null
> > +}
> > +
> > +# Start the NFS server if not already running.
> > +_start_nfsd()
> > +{
> > +	rpcinfo -p localhost 2>/dev/null | grep -q nfs && return 0
> > +	rpc.nfsd 2>> $seqres.full || _notrun "Cannot start rpc.nfsd"
> > +	rpc.mountd 2>> $seqres.full || _notrun "Cannot start rpc.mountd"
> > +}
> > +
> > +# Stop the NFS server.
> > +_stop_nfsd()
> > +{
> > +	rpc.nfsd 0 2>/dev/null
> > +	pkill rpc.mountd 2>/dev/null
> 
> If the system under test has nfs filesystems mounted, won't killing
> those daemons also break the mounts?
> 
> I think that might break testing of nfs itself, and nfs-booted testing
> nodes as well?

Possibly.  I guess if we want to save we need to launch a container
or at least a network namespace this is bound too. 

Re: [RFC PATCH 1/2] common/nfs: add management helpers

[Darrick J. Wong]

On Tue, Sep 08, 2026 at 11:12:28PM -0700, Christoph Hellwig wrote:
> On Tue, Sep 08, 2026 at 07:22:26AM -0700, Darrick J. Wong wrote:
> > > +# Start rpcbind if it is not already running.
> > > +_start_rpcbind()
> > > +{
> > > +	rpcinfo -p localhost > /dev/null 2>&1 && return 0
> > > +	rpcbind 2>> $seqres.full || _notrun "Cannot start rpcbind"
> > > +	/usr/sbin/rpc.statd 2>> $seqres.full || _notrun "Cannot start rpc.statd"
> > > +	/usr/sbin/rpc.idmapd 2>> $seqres.full || _notrun "Cannot start rpc.idmapd"
> > > +	/usr/sbin/nfsdcld 2>> $seqres.full || _notrun "Cannot start nfsdcld"
> > 
> > Aren't these daemons usually configured as system services?
> > 
> > # service rpcbind start
> > 
> > etc?
> 
> They usually are, but doing that as part of a test feels wrong.
> Adding the relevant maintainers and list.

<nod> I guess for this test we actually want to launch our own nfs
daemons in a separate pid / network namespace so that they don't
interfere with nfs operations outside of the test (e.g. testing nfs
itself, nfsboot, etc)

> > 
> > > +}
> > > +
> > > +# Stop rpcbind.
> > > +_stop_rpcbind()
> > > +{
> > > +	pkill rpcbind 2>/dev/null
> > > +}
> > > +
> > > +# Start the NFS server if not already running.
> > > +_start_nfsd()
> > > +{
> > > +	rpcinfo -p localhost 2>/dev/null | grep -q nfs && return 0
> > > +	rpc.nfsd 2>> $seqres.full || _notrun "Cannot start rpc.nfsd"
> > > +	rpc.mountd 2>> $seqres.full || _notrun "Cannot start rpc.mountd"
> > > +}
> > > +
> > > +# Stop the NFS server.
> > > +_stop_nfsd()
> > > +{
> > > +	rpc.nfsd 0 2>/dev/null
> > > +	pkill rpc.mountd 2>/dev/null
> > 
> > If the system under test has nfs filesystems mounted, won't killing
> > those daemons also break the mounts?
> > 
> > I think that might break testing of nfs itself, and nfs-booted testing
> > nodes as well?
> 
> Possibly.  I guess if we want to save we need to launch a container
> or at least a network namespace this is bound too. 

Agreed, some isolation from the main system is necessary.

--D

Re: [RFC PATCH 1/2] common/nfs: add management helpers

[Carlos Maiolino]

On Wed, Sep 09, 2026 at 09:13:42AM -0700, Darrick J. Wong wrote:
> On Tue, Sep 08, 2026 at 11:12:28PM -0700, Christoph Hellwig wrote:
> > On Tue, Sep 08, 2026 at 07:22:26AM -0700, Darrick J. Wong wrote:
> > > > +# Start rpcbind if it is not already running.
> > > > +_start_rpcbind()
> > > > +{
> > > > +	rpcinfo -p localhost > /dev/null 2>&1 && return 0
> > > > +	rpcbind 2>> $seqres.full || _notrun "Cannot start rpcbind"
> > > > +	/usr/sbin/rpc.statd 2>> $seqres.full || _notrun "Cannot start rpc.statd"
> > > > +	/usr/sbin/rpc.idmapd 2>> $seqres.full || _notrun "Cannot start rpc.idmapd"
> > > > +	/usr/sbin/nfsdcld 2>> $seqres.full || _notrun "Cannot start nfsdcld"
> > > 
> > > Aren't these daemons usually configured as system services?
> > > 
> > > # service rpcbind start
> > > 
> > > etc?
> > 
> > They usually are, but doing that as part of a test feels wrong.
> > Adding the relevant maintainers and list.
> 
> <nod> I guess for this test we actually want to launch our own nfs
> daemons in a separate pid / network namespace so that they don't
> interfere with nfs operations outside of the test (e.g. testing nfs
> itself, nfsboot, etc)
> 
> > > 
> > > > +}
> > > > +
> > > > +# Stop rpcbind.
> > > > +_stop_rpcbind()
> > > > +{
> > > > +	pkill rpcbind 2>/dev/null
> > > > +}
> > > > +
> > > > +# Start the NFS server if not already running.
> > > > +_start_nfsd()
> > > > +{
> > > > +	rpcinfo -p localhost 2>/dev/null | grep -q nfs && return 0
> > > > +	rpc.nfsd 2>> $seqres.full || _notrun "Cannot start rpc.nfsd"
> > > > +	rpc.mountd 2>> $seqres.full || _notrun "Cannot start rpc.mountd"
> > > > +}
> > > > +
> > > > +# Stop the NFS server.
> > > > +_stop_nfsd()
> > > > +{
> > > > +	rpc.nfsd 0 2>/dev/null
> > > > +	pkill rpc.mountd 2>/dev/null
> > > 
> > > If the system under test has nfs filesystems mounted, won't killing
> > > those daemons also break the mounts?
> > > 
> > > I think that might break testing of nfs itself, and nfs-booted testing
> > > nodes as well?
> > 
> > Possibly.  I guess if we want to save we need to launch a container
> > or at least a network namespace this is bound too. 
> 
> Agreed, some isolation from the main system is necessary.

Perhaps couldn't we just:
	- start nfs server if not started
	- only stop nfs server if we started it

And just take advantage of the server running if one is already there?

> 
> --D
> 

Re: [RFC PATCH 1/2] common/nfs: add management helpers

[Jeff Layton]

On Tue, 2026-09-08 at 23:12 -0700, Christoph Hellwig wrote:
> On Tue, Sep 08, 2026 at 07:22:26AM -0700, Darrick J. Wong wrote:
> > > +# Start rpcbind if it is not already running.
> > > +_start_rpcbind()
> > > +{
> > > +	rpcinfo -p localhost > /dev/null 2>&1 && return 0
> > > +	rpcbind 2>> $seqres.full || _notrun "Cannot start rpcbind"
> > > +	/usr/sbin/rpc.statd 2>> $seqres.full || _notrun "Cannot start rpc.statd"
> > > +	/usr/sbin/rpc.idmapd 2>> $seqres.full || _notrun "Cannot start rpc.idmapd"
> > > +	/usr/sbin/nfsdcld 2>> $seqres.full || _notrun "Cannot start nfsdcld"
> > 
> > Aren't these daemons usually configured as system services?
> > 
> > # service rpcbind start
> > 
> > etc?
> 
> They usually are, but doing that as part of a test feels wrong.
> Adding the relevant maintainers and list.
> 
> 

I don't see a problem with using the normal systemd services as long as
you're just doing a "start" instead of an "enable". That would be a lot
less likely to bitrot than these scripts.

> > > +}
> > > +
> > > +# Stop rpcbind.
> > > +_stop_rpcbind()
> > > +{
> > > +	pkill rpcbind 2>/dev/null
> > > +}
> > > +
> > > +# Start the NFS server if not already running.
> > > +_start_nfsd()
> > > +{
> > > +	rpcinfo -p localhost 2>/dev/null | grep -q nfs && return 0
> > > +	rpc.nfsd 2>> $seqres.full || _notrun "Cannot start rpc.nfsd"
> > > +	rpc.mountd 2>> $seqres.full || _notrun "Cannot start rpc.mountd"
> > > +}
> > > +
> > > +# Stop the NFS server.
> > > +_stop_nfsd()
> > > +{
> > > +	rpc.nfsd 0 2>/dev/null
> > > +	pkill rpc.mountd 2>/dev/null
> > 
> > If the system under test has nfs filesystems mounted, won't killing
> > those daemons also break the mounts?
> > 
> > I think that might break testing of nfs itself, and nfs-booted testing
> > nodes as well?
> 
> Possibly.  I guess if we want to save we need to launch a container
> or at least a network namespace this is bound too. 

Doing this in a container would be better and less likely to interfere
with other stuff running on the box. Our container isolation is still
not 100% perfect with nfsd (there is still a global mutex, etc.), but
we're getting closer.

-- 
Jeff Layton <jlayton@kernel.org>

Re: [RFC PATCH 0/2] quota evasion test and nfs helpers

[Jeff Layton]

On Mon, 2026-09-07 at 18:40 +0200, cem@kernel.org wrote:
> From: Carlos Maiolino <cem@kernel.org>
> 
> Hi folks.
> 
> I'm flagging these as RFC because I'd like an input in the approach I
> took here regarding how to setup a local nfs-server to reproduce the bug
> recently fixed on xfs quotas.
> 
> The issue is regarding how we checked the credentials before proceeding
> with quota enforcement / or not. And due the chgrp() being run through a
> NSF share, xfs used the wrong credentials allowing an user to evade
> quotas.
> 
> The TL;DR; for the approach is:
> 	- setup a xfs fs with an user belonging to two groups with group
> 	  quotas enforced
> 	- Setup a local nfs server/client and mount it locally through
> 	  loopback
> 	- use the user to fill in the share until it exceeds quota
> 	- change group of the file to the second group.
> 	- repeat a couple times until the second group quota is
> 	  exceeded.
> 
> I'm using the already existing user/groups. The tests uses exportfs directly
> instead of seeting up a exports file, and I added a few new helpers to
> start/stop nfsd and rpcbind. The latter I did as an attempt to make the test
> systemd-agnostic. It is working even if nfs-server systemd service is disabled,
> but I didn't try on a systemd-less OS.
> 
> While writing it I stumped on a weird issue that I'm not exactly sure
> how to fix (or if it's perhaps a bug on umount):
> 
> During cleanup(), I umount the share and unexport the it so the rest
> of the generic cleanup can take place, specially umounting the scratch
> fs There is some timing though required by umount() to properly cleanup
> internal kernel structures before it can be unexported. I honestly
> assumed umount() was synchronous (unless lazy umount) and once it returned
> it was "done". But for some reason I didn't dig into, I need to wait a
> bit between unmounting the share and unexporting it.
> I tried to wait until the mount was excluded from /proc/mounts but even
> after the mount is gone, something still holds the share a bit
> preventing it to be unexported. So I went with a 2 second sleep :)
> 

It may be that nfsd still has some state held here that is being
cleaned up. Chuck has a patchset in progress that may help this:

https://lore.kernel.org/linux-nfs/20260419-umount-kills-nfsv4-state-v9-0-0660bd06d2b6@oracle.com/


> Overall the test works, passing on a patched kernel or failing
> otherwise.
> 
> Comments? Flames? Stones?
> 
> Cheers.
> 
> Carlos Maiolino (2):
>   common/nfs: add management helpers
>   generic: add test for quota enforcement via a nfs share
> 
>  common/nfs            |  55 ++++++++++++++++++++++
>  tests/generic/803     | 106 ++++++++++++++++++++++++++++++++++++++++++
>  tests/generic/803.out |   2 +
>  3 files changed, 163 insertions(+)
>  create mode 100755 tests/generic/803
>  create mode 100644 tests/generic/803.out

-- 
Jeff Layton <jlayton@kernel.org>

Re: [RFC PATCH 1/2] common/nfs: add management helpers

[Carlos Maiolino]

On Thu, Sep 10, 2026 at 07:30:46AM -0400, Jeff Layton wrote:
> On Tue, 2026-09-08 at 23:12 -0700, Christoph Hellwig wrote:
> > On Tue, Sep 08, 2026 at 07:22:26AM -0700, Darrick J. Wong wrote:
> > > > +# Start rpcbind if it is not already running.
> > > > +_start_rpcbind()
> > > > +{
> > > > +	rpcinfo -p localhost > /dev/null 2>&1 && return 0
> > > > +	rpcbind 2>> $seqres.full || _notrun "Cannot start rpcbind"
> > > > +	/usr/sbin/rpc.statd 2>> $seqres.full || _notrun "Cannot start rpc.statd"
> > > > +	/usr/sbin/rpc.idmapd 2>> $seqres.full || _notrun "Cannot start rpc.idmapd"
> > > > +	/usr/sbin/nfsdcld 2>> $seqres.full || _notrun "Cannot start nfsdcld"
> > > 
> > > Aren't these daemons usually configured as system services?
> > > 
> > > # service rpcbind start
> > > 
> > > etc?
> > 
> > They usually are, but doing that as part of a test feels wrong.
> > Adding the relevant maintainers and list.
> > 
> > 
> 
> I don't see a problem with using the normal systemd services as long as
> you're just doing a "start" instead of an "enable". That would be a lot
> less likely to bitrot than these scripts.

My only concern regarding using systemd services is portability. I tried
to keep the test agnostic to the init system being used, but it indeed
would be way easier to put this into xfstests if we just accept this
will be a __not_run on systemd-less distros. Giving the majority of
people I know frequently running xfstests (including me) uses
systemd-based distros, this wouldn't be a problem for me personally...

> 
> > > > +}
> > > > +
> > > > +# Stop rpcbind.
> > > > +_stop_rpcbind()
> > > > +{
> > > > +	pkill rpcbind 2>/dev/null
> > > > +}
> > > > +
> > > > +# Start the NFS server if not already running.
> > > > +_start_nfsd()
> > > > +{
> > > > +	rpcinfo -p localhost 2>/dev/null | grep -q nfs && return 0
> > > > +	rpc.nfsd 2>> $seqres.full || _notrun "Cannot start rpc.nfsd"
> > > > +	rpc.mountd 2>> $seqres.full || _notrun "Cannot start rpc.mountd"
> > > > +}
> > > > +
> > > > +# Stop the NFS server.
> > > > +_stop_nfsd()
> > > > +{
> > > > +	rpc.nfsd 0 2>/dev/null
> > > > +	pkill rpc.mountd 2>/dev/null
> > > 
> > > If the system under test has nfs filesystems mounted, won't killing
> > > those daemons also break the mounts?
> > > 
> > > I think that might break testing of nfs itself, and nfs-booted testing
> > > nodes as well?
> > 
> > Possibly.  I guess if we want to save we need to launch a container
> > or at least a network namespace this is bound too. 
> 
> Doing this in a container would be better and less likely to interfere
> with other stuff running on the box. Our container isolation is still
> not 100% perfect with nfsd (there is still a global mutex, etc.), but
> we're getting closer.
> 
> -- 
> Jeff Layton <jlayton@kernel.org>
> 

Re: [RFC PATCH 1/2] common/nfs: add management helpers

[Jeff Layton]

On Thu, 2026-09-10 at 13:40 +0200, Carlos Maiolino wrote:
> On Thu, Sep 10, 2026 at 07:30:46AM -0400, Jeff Layton wrote:
> > On Tue, 2026-09-08 at 23:12 -0700, Christoph Hellwig wrote:
> > > On Tue, Sep 08, 2026 at 07:22:26AM -0700, Darrick J. Wong wrote:
> > > > > +# Start rpcbind if it is not already running.
> > > > > +_start_rpcbind()
> > > > > +{
> > > > > +	rpcinfo -p localhost > /dev/null 2>&1 && return 0
> > > > > +	rpcbind 2>> $seqres.full || _notrun "Cannot start rpcbind"
> > > > > +	/usr/sbin/rpc.statd 2>> $seqres.full || _notrun "Cannot start rpc.statd"
> > > > > +	/usr/sbin/rpc.idmapd 2>> $seqres.full || _notrun "Cannot start rpc.idmapd"
> > > > > +	/usr/sbin/nfsdcld 2>> $seqres.full || _notrun "Cannot start nfsdcld"
> > > > 
> > > > Aren't these daemons usually configured as system services?
> > > > 
> > > > # service rpcbind start
> > > > 
> > > > etc?
> > > 
> > > They usually are, but doing that as part of a test feels wrong.
> > > Adding the relevant maintainers and list.
> > > 
> > > 
> > 
> > I don't see a problem with using the normal systemd services as long as
> > you're just doing a "start" instead of an "enable". That would be a lot
> > less likely to bitrot than these scripts.
> 
> My only concern regarding using systemd services is portability. I tried
> to keep the test agnostic to the init system being used, but it indeed
> would be way easier to put this into xfstests if we just accept this
> will be a __not_run on systemd-less distros. Giving the majority of
> people I know frequently running xfstests (including me) uses
> systemd-based distros, this wouldn't be a problem for me personally...
> 

That's what I'd probably do. If someone wants to step up and do
something for non-systemd distros then they can have at it.

Alternately, you could use systemd and just fall back to what you're
doing now in the case where it's not present. My only fear there is
that the non-systemd cases would probably bitrot because no one would
use them.

That said, if you're doing all of this in a container then it shouldn't
matter much how it gets started.

> > 
> > > > > +}
> > > > > +
> > > > > +# Stop rpcbind.
> > > > > +_stop_rpcbind()
> > > > > +{
> > > > > +	pkill rpcbind 2>/dev/null
> > > > > +}
> > > > > +
> > > > > +# Start the NFS server if not already running.
> > > > > +_start_nfsd()
> > > > > +{
> > > > > +	rpcinfo -p localhost 2>/dev/null | grep -q nfs && return 0
> > > > > +	rpc.nfsd 2>> $seqres.full || _notrun "Cannot start rpc.nfsd"

If you do decide to go this route, note that rpc.nfsd is being
deprecated. We have a new tool for managing the server now called
"nfsdctl" that you probably want to use when possible.

> > > > > +	rpc.mountd 2>> $seqres.full || _notrun "Cannot start rpc.mountd"
> > > > > +}
> > > > > +
> > > > > +# Stop the NFS server.
> > > > > +_stop_nfsd()
> > > > > +{
> > > > > +	rpc.nfsd 0 2>/dev/null
> > > > > +	pkill rpc.mountd 2>/dev/null
> > > > 
> > > > If the system under test has nfs filesystems mounted, won't killing
> > > > those daemons also break the mounts?
> > > > 
> > > > I think that might break testing of nfs itself, and nfs-booted testing
> > > > nodes as well?
> > > 
> > > Possibly.  I guess if we want to save we need to launch a container
> > > or at least a network namespace this is bound too. 
> > 
> > Doing this in a container would be better and less likely to interfere
> > with other stuff running on the box. Our container isolation is still
> > not 100% perfect with nfsd (there is still a global mutex, etc.), but
> > we're getting closer.
> > 
> > -- 
> > Jeff Layton <jlayton@kernel.org>
> > 

-- 
Jeff Layton <jlayton@kernel.org>