linux-toradex.git/fs/lockd, branch v3.0.74

NLM: Ensure that we resend all pending blocking locks after a reclaim

2013-02-28T14:32:25+00:00

commit 666b3d803a511fbc9bc5e5ea8ce66010cf03ea13 upstream.

Currently, nlmclnt_lock will break out of the for(;;) loop when
the reclaimer wakes up the blocking lock thread by setting
nlm_lck_denied_grace_period. This causes the lock request to fail
with an ENOLCK error.
The intention was always to ensure that we resend the lock request
after the grace period has expired.

Reported-by: Wangyuan Zhang 
Signed-off-by: Trond Myklebust 
Signed-off-by: Greg Kroah-Hartman

Revert: lockd: use rpc client's cl_nodename for id encoding

2012-10-28T17:02:11+00:00

This reverts 12d63702c53bc2230dfc997e91ca891f39cb6446 which was commit
303a7ce92064c285a04c870f2dc0192fdb2968cb upstream.

Taking hostname from uts namespace if not safe, because this cuold be
performind during umount operation on child reaper death. And in this case
current->nsproxy is NULL already.

Signed-off-by: Greg Kroah-Hartman 
Cc: Stanislav Kinsbursky 
Cc: Trond Myklebust

NLM: nlm_lookup_file() may return NLMv4-specific error codes

2012-10-28T17:02:11+00:00

commit cd0b16c1c3cda12dbed1f8de8f1a9b0591990724 upstream.

If the filehandle is stale, or open access is denied for some reason,
nlm_fopen() may return one of the NLMv4-specific error codes nlm4_stale_fh
or nlm4_failed. These get passed right through nlm_lookup_file(),
and so when nlmsvc_retrieve_args() calls the latter, it needs to filter
the result through the cast_status() machinery.

Failure to do so, will trigger the BUG_ON() in encode_nlm_stat...

Signed-off-by: Trond Myklebust 
Reported-by: Larry McVoy 
Signed-off-by: J. Bruce Fields 
Signed-off-by: Greg Kroah-Hartman

lockd: use rpc client's cl_nodename for id encoding

2012-10-21T16:17:09+00:00

commit 303a7ce92064c285a04c870f2dc0192fdb2968cb upstream.

Taking hostname from uts namespace if not safe, because this cuold be
performind during umount operation on child reaper death. And in this case
current->nsproxy is NULL already.

Signed-off-by: Stanislav Kinsbursky 
Signed-off-by: Trond Myklebust 
Signed-off-by: Greg Kroah-Hartman

lockd: fix the endianness bug

2012-04-27T16:51:18+00:00

commit e847469bf77a1d339274074ed068d461f0c872bc upstream.

comparing be32 values for < is not doing the right thing...

Signed-off-by: Al Viro 
Cc: "J. Bruce Fields" 
Cc: Trond Myklebust 
Signed-off-by: Greg Kroah-Hartman

lockd: fix arg parsing for grace_period and timeout.

2012-04-02T16:27:21+00:00

commit de5b8e8e047534aac6bc9803f96e7257436aef9c upstream.

If you try to set grace_period or timeout via a module parameter
to lockd, and do this on a big-endian machine where

   sizeof(int) != sizeof(unsigned long)

it won't work.  This number given will be effectively shifted right
by the difference in those two sizes.

So cast kp->arg properly to get correct result.

Signed-off-by: NeilBrown 
Signed-off-by: J. Bruce Fields 
Signed-off-by: Greg Kroah-Hartman

NLM: Don't hang forever on NLM unlock requests

2011-06-15T15:24:27+00:00

If the NLM daemon is killed on the NFS server, we can currently end up
hanging forever on an 'unlock' request, instead of aborting. Basically,
if the rpcbind request fails, or the server keeps returning garbage, we
really want to quit instead of retrying.

Tested-by: Vasily Averin 
Signed-off-by: Trond Myklebust 
Cc: stable@kernel.org

NLM: Fix "kernel BUG at fs/lockd/host.c:417!" or ".../host.c:283!"

2011-01-25T20:24:47+00:00

Nick Bowler  reports:

> We were just having some NFS server troubles, and my client machine
> running 2.6.38-rc1+ (specifically, commit 2b1caf6ed7b888c95) crashed
> hard (syslog output appended to this mail).
>
> I'm not sure what the exact timeline was or how to reproduce this,
> but the server was rebooted during all this.  Since I've never seen
> this happen before, it is possibly a regression from previous kernel
> releases.  However, I recently updated my nfs-utils (on the client) to
> version 1.2.3, so that might be related as well.

  [ BUG output redacted ]

When done searching, the for_each_host loop in next_host_state() falls
through and returns the final host on the host chain without bumping
it's reference count.

Since the host's ref count is only one at that point, releasing the
host in nlm_host_rebooted() attempts to destroy the host prematurely,
and therefore hits a BUG().

Likely, the original intent of the for_each_host behavior in
next_host_state() was to handle the case when the host chain is empty.
Searching the chain and finding no suitable host to return needs to be
handled as well.

Defensively restructure next_host_state() always to return NULL when
the loop falls through.

Introduced by commit b10e30f6 "lockd: reorganize nlm_host_rebooted".

Cc: J. Bruce Fields 
Signed-off-by: Chuck Lever 
Signed-off-by: Trond Myklebust

lockd: double unlock in next_host_state()

2011-01-04T18:10:37+00:00

We unlock again after we goto out.

Signed-off-by: Dan Carpenter 
Signed-off-by: Trond Myklebust

lockd: Remove src_sap and src_len from nlm_lookup_host_info struct

2010-12-16T17:37:27+00:00

Clean up.

The contents of the src_sap field is not used in nlm_alloc_host().

Signed-off-by: Chuck Lever 
Signed-off-by: Trond Myklebust