Bug 235712 - Kernel Bug fs/lockd/host.c
Summary: Kernel Bug fs/lockd/host.c
Keywords:
Status: CLOSED INSUFFICIENT_DATA
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: kernel
Version: 4.0
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
: ---
Assignee: Jeff Layton
QA Contact: Martin Jenner
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2007-04-09 19:19 UTC by Jim Summers
Modified: 2007-11-30 22:07 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2007-05-03 14:06:41 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
Log Messages right before the panic (5.80 KB, text/plain)
2007-04-09 19:19 UTC, Jim Summers
no flags Details

Description Jim Summers 2007-04-09 19:19:22 UTC
Description of problem:
The server panicked and after recovery the logs had messages regarding a bug
in fs/lockd/host.c line 252

Version-Release number of selected component (if applicable):
2.6.9-42.0.3.ELsmp


How reproducible:
It has happened twice now in about a month and a half span.

Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:

Attached file has the kernel messages before the 5 second panic.

Comment 1 Jim Summers 2007-04-09 19:19:22 UTC
Created attachment 152008 [details]
Log Messages right before the panic

Comment 2 Jeff Layton 2007-04-26 16:55:05 UTC
In taking a look at this case, it looks like the machine paniced due to this:

        BUG_ON(atomic_read(&host->h_count) < 0);

So the h_count here was too low at the time this function was called. The big
question is why. Unfortunately, it's hard to tell much from the oops here. What
can you tell me about the conditions under which this is occuring? Would it be
possible to get a crash dump?



Comment 3 Jim Summers 2007-04-27 02:51:39 UTC
The first time it happened, the main campus's IT department was having a big
outage of network services.  So I had written it off to some severe delay in
name resolution or something.  

But this last time, it seemed to be a regular day and then all of a sudden the
calls started coming in and when I got to the console it had panicked.  

Setup is nothing out of the ordinary.  Redhat server, fedora 5 clients, a few
OS/X machines.  

What does h_count keep track of?  Maybe that will give me a clue to some more
info I can provide.

I looked in /var/crash and did not see any files.  Are they saved somewhere else?

Thanks for your time and efforts.


Comment 4 Jeff Layton 2007-04-27 11:33:05 UTC
h_count is a reference count for the nlm_host structure. The kernel crashed
because after it went to decrement this count, it was less than 0, and so it
should not have been being used in the first place. This may mean that we have a
case of too many "releases" and not enough "gets" on this struct, or it may mean
some sort of memory corruption is occuring. Unfortunately, I can't tell much
from just the oops messages here. I've seen some upstream reports of panics that
look similar to this, but nothing that points me to whether they were ever resolved.

If you can get a core, that may help answer some questions. Our support people
should be able to help you do this. There are also some kbase articles on how to
set up diskdump and netdump. It would also be good to open a support case anyway
so that we can track this as an actual customer issue internally.

If you do so, reference this BZ case number so they're aware of it.


Comment 5 Jeff Layton 2007-05-02 13:36:54 UTC
Setting to needinfo until we can get some more info on how this is reproduced,
or a vmcore...


Comment 6 Jim Summers 2007-05-03 13:59:36 UTC
Sounds good here.

I am not sure I will be able to provide much more info.  I have since upgraded
to a newer kernel.  This is on a production machine and I can't really shutdown
for testing and such.

Thanks

Comment 7 Jeff Layton 2007-05-03 14:06:41 UTC
Fair enough. I've not heard of anyone else hitting this issue and it sounds like
you've worked around it by using a different kernel. I'm going to close this
case with a resolution of INSUFFICIENT_DATA. If you find you're able to
reproduce it (and optimally, get a vmcore), then please reopen this case and
I'll have another look.



Note You need to log in before you can comment on or make changes to this bug.