Re: Oops in 4.0.0-rc6: __destroy_inode

From: Al Viro
Date: Fri Apr 10 2015 - 08:23:46 EST


On Wed, Apr 08, 2015 at 01:12:39PM +0200, Tobias Hoffmann wrote:
> BUG: unable to handle kernel paging request at ffffffffff3cffff
> IP: [<ffffffff8115a1c7>] __destroy_inode+0x77/0xd0
> RIP: 0010:[<ffffffff8115a1c7>] [<ffffffff8115a1c7>]
> __destroy_inode+0x77/0xd0
> RSP: 0000:ffff8801aaa67bd8 EFLAGS: 00210286
> RAX: ffffffffff3cfffe RBX: ffff88010238d978 RCX: 00000000000024c0
> RDX: 0000000000000001 RSI: ffff88010238da08 RDI: ffffffffff3cffff
> RBP: ffff8801aaa67be8 R08: ffffffff8115b3d0 R09: ffff8801aaa67d40
> R10: 0000000000000400 R11: 0000000000000000 R12: ffff88010238d9f8
> R13: ffffffff815210e0 R14: 0000000000000000 R15: 00000000000000a9
> FS: 0000000000000000(0000) GS:ffff8801b1c80000(0000) knlGS:00000000f1604b40
> CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> CR2: ffffffffff3cffff CR3: 00000000c0e95000 CR4: 00000000000006e0
> Stack:
> 0000000000000003 ffff88010238d978 ffff8801aaa67c08 ffffffff8115a7d1
> ffff88010238d978 ffff88010238d978 ffff8801aaa67c38 ffffffff8115a922
> ffff8801aaa67c38 ffff8801aaa67c78 ffff8800cda4e800 ffff8800cda4eb40
> Call Trace:
> [<ffffffff8115a7d1>] destroy_inode+0x21/0x60
> [<ffffffff8115a922>] evict+0x112/0x180
> [<ffffffff8115a9c9>] dispose_list+0x39/0x50
> [<ffffffff8115b825>] prune_icache_sb+0x45/0x50
> [<ffffffff811447e3>] super_cache_scan+0x153/0x1a0
> [<ffffffff811105a3>] shrink_slab.part.55.constprop.60+0x1a3/0x250
> [<ffffffff811129c1>] shrink_zone+0xa1/0xb0
> [<ffffffff81112dbf>] kswapd+0x3ef/0x700
> [<ffffffff811129d0>] ? shrink_zone+0xb0/0xb0
> [<ffffffff810aaf04>] kthread+0xc4/0xe0
> [<ffffffff810aae40>] ? kthread_freezable_should_stop+0x60/0x60
> [<ffffffff814f6588>] ret_from_fork+0x58/0x90
> [<ffffffff810aae40>] ? kthread_freezable_should_stop+0x60/0x60
> Code: 48 8b 7b 10 48 8d 47 ff 48 83 f8 fd 77 0a 48 85 ff 74 05 f0 ff
> 0f 74 3c 48 8b 7b 18 48 8d 47 ff 48 83 f8 fd 77 0a 48 85 ff 74 05
> <f0> ff 0f 74 14 65 48 ff 0d c4 3d eb 7e 48 83 c4 08 5b 5d c3 0f
> RIP [<ffffffff8115a1c7>] __destroy_inode+0x77/0xd0
> RSP <ffff8801aaa67bd8>
> CR2: ffffffffff3cffff

FWIW, that's
if (inode->i_default_acl && inode->i_default_acl != ACL_NOT_CACHED)
posix_acl_release(inode->i_default_acl);
finding 0xffffffffff3cffff in inode->i_default_acl. Which filesystem had
that been?

> BUG: unable to handle kernel paging request at fffffffffffcffff
> IP: [<ffffffff8115a1c7>] __destroy_inode+0x77/0xd0

Same, only it had found 0xfffffffffffcffff in the same field.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/