]> git.baikalelectronics.ru Git - kernel.git/commit
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)
commit9f3b02b913de91753114ae56c55a3a722638f287
tree1adf291e8fe056e4a799b5292d7ff32988ebdbff
parent81189df95bab9e654a09c3d3ca420cfcd8cb6f49
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 888e422a1fbd9fb87) 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 865bd2b7 "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