linux-toradex.git/fs/nfsd/netns.h, branch v4.4.6

nfsd: New counter for generating client confirm verifier

2015-08-10T20:05:47+00:00

If using clientid_counter, it seems possible that gen_confirm could
generate the same verifier for the same client in some situations.

Add a new counter for client confirm verifier to make sure gen_confirm
generates a different verifier on each call for the same clientid.

Signed-off-by: Kinglong Mee 
Reviewed-by: Jeff Layton 
Signed-off-by: J. Bruce Fields

nfsd: add some comments to the nfsd4 object definitions

2014-08-05T20:09:20+00:00

Add some comments that describe what each of these objects is, and how
they related to one another.

Signed-off-by: Jeff Layton 
Signed-off-by: J. Bruce Fields

nfsd: protect clid and verifier generation with client_lock

2014-08-05T14:55:02+00:00

The clid counter is a global counter currently. Move it to be a per-net
property so that it can be properly protected by the nn->client_lock
instead of relying on the client_mutex.

The verifier generator is also potentially racy if there are two
simultaneous callers. Generate the verifier when we generate the clid
value, so it's also created under the client_lock. With this, there's
no need to keep two counters as they'd always be in sync anyway, so
just use the clientid_counter for both.

As Trond points out, what would be best is to eventually move this
code to use IDR instead of the hash tables. That would also help ensure
uniqueness, but that's probably best done as a separate project.

Signed-off-by: Jeff Layton 
Signed-off-by: J. Bruce Fields

nfsd: Move the open owner hash table into struct nfs4_client

2014-07-31T18:20:26+00:00

Preparation for removing the client_mutex.

Convert the open owner hash table into a per-client table and protect it
using the nfs4_client->cl_lock spin lock.

Signed-off-by: Trond Myklebust 
Signed-off-by: J. Bruce Fields

nfsd: NFSv4 lock-owners are not associated to a specific file

2014-07-10T00:54:58+00:00

Just like open-owners, lock-owners are associated with a name, a clientid
and, in the case of minor version 0, a sequence id. There is no association
to a file.

Signed-off-by: Trond Myklebust 
Reviewed-by: Christoph Hellwig 
Signed-off-by: J. Bruce Fields

nfsd: add a new /proc/fs/nfsd/max_connections file

2014-07-08T21:14:32+00:00

Currently, the maximum number of connections that nfsd will allow
is based on the number of threads spawned. While this is fine for a
default, there really isn't a clear relationship between the two.

The number of threads corresponds to the number of concurrent requests
that we want to allow the server to process at any given time. The
connection limit corresponds to the maximum number of clients that we
want to allow the server to handle. These are two entirely different
quantities.

Break the dependency on increasing threads in order to allow for more
connections, by adding a new per-net parameter that can be set to a
non-zero value. The default is still to base it on the number of threads,
so there should be no behavior change for anyone who doesn't use it.

Cc: Trond Myklebust 
Signed-off-by: Jeff Layton 
Signed-off-by: J. Bruce Fields

NFSD: Don't start lockd when only NFSv4 is running

2014-01-03T23:18:50+00:00

When starting without nfsv2 and nfsv3, nfsd does not need to start
lockd (and certainly doesn't need to fail because lockd failed to
register with the portmapper).

Reported-by: Gareth Williams 
Reviewed-by: Chuck Lever 
Signed-off-by: Kinglong Mee 
Signed-off-by: J. Bruce Fields

nfsd4: make del_recall_lru per-network-namespace

2013-04-04T17:25:16+00:00

If nothing else this simplifies the nfs4_state_shutdown_net logic a tad.

Signed-off-by: J. Bruce Fields

nfsd: make NFSd service structure allocated per net

2012-12-10T21:25:39+00:00

This patch makes main step in NFSd containerisation.

There could be different approaches to how to make NFSd able to handle
incoming RPC request from different network namespaces.  The two main
options are:

1) Share NFSd kthreads betwween all network namespaces.
2) Create separated pool of threads for each namespace.

While first approach looks more flexible, second one is simpler and
non-racy.  This patch implements the second option.

To make it possible to allocate separate pools of threads, we have to
make it possible to allocate separate NFSd service structures per net.

Signed-off-by: Stanislav Kinsbursky 
Signed-off-by: J. Bruce Fields

nfsd: make NFSd service boot time per-net

2012-12-10T21:25:38+00:00

This is simple: an NFSd service can be started at different times in
different network environments. So, its "boot time" has to be assigned
per net.

Signed-off-by: Stanislav Kinsbursky 
Signed-off-by: J. Bruce Fields