[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <8eaf2c6b79842e4b932b72ae3f402eaffe219c64.camel@kernel.org>
Date: Mon, 22 Jan 2024 16:37:28 -0500
From: Jeff Layton <jlayton@...nel.org>
To: NeilBrown <neilb@...e.de>
Cc: Lorenzo Bianconi <lorenzo@...nel.org>, linux-nfs@...r.kernel.org,
lorenzo.bianconi@...hat.com, kuba@...nel.org, chuck.lever@...cle.com,
horms@...nel.org, netdev@...r.kernel.org
Subject: Re: [PATCH v6 3/3] NFSD: add write_ports to netlink command
On Tue, 2024-01-23 at 08:35 +1100, NeilBrown wrote:
> On Tue, 23 Jan 2024, Jeff Layton wrote:
> > On Sat, 2024-01-20 at 18:33 +0100, Lorenzo Bianconi wrote:
> > > Introduce write_ports netlink command. For listener-set, userspace is
> > > expected to provide a NFS listeners list it wants to enable (all the
> > > other ports will be closed).
> > >
> >
> > Ditto here. This is a change to a declarative interface, which I think
> > is a better way to handle this, but we should be aware of the change.
>
> I agree it is better, and thanks for highlighting the change.
>
> > > + /* 2- remove stale listeners */
> >
> >
> > The old portlist interface was weird, in that it was only additive. You
> > couldn't use it to close a listening socket (AFAICT). We may be able to
> > support that now with this interface, but we'll need to test that case
> > carefully.
>
> Do we ever want/need to remove listening sockets?
> Normal practice when making any changes is to stop and restart where
> "stop" removes all sockets, unexports all filesystems, disables all
> versions.
> I don't exactly object to supporting fine-grained changes, but I suspect
> anything that is not used by normal service start will hardly ever be
> used in practice, so will not be tested.
>
> So if it is easiest to support reverting previous configuration (as it
> probably is for version setting), then do so. But if there is any
> complexity (as maybe there is with listening sockets), then don't
> add complexity that won't be used.
>
I completely agree here. It's probably simplest to just prevent this for
now unless and until there is some need for it.
--
Jeff Layton <jlayton@...nel.org>
Powered by blists - more mailing lists