Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 234726 - Crash in NFS4/fscache during nfs_opendir()
Summary: Crash in NFS4/fscache during nfs_opendir()
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kernel
Version: 5.0
Hardware: All
OS: Linux
Target Milestone: ---
: ---
Assignee: Steve Dickson
QA Contact: Red Hat Kernel QE team
Depends On:
TreeView+ depends on / blocked
Reported: 2007-03-31 22:00 UTC by Matthew Booth
Modified: 2010-10-21 12:30 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2010-10-21 12:30:04 UTC
Target Upstream Version:

Attachments (Terms of Use)

Description Matthew Booth 2007-03-31 22:00:57 UTC
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:

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 08:48:30 UTC
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:

Here the volume is mounted over nfsv3.


Comment 3 Steve Dickson 2010-10-21 12:30:04 UTC
FScache is no longer supported in RHEL5

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