Bug 13588 - shrink_dcache_for_umount_subtree+0x238/0x240
Summary: shrink_dcache_for_umount_subtree+0x238/0x240
Status: CLOSED OBSOLETE
Alias: None
Product: File System
Classification: Unclassified
Component: NFS (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: bfields
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-06-20 15:03 UTC by Francois Cartegnie
Modified: 2012-06-08 15:29 UTC (History)
4 users (show)

See Also:
Kernel Version: NFS umount dcache shrink bug
Subsystem:
Regression: No
Bisected commit-id:


Attachments

Description Francois Cartegnie 2009-06-20 15:03:09 UTC
nfsd: last server has exited, flushing export cache
BUG: Dentry cd7a6aa0{i=df,n=bomberx} still in use (1) [unmount of vfat sdc9]
------------[ cut here ]------------
kernel BUG at fs/dcache.c:669!
invalid opcode: 0000 [#1] SMP 
last sysfs file: /sys/firmware/edd/int13_dev81/mbr_signature
Modules linked in: nfsd lockd nfs_acl auth_rpcgss sunrpc exportfs nls_iso8859_1 nls_cp437 vfat fat ipt_MASQUERADE iptable_nat nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 ip_tables usblp wlan_tkip af_packet wlan_wep ip6t_REJECT xt_limit ip6t_LOG w83l785ts nf_conntrack_ipv6 xt_state nf_conntrack asb100 hwmon_vid ip6table_filter ip6_tables eeprom x_tables ipv6 binfmt_misc loop dm_mod raid0 nvidia(P) nvram visor usbserial sbp2 emu10k1_gp gameport wlan_scan_sta ath_rate_sample snd_intel8x0 snd_ac97_codec ac97_bus snd_seq_dummy evdev ath_pci ohci1394 ieee1394 snd_seq_oss 3c59x wlan snd_seq_midi_event snd_seq mii ath_hal(P) snd_seq_device snd_pcm_oss snd_pcm snd_timer snd_mixer_oss snd i2c_nforce2 usbhid soundcore rtc_cmos nvidia_agp forcedeth snd_page_alloc sg i2c_core shpchp sr_mod hid agpgart thermal pci_hotplug button processor usb_storage uhci_hcd ohci_hcd ehci_hcd usbcore ppa parport_pc imm parport ata_generic ide_pci_generic pata_acpi amd74xx ide_gd_mod ide_core pata_amd libata sd_mod scsi_mod crc_t10dif raid456 async_xor async_memcpy async_tx xor raid1 reiserfs

Pid: 3490, comm: umount Tainted: P           (2.6.29.3-desktop-1mnb #1) A7N8X2.0
EIP: 0060:[<c01c12f8>] EFLAGS: 00010282 CPU: 0
EIP is at shrink_dcache_for_umount_subtree+0x238/0x240
EAX: 00000050 EBX: cd7a6afc ECX: ffffffff EDX: 00e51000
ESI: cd7a6aa0 EDI: 00000001 EBP: ddb1feec ESP: ddb1febc
 DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
Process umount (pid: 3490, ti=ddb1e000 task=cf10d4e0 task.ti=ddb1e000)
Stack:
 c0492798 cd7a6aa0 000000df cd7a6afc 00000001 e120dcf1 d921656c e120dcf1
 00000008 d9216400 e11998c0 e120e7c0 ddb1fef8 c01c1328 d9216400 ddb1ff10
 c01b25bb c053f51c ddb1ff0c cc0f81e0 00000003 ddb1ff20 c01b26d5 d9216400
Call Trace:
 [<c01c1328>] ? shrink_dcache_for_umount+0x28/0x50
 [<c01b25bb>] ? generic_shutdown_super+0x1b/0x110
 [<c01b26d5>] ? kill_block_super+0x25/0x40
 [<c01eb9e0>] ? vfs_quota_off+0x0/0x20
 [<c01b298f>] ? deactivate_super+0x5f/0x80
 [<c01c6c39>] ? mntput_no_expire+0xf9/0x140
 [<c01c6d02>] ? release_mounts+0x82/0x90
 [<c01c6f55>] ? sys_umount+0x75/0x360
 [<c01c7259>] ? sys_oldumount+0x19/0x20
 [<c01053db>] ? sysenter_do_call+0x12/0x2f
Code: 6c 01 00 00 89 44 24 18 8b 45 ec 89 7c 24 10 89 5c 24 0c 89 54 24 08 89 74 24 04 89 44 24 14 c7 04 24 98 27 49 c0 e8 25 84 1e 00 <0f> 0b eb fe 0f 0b eb fe 55 89 e5 53 89 c3 8d 40 3c e8 52 b8 f8 
EIP: [<c01c12f8>] shrink_dcache_for_umount_subtree+0x238/0x240 SS:ESP 0068:ddb1febc
---[ end trace 38f87c0643f872c5 ]---
Comment 1 Trond Myklebust 2009-06-20 18:30:10 UTC
Apparently a server bug. Reassigning to Bruce...
Comment 2 Andrew Morton 2009-06-29 20:52:21 UTC
cc neilb.
Comment 3 Neil Brown 2009-06-29 21:12:59 UTC
Looks like a VFAT bug or a VFS bug.  The link to NFS is purely
circumstancial.
During shutdown, nfsd was stopped which generated the first line,
then a VFAT filesystem on /dev/sdc9 was unmounted which generated the
remaining messages.

Was the VFAT filesystem exported over NFS?  If so, there might be a
connection.  If not, there is very unlikely to be a connection.

If it wasn't NFS-exported, is there anything else at all unusual that
might have been happening on that filesystem?
Comment 4 Francois Cartegnie 2009-06-29 22:49:03 UTC
There was a VFAT filesystem on /dev/sdc9, but it's access wasn't working, so I'm not sure it was mounted.
Share was done on /mnt/ accessed through autofs.
on server side:
/mnt/disk/vfat/ (mount point for sdc9)
/mnt/disk/reiser/ (mount point for sdc8)
Comment 5 Neil Brown 2009-06-29 23:05:11 UTC
What do you mean by "its access wasn't working" ??  Access from NFS clients,
or locally on the server.  In what way didn't it work?

Now it looks like it could be an NFSd problem, and VFAT problem, a
VFS problem, or an autofs problem.

The bug report mentioned a filesystem object called "bomberx".
Can you tell us anything about this?  Is it a file or a directory?
Is it in the top level of the filesystem or deeper?
If it is a file, what is it used for?  Is it an executable or what?
It is likely that some client will have tried to access it?
Comment 6 Francois Cartegnie 2009-07-11 12:52:05 UTC
-It's wasn't working in the way that it's mounted by the user, the exports are updated (*,rw), and the same uid can't still access it from a remote nfs clients (only reads empty dir).
-bomberx is a picture in a subdir
There have been many exports/re-exports to try to solve the problem.
Comment 7 bfields 2009-07-12 20:02:14 UTC
So, you have a file "bomberx" that's visible when you mount the filesystem, but that can't be seen on a client?  (Even if you restart the server and remount from the client?)

If you create other files in that same directory, are they also invisible to the client?

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