I get the following backtrace when running fuser on a local directory eg. fuser /var/cache/yum on a system with NFSv4 mounted via autofs. The system isn't usable afterwards. kernel BUG at fs/namei.c:405! invalid opcode: 0000 [#1] SMP last sysfs file: /sys/devices/system/cpu/cpu1/cache/index2/shared_cpu_map CPU 0 Modules linked in: fuse nfs lockd fscache nfs_acl rpcsec_gss_krb5 auth_rpcgss des_generic sunrpc cpufreq_ondemand acpi_cpufreq freq_table mperf ipv6 uinput snd_hda_codec_analog snd_hda_intel snd_hda_codec snd_hwdep snd_seq snd_seq_device snd_pcm serio_raw snd_timer snd e1000e iTCO_wdt soundcore snd_page_alloc i2c_i801 microcode iTCO_vendor_support firewire_ohci firewire_core pata_acpi crc_itu_t ata_generic i915 drm_kms_helper drm i2c_algo_bit i2c_core video [last unloaded: scsi_wait_scan] Pid: 2689, comm: fuser Not tainted 2.6.38-0.rc3.git4.1.fc15.x86_64 #1 DQ45CB/DQ45CB RIP: 0010:[<ffffffff8112a1f8>] [<ffffffff8112a1f8>] nameidata_drop_rcu+0x2d/0xca RSP: 0018:ffff880057e9fc78 EFLAGS: 00010246 RAX: ffff880070715c80 RBX: ffff880057e9fdd0 RCX: ffff880057cb0b40 RDX: 0000000000000000 RSI: 00000000f42f9d10 RDI: ffff880057e9fdd0 RBP: ffff880057e9fc98 R08: 0000000000000000 R09: 00000000000007ff R10: 00000000000007ff R11: ffff880065c9f180 R12: ffff880070684300 R13: ffff880065c9f180 R14: 0000000000000000 R15: 0000000000000000 FS: 00007fe65d919720(0000) GS:ffff880079800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000001ac74b8 CR3: 0000000071fc0000 CR4: 00000000000406f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process fuser (pid: 2689, threadinfo ffff880057e9e000, task ffff880070715c80) Stack: 00000000000007ff ffff880065c9f180 ffff880057e9fdd0 ffff880057e9fd10 ffff880057e9fcb8 ffffffff8112ae6a ffff880057e9fdd0 0000000000000000 ffff880057e9fcf8 ffffffff8112b004 ffff880052b47a80 ffff880057e9fdd0 Call Trace: [<ffffffff8112ae6a>] force_reval_path.isra.24+0x39/0x5a [<ffffffff8112b004>] do_follow_link+0x179/0x1e8 [<ffffffff8112b32b>] link_path_walk+0x2b8/0x430 [<ffffffff8112b6ce>] do_path_lookup+0x4d/0xf6 [<ffffffff8112c4d0>] user_path_at+0x57/0x94 [<ffffffff8146f37c>] ? _cond_resched+0xe/0x22 [<ffffffff81124a2f>] ? might_fault+0x21/0x23 [<ffffffff81124b28>] ? cp_new_stat+0xf7/0x10d [<ffffffff81124d16>] vfs_fstatat+0x39/0x63 [<ffffffff81124d7b>] vfs_stat+0x1b/0x1d [<ffffffff81124e7a>] sys_newstat+0x1a/0x33 [<ffffffff8112985f>] ? path_put+0x1f/0x23 [<ffffffff81009bc2>] system_call_fastpath+0x16/0x1b Code: 89 e5 41 55 41 54 53 41 52 0f 1f 44 00 00 65 48 8b 04 25 c0 cc 00 00 f6 47 40 40 48 89 fb 4c 8b a0 20 05 00 00 4c 8b 6f 08 75 02 <0f> 0b 48 83 7f 20 00 74 20 49 8d 7c 24 04 e8 a5 66 34 00 49 8b RIP [<ffffffff8112a1f8>] nameidata_drop_rcu+0x2d/0xca RSP <ffff880057e9fc78>
(In reply to comment #1) > I get the following backtrace when running fuser on a local directory eg. fuser > /var/cache/yum on a system with NFSv4 mounted via autofs. What does that mean exactly? Does some remote system have that directory mounted, or is autofs being used to mount some unrelated directory? Can you list steps needed to reproduce this, including what autofs config to use?
The crash happens when I run fuser on an unrelated ordinary directory on the local disk. I am still trying to narrow down the circumstances to work out when it occurs and when it doesn't. So far I have found that if I am logged in (via a graphical desktop) in a home directory that is NFS mounted via autofs then running fuser (as root from a text console) gives the backtrace. If I start again with a clean boot, log in graphically and log out (so NFS will still be mounted), and then run fuser I don't get a crash. I am not sure whether autofs or NFS mounting is necessary for the crash or just a consequence of the environment I am testing it in.
autofs is unnecessary, it is reproducible in a hand mounted NFS directory with no automount or other NFS mounts.
So in summary to reproduce this problem you need a graphical session in an NFSv4 mounted home directory when you run fuser. It doesn't happen with a user home directory on the local disk.
Looks like this is fixed in today's updates (commit 844a391799c25d9ba85cbce33e4697db06083ec6)
Yes, kernel-2.6.38-0.rc5.git0.1.fc15.x86_64 has stopped throwing up kernel bugs (fuser throws up warnings about Stale NFS file handle for open but deleted files but I doubt that is a kernel bug).
kernel-2.6.38-0.rc5.git1.1.fc15 has been submitted as an update for Fedora 15. https://admin.fedoraproject.org/updates/kernel-2.6.38-0.rc5.git1.1.fc15
kernel-2.6.38-0.rc5.git1.1.fc15 has been pushed to the Fedora 15 stable repository. If problems still persist, please make note of it in this bug report.