Then, how about remove dput() from usbfs_rmdir() accordingly ? please try following patch, it could work for me. ========================================================================== >From 23bdd44cd7c973916187fc4c30ed383f7d7e53af Mon Sep 17 00:00:00 2001 From: Huajun Li <huajun.li.lee@xxxxxxxxx> Date: Tue, 31 May 2011 16:42:25 +0800 Subject: [PATCH] remove dput from usbfs_rmdir() as dentry_unhash() is updated Signed-off-by: Huajun Li <huajun.li.lee@xxxxxxxxx> --- drivers/usb/core/inode.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/usb/core/inode.c b/drivers/usb/core/inode.c index 1b125c2..bca36ca 100644 --- a/drivers/usb/core/inode.c +++ b/drivers/usb/core/inode.c @@ -389,7 +389,7 @@ static int usbfs_rmdir(struct inode *dir, struct dentry *dentry) mutex_unlock(&inode->i_mutex); if (!error) d_delete(dentry); - dput(dentry); + /*dput(dentry);*/ return error; } -- 1.7.4.1 2011/5/30 Brokhman Tatyana <tlinder@xxxxxxxxxxxxxx>: > > Hi All > > I've tried using dummy_hcd with v2.6.39 and encountered a small issue. > When unloading the module there is a crash with the flowing call stack: > > kernel BUG at /prj/qi-android/users/tlinder/SNPS-DCD/fs/dcache.c:419! > [ 47.722100] invalid opcode: 0000 [#1] SMP > [ 47.722100] Modules linked in: dummy_hcd(-) > [ 47.722100] > [ 47.722100] Pid: 1427, comm: modprobe Not tainted 2.6.39+ #415 Bochs Bochs > [ 47.722100] EIP: 0060:[<c10c5fc3>] EFLAGS: 00000246 CPU: 0 > [ 47.722100] EIP is at dput+0x2b/0xbb > [ 47.722100] EAX: 00000000 EBX: d71a2600 ECX: c167c940 EDX: 00000f0f > [ 47.722100] ESI: d71a264c EDI: d71a2670 EBP: d6c47df8 ESP: d6c47df0 > [ 47.722100] DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 > [ 47.722100] Process modprobe (pid: 1427, ti=d6c46000 task=d6c404e0 > task.ti=d6c46000) > [ 47.722100] Stack: > [ 47.722100] d71a2600 00000000 d6c47e28 c12bf007 0000002f c171f640 > d71a2670 d71a264c > [ 47.722100] d717d580 d717d85c d71a2500 d77df800 00000000 00000004 > d6c47e44 c12bf43b > [ 47.722100] c10b43c3 c12b013e c169fa6c 00000000 00000004 d6c47e60 > c1441845 d77df800 > [ 47.722100] Call Trace: > [ 47.722100] [<c12bf007>] fs_remove_file+0x13d/0x15f > [ 47.722100] [<c12bf43b>] usbfs_notify+0x1fc/0x25a > [ 47.722100] [<c10b43c3>] ? kfree+0xd0/0xd9 > [ 47.722100] [<c12b013e>] ? usb_release_dev+0x2f/0x45 > [ 47.722100] [<c1441845>] notifier_call_chain+0x26/0x48 > [ 47.722100] [<c10488a1>] __blocking_notifier_call_chain+0x37/0x4c > [ 47.722100] [<c10488c2>] blocking_notifier_call_chain+0xc/0xe > [ 47.722100] [<c12bd504>] usb_notify_remove_bus+0x14/0x16 > [ 47.722100] [<c12b4250>] usb_deregister_bus+0x49/0x5c > [ 47.722100] [<c12b436e>] usb_remove_hcd+0x10b/0x119 > [ 47.722100] [<d881615f>] dummy_hcd_remove+0x13/0x29 [dummy_hcd] > [ 47.722100] [<c1222d32>] platform_drv_remove+0xc/0xe > [ 47.722100] [<c1221d1d>] __device_release_driver+0x45/0x7b > [ 47.722100] [<c1221de6>] device_release_driver+0x18/0x23 > [ 47.722100] [<c12213ba>] bus_remove_device+0x78/0x85 > [ 47.722100] [<c12200eb>] device_del+0xe9/0x144 > [ 47.722100] [<c1223173>] platform_device_del+0x15/0x4b > [ 47.722100] [<c12234fc>] platform_device_unregister+0xb/0x15 > [ 47.722100] [<d8817f17>] cleanup+0x17/0x2d [dummy_hcd] > [ 47.722100] [<c10591f3>] sys_delete_module+0x17e/0x1d7 > [ 47.722100] [<c10a6b2f>] ? remove_vma+0x46/0x4c > [ 47.722100] [<c10a77bc>] ? do_munmap+0x217/0x231 > [ 47.722100] [<c1443fcc>] sysenter_do_call+0x12/0x22 > [ 47.722100] Code: 55 89 e5 56 53 85 c0 89 c3 0f 84 a8 00 00 00 83 78 48 > 01 75 05 e8 dd 7f 37 00 8d 73 4c 89 f0 e8 fb 8e 37 00 8b 43 48 85 c0 75 04 > <0f> 0b eb fe 83 f8 01 76 08 48 89 43 48 fe 06 eb 7b 66 83 3b 00 > [ 47.722100] EIP: [<c10c5fc3>] dput+0x2b/0xbb SS:ESP 0068:d6c47df0 > [ 47.727248] ---[ end trace 7508933c4c84d72a ]--- > > I ran bisect and found out that the commit that caused it is: > commit 64252c75a2196a0cf1e0d3777143ecfe0e3ae650 > Author: Sage Weil <sage@xxxxxxxxxxxx> > Date: Tue May 24 13:06:05 2011 -0700 > > vfs: remove dget() from dentry_unhash() > > This serves no useful purpose that I can discern. All callers (rename, > rmdir) hold their own reference to the dentry. > > A quick audit of all file systems showed no relevant checks on the value > of d_count in vfs_rmdir/vfs_rename_dir paths. > > Signed-off-by: Sage Weil <sage@xxxxxxxxxxxx> > Signed-off-by: Al Viro <viro@xxxxxxxxxxxxxxxxxx> > > It seems that this commit was part of a series so the issue was fixed only > when I reverted all of the flowing commits: > Revert "vfs: dentry_unhash immediately prior to rmdir" > This reverts commit 48293699a09324d2e3c66bd53d10eed6d67937a0. > > Revert "vfs: remove dget() from dentry_unhash()" > This reverts commit 64252c75a2196a0cf1e0d3777143ecfe0e3ae650. > > Revert "vfs: push dentry_unhash on rmdir into file systems" > This reverts commit 79bf7c732b5ff75b96022ed9d29181afd3d2509c. > > Revert "vfs: push dentry_unhash on rename_dir into file systems" > This reverts commit e4eaac06bcccb2a70bca6a2de9871882dce2aa14. > > Revert "vfs: update dentry_unhash() comment" > This reverts commit a71905f0db41d4b2b01044fb40f97656fefc44a7. > > Revert "vfs: fix vfs_rename_dir for FS_RENAME_DOES_D_MOVE filesystems" > This reverts commit b5afd2c406f5c6272d916fd705f44f070fbbc0ba. > > Revert "vfs: clean up vfs_rmdir" > This reverts commit 912dbc15d953791f013b0c64a8093ab0490e5f40. > > Revert "vfs: clean up vfs_rename_dir" > This reverts commit 9055cba711891a6313232629cd6bbca7c901e07f. > > Revert "vfs: clean up vfs_rename_other" > This reverts commit 51892bbb57e87854c27c105317797823f8891e68. > > Unfortunately I'm not familiar with that part of the code at all so I > would appreciate your assistance on fixing this properly. > > Thanks, > Tanya Brokhman > -- > Sent by an consultant of the Qualcomm Innovation Center, Inc. > The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. > > > -- > To unsubscribe from this list: send the line "unsubscribe linux-usb" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
