On Wed, 19 Jun 2024, Mike Snitzer wrote:
> First use is in nfsd, to add access to a global nfsd_uuids list that
> will be used to identify local nfsd instances.
>
> nfsd_uuids is protected by nfsd_mutex or RCU read lock. List is
> composed of nfsd_uuid_t instances that are managed as nfsd creates
> them (per network namespace).
>
> nfsd_uuid_is_local() will be used to search all local nfsd for the
> client specified nfsd uuid.
>
> +
> +bool nfsd_uuid_is_local(const uuid_t *uuid)
> +{
> + const uuid_t *nfsd_uuid;
> +
> + rcu_read_lock();
> + nfsd_uuid = nfsd_uuid_lookup(uuid);
> + rcu_read_unlock();
> +
> + return !uuid_is_null(nfsd_uuid);
This uuid_is_null() test needs to be inside rcu_read_lock()ed region, or
it could deref a freed pointer.
But this seems to be a good place in the series to propose a bigger
change.
I think that every fs that is communicating with a localio server should
be registered with nfs_common even if that server isn't presently local.
On each IO it should check if the server is actually local, and act
accordingly. This might mean an extra pointer-deref but if that is
deemed a problem I'm sure we can find a solution.
Imagine an NFS server cluster where the server instances can migrate
around the cluster. Imagine there are also client side mounts on nodes
in this cluster. At any point a server might migrate onto a node which
is also a client of that server. We have customers who do this and for
that reason we make sure that loop-back mounts work and don't hit memory
deadlocks.
It would be good if these configurations could set the uuid for each
server instance and have it follow the server when it is migrated. So
if the server suddenly becomes local, we get to bypass the network code
for all IO.
Each uuid registered with nfs_common could be possibly linked to a
server, and to zero or more struct nfs_clients. When the server
registration changes, we walk the list of clients and tell them about
the change.
We could certainly add that functionality later if there seems to be too
much change already, but I think it would be good to add at some stage,
and maybe now is the right time.
Thanks,
NeilBrown
