* xfs crash, kernel 2.6.29 @ 2009-08-11 7:21 Christian Fischer 2009-08-11 8:09 ` Christian Fischer 2009-08-11 14:20 ` Christoph Hellwig 0 siblings, 2 replies; 9+ messages in thread From: Christian Fischer @ 2009-08-11 7:21 UTC (permalink / raw) To: xfs; +Cc: Andrew Lyon, Eric Sandeen We had a new crash yesterday, server uptime maybe 20 hours. This is 2.6.29-xen-r4 from http://code.google.com/p/gentoo-xen-kernel/downloads/list @Eric/Andrew: do we have a xfs or a xen patches problem? Christian ------------[ cut here ]------------ Kernel BUG at ffffffff8045281d [verbose debug info unavailable] invalid opcode: 0000 [#1] SMP last sysfs file: /sys/devices/xen/pci-0/pci0000:00/0000:00:00.0/host3/target3:0:6/3:0:6:0/rev CPU 3 Modules linked in: nfsd Pid: 227, comm: kswapd0 Not tainted 2.6.29-xen-r4 #13 RIP: e030:[<ffffffff8045281d>] [<ffffffff8045281d>] radix_tree_tag_set+0x9d/0xb0 RSP: e02b:ffff8800ff97bce0 EFLAGS: 00010246 RAX: 000000000000002d RBX: 0000000000000000 RCX: ffff8800c13ceba8 RDX: 0000000000000000 RSI: 000000000022df71 RDI: ffff8800fe866e40 RBP: ffff8800fe866e00 R08: 000000000000002d R09: 000000000000000c R10: 0000000000000000 R11: 0000000000000003 R12: ffff8800fec59c00 R13: ffff8800067f7938 R14: 0000000000000080 R15: 000000000004828f FS: 00007f0617e8e6f0(0000) GS:ffff8800010061c0(0000) knlGS:0000000000000000 CS: e033 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 00007f187e14a110 CR3: 00000000fdcbd000 CR4: 0000000000002620 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process kswapd0 (pid: 227, threadinfo ffff8800ff97a000, task ffff8800ffb50540) Stack: ffff8800067f7840 ffffffff80422100 000000000004828f ffff8800067f7840 ffff8800067f79c0 ffff8800ff97bd80 0000000000000012 ffffffff8041229b ffff8800067f79c0 ffff8800067f79c0 ffff8800067f79c0 ffffffff80421146 Call Trace: [<ffffffff80422100>] ? xfs_inode_set_reclaim_tag+0x80/0xd0 [<ffffffff8041229b>] ? xfs_reclaim+0x6b/0xe0 [<ffffffff80421146>] ? xfs_fs_destroy_inode+0x36/0x60 [<ffffffff802a8c12>] ? dispose_list+0xa2/0x150 [<ffffffff802a8e9f>] ? shrink_icache_memory+0x1df/0x310 [<ffffffff8026da44>] ? shrink_slab+0x124/0x180 [<ffffffff8026e24d>] ? kswapd+0x3bd/0x600 [<ffffffff8026b700>] ? isolate_pages_global+0x0/0x280 [<ffffffff80245670>] ? autoremove_wake_function+0x0/0x30 [<ffffffff802242fb>] ? __wake_up_common+0x5b/0x90 [<ffffffff8026de90>] ? kswapd+0x0/0x600 [<ffffffff802451eb>] ? kthread+0x4b/0x80 [<ffffffff8020b66a>] ? child_rip+0xa/0x20 [<ffffffff802451a0>] ? kthread+0x0/0x80 [<ffffffff8020b660>] ? child_rip+0x0/0x20 Code: 18 4d 85 d2 74 25 41 ff cb 75 c4 4d 85 d2 74 16 8b 47 04 8d 4b 15 ba 01 00 00 00 d3 e2 85 d0 75 05 09 d0 89 47 04 5b 4c 89 d0 c3 <0f> 0b eb fe 0f 0b eb fe 66 66 2e 0f 1f 84 00 00 00 00 00 41 57 RIP [<ffffffff8045281d>] radix_tree_tag_set+0x9d/0xb0 RSP <ffff8800ff97bce0> ---[ end trace 48e7c392f10d019e ]--- Aug 10 17:23:35 ganges ------------[ cut here ]------------ Aug 10 17:23:35 ganges Kernel BUG at ffffffff8045281d [verbose debug info unavailable] Aug 10 17:23:35 ganges invalid opcode: 0000 [#1] SMP Aug 10 17:23:35 ganges last sysfs file: /sys/devices/xen/pci-0/pci0000:00/0000:00:00.0/host3/target3:0:6/3:0:6:0/rev Aug 10 17:23:35 ganges CPU 3 Aug 10 17:23:35 ganges Modules linked in: nfsd Aug 10 17:23:35 ganges Pid: 227, comm: kswapd0 Not tainted 2.6.29-xen-r4 #13 Aug 10 17:23:35 ganges RIP: e030:[<ffffffff8045281d>] [<ffffffff8045281d>] radix_tree_tag_set+0x9d/0xb0 Aug 10 17:23:35 ganges RSP: e02b:ffff8800ff97bce0 EFLAGS: 00010246 Aug 10 17:23:35 ganges RAX: 000000000000002d RBX: 0000000000000000 RCX: ffff8800c13ceba8 Aug 10 17:23:35 ganges RDX: 0000000000000000 RSI: 000000000022df71 RDI: ffff8800fe866e40 Aug 10 17:23:35 ganges RBP: ffff8800fe866e00 R08: 000000000000002d R09: 000000000000000c Aug 10 17:23:35 ganges R10: 0000000000000000 R11: 0000000000000003 R12: ffff8800fec59c00 Aug 10 17:23:35 ganges R13: ffff8800067f7938 R14: 0000000000000080 R15: 000000000004828f Aug 10 17:23:35 ganges FS: 00007f0617e8e6f0(0000) GS:ffff8800010061c0(0000) knlGS:0000000000000000 Aug 10 17:23:35 ganges CS: e033 DS: 0000 ES: 0000 CR0: 000000008005003b Aug 10 17:23:35 ganges CR2: 00007f187e14a110 CR3: 00000000fdcbd000 CR4: 0000000000002620 Aug 10 17:23:35 ganges DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 Aug 10 17:23:35 ganges DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Aug 10 17:23:35 ganges Process kswapd0 (pid: 227, threadinfo ffff8800ff97a000, task ffff8800ffb50540) Aug 10 17:23:35 ganges Stack: Aug 10 17:23:35 ganges ffff8800067f7840 ffffffff80422100 000000000004828f ffff8800067f7840 Aug 10 17:23:35 ganges ffff8800067f79c0 ffff8800ff97bd80 0000000000000012 ffffffff8041229b Aug 10 17:23:35 ganges ffff8800067f79c0 ffff8800067f79c0 ffff8800067f79c0 ffffffff80421146 Aug 10 17:23:35 ganges Call Trace: Aug 10 17:23:35 ganges [<ffffffff80422100>] ? xfs_inode_set_reclaim_tag+0x80/0xd0 Aug 10 17:23:35 ganges [<ffffffff8041229b>] ? xfs_reclaim+0x6b/0xe0 Aug 10 17:23:35 ganges [<ffffffff80421146>] ? xfs_fs_destroy_inode+0x36/0x60 Aug 10 17:23:35 ganges [<ffffffff802a8c12>] ? dispose_list+0xa2/0x150 Aug 10 17:23:35 ganges [<ffffffff802a8e9f>] ? shrink_icache_memory+0x1df/0x310 Aug 10 17:23:35 ganges [<ffffffff8026da44>] ? shrink_slab+0x124/0x180 Aug 10 17:23:35 ganges [<ffffffff8026e24d>] ? kswapd+0x3bd/0x600 Aug 10 17:23:35 ganges [<ffffffff8026b700>] ? isolate_pages_global+0x0/0x280 Aug 10 17:23:35 ganges [<ffffffff80245670>] ? autoremove_wake_function+0x0/0x30 Aug 10 17:23:35 ganges [<ffffffff802242fb>] ? __wake_up_common+0x5b/0x90 Aug 10 17:23:35 ganges [<ffffffff8026de90>] ? kswapd+0x0/0x600 Aug 10 17:23:35 ganges [<ffffffff802451eb>] ? kthread+0x4b/0x80 Aug 10 17:23:35 ganges [<ffffffff8020b66a>] ? child_rip+0xa/0x20 Aug 10 17:23:35 ganges [<ffffffff802451a0>] ? kthread+0x0/0x80 Aug 10 17:23:35 ganges [<ffffffff8020b660>] ? child_rip+0x0/0x20 Aug 10 17:23:35 ganges Code: 18 4d 85 d2 74 25 41 ff cb 75 c4 4d 85 d2 74 16 8b 47 04 8d 4b 15 ba 01 00 00 00 d3 e2 85 d0 75 05 09 d0 89 47 04 5b 4c 89 d0 c3 <0f> 0b eb fe 0f 0b eb fe 66 66 2e 0f 1f 84 00 00 00 00 00 41 57 Aug 10 17:23:35 ganges RIP [<ffffffff8045281d>] radix_tree_tag_set+0x9d/0xb0 Aug 10 17:23:35 ganges RSP <ffff8800ff97bce0> Aug 10 17:23:35 ganges ---[ end trace 48e7c392f10d019e ]--- _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: xfs crash, kernel 2.6.29 2009-08-11 7:21 xfs crash, kernel 2.6.29 Christian Fischer @ 2009-08-11 8:09 ` Christian Fischer 2009-08-11 14:20 ` Christoph Hellwig 1 sibling, 0 replies; 9+ messages in thread From: Christian Fischer @ 2009-08-11 8:09 UTC (permalink / raw) To: xfs; +Cc: Andrew Lyon, Eric Sandeen On Tuesday 11 August 2009, Christian Fischer wrote: > We had a new crash yesterday, server uptime maybe 20 hours. > > This is 2.6.29-xen-r4 from > http://code.google.com/p/gentoo-xen-kernel/downloads/list > > @Eric/Andrew: do we have a xfs or a xen patches problem? > > Christian I found that: http://oss.sgi.com/archives/xfs-masters/2009-06/msg00056.html > > > > > ------------[ cut here ]------------ > Kernel BUG at ffffffff8045281d [verbose debug info unavailable] > invalid opcode: 0000 [#1] SMP > last sysfs > file: > /sys/devices/xen/pci-0/pci0000:00/0000:00:00.0/host3/target3:0:6/3:0:6:0/re >v CPU 3 > Modules linked in: nfsd > Pid: 227, comm: kswapd0 Not tainted 2.6.29-xen-r4 #13 > RIP: e030:[<ffffffff8045281d>] [<ffffffff8045281d>] > radix_tree_tag_set+0x9d/0xb0 > RSP: e02b:ffff8800ff97bce0 EFLAGS: 00010246 > RAX: 000000000000002d RBX: 0000000000000000 RCX: ffff8800c13ceba8 > RDX: 0000000000000000 RSI: 000000000022df71 RDI: ffff8800fe866e40 > RBP: ffff8800fe866e00 R08: 000000000000002d R09: 000000000000000c > R10: 0000000000000000 R11: 0000000000000003 R12: ffff8800fec59c00 > R13: ffff8800067f7938 R14: 0000000000000080 R15: 000000000004828f > FS: 00007f0617e8e6f0(0000) GS:ffff8800010061c0(0000) > knlGS:0000000000000000 CS: e033 DS: 0000 ES: 0000 CR0: 000000008005003b > CR2: 00007f187e14a110 CR3: 00000000fdcbd000 CR4: 0000000000002620 > DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 > DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 > Process kswapd0 (pid: 227, threadinfo ffff8800ff97a000, task > ffff8800ffb50540) Stack: > ffff8800067f7840 ffffffff80422100 000000000004828f ffff8800067f7840 > ffff8800067f79c0 ffff8800ff97bd80 0000000000000012 ffffffff8041229b > ffff8800067f79c0 ffff8800067f79c0 ffff8800067f79c0 ffffffff80421146 > Call Trace: > [<ffffffff80422100>] ? xfs_inode_set_reclaim_tag+0x80/0xd0 > [<ffffffff8041229b>] ? xfs_reclaim+0x6b/0xe0 > [<ffffffff80421146>] ? xfs_fs_destroy_inode+0x36/0x60 > [<ffffffff802a8c12>] ? dispose_list+0xa2/0x150 > [<ffffffff802a8e9f>] ? shrink_icache_memory+0x1df/0x310 > [<ffffffff8026da44>] ? shrink_slab+0x124/0x180 > [<ffffffff8026e24d>] ? kswapd+0x3bd/0x600 > [<ffffffff8026b700>] ? isolate_pages_global+0x0/0x280 > [<ffffffff80245670>] ? autoremove_wake_function+0x0/0x30 > [<ffffffff802242fb>] ? __wake_up_common+0x5b/0x90 > [<ffffffff8026de90>] ? kswapd+0x0/0x600 > [<ffffffff802451eb>] ? kthread+0x4b/0x80 > [<ffffffff8020b66a>] ? child_rip+0xa/0x20 > [<ffffffff802451a0>] ? kthread+0x0/0x80 > [<ffffffff8020b660>] ? child_rip+0x0/0x20 > Code: 18 4d 85 d2 74 25 41 ff cb 75 c4 4d 85 d2 74 16 8b 47 04 8d 4b 15 ba > 01 00 00 00 d3 e2 85 d0 75 05 09 d0 89 47 04 5b 4c 89 d0 c3 <0f> 0b eb fe > 0f 0b eb fe 66 66 2e 0f 1f 84 00 00 00 00 00 41 57 > RIP [<ffffffff8045281d>] radix_tree_tag_set+0x9d/0xb0 > RSP <ffff8800ff97bce0> > ---[ end trace 48e7c392f10d019e ]--- > Aug 10 17:23:35 ganges ------------[ cut here ]------------ > Aug 10 17:23:35 ganges Kernel BUG at ffffffff8045281d [verbose debug info > unavailable] > Aug 10 17:23:35 ganges invalid opcode: 0000 [#1] SMP > Aug 10 17:23:35 ganges last sysfs > file: > /sys/devices/xen/pci-0/pci0000:00/0000:00:00.0/host3/target3:0:6/3:0:6:0/re >v Aug 10 17:23:35 ganges CPU 3 > Aug 10 17:23:35 ganges Modules linked in: nfsd > Aug 10 17:23:35 ganges Pid: 227, comm: kswapd0 Not tainted 2.6.29-xen-r4 > #13 Aug 10 17:23:35 ganges RIP: e030:[<ffffffff8045281d>] > [<ffffffff8045281d>] radix_tree_tag_set+0x9d/0xb0 > Aug 10 17:23:35 ganges RSP: e02b:ffff8800ff97bce0 EFLAGS: 00010246 > Aug 10 17:23:35 ganges RAX: 000000000000002d RBX: 0000000000000000 RCX: > ffff8800c13ceba8 > Aug 10 17:23:35 ganges RDX: 0000000000000000 RSI: 000000000022df71 RDI: > ffff8800fe866e40 > Aug 10 17:23:35 ganges RBP: ffff8800fe866e00 R08: 000000000000002d R09: > 000000000000000c > Aug 10 17:23:35 ganges R10: 0000000000000000 R11: 0000000000000003 R12: > ffff8800fec59c00 > Aug 10 17:23:35 ganges R13: ffff8800067f7938 R14: 0000000000000080 R15: > 000000000004828f > Aug 10 17:23:35 ganges FS: 00007f0617e8e6f0(0000) > GS:ffff8800010061c0(0000) knlGS:0000000000000000 > Aug 10 17:23:35 ganges CS: e033 DS: 0000 ES: 0000 CR0: 000000008005003b > Aug 10 17:23:35 ganges CR2: 00007f187e14a110 CR3: 00000000fdcbd000 CR4: > 0000000000002620 > Aug 10 17:23:35 ganges DR0: 0000000000000000 DR1: 0000000000000000 DR2: > 0000000000000000 > Aug 10 17:23:35 ganges DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: > 0000000000000400 > Aug 10 17:23:35 ganges Process kswapd0 (pid: 227, threadinfo > ffff8800ff97a000, task ffff8800ffb50540) > Aug 10 17:23:35 ganges Stack: > Aug 10 17:23:35 ganges ffff8800067f7840 ffffffff80422100 000000000004828f > ffff8800067f7840 > Aug 10 17:23:35 ganges ffff8800067f79c0 ffff8800ff97bd80 0000000000000012 > ffffffff8041229b > Aug 10 17:23:35 ganges ffff8800067f79c0 ffff8800067f79c0 ffff8800067f79c0 > ffffffff80421146 > Aug 10 17:23:35 ganges Call Trace: > Aug 10 17:23:35 ganges [<ffffffff80422100>] ? > xfs_inode_set_reclaim_tag+0x80/0xd0 > Aug 10 17:23:35 ganges [<ffffffff8041229b>] ? xfs_reclaim+0x6b/0xe0 > Aug 10 17:23:35 ganges [<ffffffff80421146>] ? > xfs_fs_destroy_inode+0x36/0x60 Aug 10 17:23:35 ganges [<ffffffff802a8c12>] > ? dispose_list+0xa2/0x150 Aug 10 17:23:35 ganges [<ffffffff802a8e9f>] ? > shrink_icache_memory+0x1df/0x310 Aug 10 17:23:35 ganges > [<ffffffff8026da44>] ? shrink_slab+0x124/0x180 Aug 10 17:23:35 ganges > [<ffffffff8026e24d>] ? kswapd+0x3bd/0x600 > Aug 10 17:23:35 ganges [<ffffffff8026b700>] ? > isolate_pages_global+0x0/0x280 Aug 10 17:23:35 ganges [<ffffffff80245670>] > ? > autoremove_wake_function+0x0/0x30 > Aug 10 17:23:35 ganges [<ffffffff802242fb>] ? __wake_up_common+0x5b/0x90 > Aug 10 17:23:35 ganges [<ffffffff8026de90>] ? kswapd+0x0/0x600 > Aug 10 17:23:35 ganges [<ffffffff802451eb>] ? kthread+0x4b/0x80 > Aug 10 17:23:35 ganges [<ffffffff8020b66a>] ? child_rip+0xa/0x20 > Aug 10 17:23:35 ganges [<ffffffff802451a0>] ? kthread+0x0/0x80 > Aug 10 17:23:35 ganges [<ffffffff8020b660>] ? child_rip+0x0/0x20 > Aug 10 17:23:35 ganges Code: 18 4d 85 d2 74 25 41 ff cb 75 c4 4d 85 d2 74 > 16 8b 47 04 8d 4b 15 ba 01 00 00 00 d3 e2 85 d0 75 05 09 d0 89 47 04 5b 4c > 89 d0 c3 <0f> 0b eb fe 0f 0b eb fe 66 66 2e 0f 1f 84 00 00 00 00 00 41 57 > Aug 10 17:23:35 ganges RIP [<ffffffff8045281d>] > radix_tree_tag_set+0x9d/0xb0 Aug 10 17:23:35 ganges RSP <ffff8800ff97bce0> > Aug 10 17:23:35 ganges ---[ end trace 48e7c392f10d019e ]--- > > _______________________________________________ > xfs mailing list > xfs@oss.sgi.com > http://oss.sgi.com/mailman/listinfo/xfs -- ------------------------------------------------------------ EasternGraphics - visualize your business Christian Fischer Administration http://www.EasternGraphics.com phone: +49 3677 678265 EasternGraphics GmbH - Albert-Einstein-Strasse 1 - DE-98693 Ilmenau Geschaeftsfuehrer - Ekkehard Beier, Volker Blankenberg, Frank Wicht Amtsgericht Jena - HRB 304052 _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: xfs crash, kernel 2.6.29 2009-08-11 7:21 xfs crash, kernel 2.6.29 Christian Fischer 2009-08-11 8:09 ` Christian Fischer @ 2009-08-11 14:20 ` Christoph Hellwig 2009-08-11 14:39 ` Christian Fischer ` (2 more replies) 1 sibling, 3 replies; 9+ messages in thread From: Christoph Hellwig @ 2009-08-11 14:20 UTC (permalink / raw) To: Christian Fischer; +Cc: Andrew Lyon, Eric Sandeen, xfs On Tue, Aug 11, 2009 at 09:21:50AM +0200, Christian Fischer wrote: > We had a new crash yesterday, server uptime maybe 20 hours. > > This is 2.6.29-xen-r4 from > http://code.google.com/p/gentoo-xen-kernel/downloads/list > > @Eric/Andrew: do we have a xfs or a xen patches problem? It's a known bug that we just fixed in 2.6.31-rc. Can you check if this patch http://bugzilla.kernel.org/attachment.cgi?id=22590 applies to 2.6.29 (I produced it against 2.6.30) _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: xfs crash, kernel 2.6.29 2009-08-11 14:20 ` Christoph Hellwig @ 2009-08-11 14:39 ` Christian Fischer 2009-08-14 12:56 ` [Patch] " Christian Fischer 2009-08-14 13:02 ` Christian Fischer 2 siblings, 0 replies; 9+ messages in thread From: Christian Fischer @ 2009-08-11 14:39 UTC (permalink / raw) To: Christoph Hellwig; +Cc: Andrew Lyon, Eric Sandeen, xfs On Tuesday 11 August 2009, Christoph Hellwig wrote: > On Tue, Aug 11, 2009 at 09:21:50AM +0200, Christian Fischer wrote: > > We had a new crash yesterday, server uptime maybe 20 hours. > > > > This is 2.6.29-xen-r4 from > > http://code.google.com/p/gentoo-xen-kernel/downloads/list > > > > @Eric/Andrew: do we have a xfs or a xen patches problem? > > It's a known bug that we just fixed in 2.6.31-rc. Can you check if this > patch > > http://bugzilla.kernel.org/attachment.cgi?id=22590 > > applies to 2.6.29 (I produced it against 2.6.30) Yes, I've seen this after sending my first mail. If there are no patches against 2.6.29 then i have no other chance than trying this, or i switch to ext4. But what happens then? What a bullshit, from one bug to the next, my company kills me. Thanks for all comments and help. Christian _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 9+ messages in thread
* [Patch] Re: xfs crash, kernel 2.6.29 2009-08-11 14:20 ` Christoph Hellwig 2009-08-11 14:39 ` Christian Fischer @ 2009-08-14 12:56 ` Christian Fischer 2009-08-14 14:18 ` Christoph Hellwig 2009-08-14 13:02 ` Christian Fischer 2 siblings, 1 reply; 9+ messages in thread From: Christian Fischer @ 2009-08-14 12:56 UTC (permalink / raw) To: Christoph Hellwig; +Cc: Andrew Lyon, Eric Sandeen, xfs On Tuesday 11 August 2009, Christoph Hellwig wrote: > On Tue, Aug 11, 2009 at 09:21:50AM +0200, Christian Fischer wrote: > > We had a new crash yesterday, server uptime maybe 20 hours. > > > > This is 2.6.29-xen-r4 from > > http://code.google.com/p/gentoo-xen-kernel/downloads/list > > > > @Eric/Andrew: do we have a xfs or a xen patches problem? > > It's a known bug that we just fixed in 2.6.31-rc. Can you check if this > patch > > http://bugzilla.kernel.org/attachment.cgi?id=22590 > > applies to 2.6.29 (I produced it against 2.6.30) backported to 2.6.29-xen-r4 from http://code.google.com/p/gentoo-xen-kernel/downloads/list Can you please review it? The kernel complies and runs, but I can't test it. I can't reproduce a crash as you could with 2.6.30 and 2.6.31. Nothing triggers it. http://bugzilla.kernel.org/show_bug.cgi?id=13375 Christian _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Patch] Re: xfs crash, kernel 2.6.29 2009-08-14 12:56 ` [Patch] " Christian Fischer @ 2009-08-14 14:18 ` Christoph Hellwig 2009-08-19 7:50 ` Andrew Lyon 0 siblings, 1 reply; 9+ messages in thread From: Christoph Hellwig @ 2009-08-14 14:18 UTC (permalink / raw) To: Christian Fischer; +Cc: Christoph Hellwig, Andrew Lyon, Eric Sandeen, xfs On Fri, Aug 14, 2009 at 02:56:58PM +0200, Christian Fischer wrote: > backported to 2.6.29-xen-r4 from > http://code.google.com/p/gentoo-xen-kernel/downloads/list > > Can you please review it? I'll reviewed it and do some QA over the weekend, and we'll send it to -stable then. _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Patch] Re: xfs crash, kernel 2.6.29 2009-08-14 14:18 ` Christoph Hellwig @ 2009-08-19 7:50 ` Andrew Lyon 2009-08-19 8:16 ` Christian Fischer 0 siblings, 1 reply; 9+ messages in thread From: Andrew Lyon @ 2009-08-19 7:50 UTC (permalink / raw) To: Christoph Hellwig; +Cc: Eric Sandeen, Christian Fischer, xfs On Fri, Aug 14, 2009 at 3:18 PM, Christoph Hellwig<hch@infradead.org> wrote: > On Fri, Aug 14, 2009 at 02:56:58PM +0200, Christian Fischer wrote: >> backported to 2.6.29-xen-r4 from >> http://code.google.com/p/gentoo-xen-kernel/downloads/list >> >> Can you please review it? > > I'll reviewed it and do some QA over the weekend, and we'll send it to > -stable then. > > Did the patch fix the problem? Andy _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Patch] Re: xfs crash, kernel 2.6.29 2009-08-19 7:50 ` Andrew Lyon @ 2009-08-19 8:16 ` Christian Fischer 0 siblings, 0 replies; 9+ messages in thread From: Christian Fischer @ 2009-08-19 8:16 UTC (permalink / raw) To: Andrew Lyon; +Cc: Christoph Hellwig, Eric Sandeen, xfs On Wednesday 19 August 2009, Andrew Lyon wrote: > On Fri, Aug 14, 2009 at 3:18 PM, Christoph Hellwig<hch@infradead.org> wrote: > > On Fri, Aug 14, 2009 at 02:56:58PM +0200, Christian Fischer wrote: > >> backported to 2.6.29-xen-r4 from > >> http://code.google.com/p/gentoo-xen-kernel/downloads/list > >> > >> Can you please review it? > > > > I'll reviewed it and do some QA over the weekend, and we'll send it to > > -stable then. > > Did the patch fix the problem? > > Andy Hi Andrew, nice to hear you. All i can say is that the kernel compiles and runs. On my testbox I can't reproduce the fs crash, seems 2.6.29.4 is more stable than 2.6.30/31. I've tried Erics steps to reproduce for 2.6.30/31, tried stressing the nfs mount with iozone, tried recursive unpacking and removing eclipse (a lot of small files) and this in a lot of parallel tasks. Nothing triggers the bug. You know, if I can't reproduce it I can't say whether it is fixed or not. I'll update one server this week with the patched kernel and switch nfs on again, and wait then for the next crash. Hope that comes never. Christian -- ------------------------------------------------------------ EasternGraphics - visualize your business Christian Fischer Administration http://www.EasternGraphics.com phone: +49 3677 678265 EasternGraphics GmbH - Albert-Einstein-Strasse 1 - DE-98693 Ilmenau Geschaeftsfuehrer - Ekkehard Beier, Volker Blankenberg, Frank Wicht Amtsgericht Jena - HRB 304052 _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: xfs crash, kernel 2.6.29 2009-08-11 14:20 ` Christoph Hellwig 2009-08-11 14:39 ` Christian Fischer 2009-08-14 12:56 ` [Patch] " Christian Fischer @ 2009-08-14 13:02 ` Christian Fischer 2 siblings, 0 replies; 9+ messages in thread From: Christian Fischer @ 2009-08-14 13:02 UTC (permalink / raw) To: Christoph Hellwig; +Cc: Andrew Lyon, Eric Sandeen, xfs [-- Attachment #1: Type: text/plain, Size: 700 bytes --] On Tuesday 11 August 2009, Christoph Hellwig wrote: > On Tue, Aug 11, 2009 at 09:21:50AM +0200, Christian Fischer wrote: > > We had a new crash yesterday, server uptime maybe 20 hours. > > > > This is 2.6.29-xen-r4 from > > http://code.google.com/p/gentoo-xen-kernel/downloads/list > > > > @Eric/Andrew: do we have a xfs or a xen patches problem? > > It's a known bug that we just fixed in 2.6.31-rc. Can you check if this > patch > > http://bugzilla.kernel.org/attachment.cgi?id=22590 > > applies to 2.6.29 (I produced it against 2.6.30) > > _______________________________________________ > xfs mailing list > xfs@oss.sgi.com > http://oss.sgi.com/mailman/listinfo/xfs Well, attached the patch. [-- Attachment #2: xfs_mine.diff --] [-- Type: text/x-diff, Size: 18806 bytes --] diff -Nurp linux-2.6.29-xen-r4.orig/fs/exportfs/Makefile linux-2.6.29-xen-r4/fs/exportfs/Makefile --- linux-2.6.29-xen-r4.orig/fs/exportfs/Makefile 2009-03-24 00:12:14.000000000 +0100 +++ linux-2.6.29-xen-r4/fs/exportfs/Makefile 2009-08-14 10:36:22.572098064 +0200 @@ -1,6 +1,8 @@ # # Makefile for the filesystem export support routines. +EXTRA_CFLAGS += -I$(src)/../../fs/xfs -I$(src)/../../fs/xfs/linux-2.6 + obj-$(CONFIG_EXPORTFS) += exportfs.o exportfs-objs := expfs.o diff -Nurp linux-2.6.29-xen-r4.orig/fs/exportfs/expfs.c linux-2.6.29-xen-r4/fs/exportfs/expfs.c --- linux-2.6.29-xen-r4.orig/fs/exportfs/expfs.c 2009-03-24 00:12:14.000000000 +0100 +++ linux-2.6.29-xen-r4/fs/exportfs/expfs.c 2009-08-14 10:39:58.917630424 +0200 @@ -15,6 +15,11 @@ #include <linux/mount.h> #include <linux/namei.h> #include <linux/sched.h> +#include "xfs.h" +#include "xfs_inum.h" +#include "xfs_bmap_btree.h" +#include "xfs_dinode.h" +#include "xfs_inode.h" #define dprintk(fmt, args...) do{}while(0) @@ -187,8 +192,25 @@ reconnect_path(struct vfsmount *mnt, str */ if (npd == pd) noprogress = 0; - else + else { printk("%s: npd != pd\n", __func__); + if (npd->d_inode) { + printk("npd = 0x%p, inode = 0%p, ino = 0x%llx\n", + npd, npd->d_inode, + (unsigned long long)npd->d_inode->i_ino); + printk("i_state = 0x%lx, i_flags = 0x%x\n", + npd->d_inode->i_state, + XFS_I(npd->d_inode)->i_flags); + } + if (pd->d_inode) { + printk("pd = 0x%p, inode = 0%p, ino = 0x%llx\n", + pd, pd->d_inode, + (unsigned long long)pd->d_inode->i_ino); + printk("i_state = 0x%lx, i_flags = 0x%x\n", + pd->d_inode->i_state, + XFS_I(pd->d_inode)->i_flags); + } + } dput(npd); dput(ppd); if (IS_ROOT(pd)) { diff -Nurp linux-2.6.29-xen-r4.orig/fs/inode.c linux-2.6.29-xen-r4/fs/inode.c --- linux-2.6.29-xen-r4.orig/fs/inode.c 2009-03-24 00:12:14.000000000 +0100 +++ linux-2.6.29-xen-r4/fs/inode.c 2009-08-14 14:08:17.373785137 +0200 @@ -117,7 +117,7 @@ static void wake_up_inode(struct inode * * These are initializations that need to be done on every inode * allocation as the fields are not initialised by slab allocation. */ -struct inode *inode_init_always(struct super_block *sb, struct inode *inode) +int inode_init_always(struct super_block *sb, struct inode *inode) { static const struct address_space_operations empty_aops; static struct inode_operations empty_iops; @@ -147,14 +147,10 @@ struct inode *inode_init_always(struct s inode->i_cdev = NULL; inode->i_rdev = 0; inode->dirtied_when = 0; - if (security_inode_alloc(inode)) { - if (inode->i_sb->s_op->destroy_inode) - inode->i_sb->s_op->destroy_inode(inode); - else - kmem_cache_free(inode_cachep, (inode)); - return NULL; - } - + + if (security_inode_alloc(inode)) + return -ENOMEM; + spin_lock_init(&inode->i_lock); lockdep_set_class(&inode->i_lock, &sb->s_type->i_lock_key); @@ -188,7 +184,7 @@ struct inode *inode_init_always(struct s inode->i_private = NULL; inode->i_mapping = mapping; - return inode; + return 0; } EXPORT_SYMBOL(inode_init_always); @@ -201,22 +197,34 @@ static struct inode *alloc_inode(struct else inode = kmem_cache_alloc(inode_cachep, GFP_KERNEL); - if (inode) - return inode_init_always(sb, inode); - return NULL; + if (!inode) + return NULL; + + if (unlikely(inode_init_always(sb, inode))) { + if (inode->i_sb->s_op->destroy_inode) + inode->i_sb->s_op->destroy_inode(inode); + else + kmem_cache_free(inode_cachep, inode); + } + + return inode; } -void destroy_inode(struct inode *inode) +void __destroy_inode(struct inode *inode) { BUG_ON(inode_has_buffers(inode)); security_inode_free(inode); +} +EXPORT_SYMBOL(__destroy_inode); + +void destroy_inode(struct inode *inode) +{ + __destroy_inode(inode); if (inode->i_sb->s_op->destroy_inode) inode->i_sb->s_op->destroy_inode(inode); else kmem_cache_free(inode_cachep, (inode)); } -EXPORT_SYMBOL(destroy_inode); - /* * These are initializations that only need to be done diff -Nurp linux-2.6.29-xen-r4.orig/fs/xfs/linux-2.6/xfs_sync.c linux-2.6.29-xen-r4/fs/xfs/linux-2.6/xfs_sync.c --- linux-2.6.29-xen-r4.orig/fs/xfs/linux-2.6/xfs_sync.c 2009-03-24 00:12:14.000000000 +0100 +++ linux-2.6.29-xen-r4/fs/xfs/linux-2.6/xfs_sync.c 2009-08-14 09:43:47.487023831 +0200 @@ -619,6 +619,17 @@ xfs_reclaim_inode( return 0; } +void +__xfs_inode_set_reclaim_tag( + struct xfs_perag *pag, + struct xfs_inode *ip) +{ + radix_tree_tag_set(&pag->pag_ici_root, + XFS_INO_TO_AGINO(ip->i_mount, ip->i_ino), + XFS_ICI_RECLAIM_TAG); + ip->i_flags |= XFS_IRECLAIMABLE; +} + /* * We set the inode flag atomically with the radix tree tag. * Once we get tag lookups on the radix tree, this inode flag @@ -633,9 +644,7 @@ xfs_inode_set_reclaim_tag( read_lock(&pag->pag_ici_lock); spin_lock(&ip->i_flags_lock); - radix_tree_tag_set(&pag->pag_ici_root, - XFS_INO_TO_AGINO(mp, ip->i_ino), XFS_ICI_RECLAIM_TAG); - __xfs_iflags_set(ip, XFS_IRECLAIMABLE); + __xfs_inode_set_reclaim_tag(pag, ip); spin_unlock(&ip->i_flags_lock); read_unlock(&pag->pag_ici_lock); xfs_put_perag(mp, pag); @@ -643,27 +652,13 @@ xfs_inode_set_reclaim_tag( void __xfs_inode_clear_reclaim_tag( - xfs_mount_t *mp, - xfs_perag_t *pag, - xfs_inode_t *ip) + struct xfs_perag *pag, + struct xfs_inode *ip) { + ip->i_flags &= ~XFS_IRECLAIMABLE; radix_tree_tag_clear(&pag->pag_ici_root, - XFS_INO_TO_AGINO(mp, ip->i_ino), XFS_ICI_RECLAIM_TAG); -} - -void -xfs_inode_clear_reclaim_tag( - xfs_inode_t *ip) -{ - xfs_mount_t *mp = ip->i_mount; - xfs_perag_t *pag = xfs_get_perag(mp, ip->i_ino); - - read_lock(&pag->pag_ici_lock); - spin_lock(&ip->i_flags_lock); - __xfs_inode_clear_reclaim_tag(mp, pag, ip); - spin_unlock(&ip->i_flags_lock); - read_unlock(&pag->pag_ici_lock); - xfs_put_perag(mp, pag); + XFS_INO_TO_AGINO(ip->i_mount, ip->i_ino), + XFS_ICI_RECLAIM_TAG); } diff -Nurp linux-2.6.29-xen-r4.orig/fs/xfs/linux-2.6/xfs_sync.h linux-2.6.29-xen-r4/fs/xfs/linux-2.6/xfs_sync.h --- linux-2.6.29-xen-r4.orig/fs/xfs/linux-2.6/xfs_sync.h 2009-03-24 00:12:14.000000000 +0100 +++ linux-2.6.29-xen-r4/fs/xfs/linux-2.6/xfs_sync.h 2009-08-14 10:41:10.087152772 +0200 @@ -49,7 +49,6 @@ int xfs_reclaim_inode(struct xfs_inode * int xfs_reclaim_inodes(struct xfs_mount *mp, int noblock, int mode); void xfs_inode_set_reclaim_tag(struct xfs_inode *ip); -void xfs_inode_clear_reclaim_tag(struct xfs_inode *ip); -void __xfs_inode_clear_reclaim_tag(struct xfs_mount *mp, struct xfs_perag *pag, - struct xfs_inode *ip); +void __xfs_inode_set_reclaim_tag(struct xfs_perag *pag, struct xfs_inode *ip); +void __xfs_inode_clear_reclaim_tag(struct xfs_perag *pag, struct xfs_inode *ip); #endif diff -Nurp linux-2.6.29-xen-r4.orig/fs/xfs/xfs_iget.c linux-2.6.29-xen-r4/fs/xfs/xfs_iget.c --- linux-2.6.29-xen-r4.orig/fs/xfs/xfs_iget.c 2009-03-24 00:12:14.000000000 +0100 +++ linux-2.6.29-xen-r4/fs/xfs/xfs_iget.c 2009-08-14 09:36:23.472454929 +0200 @@ -64,20 +64,20 @@ xfs_inode_alloc( if (!ip) return NULL; - ASSERT(atomic_read(&ip->i_iocount) == 0); - ASSERT(atomic_read(&ip->i_pincount) == 0); - ASSERT(!spin_is_locked(&ip->i_flags_lock)); - ASSERT(completion_done(&ip->i_flush)); - /* * initialise the VFS inode here to get failures * out of the way early. */ - if (!inode_init_always(mp->m_super, VFS_I(ip))) { + if (inode_init_always(mp->m_super, VFS_I(ip))) { kmem_zone_free(xfs_inode_zone, ip); return NULL; } + ASSERT(atomic_read(&ip->i_iocount) == 0); + ASSERT(atomic_read(&ip->i_pincount) == 0); + ASSERT(!spin_is_locked(&ip->i_flags_lock)); + ASSERT(completion_done(&ip->i_flush)); + /* initialise the xfs inode */ ip->i_ino = ino; ip->i_mount = mp; @@ -114,9 +114,77 @@ xfs_inode_alloc( ip->i_dir_trace = ktrace_alloc(XFS_DIR2_KTRACE_SIZE, KM_NOFS); #endif + /* prevent anyone from using this yet */ + VFS_I(ip)->i_state = I_NEW|I_LOCK; + return ip; } +STATIC void +xfs_inode_free( + struct xfs_inode *ip) +{ + switch (ip->i_d.di_mode & S_IFMT) { + case S_IFREG: + case S_IFDIR: + case S_IFLNK: + xfs_idestroy_fork(ip, XFS_DATA_FORK); + break; + } + + if (ip->i_afp) + xfs_idestroy_fork(ip, XFS_ATTR_FORK); + +#ifdef XFS_INODE_TRACE + ktrace_free(ip->i_trace); +#endif +#ifdef XFS_BMAP_TRACE + ktrace_free(ip->i_xtrace); +#endif +#ifdef XFS_BTREE_TRACE + ktrace_free(ip->i_btrace); +#endif +#ifdef XFS_RW_TRACE + ktrace_free(ip->i_rwtrace); +#endif +#ifdef XFS_ILOCK_TRACE + ktrace_free(ip->i_lock_trace); +#endif +#ifdef XFS_DIR2_TRACE + ktrace_free(ip->i_dir_trace); +#endif + + if (ip->i_itemp) { + /* + * Only if we are shutting down the fs will we see an + * inode still in the AIL. If it is there, we should remove + * it to prevent a use-after-free from occurring. + */ + xfs_log_item_t *lip = &ip->i_itemp->ili_item; + struct xfs_ail *ailp = lip->li_ailp; + + ASSERT(((lip->li_flags & XFS_LI_IN_AIL) == 0) || + XFS_FORCED_SHUTDOWN(ip->i_mount)); + if (lip->li_flags & XFS_LI_IN_AIL) { + spin_lock(&ailp->xa_lock); + if (lip->li_flags & XFS_LI_IN_AIL) + xfs_trans_ail_delete(ailp, lip); + else + spin_unlock(&ailp->xa_lock); + } + xfs_inode_item_destroy(ip); + ip->i_itemp = NULL; + } + + /* asserts to verify all state is correct here */ + ASSERT(atomic_read(&ip->i_iocount) == 0); + ASSERT(atomic_read(&ip->i_pincount) == 0); + ASSERT(!spin_is_locked(&ip->i_flags_lock)); + ASSERT(completion_done(&ip->i_flush)); + + kmem_zone_free(xfs_inode_zone, ip); +} + /* * Check the validity of the inode we just found it the cache */ @@ -127,80 +195,90 @@ xfs_iget_cache_hit( int flags, int lock_flags) __releases(pag->pag_ici_lock) { + struct inode *inode = VFS_I(ip); struct xfs_mount *mp = ip->i_mount; - int error = EAGAIN; + int error; + + spin_lock(&ip->i_flags_lock); /* - * If INEW is set this inode is being set up - * If IRECLAIM is set this inode is being torn down - * Pause and try again. + * This inode is being torn down, pause and try again. */ - if (xfs_iflags_test(ip, (XFS_INEW|XFS_IRECLAIM))) { + if (ip->i_flags & XFS_IRECLAIM) { XFS_STATS_INC(xs_ig_frecycle); + error = EAGAIN; goto out_error; } - /* If IRECLAIMABLE is set, we've torn down the vfs inode part */ - if (xfs_iflags_test(ip, XFS_IRECLAIMABLE)) { - - /* - * If lookup is racing with unlink, then we should return an - * error immediately so we don't remove it from the reclaim - * list and potentially leak the inode. - */ - if ((ip->i_d.di_mode == 0) && !(flags & XFS_IGET_CREATE)) { - error = ENOENT; - goto out_error; - } - + /* + * If we are racing with another cache hit that is currently recycling + * this inode out of the XFS_IRECLAIMABLE state, wait for the + * initialisation to complete before continuing. + */ + if (ip->i_flags & XFS_INEW) { + spin_unlock(&ip->i_flags_lock); + read_unlock(&pag->pag_ici_lock); + XFS_STATS_INC(xs_ig_frecycle); + wait_on_inode(inode); + return EAGAIN; + } + + /* + * If lookup is racing with unlink, then we should return an + * error immediately so we don't remove it from the reclaim + * list and potentially leak the inode. + */ + if (ip->i_d.di_mode == 0 && !(flags & XFS_IGET_CREATE)) { + error = ENOENT; + goto out_error; + } + + /* + * If IRECLAIMABLE is set, we've torn down the VFS inode already. + * Need to carefully get it back into useable state. + */ + if (ip->i_flags & XFS_IRECLAIMABLE) { xfs_itrace_exit_tag(ip, "xfs_iget.alloc"); /* - * We need to re-initialise the VFS inode as it has been - * 'freed' by the VFS. Do this here so we can deal with - * errors cleanly, then tag it so it can be set up correctly - * later. + * We need to set XFS_INEW atomically with clearing the + * reclaimable tag so that we do have an indicator of the + * inode still being initialized. */ - if (!inode_init_always(mp->m_super, VFS_I(ip))) { + ip->i_flags |= XFS_INEW; + __xfs_inode_clear_reclaim_tag(pag, ip); + + spin_unlock(&ip->i_flags_lock); + read_unlock(&pag->pag_ici_lock); + + if (unlikely(inode_init_always(mp->m_super, inode))) { + /* + * Re-initializing the inode failed, and we are in deep + * trouble. Try to re-add it to the reclaim list. + */ + read_lock(&pag->pag_ici_lock); + spin_lock(&ip->i_flags_lock); + + ip->i_flags &= ~XFS_INEW; + __xfs_inode_set_reclaim_tag(pag, ip); + error = ENOMEM; goto out_error; } - - /* - * We must set the XFS_INEW flag before clearing the - * XFS_IRECLAIMABLE flag so that if a racing lookup does - * not find the XFS_IRECLAIMABLE above but has the igrab() - * below succeed we can safely check XFS_INEW to detect - * that this inode is still being initialised. - */ - xfs_iflags_set(ip, XFS_INEW); - xfs_iflags_clear(ip, XFS_IRECLAIMABLE); - - /* clear the radix tree reclaim flag as well. */ - __xfs_inode_clear_reclaim_tag(mp, pag, ip); - } else if (!igrab(VFS_I(ip))) { + + inode->i_state = I_LOCK|I_NEW; + } else { /* If the VFS inode is being torn down, pause and try again. */ - XFS_STATS_INC(xs_ig_frecycle); - goto out_error; - } else if (xfs_iflags_test(ip, XFS_INEW)) { - /* - * We are racing with another cache hit that is - * currently recycling this inode out of the XFS_IRECLAIMABLE - * state. Wait for the initialisation to complete before - * continuing. - */ - wait_on_inode(VFS_I(ip)); - } - - if (ip->i_d.di_mode == 0 && !(flags & XFS_IGET_CREATE)) { - error = ENOENT; - iput(VFS_I(ip)); - goto out_error; + if (!igrab(inode)) { + error = EAGAIN; + goto out_error; + } + + /* We've got a live one. */ + spin_unlock(&ip->i_flags_lock); + read_unlock(&pag->pag_ici_lock); } - /* We've got a live one. */ - read_unlock(&pag->pag_ici_lock); - if (lock_flags != 0) xfs_ilock(ip, lock_flags); @@ -210,6 +288,7 @@ xfs_iget_cache_hit( return 0; out_error: + spin_unlock(&ip->i_flags_lock); read_unlock(&pag->pag_ici_lock); return error; } @@ -293,7 +372,8 @@ out_preload_end: if (lock_flags) xfs_iunlock(ip, lock_flags); out_destroy: - xfs_destroy_inode(ip); + __destroy_inode(VFS_I(ip)); + xfs_inode_free(ip); return error; } @@ -470,17 +550,21 @@ xfs_ireclaim( { struct xfs_mount *mp = ip->i_mount; struct xfs_perag *pag; + xfs_agino_t agino = XFS_INO_TO_AGINO(mp, ip->i_ino); XFS_STATS_INC(xs_ig_reclaims); /* - * Remove the inode from the per-AG radix tree. It doesn't matter - * if it was never added to it because radix_tree_delete can deal - * with that case just fine. + * Remove the inode from the per-AG radix tree. + * + * Because radix_tree_delete won't complain even if the item was never + * added to the tree assert that it's been there before to catch + * problems with the inode life time early on. */ pag = xfs_get_perag(mp, ip->i_ino); write_lock(&pag->pag_ici_lock); - radix_tree_delete(&pag->pag_ici_root, XFS_INO_TO_AGINO(mp, ip->i_ino)); + ASSERT(radix_tree_lookup(&pag->pag_ici_root, agino)); + radix_tree_delete(&pag->pag_ici_root, agino); write_unlock(&pag->pag_ici_lock); xfs_put_perag(mp, pag); @@ -500,63 +584,7 @@ xfs_ireclaim( */ XFS_QM_DQDETACH(ip->i_mount, ip); xfs_iunlock(ip, XFS_ILOCK_EXCL | XFS_IOLOCK_EXCL); - - switch (ip->i_d.di_mode & S_IFMT) { - case S_IFREG: - case S_IFDIR: - case S_IFLNK: - xfs_idestroy_fork(ip, XFS_DATA_FORK); - break; - } - - if (ip->i_afp) - xfs_idestroy_fork(ip, XFS_ATTR_FORK); - -#ifdef XFS_INODE_TRACE - ktrace_free(ip->i_trace); -#endif -#ifdef XFS_BMAP_TRACE - ktrace_free(ip->i_xtrace); -#endif -#ifdef XFS_BTREE_TRACE - ktrace_free(ip->i_btrace); -#endif -#ifdef XFS_RW_TRACE - ktrace_free(ip->i_rwtrace); -#endif -#ifdef XFS_ILOCK_TRACE - ktrace_free(ip->i_lock_trace); -#endif -#ifdef XFS_DIR2_TRACE - ktrace_free(ip->i_dir_trace); -#endif - if (ip->i_itemp) { - /* - * Only if we are shutting down the fs will we see an - * inode still in the AIL. If it is there, we should remove - * it to prevent a use-after-free from occurring. - */ - xfs_log_item_t *lip = &ip->i_itemp->ili_item; - struct xfs_ail *ailp = lip->li_ailp; - - ASSERT(((lip->li_flags & XFS_LI_IN_AIL) == 0) || - XFS_FORCED_SHUTDOWN(ip->i_mount)); - if (lip->li_flags & XFS_LI_IN_AIL) { - spin_lock(&ailp->xa_lock); - if (lip->li_flags & XFS_LI_IN_AIL) - xfs_trans_ail_delete(ailp, lip); - else - spin_unlock(&ailp->xa_lock); - } - xfs_inode_item_destroy(ip); - ip->i_itemp = NULL; - } - /* asserts to verify all state is correct here */ - ASSERT(atomic_read(&ip->i_iocount) == 0); - ASSERT(atomic_read(&ip->i_pincount) == 0); - ASSERT(!spin_is_locked(&ip->i_flags_lock)); - ASSERT(completion_done(&ip->i_flush)); - kmem_zone_free(xfs_inode_zone, ip); + xfs_inode_free(ip); } /* diff -Nurp linux-2.6.29-xen-r4.orig/fs/xfs/xfs_inode.h linux-2.6.29-xen-r4/fs/xfs/xfs_inode.h --- linux-2.6.29-xen-r4.orig/fs/xfs/xfs_inode.h 2009-03-24 00:12:14.000000000 +0100 +++ linux-2.6.29-xen-r4/fs/xfs/xfs_inode.h 2009-08-14 10:35:44.458392694 +0200 @@ -309,23 +309,6 @@ static inline struct inode *VFS_I(struct } /* - * Get rid of a partially initialized inode. - * - * We have to go through destroy_inode to make sure allocations - * from init_inode_always like the security data are undone. - * - * We mark the inode bad so that it takes the short cut in - * the reclaim path instead of going through the flush path - * which doesn't make sense for an inode that has never seen the - * light of day. - */ -static inline void xfs_destroy_inode(struct xfs_inode *ip) -{ - make_bad_inode(VFS_I(ip)); - return destroy_inode(VFS_I(ip)); -} - -/* * i_flags helper functions */ static inline void diff -Nurp linux-2.6.29-xen-r4.orig/include/linux/fs.h linux-2.6.29-xen-r4/include/linux/fs.h --- linux-2.6.29-xen-r4.orig/include/linux/fs.h 2009-03-24 00:12:14.000000000 +0100 +++ linux-2.6.29-xen-r4/include/linux/fs.h 2009-08-14 10:34:54.366761940 +0200 @@ -1905,7 +1905,7 @@ extern loff_t default_llseek(struct file extern loff_t vfs_llseek(struct file *file, loff_t offset, int origin); -extern struct inode * inode_init_always(struct super_block *, struct inode *); +extern int inode_init_always(struct super_block *, struct inode *); extern void inode_init_once(struct inode *); extern void inode_add_to_lists(struct super_block *, struct inode *); extern void iput(struct inode *); @@ -1932,6 +1932,7 @@ extern void __iget(struct inode * inode) extern void iget_failed(struct inode *); extern void clear_inode(struct inode *); extern void destroy_inode(struct inode *); +extern void __destroy_inode(struct inode *); extern struct inode *new_inode(struct super_block *); extern int should_remove_suid(struct dentry *); extern int file_remove_suid(struct file *); [-- Attachment #3: Type: text/plain, Size: 121 bytes --] _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2009-08-19 8:17 UTC | newest] Thread overview: 9+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2009-08-11 7:21 xfs crash, kernel 2.6.29 Christian Fischer 2009-08-11 8:09 ` Christian Fischer 2009-08-11 14:20 ` Christoph Hellwig 2009-08-11 14:39 ` Christian Fischer 2009-08-14 12:56 ` [Patch] " Christian Fischer 2009-08-14 14:18 ` Christoph Hellwig 2009-08-19 7:50 ` Andrew Lyon 2009-08-19 8:16 ` Christian Fischer 2009-08-14 13:02 ` Christian Fischer
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox