* 3.5-rc3: BUG: Dentry still in use (1) [unmount of cgroup cgroup]
@ 2012-06-24 19:08 ` shyju pv
0 siblings, 0 replies; 35+ messages in thread
From: shyju pv @ 2012-06-24 19:08 UTC (permalink / raw)
To: linux-kernel, cgroups, tj; +Cc: Sanil kumar
Hi,
Observed a crash on 3.5-rc3 with cgroup tests from LTP(Stable April,2012 release)on Dell Inspiron 1526[Intel(R) Core2Duo T7250, MEM 4GB] and also on another x86 quad core target(4GB RAM).
LTP test case: cgroup_regression_test.sh(test 4,7 and 9 crashes randomly when the test cases are executed in order)
Shyju
[ 532.805905] BUG: Dentry ffff8801164db490{i=491b,n=/} still in use (1) [unmount of cgroup cgroup]
[ 532.805961] ------------[ cut here ]------------
[ 532.805996] kernel BUG at fs/dcache.c:965!
[ 532.806035] invalid opcode: 0000 [#1] SMP
[ 532.806067] CPU 1
[ 532.806505] Modules linked in: raw binfmt_misc ipv6 af_packet mperf fuse loop dm_mod coretemp kvm_intel kvm microcode tpm_tis tpm tpm_bios pcspkr serio_raw i2c_i801 i2c_core lpc_ich mfd_core hid_generic sg mptctl i5k_amb i5000_edac tg3 edac_core shpchp e1000e pci_hotplug button usbhid hid uhci_hcd ehci_hcd usbcore usb_common sd_mod crc_t10dif edd ext3 mbcache jbd fan processor ide_pci_generic ide_core ata_generic ata_piix libata mptsas mptscsih mptbase scsi_transport_sas scsi_mod thermal thermal_sys hwmon
[ 532.806625]
[ 532.806650] Pid: 930, comm: kworker/1:2 Not tainted 3.5.0-rc3-0.7-default #2 HUAWEI TECHNOLOGIES CO.,LTD. Tecal/CN21WBSA
[ 532.806721] RIP: 0010:[<ffffffff811ec127>] [<ffffffff811ec127>] shrink_dcache_for_umount_subtree+0x267/0x290
[ 532.806765] RSP: 0018:ffff880111eafbf0 EFLAGS: 00010202
[ 532.806788] RAX: 0000000000000054 RBX: ffff8801164db490 RCX: 0000000000000006
[ 532.806811] RDX: ffffffff82a7d630 RSI: ffff88011318dfa8 RDI: 0000000000000246
[ 532.806832] RBP: ffff880111eafc10 R08: 0000000000000002 R09: 0000000000000000
[ 532.806855] R10: 000000000000000a R11: 0000000000000006 R12: ffff8801164db490
[ 532.806877] R13: ffffffff8181ca80 R14: ffff880116d43000 R15: ffff88011a9d5000
[ 532.806904] FS: 0000000000000000(0000) GS:ffff88011a800000(0000) knlGS:0000000000000000
[ 532.806931] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[ 532.806951] CR2: 00007fcf7b4843e0 CR3: 0000000001c0c000 CR4: 00000000000007e0
[ 532.806984] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 532.807011] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[ 532.807034] Process kworker/1:2 (pid: 930, threadinfo ffff880111eae000, task ffff88011318d680)
[ 532.807060] Stack:
[ 532.807084] ffff880116d43580 ffff8801164db4f0 ffff880116d43000 ffff880116d431b8
[ 532.807113] ffff880111eafc30 ffffffff811ec19a ffff880111eafc80 ffff880116d43000
[ 532.807143] ffff880111eafc60 ffffffff811cc3c7 ffff8801164db490 0000000000000013
[ 532.807164] Call Trace:
[ 532.807186] [<ffffffff811ec19a>] shrink_dcache_for_umount+0x4a/0x90
[ 532.807217] [<ffffffff811cc3c7>] generic_shutdown_super+0x37/0x160
[ 532.807247] [<ffffffff811cc5d9>] kill_anon_super+0x19/0x40
[ 532.807273] [<ffffffff811cc63a>] kill_litter_super+0x3a/0x50
[ 532.807300] [<ffffffff810fb65a>] cgroup_kill_sb+0x20a/0x280
[ 532.807330] [<ffffffff811ccdc5>] deactivate_locked_super+0x65/0xb0
[ 532.807353] [<ffffffff811ce339>] deactivate_super+0x89/0xe0
[ 532.807379] [<ffffffff810f7734>] cgroup_d_release+0x34/0x40
[ 532.807405] [<ffffffff811eb258>] d_free+0x58/0xc0
[ 532.807433] [<ffffffff811ee5f0>] dput+0x220/0x350
[ 532.807455] [<ffffffff810f7429>] css_dput_fn+0x19/0x30
[ 532.807483] [<ffffffff8107b4d9>] process_one_work+0x239/0x800
[ 532.807509] [<ffffffff8107b450>] ? process_one_work+0x1b0/0x800
[ 532.807527] [<ffffffff810f7410>] ? cgroup_rename+0x70/0x70
[ 532.807547] [<ffffffff8107eba3>] worker_thread+0x2e3/0x710
[ 532.807575] [<ffffffff8107e8c0>] ? manage_workers+0x370/0x370
[ 532.807595] [<ffffffff81087e46>] kthread+0xd6/0xf0
[ 532.807636] [<ffffffff81630474>] kernel_thread_helper+0x4/0x10
[ 532.807658] [<ffffffff816256f0>] ? retint_restore_args+0x13/0x13
[ 532.807672] [<ffffffff81087d70>] ? __init_kthread_worker+0x80/0x80
[ 532.807683] [<ffffffff81630470>] ? gs_change+0x13/0x13
[ 532.807811] Code: 83 05 6d a5 f1 01 01 48 8d 86 80 05 00 00 48 c7 c7 f0 68 9b 81 48 89 de 48 89 04 24 31 c0 e8 dd 30 43 00 48 83 05 59 a5 f1 01 01 <0f> 0b eb fe 48 83 05 45 a5 f1 01 01 31 d2 eb cc 48 83 05 11 a5
[ 532.807843] RIP [<ffffffff811ec127>] shrink_dcache_for_umount_subtree+0x267/0x290
[ 532.807856] RSP <ffff880111eafbf0>
[ 532.807876] ---[ end trace 1e5c705163c24a85 ]---
[ 532.808176] BUG: unable to handle kernel paging request at fffffffffffffff8
[ 532.808188] IP: [<ffffffff81087573>] kthread_data+0x13/0x20
[ 532.808198] PGD 1c0e067 PUD 1c0f067 PMD 0
[ 532.808206] Oops: 0000 [#2] SMP
[ 532.808212] CPU 1
[ 532.808326] Modules linked in: raw binfmt_misc ipv6 af_packet mperf fuse loop dm_mod coretemp kvm_intel kvm microcode tpm_tis tpm tpm_bios pcspkr serio_raw i2c_i801 i2c_core lpc_ich mfd_core hid_generic sg mptctl i5k_amb i5000_edac tg3 edac_core shpchp e1000e pci_hotplug button usbhid hid uhci_hcd ehci_hcd usbcore usb_common sd_mod crc_t10dif edd ext3 mbcache jbd fan processor ide_pci_generic ide_core ata_generic ata_piix libata mptsas mptscsih mptbase scsi_transport_sas scsi_mod thermal thermal_sys hwmon
[ 532.808360]
[ 532.808368] Pid: 930, comm: kworker/1:2 Tainted: G D 3.5.0-rc3-0.7-default #2 HUAWEI TECHNOLOGIES CO.,LTD. Tecal/CN21WBSA
[ 532.808382] RIP: 0010:[<ffffffff81087573>] [<ffffffff81087573>] kthread_data+0x13/0x20
[ 532.808390] RSP: 0018:ffff880111eaf7e8 EFLAGS: 00010006
[ 532.808397] RAX: 0000000000000000 RBX: 0000000000000001 RCX: ffff88011318d6c8
[ 532.808404] RDX: ffff88011318d680 RSI: 0000000000000001 RDI: ffff88011318d680
[ 532.808412] RBP: ffff880111eaf7e8 R08: 0000000000000000 R09: 0000000000000001
[ 532.808422] R10: 0000000000000800 R11: 0000000000000000 R12: ffff88011318dc10
[ 532.808432] R13: 0000000000000001 R14: ffff88011a9d1b00 R15: 0000000000000000
[ 532.808442] FS: 0000000000000000(0000) GS:ffff88011a800000(0000) knlGS:0000000000000000
[ 532.808455] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[ 532.808468] CR2: fffffffffffffff8 CR3: 0000000001c0c000 CR4: 00000000000007e0
[ 532.808487] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 532.808504] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[ 532.808516] Process kworker/1:2 (pid: 930, threadinfo ffff880111eae000, task ffff88011318d680)
[ 532.808531] Stack:
[ 532.808549] ffff880111eaf808 ffffffff8107d428 ffff880111eaf808 ffff880111eae010
[ 532.808570] ffff880111eaf948 ffffffff8162231d ffff880111eae010 00000000001d1b00
[ 532.808596] 00000000001d1b00 ffff88011318d680 00000000001d1b00 ffff880111eaffd8
[ 532.808608] Call Trace:
[ 532.808618] [<ffffffff8107d428>] wq_worker_sleeping+0x18/0x130
[ 532.808639] [<ffffffff8162231d>] __schedule+0x92d/0xe00
[ 532.808651] [<ffffffff810d976d>] ? trace_hardirqs_on+0x1d/0x30
[ 532.808667] [<ffffffff812f43c0>] ? put_io_context+0xc0/0x110
[ 532.808682] [<ffffffff812f453b>] ? put_io_context_active+0x12b/0x1a0
[ 532.808705] [<ffffffff81622984>] schedule+0x34/0xc0
[ 532.808717] [<ffffffff8105f306>] do_exit+0x9a6/0xe60
[ 532.808732] [<ffffffff81057c38>] ? kmsg_dump+0x98/0x1e0
[ 532.808759] [<ffffffff8162698c>] oops_end+0x15c/0x160
[ 532.808775] [<ffffffff81008889>] die+0x79/0xd0
[ 532.808794] [<ffffffff81625fe8>] do_trap+0x1b8/0x1f0
[ 532.808813] [<ffffffff81005988>] do_invalid_op+0xb8/0x100
[ 532.808830] [<ffffffff811ec127>] ? shrink_dcache_for_umount_subtree+0x267/0x290
[ 532.808844] [<ffffffff81058d0e>] ? vprintk_emit+0x23e/0x820
[ 532.808856] [<ffffffff81326c0d>] ? trace_hardirqs_off_thunk+0x3a/0x3c
[ 532.808872] [<ffffffff81625720>] ? restore_args+0x30/0x30
[ 532.808886] [<ffffffff816302eb>] invalid_op+0x1b/0x20
[ 532.808916] [<ffffffff811ec127>] ? shrink_dcache_for_umount_subtree+0x267/0x290
[ 532.808933] [<ffffffff811ec19a>] shrink_dcache_for_umount+0x4a/0x90
[ 532.808952] [<ffffffff811cc3c7>] generic_shutdown_super+0x37/0x160
[ 532.808972] [<ffffffff811cc5d9>] kill_anon_super+0x19/0x40
[ 532.808986] [<ffffffff811cc63a>] kill_litter_super+0x3a/0x50
[ 532.809011] [<ffffffff810fb65a>] cgroup_kill_sb+0x20a/0x280
[ 532.809026] [<ffffffff811ccdc5>] deactivate_locked_super+0x65/0xb0
[ 532.809040] [<ffffffff811ce339>] deactivate_super+0x89/0xe0
[ 532.809056] [<ffffffff810f7734>] cgroup_d_release+0x34/0x40
[ 532.809070] [<ffffffff811eb258>] d_free+0x58/0xc0
[ 532.809083] [<ffffffff811ee5f0>] dput+0x220/0x350
[ 532.809095] [<ffffffff810f7429>] css_dput_fn+0x19/0x30
[ 532.809112] [<ffffffff8107b4d9>] process_one_work+0x239/0x800
[ 532.809128] [<ffffffff8107b450>] ? process_one_work+0x1b0/0x800
[ 532.809142] [<ffffffff810f7410>] ? cgroup_rename+0x70/0x70
[ 532.809170] [<ffffffff8107eba3>] worker_thread+0x2e3/0x710
[ 532.809190] [<ffffffff8107e8c0>] ? manage_workers+0x370/0x370
[ 532.809207] [<ffffffff81087e46>] kthread+0xd6/0xf0
[ 532.809234] [<ffffffff81630474>] kernel_thread_helper+0x4/0x10
[ 532.809254] [<ffffffff816256f0>] ? retint_restore_args+0x13/0x13
[ 532.809279] [<ffffffff81087d70>] ? __init_kthread_worker+0x80/0x80
[ 532.809291] [<ffffffff81630470>] ? gs_change+0x13/0x13
[ 532.809352] Code: 00 48 89 e5 8b 40 f0 c9 c3 66 66 66 66 66 66 2e 0f 1f 84 00 00 00 00 00 48 83 05 e0 46 71 01 01 55 48 8b 87 38 05 00 00 48 89 e5 <48> 8b 40 f8 c9 c3 0f 1f 80 00 00 00 00 55 48 3b 3d 78 46 71 01
[ 532.809369] RIP [<ffffffff81087573>] kthread_data+0x13/0x20
[ 532.809376] RSP <ffff880111eaf7e8>
[ 532.809381] CR2: fffffffffffffff8
[ 532.809390] ---[ end trace 1e5c705163c24a86 ]---
[ 532.809401] Fixing recursive fault but reboot is needed!
[ 592.820384] INFO: rcu_sched detected stalls on CPUs/tasks: { 1} (detected by 0, t=15002 jiffies)
[ 592.820402] INFO: Stall ended before state dump start
[ 609.100148] INFO: rcu_bh detected stalls on CPUs/tasks: { 1} (detected by 0, t=15002 jiffies)
[ 609.100168] INFO: Stall ended before state dump start
^ permalink raw reply [flat|nested] 35+ messages in thread
* 3.5-rc3: BUG: Dentry still in use (1) [unmount of cgroup cgroup]
@ 2012-06-24 19:08 ` shyju pv
0 siblings, 0 replies; 35+ messages in thread
From: shyju pv @ 2012-06-24 19:08 UTC (permalink / raw)
To: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
cgroups-u79uwXL29TY76Z2rM5mHXA, tj-DgEjT+Ai2ygdnm+yROfE0A
Cc: Sanil kumar
Hi,
Observed a crash on 3.5-rc3 with cgroup tests from LTP(Stable April,2012 release)on Dell Inspiron 1526[Intel(R) Core2Duo T7250, MEM 4GB] and also on another x86 quad core target(4GB RAM).
LTP test case: cgroup_regression_test.sh(test 4,7 and 9 crashes randomly when the test cases are executed in order)
Shyju
[ 532.805905] BUG: Dentry ffff8801164db490{i=491b,n=/} still in use (1) [unmount of cgroup cgroup]
[ 532.805961] ------------[ cut here ]------------
[ 532.805996] kernel BUG at fs/dcache.c:965!
[ 532.806035] invalid opcode: 0000 [#1] SMP
[ 532.806067] CPU 1
[ 532.806505] Modules linked in: raw binfmt_misc ipv6 af_packet mperf fuse loop dm_mod coretemp kvm_intel kvm microcode tpm_tis tpm tpm_bios pcspkr serio_raw i2c_i801 i2c_core lpc_ich mfd_core hid_generic sg mptctl i5k_amb i5000_edac tg3 edac_core shpchp e1000e pci_hotplug button usbhid hid uhci_hcd ehci_hcd usbcore usb_common sd_mod crc_t10dif edd ext3 mbcache jbd fan processor ide_pci_generic ide_core ata_generic ata_piix libata mptsas mptscsih mptbase scsi_transport_sas scsi_mod thermal thermal_sys hwmon
[ 532.806625]
[ 532.806650] Pid: 930, comm: kworker/1:2 Not tainted 3.5.0-rc3-0.7-default #2 HUAWEI TECHNOLOGIES CO.,LTD. Tecal/CN21WBSA
[ 532.806721] RIP: 0010:[<ffffffff811ec127>] [<ffffffff811ec127>] shrink_dcache_for_umount_subtree+0x267/0x290
[ 532.806765] RSP: 0018:ffff880111eafbf0 EFLAGS: 00010202
[ 532.806788] RAX: 0000000000000054 RBX: ffff8801164db490 RCX: 0000000000000006
[ 532.806811] RDX: ffffffff82a7d630 RSI: ffff88011318dfa8 RDI: 0000000000000246
[ 532.806832] RBP: ffff880111eafc10 R08: 0000000000000002 R09: 0000000000000000
[ 532.806855] R10: 000000000000000a R11: 0000000000000006 R12: ffff8801164db490
[ 532.806877] R13: ffffffff8181ca80 R14: ffff880116d43000 R15: ffff88011a9d5000
[ 532.806904] FS: 0000000000000000(0000) GS:ffff88011a800000(0000) knlGS:0000000000000000
[ 532.806931] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[ 532.806951] CR2: 00007fcf7b4843e0 CR3: 0000000001c0c000 CR4: 00000000000007e0
[ 532.806984] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 532.807011] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[ 532.807034] Process kworker/1:2 (pid: 930, threadinfo ffff880111eae000, task ffff88011318d680)
[ 532.807060] Stack:
[ 532.807084] ffff880116d43580 ffff8801164db4f0 ffff880116d43000 ffff880116d431b8
[ 532.807113] ffff880111eafc30 ffffffff811ec19a ffff880111eafc80 ffff880116d43000
[ 532.807143] ffff880111eafc60 ffffffff811cc3c7 ffff8801164db490 0000000000000013
[ 532.807164] Call Trace:
[ 532.807186] [<ffffffff811ec19a>] shrink_dcache_for_umount+0x4a/0x90
[ 532.807217] [<ffffffff811cc3c7>] generic_shutdown_super+0x37/0x160
[ 532.807247] [<ffffffff811cc5d9>] kill_anon_super+0x19/0x40
[ 532.807273] [<ffffffff811cc63a>] kill_litter_super+0x3a/0x50
[ 532.807300] [<ffffffff810fb65a>] cgroup_kill_sb+0x20a/0x280
[ 532.807330] [<ffffffff811ccdc5>] deactivate_locked_super+0x65/0xb0
[ 532.807353] [<ffffffff811ce339>] deactivate_super+0x89/0xe0
[ 532.807379] [<ffffffff810f7734>] cgroup_d_release+0x34/0x40
[ 532.807405] [<ffffffff811eb258>] d_free+0x58/0xc0
[ 532.807433] [<ffffffff811ee5f0>] dput+0x220/0x350
[ 532.807455] [<ffffffff810f7429>] css_dput_fn+0x19/0x30
[ 532.807483] [<ffffffff8107b4d9>] process_one_work+0x239/0x800
[ 532.807509] [<ffffffff8107b450>] ? process_one_work+0x1b0/0x800
[ 532.807527] [<ffffffff810f7410>] ? cgroup_rename+0x70/0x70
[ 532.807547] [<ffffffff8107eba3>] worker_thread+0x2e3/0x710
[ 532.807575] [<ffffffff8107e8c0>] ? manage_workers+0x370/0x370
[ 532.807595] [<ffffffff81087e46>] kthread+0xd6/0xf0
[ 532.807636] [<ffffffff81630474>] kernel_thread_helper+0x4/0x10
[ 532.807658] [<ffffffff816256f0>] ? retint_restore_args+0x13/0x13
[ 532.807672] [<ffffffff81087d70>] ? __init_kthread_worker+0x80/0x80
[ 532.807683] [<ffffffff81630470>] ? gs_change+0x13/0x13
[ 532.807811] Code: 83 05 6d a5 f1 01 01 48 8d 86 80 05 00 00 48 c7 c7 f0 68 9b 81 48 89 de 48 89 04 24 31 c0 e8 dd 30 43 00 48 83 05 59 a5 f1 01 01 <0f> 0b eb fe 48 83 05 45 a5 f1 01 01 31 d2 eb cc 48 83 05 11 a5
[ 532.807843] RIP [<ffffffff811ec127>] shrink_dcache_for_umount_subtree+0x267/0x290
[ 532.807856] RSP <ffff880111eafbf0>
[ 532.807876] ---[ end trace 1e5c705163c24a85 ]---
[ 532.808176] BUG: unable to handle kernel paging request at fffffffffffffff8
[ 532.808188] IP: [<ffffffff81087573>] kthread_data+0x13/0x20
[ 532.808198] PGD 1c0e067 PUD 1c0f067 PMD 0
[ 532.808206] Oops: 0000 [#2] SMP
[ 532.808212] CPU 1
[ 532.808326] Modules linked in: raw binfmt_misc ipv6 af_packet mperf fuse loop dm_mod coretemp kvm_intel kvm microcode tpm_tis tpm tpm_bios pcspkr serio_raw i2c_i801 i2c_core lpc_ich mfd_core hid_generic sg mptctl i5k_amb i5000_edac tg3 edac_core shpchp e1000e pci_hotplug button usbhid hid uhci_hcd ehci_hcd usbcore usb_common sd_mod crc_t10dif edd ext3 mbcache jbd fan processor ide_pci_generic ide_core ata_generic ata_piix libata mptsas mptscsih mptbase scsi_transport_sas scsi_mod thermal thermal_sys hwmon
[ 532.808360]
[ 532.808368] Pid: 930, comm: kworker/1:2 Tainted: G D 3.5.0-rc3-0.7-default #2 HUAWEI TECHNOLOGIES CO.,LTD. Tecal/CN21WBSA
[ 532.808382] RIP: 0010:[<ffffffff81087573>] [<ffffffff81087573>] kthread_data+0x13/0x20
[ 532.808390] RSP: 0018:ffff880111eaf7e8 EFLAGS: 00010006
[ 532.808397] RAX: 0000000000000000 RBX: 0000000000000001 RCX: ffff88011318d6c8
[ 532.808404] RDX: ffff88011318d680 RSI: 0000000000000001 RDI: ffff88011318d680
[ 532.808412] RBP: ffff880111eaf7e8 R08: 0000000000000000 R09: 0000000000000001
[ 532.808422] R10: 0000000000000800 R11: 0000000000000000 R12: ffff88011318dc10
[ 532.808432] R13: 0000000000000001 R14: ffff88011a9d1b00 R15: 0000000000000000
[ 532.808442] FS: 0000000000000000(0000) GS:ffff88011a800000(0000) knlGS:0000000000000000
[ 532.808455] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[ 532.808468] CR2: fffffffffffffff8 CR3: 0000000001c0c000 CR4: 00000000000007e0
[ 532.808487] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 532.808504] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[ 532.808516] Process kworker/1:2 (pid: 930, threadinfo ffff880111eae000, task ffff88011318d680)
[ 532.808531] Stack:
[ 532.808549] ffff880111eaf808 ffffffff8107d428 ffff880111eaf808 ffff880111eae010
[ 532.808570] ffff880111eaf948 ffffffff8162231d ffff880111eae010 00000000001d1b00
[ 532.808596] 00000000001d1b00 ffff88011318d680 00000000001d1b00 ffff880111eaffd8
[ 532.808608] Call Trace:
[ 532.808618] [<ffffffff8107d428>] wq_worker_sleeping+0x18/0x130
[ 532.808639] [<ffffffff8162231d>] __schedule+0x92d/0xe00
[ 532.808651] [<ffffffff810d976d>] ? trace_hardirqs_on+0x1d/0x30
[ 532.808667] [<ffffffff812f43c0>] ? put_io_context+0xc0/0x110
[ 532.808682] [<ffffffff812f453b>] ? put_io_context_active+0x12b/0x1a0
[ 532.808705] [<ffffffff81622984>] schedule+0x34/0xc0
[ 532.808717] [<ffffffff8105f306>] do_exit+0x9a6/0xe60
[ 532.808732] [<ffffffff81057c38>] ? kmsg_dump+0x98/0x1e0
[ 532.808759] [<ffffffff8162698c>] oops_end+0x15c/0x160
[ 532.808775] [<ffffffff81008889>] die+0x79/0xd0
[ 532.808794] [<ffffffff81625fe8>] do_trap+0x1b8/0x1f0
[ 532.808813] [<ffffffff81005988>] do_invalid_op+0xb8/0x100
[ 532.808830] [<ffffffff811ec127>] ? shrink_dcache_for_umount_subtree+0x267/0x290
[ 532.808844] [<ffffffff81058d0e>] ? vprintk_emit+0x23e/0x820
[ 532.808856] [<ffffffff81326c0d>] ? trace_hardirqs_off_thunk+0x3a/0x3c
[ 532.808872] [<ffffffff81625720>] ? restore_args+0x30/0x30
[ 532.808886] [<ffffffff816302eb>] invalid_op+0x1b/0x20
[ 532.808916] [<ffffffff811ec127>] ? shrink_dcache_for_umount_subtree+0x267/0x290
[ 532.808933] [<ffffffff811ec19a>] shrink_dcache_for_umount+0x4a/0x90
[ 532.808952] [<ffffffff811cc3c7>] generic_shutdown_super+0x37/0x160
[ 532.808972] [<ffffffff811cc5d9>] kill_anon_super+0x19/0x40
[ 532.808986] [<ffffffff811cc63a>] kill_litter_super+0x3a/0x50
[ 532.809011] [<ffffffff810fb65a>] cgroup_kill_sb+0x20a/0x280
[ 532.809026] [<ffffffff811ccdc5>] deactivate_locked_super+0x65/0xb0
[ 532.809040] [<ffffffff811ce339>] deactivate_super+0x89/0xe0
[ 532.809056] [<ffffffff810f7734>] cgroup_d_release+0x34/0x40
[ 532.809070] [<ffffffff811eb258>] d_free+0x58/0xc0
[ 532.809083] [<ffffffff811ee5f0>] dput+0x220/0x350
[ 532.809095] [<ffffffff810f7429>] css_dput_fn+0x19/0x30
[ 532.809112] [<ffffffff8107b4d9>] process_one_work+0x239/0x800
[ 532.809128] [<ffffffff8107b450>] ? process_one_work+0x1b0/0x800
[ 532.809142] [<ffffffff810f7410>] ? cgroup_rename+0x70/0x70
[ 532.809170] [<ffffffff8107eba3>] worker_thread+0x2e3/0x710
[ 532.809190] [<ffffffff8107e8c0>] ? manage_workers+0x370/0x370
[ 532.809207] [<ffffffff81087e46>] kthread+0xd6/0xf0
[ 532.809234] [<ffffffff81630474>] kernel_thread_helper+0x4/0x10
[ 532.809254] [<ffffffff816256f0>] ? retint_restore_args+0x13/0x13
[ 532.809279] [<ffffffff81087d70>] ? __init_kthread_worker+0x80/0x80
[ 532.809291] [<ffffffff81630470>] ? gs_change+0x13/0x13
[ 532.809352] Code: 00 48 89 e5 8b 40 f0 c9 c3 66 66 66 66 66 66 2e 0f 1f 84 00 00 00 00 00 48 83 05 e0 46 71 01 01 55 48 8b 87 38 05 00 00 48 89 e5 <48> 8b 40 f8 c9 c3 0f 1f 80 00 00 00 00 55 48 3b 3d 78 46 71 01
[ 532.809369] RIP [<ffffffff81087573>] kthread_data+0x13/0x20
[ 532.809376] RSP <ffff880111eaf7e8>
[ 532.809381] CR2: fffffffffffffff8
[ 532.809390] ---[ end trace 1e5c705163c24a86 ]---
[ 532.809401] Fixing recursive fault but reboot is needed!
[ 592.820384] INFO: rcu_sched detected stalls on CPUs/tasks: { 1} (detected by 0, t=15002 jiffies)
[ 592.820402] INFO: Stall ended before state dump start
[ 609.100148] INFO: rcu_bh detected stalls on CPUs/tasks: { 1} (detected by 0, t=15002 jiffies)
[ 609.100168] INFO: Stall ended before state dump start
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: 3.5-rc3: BUG: Dentry still in use (1) [unmount of cgroup cgroup]
@ 2012-06-26 23:00 ` Masanari Iida
0 siblings, 0 replies; 35+ messages in thread
From: Masanari Iida @ 2012-06-26 23:00 UTC (permalink / raw)
To: shyju pv; +Cc: linux-kernel, cgroups, tj, Sanil kumar
Hello Shyju,
I have also encountered this symptom since 3.5-rc1.
Still exist on 3.5-rc4. The last known working is 3.4.
In my case, either "shutdown or reboot" or "service cgroup stop"
reproduce this symptom.
I have opened https://bugzilla.kernel.org/show_bug.cgi?id=43771
Masanari
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: 3.5-rc3: BUG: Dentry still in use (1) [unmount of cgroup cgroup]
@ 2012-06-26 23:00 ` Masanari Iida
0 siblings, 0 replies; 35+ messages in thread
From: Masanari Iida @ 2012-06-26 23:00 UTC (permalink / raw)
To: shyju pv
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
cgroups-u79uwXL29TY76Z2rM5mHXA, tj-DgEjT+Ai2ygdnm+yROfE0A,
Sanil kumar
Hello Shyju,
I have also encountered this symptom since 3.5-rc1.
Still exist on 3.5-rc4. The last known working is 3.4.
In my case, either "shutdown or reboot" or "service cgroup stop"
reproduce this symptom.
I have opened https://bugzilla.kernel.org/show_bug.cgi?id=43771
Masanari
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: 3.5-rc3: BUG: Dentry still in use (1) [unmount of cgroup cgroup]
@ 2012-06-27 18:29 ` tj-DgEjT+Ai2ygdnm+yROfE0A
0 siblings, 0 replies; 35+ messages in thread
From: tj @ 2012-06-27 18:29 UTC (permalink / raw)
To: shyju pv; +Cc: linux-kernel, cgroups, Sanil kumar, Masanari Iida, Li Zefan
On Sun, Jun 24, 2012 at 07:08:07PM +0000, shyju pv wrote:
> Hi,
> Observed a crash on 3.5-rc3 with cgroup tests from LTP(Stable April,2012 release)on Dell Inspiron 1526[Intel(R) Core2Duo T7250, MEM 4GB] and also on another x86 quad core target(4GB RAM).
> LTP test case: cgroup_regression_test.sh(test 4,7 and 9 crashes randomly when the test cases are executed in order)
> Shyju
>
> [ 532.805905] BUG: Dentry ffff8801164db490{i=491b,n=/} still in use (1) [unmount of cgroup cgrou
Hmm... fa980ca87d "cgroup: superblock can't be released with active
dentries" is supposed to have fixed that. Looking into it.
Thanks.
--
tejun
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: 3.5-rc3: BUG: Dentry still in use (1) [unmount of cgroup cgroup]
@ 2012-06-27 18:29 ` tj-DgEjT+Ai2ygdnm+yROfE0A
0 siblings, 0 replies; 35+ messages in thread
From: tj-DgEjT+Ai2ygdnm+yROfE0A @ 2012-06-27 18:29 UTC (permalink / raw)
To: shyju pv
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
cgroups-u79uwXL29TY76Z2rM5mHXA, Sanil kumar, Masanari Iida,
Li Zefan
On Sun, Jun 24, 2012 at 07:08:07PM +0000, shyju pv wrote:
> Hi,
> Observed a crash on 3.5-rc3 with cgroup tests from LTP(Stable April,2012 release)on Dell Inspiron 1526[Intel(R) Core2Duo T7250, MEM 4GB] and also on another x86 quad core target(4GB RAM).
> LTP test case: cgroup_regression_test.sh(test 4,7 and 9 crashes randomly when the test cases are executed in order)
> Shyju
>
> [ 532.805905] BUG: Dentry ffff8801164db490{i=491b,n=/} still in use (1) [unmount of cgroup cgrou
Hmm... fa980ca87d "cgroup: superblock can't be released with active
dentries" is supposed to have fixed that. Looking into it.
Thanks.
--
tejun
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: 3.5-rc3: BUG: Dentry still in use (1) [unmount of cgroup cgroup]
@ 2012-06-27 23:02 ` tj-DgEjT+Ai2ygdnm+yROfE0A
0 siblings, 0 replies; 35+ messages in thread
From: tj @ 2012-06-27 23:02 UTC (permalink / raw)
To: shyju pv; +Cc: linux-kernel, cgroups, Sanil kumar, Masanari Iida, Li Zefan
Hello,
Does the following patch make the problem go away?
Thank you.
diff --git a/kernel/cgroup.c b/kernel/cgroup.c
index 2097684..f9556cf 100644
--- a/kernel/cgroup.c
+++ b/kernel/cgroup.c
@@ -3644,6 +3644,7 @@ static void cgroup_event_remove(struct work_struct *work)
eventfd_ctx_put(event->eventfd);
kfree(event);
dput(cgrp->dentry);
+ deactivate_super(cgrp->root->sb);
}
/*
@@ -3770,6 +3771,7 @@ static int cgroup_write_event_control(struct cgroup *cgrp, struct cftype *cft,
* destroying subsystem state objects. Let's take reference to cgroup
* directory dentry to do that.
*/
+ atomic_inc(&cgrp->root->sb->s_active);
dget(cgrp->dentry);
spin_lock(&cgrp->event_list_lock);
^ permalink raw reply related [flat|nested] 35+ messages in thread
* Re: 3.5-rc3: BUG: Dentry still in use (1) [unmount of cgroup cgroup]
@ 2012-06-27 23:02 ` tj-DgEjT+Ai2ygdnm+yROfE0A
0 siblings, 0 replies; 35+ messages in thread
From: tj-DgEjT+Ai2ygdnm+yROfE0A @ 2012-06-27 23:02 UTC (permalink / raw)
To: shyju pv
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
cgroups-u79uwXL29TY76Z2rM5mHXA, Sanil kumar, Masanari Iida,
Li Zefan
Hello,
Does the following patch make the problem go away?
Thank you.
diff --git a/kernel/cgroup.c b/kernel/cgroup.c
index 2097684..f9556cf 100644
--- a/kernel/cgroup.c
+++ b/kernel/cgroup.c
@@ -3644,6 +3644,7 @@ static void cgroup_event_remove(struct work_struct *work)
eventfd_ctx_put(event->eventfd);
kfree(event);
dput(cgrp->dentry);
+ deactivate_super(cgrp->root->sb);
}
/*
@@ -3770,6 +3771,7 @@ static int cgroup_write_event_control(struct cgroup *cgrp, struct cftype *cft,
* destroying subsystem state objects. Let's take reference to cgroup
* directory dentry to do that.
*/
+ atomic_inc(&cgrp->root->sb->s_active);
dget(cgrp->dentry);
spin_lock(&cgrp->event_list_lock);
^ permalink raw reply related [flat|nested] 35+ messages in thread
* Re: 3.5-rc3: BUG: Dentry still in use (1) [unmount of cgroup cgroup]
2012-06-27 18:29 ` tj-DgEjT+Ai2ygdnm+yROfE0A
(?)
(?)
@ 2012-06-28 6:07 ` Li Zefan
-1 siblings, 0 replies; 35+ messages in thread
From: Li Zefan @ 2012-06-28 6:07 UTC (permalink / raw)
To: tj; +Cc: shyju pv, linux-kernel, cgroups, Sanil kumar, Masanari Iida
tj@kernel.org wrote:
> On Sun, Jun 24, 2012 at 07:08:07PM +0000, shyju pv wrote:
>> Hi,
>> Observed a crash on 3.5-rc3 with cgroup tests from LTP(Stable April,2012 release)on Dell Inspiron 1526[Intel(R) Core2Duo T7250, MEM 4GB] and also on another x86 quad core target(4GB RAM).
>> LTP test case: cgroup_regression_test.sh(test 4,7 and 9 crashes randomly when the test cases are executed in order)
I wrote thoese test scripts. ;)
>> Shyju
>>
>> [ 532.805905] BUG: Dentry ffff8801164db490{i=491b,n=/} still in use (1) [unmount of cgroup cgrou
>
> Hmm... fa980ca87d "cgroup: superblock can't be released with active
> dentries" is supposed to have fixed that. Looking into it.
>
I think I know what happened here:
umount
deativate_super(sb)
dput(subdir)
subdir->d_count--
d_release(subdir)
deactivate_super(sb)
shrink_dcache_for_umount(sb)
BUG(root->d_count)!!
root->d_count--
I use this script to reproduce the bug:
mount -t cgroup -o cpu xxx /mnt
mkdir /mnt/sub
sleep 100 < /mnt/sub &
kill $!
wait $!
umount /mnt
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: 3.5-rc3: BUG: Dentry still in use (1) [unmount of cgroup cgroup]
2012-06-27 18:29 ` tj-DgEjT+Ai2ygdnm+yROfE0A
` (2 preceding siblings ...)
(?)
@ 2012-06-28 6:07 ` Li Zefan
2012-06-28 18:07 ` tj-DgEjT+Ai2ygdnm+yROfE0A
-1 siblings, 1 reply; 35+ messages in thread
From: Li Zefan @ 2012-06-28 6:07 UTC (permalink / raw)
To: tj; +Cc: shyju pv, linux-kernel, cgroups, Sanil kumar, Masanari Iida
tj@kernel.org wrote:
> On Sun, Jun 24, 2012 at 07:08:07PM +0000, shyju pv wrote:
>> Hi,
>> Observed a crash on 3.5-rc3 with cgroup tests from LTP(Stable April,2012 release)on Dell Inspiron 1526[Intel(R) Core2Duo T7250, MEM 4GB] and also on another x86 quad core target(4GB RAM).
>> LTP test case: cgroup_regression_test.sh(test 4,7 and 9 crashes randomly when the test cases are executed in order)
I wrote thoese test scripts. ;)
>> Shyju
>>
>> [ 532.805905] BUG: Dentry ffff8801164db490{i=491b,n=/} still in use (1) [unmount of cgroup cgrou
>
> Hmm... fa980ca87d "cgroup: superblock can't be released with active
> dentries" is supposed to have fixed that. Looking into it.
>
I think I know what happened here:
umount
deativate_super(sb)
dput(subdir)
subdir->d_count--
d_release(subdir)
deactivate_super(sb)
shrink_dcache_for_umount(sb)
BUG(root->d_count)!!
root->d_count--
I use this script to reproduce the bug:
mount -t cgroup -o cpu xxx /mnt
mkdir /mnt/sub
sleep 100 < /mnt/sub &
kill $!
wait $!
rmdir /mnt/sub
umount /mnt
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: 3.5-rc3: BUG: Dentry still in use (1) [unmount of cgroup cgroup]
@ 2012-06-28 14:09 ` Masanari Iida
0 siblings, 0 replies; 35+ messages in thread
From: Masanari Iida @ 2012-06-28 14:09 UTC (permalink / raw)
To: tj; +Cc: shyju pv, linux-kernel, cgroups, Sanil kumar, Li Zefan
Hello
I have applied this patch on 3.5-rc4, and tested.
It didn't fix the symptom. :(
Masanari
On Thu, Jun 28, 2012 at 8:02 AM, tj@kernel.org <tj@kernel.org> wrote:
> Hello,
>
> Does the following patch make the problem go away?
>
> Thank you.
>
> diff --git a/kernel/cgroup.c b/kernel/cgroup.c
> index 2097684..f9556cf 100644
> --- a/kernel/cgroup.c
> +++ b/kernel/cgroup.c
> @@ -3644,6 +3644,7 @@ static void cgroup_event_remove(struct work_struct *work)
> eventfd_ctx_put(event->eventfd);
> kfree(event);
> dput(cgrp->dentry);
> + deactivate_super(cgrp->root->sb);
> }
>
> /*
> @@ -3770,6 +3771,7 @@ static int cgroup_write_event_control(struct cgroup *cgrp, struct cftype *cft,
> * destroying subsystem state objects. Let's take reference to cgroup
> * directory dentry to do that.
> */
> + atomic_inc(&cgrp->root->sb->s_active);
> dget(cgrp->dentry);
>
> spin_lock(&cgrp->event_list_lock);
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: 3.5-rc3: BUG: Dentry still in use (1) [unmount of cgroup cgroup]
@ 2012-06-28 14:09 ` Masanari Iida
0 siblings, 0 replies; 35+ messages in thread
From: Masanari Iida @ 2012-06-28 14:09 UTC (permalink / raw)
To: tj-DgEjT+Ai2ygdnm+yROfE0A
Cc: shyju pv, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
cgroups-u79uwXL29TY76Z2rM5mHXA, Sanil kumar, Li Zefan
Hello
I have applied this patch on 3.5-rc4, and tested.
It didn't fix the symptom. :(
Masanari
On Thu, Jun 28, 2012 at 8:02 AM, tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
> Hello,
>
> Does the following patch make the problem go away?
>
> Thank you.
>
> diff --git a/kernel/cgroup.c b/kernel/cgroup.c
> index 2097684..f9556cf 100644
> --- a/kernel/cgroup.c
> +++ b/kernel/cgroup.c
> @@ -3644,6 +3644,7 @@ static void cgroup_event_remove(struct work_struct *work)
> eventfd_ctx_put(event->eventfd);
> kfree(event);
> dput(cgrp->dentry);
> + deactivate_super(cgrp->root->sb);
> }
>
> /*
> @@ -3770,6 +3771,7 @@ static int cgroup_write_event_control(struct cgroup *cgrp, struct cftype *cft,
> * destroying subsystem state objects. Let's take reference to cgroup
> * directory dentry to do that.
> */
> + atomic_inc(&cgrp->root->sb->s_active);
> dget(cgrp->dentry);
>
> spin_lock(&cgrp->event_list_lock);
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: 3.5-rc3: BUG: Dentry still in use (1) [unmount of cgroup cgroup]
@ 2012-06-28 18:07 ` tj-DgEjT+Ai2ygdnm+yROfE0A
0 siblings, 0 replies; 35+ messages in thread
From: tj @ 2012-06-28 18:07 UTC (permalink / raw)
To: Li Zefan; +Cc: shyju pv, linux-kernel, cgroups, Sanil kumar, Masanari Iida
Hello, Li.
On Thu, Jun 28, 2012 at 02:07:51PM +0800, Li Zefan wrote:
> > Hmm... fa980ca87d "cgroup: superblock can't be released with active
> > dentries" is supposed to have fixed that. Looking into it.
> >
>
>
> I think I know what happened here:
>
> umount
> deativate_super(sb)
> dput(subdir)
> subdir->d_count--
> d_release(subdir)
> deactivate_super(sb)
> shrink_dcache_for_umount(sb)
> BUG(root->d_count)!!
> root->d_count--
Can you please elaborate a bit? I'm not really following? Where does
the last root->d_count-- come from?
> I use this script to reproduce the bug:
>
> mount -t cgroup -o cpu xxx /mnt
> mkdir /mnt/sub
> sleep 100 < /mnt/sub &
> kill $!
> wait $!
> rmdir /mnt/sub
> umount /mnt
Unfortunately, this doesn't reproduce the bug here either. :(
Thanks.
--
tejun
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: 3.5-rc3: BUG: Dentry still in use (1) [unmount of cgroup cgroup]
@ 2012-06-28 18:07 ` tj-DgEjT+Ai2ygdnm+yROfE0A
0 siblings, 0 replies; 35+ messages in thread
From: tj-DgEjT+Ai2ygdnm+yROfE0A @ 2012-06-28 18:07 UTC (permalink / raw)
To: Li Zefan
Cc: shyju pv, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
cgroups-u79uwXL29TY76Z2rM5mHXA, Sanil kumar, Masanari Iida
Hello, Li.
On Thu, Jun 28, 2012 at 02:07:51PM +0800, Li Zefan wrote:
> > Hmm... fa980ca87d "cgroup: superblock can't be released with active
> > dentries" is supposed to have fixed that. Looking into it.
> >
>
>
> I think I know what happened here:
>
> umount
> deativate_super(sb)
> dput(subdir)
> subdir->d_count--
> d_release(subdir)
> deactivate_super(sb)
> shrink_dcache_for_umount(sb)
> BUG(root->d_count)!!
> root->d_count--
Can you please elaborate a bit? I'm not really following? Where does
the last root->d_count-- come from?
> I use this script to reproduce the bug:
>
> mount -t cgroup -o cpu xxx /mnt
> mkdir /mnt/sub
> sleep 100 < /mnt/sub &
> kill $!
> wait $!
> rmdir /mnt/sub
> umount /mnt
Unfortunately, this doesn't reproduce the bug here either. :(
Thanks.
--
tejun
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: 3.5-rc3: BUG: Dentry still in use (1) [unmount of cgroup cgroup]
@ 2012-06-29 2:20 ` Li Zefan
0 siblings, 0 replies; 35+ messages in thread
From: Li Zefan @ 2012-06-29 2:20 UTC (permalink / raw)
To: tj; +Cc: shyju pv, linux-kernel, cgroups, Sanil kumar, Masanari Iida
On 2012/6/29 2:07, tj@kernel.org wrote:
> Hello, Li.
>
> On Thu, Jun 28, 2012 at 02:07:51PM +0800, Li Zefan wrote:
>>> Hmm... fa980ca87d "cgroup: superblock can't be released with active
>>> dentries" is supposed to have fixed that. Looking into it.
>>>
>>
>>
>> I think I know what happened here:
>>
>> umount
>> deativate_super(sb)
>> dput(subdir)
>> subdir->d_count--
>> d_release(subdir)
>> deactivate_super(sb)
>> shrink_dcache_for_umount(sb)
>> BUG(root->d_count)!!
>> root->d_count--
>
> Can you please elaborate a bit? I'm not really following? Where does
> the last root->d_count-- come from?
>
>From my limited knowledge about vfs internal, seems the parent's refcnt won't go down
to 0 before its children. When mkdir, the parent's refcnt will be incremented, and
after rmdir, dput(subdir) will drop subdir's refcnt and then drop parent's.
So when dropping the subdir's refcnt and leading the superblock to be killed, the root's
dentry is still > 0.
>> I use this script to reproduce the bug:
>>
>> mount -t cgroup -o cpu xxx /mnt
>> mkdir /mnt/sub
>> sleep 100 < /mnt/sub &
>> kill $!
>> wait $!
>> rmdir /mnt/sub
>> umount /mnt
>
> Unfortunately, this doesn't reproduce the bug here either. :(
>
I can reproduce the bug reliably.. Try s/cpu/perf or s/cpu/net_cls, which have fewer
cgroup files?
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: 3.5-rc3: BUG: Dentry still in use (1) [unmount of cgroup cgroup]
@ 2012-06-29 2:20 ` Li Zefan
0 siblings, 0 replies; 35+ messages in thread
From: Li Zefan @ 2012-06-29 2:20 UTC (permalink / raw)
To: tj-DgEjT+Ai2ygdnm+yROfE0A
Cc: shyju pv, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
cgroups-u79uwXL29TY76Z2rM5mHXA, Sanil kumar, Masanari Iida
On 2012/6/29 2:07, tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org wrote:
> Hello, Li.
>
> On Thu, Jun 28, 2012 at 02:07:51PM +0800, Li Zefan wrote:
>>> Hmm... fa980ca87d "cgroup: superblock can't be released with active
>>> dentries" is supposed to have fixed that. Looking into it.
>>>
>>
>>
>> I think I know what happened here:
>>
>> umount
>> deativate_super(sb)
>> dput(subdir)
>> subdir->d_count--
>> d_release(subdir)
>> deactivate_super(sb)
>> shrink_dcache_for_umount(sb)
>> BUG(root->d_count)!!
>> root->d_count--
>
> Can you please elaborate a bit? I'm not really following? Where does
> the last root->d_count-- come from?
>
From my limited knowledge about vfs internal, seems the parent's refcnt won't go down
to 0 before its children. When mkdir, the parent's refcnt will be incremented, and
after rmdir, dput(subdir) will drop subdir's refcnt and then drop parent's.
So when dropping the subdir's refcnt and leading the superblock to be killed, the root's
dentry is still > 0.
>> I use this script to reproduce the bug:
>>
>> mount -t cgroup -o cpu xxx /mnt
>> mkdir /mnt/sub
>> sleep 100 < /mnt/sub &
>> kill $!
>> wait $!
>> rmdir /mnt/sub
>> umount /mnt
>
> Unfortunately, this doesn't reproduce the bug here either. :(
>
I can reproduce the bug reliably.. Try s/cpu/perf or s/cpu/net_cls, which have fewer
cgroup files?
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: 3.5-rc3: BUG: Dentry still in use (1) [unmount of cgroup cgroup]
@ 2012-06-29 16:58 ` tj-DgEjT+Ai2ygdnm+yROfE0A
0 siblings, 0 replies; 35+ messages in thread
From: tj @ 2012-06-29 16:58 UTC (permalink / raw)
To: Li Zefan; +Cc: shyju pv, linux-kernel, cgroups, Sanil kumar, Masanari Iida
Hey,
On Fri, Jun 29, 2012 at 10:20:11AM +0800, Li Zefan wrote:
> > Can you please elaborate a bit? I'm not really following? Where does
> > the last root->d_count-- come from?
>
>
> From my limited knowledge about vfs internal, seems the parent's refcnt won't go down
> to 0 before its children. When mkdir, the parent's refcnt will be incremented, and
> after rmdir, dput(subdir) will drop subdir's refcnt and then drop parent's.
>
> So when dropping the subdir's refcnt and leading the superblock to be killed, the root's
> dentry is still > 0.
Heh, yeah, I thought you found who was holding out on the refcnt. :)
> >> I use this script to reproduce the bug:
> >>
> >> mount -t cgroup -o cpu xxx /mnt
> >> mkdir /mnt/sub
> >> sleep 100 < /mnt/sub &
> >> kill $!
> >> wait $!
> >> rmdir /mnt/sub
> >> umount /mnt
> > Unfortunately, this doesn't reproduce the bug here either. :(
>
> I can reproduce the bug reliably.. Try s/cpu/perf or s/cpu/net_cls, which have fewer
> cgroup files?
Hmm... weird. Maybe some debug config option I have is preventing the
race from occurring as reliably? Can you please attach your .config?
Thanks.
--
tejun
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: 3.5-rc3: BUG: Dentry still in use (1) [unmount of cgroup cgroup]
@ 2012-06-29 16:58 ` tj-DgEjT+Ai2ygdnm+yROfE0A
0 siblings, 0 replies; 35+ messages in thread
From: tj-DgEjT+Ai2ygdnm+yROfE0A @ 2012-06-29 16:58 UTC (permalink / raw)
To: Li Zefan
Cc: shyju pv, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
cgroups-u79uwXL29TY76Z2rM5mHXA, Sanil kumar, Masanari Iida
Hey,
On Fri, Jun 29, 2012 at 10:20:11AM +0800, Li Zefan wrote:
> > Can you please elaborate a bit? I'm not really following? Where does
> > the last root->d_count-- come from?
>
>
> From my limited knowledge about vfs internal, seems the parent's refcnt won't go down
> to 0 before its children. When mkdir, the parent's refcnt will be incremented, and
> after rmdir, dput(subdir) will drop subdir's refcnt and then drop parent's.
>
> So when dropping the subdir's refcnt and leading the superblock to be killed, the root's
> dentry is still > 0.
Heh, yeah, I thought you found who was holding out on the refcnt. :)
> >> I use this script to reproduce the bug:
> >>
> >> mount -t cgroup -o cpu xxx /mnt
> >> mkdir /mnt/sub
> >> sleep 100 < /mnt/sub &
> >> kill $!
> >> wait $!
> >> rmdir /mnt/sub
> >> umount /mnt
> > Unfortunately, this doesn't reproduce the bug here either. :(
>
> I can reproduce the bug reliably.. Try s/cpu/perf or s/cpu/net_cls, which have fewer
> cgroup files?
Hmm... weird. Maybe some debug config option I have is preventing the
race from occurring as reliably? Can you please attach your .config?
Thanks.
--
tejun
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: 3.5-rc3: BUG: Dentry still in use (1) [unmount of cgroup cgroup]
2012-06-29 16:58 ` tj-DgEjT+Ai2ygdnm+yROfE0A
(?)
@ 2012-06-29 18:07 ` Masanari Iida
-1 siblings, 0 replies; 35+ messages in thread
From: Masanari Iida @ 2012-06-29 18:07 UTC (permalink / raw)
To: tj; +Cc: Li Zefan, shyju pv, linux-kernel, cgroups, Sanil kumar
[-- Attachment #1: Type: text/plain, Size: 253 bytes --]
Hi Tejun,
Attached gziped .config file.
Regards,
Masanari
>
> Hmm... weird. Maybe some debug config option I have is preventing the
> race from occurring as reliably? Can you please attach your .config?
>
> Thanks.
>
> --
> tejun
[-- Attachment #2: config.gz --]
[-- Type: application/x-gzip, Size: 26728 bytes --]
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: 3.5-rc3: BUG: Dentry still in use (1) [unmount of cgroup cgroup]
@ 2012-06-30 6:13 ` Li Zefan
0 siblings, 0 replies; 35+ messages in thread
From: Li Zefan @ 2012-06-30 6:13 UTC (permalink / raw)
To: tj; +Cc: shyju pv, linux-kernel, cgroups, Sanil kumar, Masanari Iida
On 2012/6/30 0:58, tj@kernel.org wrote:
> Hey,
>
> On Fri, Jun 29, 2012 at 10:20:11AM +0800, Li Zefan wrote:
>>> Can you please elaborate a bit? I'm not really following? Where does
>>> the last root->d_count-- come from?
>>
>>
>> From my limited knowledge about vfs internal, seems the parent's refcnt won't go down
>> to 0 before its children. When mkdir, the parent's refcnt will be incremented, and
>> after rmdir, dput(subdir) will drop subdir's refcnt and then drop parent's.
>>
>> So when dropping the subdir's refcnt and leading the superblock to be killed, the root's
>> dentry is still > 0.
>
> Heh, yeah, I thought you found who was holding out on the refcnt. :)
>
dput will drop both the subdir and the root's dentry refcnt, but kill_sb will be called
inbetween.
So it's bad to have dentry refcnts dangling after umount. I've made a patch so css will
pin cgroup instead of cgroup dentry.
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: 3.5-rc3: BUG: Dentry still in use (1) [unmount of cgroup cgroup]
@ 2012-06-30 6:13 ` Li Zefan
0 siblings, 0 replies; 35+ messages in thread
From: Li Zefan @ 2012-06-30 6:13 UTC (permalink / raw)
To: tj-DgEjT+Ai2ygdnm+yROfE0A
Cc: shyju pv, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
cgroups-u79uwXL29TY76Z2rM5mHXA, Sanil kumar, Masanari Iida
On 2012/6/30 0:58, tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org wrote:
> Hey,
>
> On Fri, Jun 29, 2012 at 10:20:11AM +0800, Li Zefan wrote:
>>> Can you please elaborate a bit? I'm not really following? Where does
>>> the last root->d_count-- come from?
>>
>>
>> From my limited knowledge about vfs internal, seems the parent's refcnt won't go down
>> to 0 before its children. When mkdir, the parent's refcnt will be incremented, and
>> after rmdir, dput(subdir) will drop subdir's refcnt and then drop parent's.
>>
>> So when dropping the subdir's refcnt and leading the superblock to be killed, the root's
>> dentry is still > 0.
>
> Heh, yeah, I thought you found who was holding out on the refcnt. :)
>
dput will drop both the subdir and the root's dentry refcnt, but kill_sb will be called
inbetween.
So it's bad to have dentry refcnts dangling after umount. I've made a patch so css will
pin cgroup instead of cgroup dentry.
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: 3.5-rc3: BUG: Dentry still in use (1) [unmount of cgroup cgroup]
@ 2012-06-30 6:47 ` Al Viro
0 siblings, 0 replies; 35+ messages in thread
From: Al Viro @ 2012-06-30 6:47 UTC (permalink / raw)
To: Li Zefan; +Cc: tj, shyju pv, linux-kernel, cgroups, Sanil kumar, Masanari Iida
On Sat, Jun 30, 2012 at 02:13:02PM +0800, Li Zefan wrote:
> dput will drop both the subdir and the root's dentry refcnt, but kill_sb will be called
> inbetween.
????!!!!??!?!?
> So it's bad to have dentry refcnts dangling after umount.
No shit. Yes, it is bad. What on the Earth is cgroup code doing with
those? And what could it possibly want to do with dentry reference
after the filesystem has been shut down, assuming it could hold one
in the first place?
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: 3.5-rc3: BUG: Dentry still in use (1) [unmount of cgroup cgroup]
@ 2012-06-30 6:47 ` Al Viro
0 siblings, 0 replies; 35+ messages in thread
From: Al Viro @ 2012-06-30 6:47 UTC (permalink / raw)
To: Li Zefan
Cc: tj-DgEjT+Ai2ygdnm+yROfE0A, shyju pv,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
cgroups-u79uwXL29TY76Z2rM5mHXA, Sanil kumar, Masanari Iida
On Sat, Jun 30, 2012 at 02:13:02PM +0800, Li Zefan wrote:
> dput will drop both the subdir and the root's dentry refcnt, but kill_sb will be called
> inbetween.
????!!!!??!?!?
> So it's bad to have dentry refcnts dangling after umount.
No shit. Yes, it is bad. What on the Earth is cgroup code doing with
those? And what could it possibly want to do with dentry reference
after the filesystem has been shut down, assuming it could hold one
in the first place?
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: 3.5-rc3: BUG: Dentry still in use (1) [unmount of cgroup cgroup]
@ 2012-06-30 7:04 ` Tejun Heo
0 siblings, 0 replies; 35+ messages in thread
From: Tejun Heo @ 2012-06-30 7:04 UTC (permalink / raw)
To: Al Viro
Cc: Li Zefan, shyju pv, linux-kernel, cgroups, Sanil kumar, Masanari Iida
Hello, Al.
On Fri, Jun 29, 2012 at 11:47 PM, Al Viro <viro@zeniv.linux.org.uk> wrote:
> On Sat, Jun 30, 2012 at 02:13:02PM +0800, Li Zefan wrote:
>> So it's bad to have dentry refcnts dangling after umount.
>
> No shit. Yes, it is bad. What on the Earth is cgroup code doing with
> those? And what could it possibly want to do with dentry reference
> after the filesystem has been shut down, assuming it could hold one
> in the first place?
cgroup interface code was copied from sysfs back when it was
piggybacking internal data structures to dentries, so, unfortunately,
sysfs is still using dentries to manage internal data structures and
propagates internal refs to dentry refs. There seem to be several
places where dentry ref is held w/o active super ref triggering BUG on
umount. Longer term, it should be updated to share sysfs code, I
guess.
Thanks.
--
tejun
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: 3.5-rc3: BUG: Dentry still in use (1) [unmount of cgroup cgroup]
@ 2012-06-30 7:04 ` Tejun Heo
0 siblings, 0 replies; 35+ messages in thread
From: Tejun Heo @ 2012-06-30 7:04 UTC (permalink / raw)
To: Al Viro
Cc: Li Zefan, shyju pv, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
cgroups-u79uwXL29TY76Z2rM5mHXA, Sanil kumar, Masanari Iida
Hello, Al.
On Fri, Jun 29, 2012 at 11:47 PM, Al Viro <viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn@public.gmane.org> wrote:
> On Sat, Jun 30, 2012 at 02:13:02PM +0800, Li Zefan wrote:
>> So it's bad to have dentry refcnts dangling after umount.
>
> No shit. Yes, it is bad. What on the Earth is cgroup code doing with
> those? And what could it possibly want to do with dentry reference
> after the filesystem has been shut down, assuming it could hold one
> in the first place?
cgroup interface code was copied from sysfs back when it was
piggybacking internal data structures to dentries, so, unfortunately,
sysfs is still using dentries to manage internal data structures and
propagates internal refs to dentry refs. There seem to be several
places where dentry ref is held w/o active super ref triggering BUG on
umount. Longer term, it should be updated to share sysfs code, I
guess.
Thanks.
--
tejun
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: 3.5-rc3: BUG: Dentry still in use (1) [unmount of cgroup cgroup]
@ 2012-06-30 8:34 ` Al Viro
0 siblings, 0 replies; 35+ messages in thread
From: Al Viro @ 2012-06-30 8:34 UTC (permalink / raw)
To: Tejun Heo
Cc: Li Zefan, shyju pv, linux-kernel, cgroups, Sanil kumar, Masanari Iida
On Sat, Jun 30, 2012 at 12:04:36AM -0700, Tejun Heo wrote:
> Hello, Al.
>
> On Fri, Jun 29, 2012 at 11:47 PM, Al Viro <viro@zeniv.linux.org.uk> wrote:
> > On Sat, Jun 30, 2012 at 02:13:02PM +0800, Li Zefan wrote:
> >> So it's bad to have dentry refcnts dangling after umount.
> >
> > No shit. ?Yes, it is bad. ?What on the Earth is cgroup code doing with
> > those? ?And what could it possibly want to do with dentry reference
> > after the filesystem has been shut down, assuming it could hold one
> > in the first place?
>
> cgroup interface code was copied from sysfs back when it was
> piggybacking internal data structures to dentries, so, unfortunately,
> sysfs is still using dentries to manage internal data structures and
> propagates internal refs to dentry refs. There seem to be several
> places where dentry ref is held w/o active super ref triggering BUG on
> umount. Longer term, it should be updated to share sysfs code, I
> guess.
Now that I've looked at that code again... What's the story with
simple_unlink(d->d_inode, d);
in cgroup_rm_file()? Wrong parent inode, at the very least...
While we are at it, what the hell is going on in
static void cgroup_clear_directory(struct dentry *dir)
{
struct cgroup *cgrp = __d_cgrp(dir);
while (!list_empty(&cgrp->files))
cgroup_rm_file(cgrp, NULL);
}
Are you fighting some kind of race against somebody adding stuff
there? Unless I'm seriously misreading cgroup_rm_file(), it'll
do all the work on the first call...
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: 3.5-rc3: BUG: Dentry still in use (1) [unmount of cgroup cgroup]
@ 2012-06-30 8:34 ` Al Viro
0 siblings, 0 replies; 35+ messages in thread
From: Al Viro @ 2012-06-30 8:34 UTC (permalink / raw)
To: Tejun Heo
Cc: Li Zefan, shyju pv, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
cgroups-u79uwXL29TY76Z2rM5mHXA, Sanil kumar, Masanari Iida
On Sat, Jun 30, 2012 at 12:04:36AM -0700, Tejun Heo wrote:
> Hello, Al.
>
> On Fri, Jun 29, 2012 at 11:47 PM, Al Viro <viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn@public.gmane.org> wrote:
> > On Sat, Jun 30, 2012 at 02:13:02PM +0800, Li Zefan wrote:
> >> So it's bad to have dentry refcnts dangling after umount.
> >
> > No shit. ?Yes, it is bad. ?What on the Earth is cgroup code doing with
> > those? ?And what could it possibly want to do with dentry reference
> > after the filesystem has been shut down, assuming it could hold one
> > in the first place?
>
> cgroup interface code was copied from sysfs back when it was
> piggybacking internal data structures to dentries, so, unfortunately,
> sysfs is still using dentries to manage internal data structures and
> propagates internal refs to dentry refs. There seem to be several
> places where dentry ref is held w/o active super ref triggering BUG on
> umount. Longer term, it should be updated to share sysfs code, I
> guess.
Now that I've looked at that code again... What's the story with
simple_unlink(d->d_inode, d);
in cgroup_rm_file()? Wrong parent inode, at the very least...
While we are at it, what the hell is going on in
static void cgroup_clear_directory(struct dentry *dir)
{
struct cgroup *cgrp = __d_cgrp(dir);
while (!list_empty(&cgrp->files))
cgroup_rm_file(cgrp, NULL);
}
Are you fighting some kind of race against somebody adding stuff
there? Unless I'm seriously misreading cgroup_rm_file(), it'll
do all the work on the first call...
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: 3.5-rc3: BUG: Dentry still in use (1) [unmount of cgroup cgroup]
@ 2012-07-03 17:10 ` Tejun Heo
0 siblings, 0 replies; 35+ messages in thread
From: Tejun Heo @ 2012-07-03 17:10 UTC (permalink / raw)
To: Al Viro
Cc: Li Zefan, shyju pv, linux-kernel, cgroups, Sanil kumar, Masanari Iida
Hello, Al.
On Sat, Jun 30, 2012 at 09:34:21AM +0100, Al Viro wrote:
> Now that I've looked at that code again... What's the story with
> simple_unlink(d->d_inode, d);
> in cgroup_rm_file()? Wrong parent inode, at the very least...
Yeah, indeed. My mistake while refactoring the code. Will fix.
> While we are at it, what the hell is going on in
> static void cgroup_clear_directory(struct dentry *dir)
> {
> struct cgroup *cgrp = __d_cgrp(dir);
>
> while (!list_empty(&cgrp->files))
> cgroup_rm_file(cgrp, NULL);
> }
> Are you fighting some kind of race against somebody adding stuff
> there? Unless I'm seriously misreading cgroup_rm_file(), it'll
> do all the work on the first call...
cgroup_rm_file() finds the file matching @cft, deletes that one file
and returns. Passing in %NULL @cft makes it deletes the first file
but it still returns after deleting one. Maybe breaking up
list_for_each_entry() so that deletion and returning is outside the
loop would make that clearer.
Thanks.
--
tejun
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: 3.5-rc3: BUG: Dentry still in use (1) [unmount of cgroup cgroup]
@ 2012-07-03 17:10 ` Tejun Heo
0 siblings, 0 replies; 35+ messages in thread
From: Tejun Heo @ 2012-07-03 17:10 UTC (permalink / raw)
To: Al Viro
Cc: Li Zefan, shyju pv, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
cgroups-u79uwXL29TY76Z2rM5mHXA, Sanil kumar, Masanari Iida
Hello, Al.
On Sat, Jun 30, 2012 at 09:34:21AM +0100, Al Viro wrote:
> Now that I've looked at that code again... What's the story with
> simple_unlink(d->d_inode, d);
> in cgroup_rm_file()? Wrong parent inode, at the very least...
Yeah, indeed. My mistake while refactoring the code. Will fix.
> While we are at it, what the hell is going on in
> static void cgroup_clear_directory(struct dentry *dir)
> {
> struct cgroup *cgrp = __d_cgrp(dir);
>
> while (!list_empty(&cgrp->files))
> cgroup_rm_file(cgrp, NULL);
> }
> Are you fighting some kind of race against somebody adding stuff
> there? Unless I'm seriously misreading cgroup_rm_file(), it'll
> do all the work on the first call...
cgroup_rm_file() finds the file matching @cft, deletes that one file
and returns. Passing in %NULL @cft makes it deletes the first file
but it still returns after deleting one. Maybe breaking up
list_for_each_entry() so that deletion and returning is outside the
loop would make that clearer.
Thanks.
--
tejun
^ permalink raw reply [flat|nested] 35+ messages in thread
* [PATCH] cgroup: cgroup_rm_files() was calling simple_unlink() with the wrong inode
@ 2012-07-03 17:38 ` Tejun Heo
0 siblings, 0 replies; 35+ messages in thread
From: Tejun Heo @ 2012-07-03 17:38 UTC (permalink / raw)
To: Al Viro
Cc: Li Zefan, shyju pv, linux-kernel, cgroups, Sanil kumar, Masanari Iida
>From 6da2689412c78b97716ec524cc30baf7b46508cd Mon Sep 17 00:00:00 2001
From: Tejun Heo <tj@kernel.org>
Date: Tue, 3 Jul 2012 10:32:26 -0700
While refactoring cgroup file removal path, 05ef1d7c4a "cgroup:
introduce struct cfent" incorrectly changed the @dir argument of
simple_unlink() to the inode of the file being deleted instead of that
of the containing directory.
The effect of this bug is minor - ctime and mtime of the parent
weren't properly updated on file deletion.
Fix it by using @cgrp->dentry->d_inode instead.
Signed-off-by: Tejun Heo <tj@kernel.org>
Reported-by: Al Viro <viro@ZenIV.linux.org.uk>
---
Will commit to cgroup/for-3.5-fixes. Li, can you please ack this?
Thanks.
kernel/cgroup.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/kernel/cgroup.c b/kernel/cgroup.c
index 2097684..b214fc2 100644
--- a/kernel/cgroup.c
+++ b/kernel/cgroup.c
@@ -964,7 +964,7 @@ static int cgroup_rm_file(struct cgroup *cgrp, const struct cftype *cft)
dget(d);
d_delete(d);
- simple_unlink(d->d_inode, d);
+ simple_unlink(cgrp->dentry->d_inode, d);
list_del_init(&cfe->node);
dput(d);
--
1.7.7.3
^ permalink raw reply related [flat|nested] 35+ messages in thread
* [PATCH] cgroup: cgroup_rm_files() was calling simple_unlink() with the wrong inode
@ 2012-07-03 17:38 ` Tejun Heo
0 siblings, 0 replies; 35+ messages in thread
From: Tejun Heo @ 2012-07-03 17:38 UTC (permalink / raw)
To: Al Viro
Cc: Li Zefan, shyju pv, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
cgroups-u79uwXL29TY76Z2rM5mHXA, Sanil kumar, Masanari Iida
From 6da2689412c78b97716ec524cc30baf7b46508cd Mon Sep 17 00:00:00 2001
From: Tejun Heo <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Date: Tue, 3 Jul 2012 10:32:26 -0700
While refactoring cgroup file removal path, 05ef1d7c4a "cgroup:
introduce struct cfent" incorrectly changed the @dir argument of
simple_unlink() to the inode of the file being deleted instead of that
of the containing directory.
The effect of this bug is minor - ctime and mtime of the parent
weren't properly updated on file deletion.
Fix it by using @cgrp->dentry->d_inode instead.
Signed-off-by: Tejun Heo <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Reported-by: Al Viro <viro-3bDd1+5oDREiFSDQTTA3OLVCufUGDwFn@public.gmane.org>
---
Will commit to cgroup/for-3.5-fixes. Li, can you please ack this?
Thanks.
kernel/cgroup.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/kernel/cgroup.c b/kernel/cgroup.c
index 2097684..b214fc2 100644
--- a/kernel/cgroup.c
+++ b/kernel/cgroup.c
@@ -964,7 +964,7 @@ static int cgroup_rm_file(struct cgroup *cgrp, const struct cftype *cft)
dget(d);
d_delete(d);
- simple_unlink(d->d_inode, d);
+ simple_unlink(cgrp->dentry->d_inode, d);
list_del_init(&cfe->node);
dput(d);
--
1.7.7.3
^ permalink raw reply related [flat|nested] 35+ messages in thread
* Re: [PATCH] cgroup: cgroup_rm_files() was calling simple_unlink() with the wrong inode
@ 2012-07-04 5:40 ` Li Zefan
0 siblings, 0 replies; 35+ messages in thread
From: Li Zefan @ 2012-07-04 5:40 UTC (permalink / raw)
To: Tejun Heo
Cc: Al Viro, shyju pv, linux-kernel, cgroups, Sanil kumar, Masanari Iida
Tejun Heo wrote:
>>From 6da2689412c78b97716ec524cc30baf7b46508cd Mon Sep 17 00:00:00 2001
> From: Tejun Heo <tj@kernel.org>
> Date: Tue, 3 Jul 2012 10:32:26 -0700
>
> While refactoring cgroup file removal path, 05ef1d7c4a "cgroup:
> introduce struct cfent" incorrectly changed the @dir argument of
> simple_unlink() to the inode of the file being deleted instead of that
> of the containing directory.
>
> The effect of this bug is minor - ctime and mtime of the parent
> weren't properly updated on file deletion.
>
> Fix it by using @cgrp->dentry->d_inode instead.
>
> Signed-off-by: Tejun Heo <tj@kernel.org>
> Reported-by: Al Viro <viro@ZenIV.linux.org.uk>
Acked-By: Li Zefan <lizefan@huawei.com>
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [PATCH] cgroup: cgroup_rm_files() was calling simple_unlink() with the wrong inode
@ 2012-07-04 5:40 ` Li Zefan
0 siblings, 0 replies; 35+ messages in thread
From: Li Zefan @ 2012-07-04 5:40 UTC (permalink / raw)
To: Tejun Heo
Cc: Al Viro, shyju pv, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
cgroups-u79uwXL29TY76Z2rM5mHXA, Sanil kumar, Masanari Iida
Tejun Heo wrote:
>>From 6da2689412c78b97716ec524cc30baf7b46508cd Mon Sep 17 00:00:00 2001
> From: Tejun Heo <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> Date: Tue, 3 Jul 2012 10:32:26 -0700
>
> While refactoring cgroup file removal path, 05ef1d7c4a "cgroup:
> introduce struct cfent" incorrectly changed the @dir argument of
> simple_unlink() to the inode of the file being deleted instead of that
> of the containing directory.
>
> The effect of this bug is minor - ctime and mtime of the parent
> weren't properly updated on file deletion.
>
> Fix it by using @cgrp->dentry->d_inode instead.
>
> Signed-off-by: Tejun Heo <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> Reported-by: Al Viro <viro-3bDd1+5oDREiFSDQTTA3OLVCufUGDwFn@public.gmane.org>
Acked-By: Li Zefan <lizefan-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [PATCH] cgroup: cgroup_rm_files() was calling simple_unlink() with the wrong inode
@ 2012-07-09 17:11 ` Tejun Heo
0 siblings, 0 replies; 35+ messages in thread
From: Tejun Heo @ 2012-07-09 17:11 UTC (permalink / raw)
To: Li Zefan
Cc: Al Viro, shyju pv, linux-kernel, cgroups, Sanil kumar, Masanari Iida
On Wed, Jul 04, 2012 at 01:40:39PM +0800, Li Zefan wrote:
> Tejun Heo wrote:
>
> >>From 6da2689412c78b97716ec524cc30baf7b46508cd Mon Sep 17 00:00:00 2001
> > From: Tejun Heo <tj@kernel.org>
> > Date: Tue, 3 Jul 2012 10:32:26 -0700
> >
> > While refactoring cgroup file removal path, 05ef1d7c4a "cgroup:
> > introduce struct cfent" incorrectly changed the @dir argument of
> > simple_unlink() to the inode of the file being deleted instead of that
> > of the containing directory.
> >
> > The effect of this bug is minor - ctime and mtime of the parent
> > weren't properly updated on file deletion.
> >
> > Fix it by using @cgrp->dentry->d_inode instead.
> >
> > Signed-off-by: Tejun Heo <tj@kernel.org>
> > Reported-by: Al Viro <viro@ZenIV.linux.org.uk>
>
>
> Acked-By: Li Zefan <lizefan@huawei.com>
I think it's now a bit too late for for-3.5-fixes and the effect of
the bug is rather minor. Applied to cgroup/for-3.6 w/ stable cc'd.
Thanks.
--
tejun
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [PATCH] cgroup: cgroup_rm_files() was calling simple_unlink() with the wrong inode
@ 2012-07-09 17:11 ` Tejun Heo
0 siblings, 0 replies; 35+ messages in thread
From: Tejun Heo @ 2012-07-09 17:11 UTC (permalink / raw)
To: Li Zefan
Cc: Al Viro, shyju pv, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
cgroups-u79uwXL29TY76Z2rM5mHXA, Sanil kumar, Masanari Iida
On Wed, Jul 04, 2012 at 01:40:39PM +0800, Li Zefan wrote:
> Tejun Heo wrote:
>
> >>From 6da2689412c78b97716ec524cc30baf7b46508cd Mon Sep 17 00:00:00 2001
> > From: Tejun Heo <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> > Date: Tue, 3 Jul 2012 10:32:26 -0700
> >
> > While refactoring cgroup file removal path, 05ef1d7c4a "cgroup:
> > introduce struct cfent" incorrectly changed the @dir argument of
> > simple_unlink() to the inode of the file being deleted instead of that
> > of the containing directory.
> >
> > The effect of this bug is minor - ctime and mtime of the parent
> > weren't properly updated on file deletion.
> >
> > Fix it by using @cgrp->dentry->d_inode instead.
> >
> > Signed-off-by: Tejun Heo <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> > Reported-by: Al Viro <viro-3bDd1+5oDREiFSDQTTA3OLVCufUGDwFn@public.gmane.org>
>
>
> Acked-By: Li Zefan <lizefan-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
I think it's now a bit too late for for-3.5-fixes and the effect of
the bug is rather minor. Applied to cgroup/for-3.6 w/ stable cc'd.
Thanks.
--
tejun
^ permalink raw reply [flat|nested] 35+ messages in thread
end of thread, other threads:[~2012-07-09 17:11 UTC | newest]
Thread overview: 35+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-06-24 19:08 3.5-rc3: BUG: Dentry still in use (1) [unmount of cgroup cgroup] shyju pv
2012-06-24 19:08 ` shyju pv
2012-06-26 23:00 ` Masanari Iida
2012-06-26 23:00 ` Masanari Iida
2012-06-27 18:29 ` tj
2012-06-27 18:29 ` tj-DgEjT+Ai2ygdnm+yROfE0A
2012-06-27 23:02 ` tj
2012-06-27 23:02 ` tj-DgEjT+Ai2ygdnm+yROfE0A
2012-06-28 14:09 ` Masanari Iida
2012-06-28 14:09 ` Masanari Iida
2012-06-28 6:07 ` Li Zefan
2012-06-28 6:07 ` Li Zefan
2012-06-28 18:07 ` tj
2012-06-28 18:07 ` tj-DgEjT+Ai2ygdnm+yROfE0A
2012-06-29 2:20 ` Li Zefan
2012-06-29 2:20 ` Li Zefan
2012-06-29 16:58 ` tj
2012-06-29 16:58 ` tj-DgEjT+Ai2ygdnm+yROfE0A
2012-06-29 18:07 ` Masanari Iida
2012-06-30 6:13 ` Li Zefan
2012-06-30 6:13 ` Li Zefan
2012-06-30 6:47 ` Al Viro
2012-06-30 6:47 ` Al Viro
2012-06-30 7:04 ` Tejun Heo
2012-06-30 7:04 ` Tejun Heo
2012-06-30 8:34 ` Al Viro
2012-06-30 8:34 ` Al Viro
2012-07-03 17:10 ` Tejun Heo
2012-07-03 17:10 ` Tejun Heo
2012-07-03 17:38 ` [PATCH] cgroup: cgroup_rm_files() was calling simple_unlink() with the wrong inode Tejun Heo
2012-07-03 17:38 ` Tejun Heo
2012-07-04 5:40 ` Li Zefan
2012-07-04 5:40 ` Li Zefan
2012-07-09 17:11 ` Tejun Heo
2012-07-09 17:11 ` Tejun Heo
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.