linux.git/fs/lockd, branch v2.6.25

Wrap buffers used for rpc debug printks into RPC_IFDEBUG

2008-02-21T23:42:29+00:00

Sorry for the noise, but here's the v3 of this compilation fix :)

There are some places, which declare the char buf[...] on the stack
to push it later into dprintk(). Since the dprintk sometimes (if the
CONFIG_SYSCTL=n) becomes an empty do { } while (0) stub, these buffers
cause gcc to produce appropriate warnings.

Wrap these buffers with RPC_IFDEBUG macro, as Trond proposed, to
compile them out when not needed.

Signed-off-by: Pavel Emelyanov 
Acked-by: J. Bruce Fields 
Signed-off-by: Trond Myklebust

NLM: don't requeue block if it was invalidated while GRANT_MSG was in flight

2008-02-10T23:09:36+00:00

It's possible for lockd to catch a SIGKILL while a GRANT_MSG callback
is in flight. If this happens we don't want lockd to insert the block
back into the nlm_blocked list.

This helps that situation, but there's still a possible race. Fixing
that will mean adding real locking for nlm_blocked.

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

NLM: don't reattempt GRANT_MSG when there is already an RPC in flight

2008-02-10T23:09:36+00:00

With the current scheme in nlmsvc_grant_blocked, we can end up with more
than one GRANT_MSG callback for a block in flight. Right now, we requeue
the block unconditionally so that a GRANT_MSG callback is done again in
30s. If the client is unresponsive, it can take more than 30s for the
call already in flight to time out.

There's no benefit to having more than one GRANT_MSG RPC queued up at a
time, so put it on the list with a timeout of NLM_NEVER before doing the
RPC call. If the RPC call submission fails, we requeue it with a short
timeout. If it works, then nlmsvc_grant_callback will end up requeueing
it with a shorter timeout after it completes.

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

NLM: have server-side RPC clients default to soft RPC tasks

2008-02-10T23:09:36+00:00

Now that it no longer does an RPC ping, lockd always ends up queueing
an RPC task for the GRANT_MSG callback. But, it also requeues the block
for later attempts. Since these are hard RPC tasks, if the client we're
calling back goes unresponsive the GRANT_MSG callbacks can stack up in
the RPC queue.

Fix this by making server-side RPC clients default to soft RPC tasks.
lockd requeues the block anyway, so this should be OK.

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

NLM: set RPC_CLNT_CREATE_NOPING for NLM RPC clients

2008-02-10T23:09:36+00:00

It's currently possible for an unresponsive NLM client to completely
lock up a server's lockd. The scenario is something like this:

1) client1 (or a process on the server) takes a lock on a file
2) client2 tries to take a blocking lock on the same file and
   awaits the callback
3) client2 goes unresponsive (plug pulled, network partition, etc)
4) client1 releases the lock

...at that point the server's lockd will try to queue up a GRANT_MSG
callback for client2, but first it requeues the block with a timeout of
30s. nlm_async_call will attempt to bind the RPC client to client2 and
will call rpc_ping. rpc_ping entails a sync RPC call and if client2 is
unresponsive it will take around 60s for that to time out. Once it times
out, it's already time to retry the block and the whole process repeats.

Once in this situation, nlmsvc_retry_blocked will never return until
the host starts responding again. lockd won't service new calls.

Fix this by skipping the RPC ping on NLM RPC clients. This makes
nlm_async_call return quickly when called.

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

NLM: tear down RPC clients in nlm_shutdown_hosts

2008-02-01T21:42:15+00:00

It's possible for a RPC to outlive the lockd daemon that created it, so
we need to make sure that all RPC's are killed when lockd is coming
down. When nlm_shutdown_hosts is called, kill off all RPC tasks
associated with the host. Since we need to wait until they have all gone
away, we might as well just shut down the RPC client altogether.

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

lockd: minor log message fix

2008-02-01T21:42:15+00:00

Wendy Cheng noticed that function name doesn't agree here.

Signed-off-by: J. Bruce Fields 
Cc: Wendy Cheng

knfsd: Support adding transports by writing portlist file

2008-02-01T21:42:13+00:00

Update the write handler for the portlist file to allow creating new
listening endpoints on a transport. The general form of the string is:



For example:

echo "tcp 2049" > /proc/fs/nfsd/portlist

This is intended to support the creation of a listening endpoint for
RDMA transports without adding #ifdef code to the nfssvc.c file.

Transports can also be removed as follows:

'-'

For example:

echo "-tcp 2049" > /proc/fs/nfsd/portlist

Attempting to add a listener with an invalid transport string results
in EPROTONOSUPPORT and a perror string of "Protocol not supported".

Attempting to remove an non-existent listener (.e.g. bad proto or port)
results in ENOTCONN and a perror string of
"Transport endpoint is not connected"

Signed-off-by: Tom Tucker 
Acked-by: Neil Brown 
Reviewed-by: Chuck Lever 
Reviewed-by: Greg Banks 
Signed-off-by: J. Bruce Fields

svc: Add svc API that queries for a transport instance

2008-02-01T21:42:13+00:00

Add a new svc function that allows a service to query whether a
transport instance has already been created. This is used in lockd
to determine whether or not a transport needs to be created when
a lockd instance is brought up.

Specifying 0 for the address family or port is effectively a wild-card,
and will result in matching the first transport in the service's list
that has a matching class name.

Signed-off-by: Tom Tucker 
Acked-by: Neil Brown 
Reviewed-by: Chuck Lever 
Reviewed-by: Greg Banks 
Signed-off-by: J. Bruce Fields

svc: Make close transport independent

2008-02-01T21:42:11+00:00

Move sk_list and sk_ready to svc_xprt. This involves close because these
lists are walked by svcs when closing all their transports. So I combined
the moving of these lists to svc_xprt with making close transport independent.

The svc_force_sock_close has been changed to svc_close_all and takes a list
as an argument. This removes some svc internals knowledge from the svcs.

This code races with module removal and transport addition.

Thanks to Simon Holm Thøgersen for a compile fix.

Signed-off-by: Tom Tucker 
Acked-by: Neil Brown 
Reviewed-by: Chuck Lever 
Reviewed-by: Greg Banks 
Signed-off-by: J. Bruce Fields 
Cc: Simon Holm Thøgersen