Re: [for-6.13 PATCH 10/19] nfs_common: move localio_lock to new lock member of nfs_uuid_t

NeilBrown
2024-11-12T23:13:28Z

On Wed, 13 Nov 2024, Chuck Lever wrote:
> On Tue, Nov 12, 2024 at 11:49:30AM +1100, NeilBrown wrote:
> > >
> > > If you have a specific idea for the mechanism we need to create to
> > > detect the v3 client reconnects to the server please let me know.
> > > Reusing or augmenting an existing thing is fine by me.
> >
> > nfs3_local_probe(struct nfs_server *server)
> > {
> > struct nfs_client *clp = server->nfs_client;
> > nfs_uuid_t *nfs_uuid = &clp->cl_uuid;
> >
> > if (nfs_uuid->connect_cookie != clp->cl_rpcclient->cl_xprt->connect_cookie)
> > nfs_local_probe_async()
> > }
> >
> > static void nfs_local_probe_async_work(struct work_struct *work)
> > {
> > struct nfs_client *clp = container_of(work, struct nfs_client,
> > cl_local_probe_work);
> > clp->cl_uuid.connect_cookie =
> > clp->cl_rpcclient->cl_xprt->connect_cookie;
> > nfs_local_probe(clp);
> > }
> >
> > Or maybe assign connect_cookie (which we have to add to uuid) inside
> > nfs_local_probe().
>
> The problem with per-connection checks is that a change in export
> security policy could disable LOCALIO rather persistently. The only
> way to recover, if checking is done only when a connection is
> established, is to remount or force a disconnect.
>
What export security policy specifically?
Do you mean changing from sec=sys to to sec=krb5i for example? This
would (hopefully) disable localio. Then changing the export back to
sec=sys would mean that localio would be possible again. I wonder how
the client copes with this. Does it work on a live mount without
remount? If so it would certainly make sense for the current security
setting to be cached in nfs_uidd and for a probe to be attempted
whenever that changed to sec=sys.

Thanks,
NeilBrown