NLM: Fix "kernel BUG at fs/lockd/host.c:417!" or ".../host.c:283!"
authorChuck Lever <chuck.lever@oracle.com>
Mon, 24 Jan 2011 20:50:26 +0000 (20:50 +0000)
committerTrond Myklebust <Trond.Myklebust@netapp.com>
Tue, 25 Jan 2011 20:24:47 +0000 (15:24 -0500)
commit80c30e8de4f81851b1f712bcc596e11d53bc76f1
tree1adf291e8fe056e4a799b5292d7ff32988ebdbff
parentf61f6da0d53842e849bab7f69e1431bd3de1136d
NLM: Fix "kernel BUG at fs/lockd/host.c:417!" or ".../host.c:283!"

Nick Bowler <nbowler@elliptictech.com> 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 <bfields@fieldses.org>
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
fs/lockd/host.c