Bug 173364 - Kernel panic - not syncing: bad locking
Kernel panic - not syncing: bad locking
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Steve Dickson
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-11-16 11:45 EST by Bill Nottingham
Modified: 2014-03-16 22:56 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-03-06 12:39:02 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
proposed patch (1.21 KB, patch)
2005-11-17 16:51 EST, Steve Dickson
no flags Details | Diff
Upstream patch (2.01 KB, patch)
2005-11-18 06:46 EST, Steve Dickson
no flags Details | Diff

  None (edit)
Description Bill Nottingham 2005-11-16 11:45:43 EST
Description of problem:

I ran the beehive client. The kernel paniced.

Version-Release number of selected component (if applicable):

2.6.14-1.166<something>

Call trace is:

panic
kernel_text_address
show_trace
dump_stack
spin_bug
_raw_spin_lock
:nfs:nfs_zap_caches
:nfs:nfs_update_inode
:nfs:nfs_post_op_update_inode
nfs:nfs3_proc_remove
__link_path_walk
avc_has_perm
lock-kernel
:nfs:nfs_unlink
vfs_unlink
sys_unlink
syscall_trace_enter
syscall_trace_leave
tracesys
tracesys
Comment 1 Bill Nottingham 2005-11-16 11:51:26 EST
OK, copying by hand:

Call Trace:<ffffffff8013a7b1>{panic+133} <ffffffff8014dfad>{kernel_text_address+28}
<fffffff80110302>{show_trace+505} <ffffffff8011036e>{dump_stack+14}
<ffffffff8021df11>{spin_bug+222} <ffffffff8021e1fa>{_raw_spin_lock+58}
<ffffffff884199b2>{:nfs:nfs_zap_caches+40}
<ffffffff8841a1ec>{:nfs:nfs_update_inode+1131}
<ffffffff8841a2a2>{:nfs:nfs_post_op_update_inode+68}
<ffffffff8842303c>{:nfs:nfs3_proc_remove+197}
<ffffffff8019c9ce>{__link_path_walk+378}
<ffffffff801efa7e>{avc_has_perm+70} <ffffffff803696e4>{lock_kernel+45}
<ffffffff88417b39>{:nfs:nfs_unlink+349} <ffffffff819e4a2>{vfs_unlink+452}
<ffffffff8019ed58>{sys_unlink+214} <ffffffff801119ea>{syscall_trace_enter+217}
<ffffffff80111a27>{syscall_trace_leave+55} <ffffffff8010ebdc>{tracesys+113}
<ffffffff8010ec3c>{tracesys+209}
Comment 2 Bill Nottingham 2005-11-16 11:53:15 EST
Version is 2.6.14-1.1665_FC5
Comment 3 Bill Nottingham 2005-11-16 12:08:36 EST
Still happens with 1682.
Comment 4 Steve Dickson 2005-11-17 16:51:40 EST
Created attachment 121206 [details]
proposed patch
Comment 6 Steve Dickson 2005-11-18 06:46:55 EST
Created attachment 121221 [details]
Upstream patch

Here is the upstream patch for this problem....
Comment 7 Dave Jones 2005-11-20 15:29:52 EST
applied to CVS, will be in all post 1698 kernels.

Thanks Steve.
Comment 8 Bill Nottingham 2005-11-21 16:08:09 EST
This doesn't panic, but it does produce the following errors:

nfs_update_inode: inode 31385370 mode changed, 0042775 to 0002775
nfs_update_inode: inode number mismatch
expected (0:16/0x1dee71a), got (0:16/0x1dee719)
nfs_update_inode: inode number mismatch
expected (0:16/0x1dee71a), got (0:16/0xf85f85)
nfs_update_inode: inode number mismatch
expected (0:16/0x1dee71a), got (0:16/0x1dee719)
nfs_update_inode: inode number mismatch
expected (0:16/0x1dee71a), got (0:16/0x1e5f27)
nfs_update_inode: inode number mismatch
expected (0:16/0x1dee71a), got (0:16/0x1dee719)
nfs_update_inode: inode 31385370 mode changed, 0042775 to 0002775
nfs_update_inode: inode number mismatch
expected (0:16/0x1dee71a), got (0:16/0x1dee719)
nfs_update_inode: inode 31385370 mode changed, 0042775 to 0002775
nfs_update_inode: inode number mismatch
expected (0:16/0x1dee71a), got (0:16/0x1e5f27)
nfs_update_inode: inode number mismatch
expected (0:16/0x1dee71a), got (0:16/0x1dee719)
nfs_update_inode: inode 31385370 mode changed, 0042775 to 0002775
nfs_update_inode: inode number mismatch
expected (0:16/0x1dee71a), got (0:16/0x1e5f27)
nfs_update_inode: inode number mismatch
expected (0:16/0x1dee71a), got (0:16/0x0)
nfs_update_inode: inode 31385370 mode changed, 0042775 to 0002775
nfs_update_inode: inode number mismatch
expected (0:16/0x1dee71a), got (0:16/0x100000000000000)
nfs_update_inode: inode number mismatch
expected (0:16/0x1dee71a), got (0:16/0x100000000000000)
nfs_update_inode: inode number mismatch
expected (0:16/0x1dee71a), got (0:16/0x846922)
nfs_update_inode: inode number mismatch
expected (0:16/0x1dee71a), got (0:16/0x1dee719)
nfs_update_inode: inode number mismatch
expected (0:16/0x1dee71a), got (0:16/0x0)
nfs_update_inode: inode number mismatch
expected (0:16/0x1dee71a), got (0:16/0x1dee719)
Comment 9 Dave Jones 2005-12-01 01:47:16 EST
still a problem ?
Comment 10 Bill Nottingham 2005-12-02 12:14:04 EST
Still have the inode number mismatch messages (as of 1725), yes.
Comment 11 Steve Dickson 2005-12-12 10:10:21 EST
Well there were two problems here... on was the panic and
the second was the "nfs_update_inode: inode number mismatch"

We've fixed the first one and the second one is more of a
warning that anything... its saying that the cached inode
number does not match the the inode number the server just
gave out. which is probably is a more of server problem than
a client one....

Does the inode message happen alot?
Comment 12 Bill Nottingham 2005-12-12 13:59:58 EST
Happens consistently with this usage case, doesn't seem to happen at all
otherwise. *shrug*
Comment 13 Steve Dickson 2006-01-03 14:22:41 EST
Lets close the bug and Bill open another one about the constant warning messages

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