Bug 234726 - Crash in NFS4/fscache during nfs_opendir()
Crash in NFS4/fscache during nfs_opendir()
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kernel (Show other bugs)
5.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: Steve Dickson
Red Hat Kernel QE team
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-03-31 18:00 EDT by Matthew Booth
Modified: 2010-10-21 08:30 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-10-21 08:30:04 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Matthew Booth 2007-03-31 18:00:57 EDT
I have an automounted NFS4 volume. I'm using cachefiles locally with a dedicated
5G ext3 filesystem:

/dev/mapper/vg_local-lv_cachefiles on /var/fscache type ext3 (rw,noatime,nodiratime)

I can reasonably reliably produce this crash on my machine within a few seconds
by clicking around directories on the volume with nautilus. I have not observed
this crash when using a regular shell, although it's not 100% so I may just have
been lucky.

I'm runing:
kernel-2.6.18-8.1.1.el5
cachefilesd-0.7-6.el5

Backtrace from crash:
 #0 [dae8fd00] crash_kexec at c0442bde
 #1 [dae8fd44] die at c04054ae
 #2 [dae8fd74] do_invalid_op at c0405bfe
 #3 [dae8fe24] error_code (via invalid_op) at c0404a6f
    EAX: f75ef448  EBX: e89e7c40  ECX: f75ef448  EDX: f75ef34c  EBP: e66ab2b0 
    DS:  007b      ESI: e89e7c40  ES:  007b      EDI: cc5e0c66 
    CS:  0060      EIP: f8cd358a  ERR: ffffffff  EFLAGS: 00210246 
 #4 [dae8fe58] cachefiles_walk_to_object at f8cd358a
 #5 [dae8feb4] fscache_lookup_object at f8b62256
 #6 [dae8fecc] __fscache_acquire_cookie at f8b62767
 #7 [dae8fee4] nfs_open at f8f26dd2
 #8 [dae8ff00] nfs_opendir at f8f23378
 #9 [dae8ff0c] __dentry_open at c04692dd
#10 [dae8ff28] nameidata_to_filp at c0469422
#11 [dae8ff38] do_filp_open at c046945c
#12 [dae8ff94] do_sys_open at c04694a0
#13 [dae8ffb0] sys_open at c046953d
#14 [dae8ffb8] system_call at c0403ef8
    EAX: ffffffda  EBX: b37ad5d8  ECX: 00018800  EDX: afaf91c8 
    DS:  007b      ESI: 08ac3898  ES:  007b      EDI: 0886e340 
    SS:  007b      ESP: afaf9174  EBP: afaf91f8 
    CS:  0073      EIP: 00155402  ERR: 00000005  EFLAGS: 00200202 

System data from crash:
      KERNEL: /usr/lib/debug/lib/modules/2.6.18-8.1.1.el5/vmlinux
    DUMPFILE: vmcore
        CPUS: 2
        DATE: Wed Mar 28 08:51:27 2007
      UPTIME: 12:27:00
LOAD AVERAGE: 0.55, 0.73, 0.43
       TASKS: 224
    NODENAME: mbooth.redhat.laptop
     RELEASE: 2.6.18-8.1.1.el5
     VERSION: #1 SMP Mon Feb 26 20:38:02 EST 2007
     MACHINE: i686  (1662 Mhz)
      MEMORY: 2 GB
       PANIC: "kernel BUG at fs/cachefiles/cf-namei.c:53!"

My reading of it suggests a bug in NFS4's usage of the netfs API, however
causing a kernel panic seems too severe a response.

I have 2 2G core files for this crash. They both have nfs_debug and rpc_debug
set to log everything. The second also has debug output from cachefiles,
although this required a recompile because 'echo 7 >
/proc/sys/fs/cachefiles/debug' did not seem to produce any debug output. I can
provide a core file directly to an individual developer on request.
Comment 2 Bart Vanbrabant 2007-04-29 04:48:30 EDT
I think I've seen the same bug. I was rebuilding an SRPM and I forgot my homedir
was on NFS. After a minute building the machine wasn't reachable any more
(remote). When I came there I saw an oops on the screen, I made a picture with
my cellphone: http://bart.ulyssis.org/bugs/cachefs/SP_A0105.jpg

Here the volume is mounted over nfsv3.

kernel-PAE-2.6.18-8.1.1.el5
cachefilesd-0.7-6.el5
Comment 3 Steve Dickson 2010-10-21 08:30:04 EDT
FScache is no longer supported in RHEL5

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