Bug 467669 - kernel panic related to autofs4_catatonic_mode when stopping autofs
Summary: kernel panic related to autofs4_catatonic_mode when stopping autofs
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: kernel
Version: 4.7
Hardware: All
OS: Linux
medium
medium
Target Milestone: rc
: ---
Assignee: Ian Kent
QA Contact: Martin Jenner
URL:
Whiteboard:
Depends On: 460083
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-10-20 05:21 UTC by Michael Kearey
Modified: 2018-10-20 03:21 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-05-18 19:30:42 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2009:1024 0 normal SHIPPED_LIVE Important: Red Hat Enterprise Linux 4.8 kernel security and bug fix update 2009-05-18 14:57:26 UTC

Description Michael Kearey 2008-10-20 05:21:27 UTC
Description of problem:

kernel panic on RHEL4 when restarting autofs5


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


How reproducible:
60%

Steps to Reproduce:
Using RHEL4 WS with the latest kernel (kernel-smp-2.6.9-78.0.5.EL) and autofs (autofs5-5.0.1-0.rc2.88) rpms, I can reliably crash (read "kernel panic") the O
S.  
To crash,
1) open a couple of terminals (I logged on to tty1 and tty2)
2) in one terminal run "while :; do ls -lR /autofs/point/mount/* ; done"
3) in the other run "while :; do service autofs5 restart; done"
4) profit!

While this is a contrived scenario we noticed the panic on a couple of cluster nodes (run RHEL 4u7 WS) when they didn't pick up some new autofs map entries. 
 Service autofs5 reload didn't help so I did a service autofs5 restart and panics soon followed.


  
Actual results:
kernel panic with following backtrace:

crash> bt
PID: 23840  TASK: 101205e1030       CPU: 0   COMMAND: "automount5"
 #0 [1011a693d20] start_disk_dump at ffffffffa01b1377
 #1 [1011a693d50] try_crashdump at ffffffff8014cda9
 #2 [1011a693d60] do_page_fault at ffffffff80124ae8
 #3 [1011a693e40] error_exit at ffffffff80110e1d
    [exception RIP: fput]
    RIP: ffffffff8017ca06  RSP: 000001011a693ef0  RFLAGS: 00010246
    RAX: 0000000000000002  RBX: 0000000000009362  RCX: 0000000000000000
    RDX: 0000000000009362  RSI: 00000101198b8bc0  RDI: 0000000000000000
    RBP: 0000000000000000   R8: 0000000000000000   R9: 0000000000000000
    R10: 0000000000000000  R11: 0000000000009362  R12: 00000101199218c0
    R13: 00000101198b8bc0  R14: 0000010119837270  R15: 0000000000000003
    ORIG_RAX: ffffffffffffffff  CS: 0010  SS: 0018
 #4 [1011a693ef0] autofs4_catatonic_mode at ffffffffa0a45df2
 #5 [1011a693f10] autofs4_root_ioctl at ffffffffa0a45b74
 #6 [1011a693f40] sys_ioctl at ffffffff8018dc6d
 #7 [1011a693f80] system_call at ffffffff801102f6
    RIP: 0000002a95946f59  RSP: 0000000040621a98  RFLAGS: 00000246
    RAX: 0000000000000010  RBX: ffffffff801102f6  RCX: 0000002a95677486
    RDX: 0000000000000000  RSI: 0000000000009362  RDI: 0000000000000003
    RBP: 000000552abfc930   R8: 0000000000000000   R9: 0000000000000000
    R10: 0000000000000000  R11: 0000000000000246  R12: 000000552abfbe10
    R13: 000000552abfbe10  R14: 0000000000000000  R15: 000000552ac17390
    ORIG_RAX: 0000000000000010  CS: 0033  SS: 002b


Expected results:
No kernel panic

Comment 1 Ian Kent 2008-10-20 05:49:46 UTC
This bug is marked as dependent on bug 460083, which is the
kernel component of another issue. The patches included for
bug 460083 happen to also resolve several other issues that
are indirectly related to 460083 and this looks like one
such issue. When we see an issue like this I recommend we
create a separate bug to document these additional issues.

Of course we still need to verify the issue is resolved by
the patch series of 460083. The patch series was committed
to RHEL-4 kernel 2.6.9-78.15 and we need to make that kernel
available for testing. If it is considered to early to make
that revision available I can make a scratch build we could
use for this purpose.

Ian

Comment 7 Ian Kent 2009-01-22 12:06:12 UTC
The issue of a panic due to an access violation in kernel
module function autofs4_catatonic_mode() is addressed in
the patch submission for bug 460083. Since they have been
committed to the RHEL-4.8 kernel I'm setting this bug to
MODIFIED.

Comment 11 Chris Ward 2009-05-05 13:58:43 UTC
Any updates here? Has this issue been resolved in the RHEL 4.8 Beta? later kernel?

Comment 12 Ian Kent 2009-05-05 14:14:53 UTC
(In reply to comment #11)
> Any updates here? Has this issue been resolved in the RHEL 4.8 Beta? later
> kernel?  

Nothing new since comment #7.

Comment 13 Chris Ward 2009-05-05 14:23:06 UTC
 tested by QA, customer or partner and if so, whether or not it has been VERIFIED. Just trying to get any stale (VERIFIED) bugs to their proper state.

Comment 15 errata-xmlrpc 2009-05-18 19:30:42 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHSA-2009-1024.html


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