* kernel BUG at fs/inode.c:LINE! @ 2018-12-17 6:11 syzbot 2018-12-17 7:21 ` Al Viro 2019-04-09 14:36 ` syzbot 0 siblings, 2 replies; 33+ messages in thread From: syzbot @ 2018-12-17 6:11 UTC (permalink / raw) To: linux-fsdevel, linux-kernel, syzkaller-bugs, viro Hello, syzbot found the following crash on: HEAD commit: d14b746c6c1c Add linux-next specific files for 20181214 git tree: linux-next console output: https://syzkaller.appspot.com/x/log.txt?x=13706347400000 kernel config: https://syzkaller.appspot.com/x/.config?x=1da6d2d18f803140 dashboard link: https://syzkaller.appspot.com/bug?extid=5399ed0832693e29f392 compiler: gcc (GCC) 8.0.1 20180413 (experimental) syz repro: https://syzkaller.appspot.com/x/repro.syz?x=101032b3400000 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=16534063400000 IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+5399ed0832693e29f392@syzkaller.appspotmail.com slab_pre_alloc_hook mm/slab.h:423 [inline] slab_alloc mm/slab.c:3365 [inline] kmem_cache_alloc+0x2c4/0x730 mm/slab.c:3539 __d_alloc+0xc8/0xb90 fs/dcache.c:1599 ------------[ cut here ]------------ kernel BUG at fs/inode.c:1566! d_alloc_anon fs/dcache.c:1698 [inline] d_make_root+0x43/0xc0 fs/dcache.c:1885 autofs_fill_super+0x6f1/0x1c30 fs/autofs/inode.c:273 invalid opcode: 0000 [#1] PREEMPT SMP KASAN CPU: 1 PID: 6100 Comm: syz-executor637 Not tainted 4.20.0-rc6-next-20181214+ #171 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:iput+0x915/0xa90 fs/inode.c:1566 Code: e4 0f 84 a8 fe ff ff e8 e9 fe a6 ff 48 89 df e8 61 f4 ff ff 48 8b bd f0 fe ff ff e8 35 41 08 06 e9 69 fd ff ff e8 cb fe a6 ff <0f> 0b e8 c4 fe a6 ff 0f 0b e9 d5 fb ff ff e8 b8 fe a6 ff 0f 0b e9 RSP: 0018:ffff8881c0ff76b8 EFLAGS: 00010293 RAX: ffff8881c0fdc100 RBX: ffff8881b25f44a0 RCX: ffffffff81d8fc14 RDX: 0000000000000000 RSI: ffffffff81d90455 RDI: 0000000000000007 RBP: ffff8881c0ff77f0 R08: ffff8881c0fdc100 R09: 0000000000000006 R10: 0000000000000000 R11: ffff8881c0fdc100 R12: 0000000000000040 R13: ffff8881c0ff7910 R14: 00000000ffffffea R15: ffff8881d0c4d200 mount_nodev+0x73/0x120 fs/super.c:1402 FS: 0000000001e1a880(0000) GS:ffff8881dad00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 autofs_mount+0x34/0x40 fs/autofs/init.c:16 CR2: 00000000006cd0a0 CR3: 00000001b2c56000 CR4: 00000000001406e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 legacy_get_tree+0x12f/0x260 fs/fs_context.c:714 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: vfs_get_tree+0x1cb/0x5c0 fs/super.c:1795 do_new_mount fs/namespace.c:2716 [inline] do_mount+0x82a/0x1ff0 fs/namespace.c:3042 autofs_fill_super+0x15fb/0x1c30 fs/autofs/inode.c:352 ksys_mount+0x12d/0x140 fs/namespace.c:3258 __do_sys_mount fs/namespace.c:3272 [inline] __se_sys_mount fs/namespace.c:3269 [inline] __x64_sys_mount+0xbe/0x150 fs/namespace.c:3269 do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290 mount_nodev+0x73/0x120 fs/super.c:1402 entry_SYSCALL_64_after_hwframe+0x49/0xbe autofs_mount+0x34/0x40 fs/autofs/init.c:16 RIP: 0033:0x441be9 Code: e8 dc e6 ff ff 48 83 c4 18 c3 0f 1f 80 00 00 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 3b 08 fc ff c3 66 2e 0f 1f 84 00 00 00 00 legacy_get_tree+0x12f/0x260 fs/fs_context.c:714 RSP: 002b:00007ffff6330f88 EFLAGS: 00000246 ORIG_RAX: 00000000000000a5 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 0000000000441be9 vfs_get_tree+0x1cb/0x5c0 fs/super.c:1795 RDX: 0000000020000180 RSI: 0000000020000100 RDI: 0000000000000000 RBP: 00007ffff6330fe0 R08: 0000000000000000 R09: 0000000000000100 R10: 0000000000000000 R11: 0000000000000246 R12: ffffffffffffffff do_new_mount fs/namespace.c:2716 [inline] do_mount+0x82a/0x1ff0 fs/namespace.c:3042 R13: 0000000000000003 R14: 0000000000000000 R15: 0000000000000000 FAULT_INJECTION: forcing a failure. name failslab, interval 1, probability 0, space 0, times 0 CPU: 0 PID: 6107 Comm: syz-executor637 Not tainted 4.20.0-rc6-next-20181214+ #171 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x244/0x39d lib/dump_stack.c:113 ksys_mount+0x12d/0x140 fs/namespace.c:3258 __do_sys_mount fs/namespace.c:3272 [inline] __se_sys_mount fs/namespace.c:3269 [inline] __x64_sys_mount+0xbe/0x150 fs/namespace.c:3269 fail_dump lib/fault-inject.c:51 [inline] should_fail.cold.4+0xa/0x17 lib/fault-inject.c:149 do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe __should_failslab+0x124/0x180 mm/failslab.c:32 RIP: 0033:0x441be9 should_failslab+0x9/0x14 mm/slab_common.c:1576 Code: e8 dc e6 ff ff 48 83 c4 18 c3 0f 1f 80 00 00 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 3b 08 fc ff c3 66 2e 0f 1f 84 00 00 00 00 slab_pre_alloc_hook mm/slab.h:423 [inline] slab_alloc mm/slab.c:3365 [inline] kmem_cache_alloc+0x2c4/0x730 mm/slab.c:3539 RSP: 002b:00007ffff6330f88 EFLAGS: 00000246 ORIG_RAX: 00000000000000a5 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 0000000000441be9 RDX: 0000000020000180 RSI: 0000000020000100 RDI: 0000000000000000 __d_alloc+0xc8/0xb90 fs/dcache.c:1599 RBP: 00007ffff6330fe0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: ffffffffffffffff R13: 0000000000000003 R14: 0000000000000000 R15: 0000000000000000 Modules linked in: d_alloc_anon fs/dcache.c:1698 [inline] d_make_root+0x43/0xc0 fs/dcache.c:1885 autofs_fill_super+0x6f1/0x1c30 fs/autofs/inode.c:273 mount_nodev+0x73/0x120 fs/super.c:1402 autofs_mount+0x34/0x40 fs/autofs/init.c:16 legacy_get_tree+0x12f/0x260 fs/fs_context.c:714 vfs_get_tree+0x1cb/0x5c0 fs/super.c:1795 ------------[ cut here ]------------ do_new_mount fs/namespace.c:2716 [inline] do_mount+0x82a/0x1ff0 fs/namespace.c:3042 kernel BUG at fs/inode.c:1566! invalid opcode: 0000 [#2] PREEMPT SMP KASAN CPU: 1 PID: 6105 Comm: syz-executor637 Tainted: G D 4.20.0-rc6-next-20181214+ #171 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:iput+0x915/0xa90 fs/inode.c:1566 Code: e4 0f 84 a8 fe ff ff e8 e9 fe a6 ff 48 89 df e8 61 f4 ff ff 48 8b bd f0 fe ff ff e8 35 41 08 06 e9 69 fd ff ff e8 cb fe a6 ff <0f> 0b e8 c4 fe a6 ff 0f 0b e9 d5 fb ff ff e8 b8 fe a6 ff 0f 0b e9 ksys_mount+0x12d/0x140 fs/namespace.c:3258 RSP: 0018:ffff8881b4f276b8 EFLAGS: 00010293 __do_sys_mount fs/namespace.c:3272 [inline] __se_sys_mount fs/namespace.c:3269 [inline] __x64_sys_mount+0xbe/0x150 fs/namespace.c:3269 RAX: ffff8881c170a580 RBX: ffff8881b2687880 RCX: ffffffff81d8fc14 do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290 RDX: 0000000000000000 RSI: ffffffff81d90455 RDI: 0000000000000007 RBP: ffff8881b4f277f0 R08: ffff8881c170a580 R09: ffffed103b5a5b77 R10: ffffed103b5a5b77 R11: ffff8881dad2dbbb R12: 0000000000000040 R13: ffff8881b4f27910 R14: 00000000ffffffea R15: ffff8881d0c4af00 FS: 0000000001e1a880(0000) GS:ffff8881dad00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000002497000 CR3: 00000001b3373000 CR4: 00000000001406e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 entry_SYSCALL_64_after_hwframe+0x49/0xbe DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 RIP: 0033:0x441be9 Call Trace: Code: e8 dc e6 ff ff 48 83 c4 18 c3 0f 1f 80 00 00 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 3b 08 fc ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:00007ffff6330f88 EFLAGS: 00000246 ORIG_RAX: 00000000000000a5 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 0000000000441be9 RDX: 0000000020000180 RSI: 0000000020000100 RDI: 0000000000000000 RBP: 00007ffff6330fe0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: ffffffffffffffff R13: 0000000000000003 R14: 0000000000000000 R15: 0000000000000000 ------------[ cut here ]------------ kernel BUG at fs/inode.c:1566! autofs_fill_super+0x15fb/0x1c30 fs/autofs/inode.c:352 CPU: 0 PID: 6109 Comm: syz-executor637 Tainted: G D 4.20.0-rc6-next-20181214+ #171 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x244/0x39d lib/dump_stack.c:113 fail_dump lib/fault-inject.c:51 [inline] should_fail.cold.4+0xa/0x17 lib/fault-inject.c:149 mount_nodev+0x73/0x120 fs/super.c:1402 autofs_mount+0x34/0x40 fs/autofs/init.c:16 legacy_get_tree+0x12f/0x260 fs/fs_context.c:714 vfs_get_tree+0x1cb/0x5c0 fs/super.c:1795 __should_failslab+0x124/0x180 mm/failslab.c:32 do_new_mount fs/namespace.c:2716 [inline] do_mount+0x82a/0x1ff0 fs/namespace.c:3042 should_failslab+0x9/0x14 mm/slab_common.c:1576 slab_pre_alloc_hook mm/slab.h:423 [inline] slab_alloc mm/slab.c:3365 [inline] kmem_cache_alloc+0x2c4/0x730 mm/slab.c:3539 __d_alloc+0xc8/0xb90 fs/dcache.c:1599 ksys_mount+0x12d/0x140 fs/namespace.c:3258 __do_sys_mount fs/namespace.c:3272 [inline] __se_sys_mount fs/namespace.c:3269 [inline] __x64_sys_mount+0xbe/0x150 fs/namespace.c:3269 do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290 d_alloc_anon fs/dcache.c:1698 [inline] d_make_root+0x43/0xc0 fs/dcache.c:1885 autofs_fill_super+0x6f1/0x1c30 fs/autofs/inode.c:273 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x441be9 Code: e8 dc e6 ff ff 48 83 c4 18 c3 0f 1f 80 00 00 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 3b 08 fc ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:00007ffff6330f88 EFLAGS: 00000246 ORIG_RAX: 00000000000000a5 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 0000000000441be9 RDX: 0000000020000180 RSI: 0000000020000100 RDI: 0000000000000000 RBP: 00007ffff6330fe0 R08: 0000000000000000 R09: 0000000000000100 R10: 0000000000000000 R11: 0000000000000246 R12: ffffffffffffffff R13: 0000000000000003 R14: 0000000000000000 R15: 0000000000000000 Modules linked in: mount_nodev+0x73/0x120 fs/super.c:1402 autofs_mount+0x34/0x40 fs/autofs/init.c:16 legacy_get_tree+0x12f/0x260 fs/fs_context.c:714 vfs_get_tree+0x1cb/0x5c0 fs/super.c:1795 do_new_mount fs/namespace.c:2716 [inline] do_mount+0x82a/0x1ff0 fs/namespace.c:3042 ksys_mount+0x12d/0x140 fs/namespace.c:3258 __do_sys_mount fs/namespace.c:3272 [inline] __se_sys_mount fs/namespace.c:3269 [inline] __x64_sys_mount+0xbe/0x150 fs/namespace.c:3269 do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x441be9 Code: e8 dc e6 ff ff 48 83 c4 18 c3 0f 1f 80 00 00 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 3b 08 fc ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:00007ffff6330f88 EFLAGS: 00000246 ORIG_RAX: 00000000000000a5 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 0000000000441be9 RDX: 0000000020000180 RSI: 0000000020000100 RDI: 0000000000000000 RBP: 00007ffff6330fe0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: ffffffffffffffff R13: 0000000000000003 R14: 0000000000000000 R15: 0000000000000000 CPU: 1 PID: 6101 Comm: syz-executor637 Tainted: G D 4.20.0-rc6-next-20181214+ #171 invalid opcode: 0000 [#3] PREEMPT SMP KASAN Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 CPU: 0 PID: 6102 Comm: syz-executor637 Tainted: G D 4.20.0-rc6-next-20181214+ #171 Call Trace: Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x244/0x39d lib/dump_stack.c:113 RIP: 0010:iput+0x915/0xa90 fs/inode.c:1566 Code: e4 0f 84 a8 fe ff ff e8 e9 fe a6 ff 48 89 df e8 61 f4 ff ff 48 8b bd f0 fe ff ff e8 35 41 08 06 e9 69 fd ff ff e8 cb fe a6 ff <0f> 0b e8 c4 fe a6 ff 0f 0b e9 d5 fb ff ff e8 b8 fe a6 ff 0f 0b e9 RSP: 0000:ffff8881cca776b8 EFLAGS: 00010293 fail_dump lib/fault-inject.c:51 [inline] should_fail.cold.4+0xa/0x17 lib/fault-inject.c:149 RAX: ffff8881d105c540 RBX: ffff8881b26768c0 RCX: ffffffff81d8fc14 RDX: 0000000000000000 RSI: ffffffff81d90455 RDI: 0000000000000007 RBP: ffff8881cca777f0 R08: ffff8881d105c540 R09: ffffed103b585b77 R10: ffffed103b585b77 R11: ffff8881dac2dbbb R12: 0000000000000040 R13: ffff8881cca77910 R14: 00000000ffffffea R15: ffff8881d0c4d000 FS: 0000000001e1a880(0000) GS:ffff8881dac00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020000140 CR3: 00000001d824d000 CR4: 00000000001406f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 __should_failslab+0x124/0x180 mm/failslab.c:32 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 should_failslab+0x9/0x14 mm/slab_common.c:1576 Call Trace: slab_pre_alloc_hook mm/slab.h:423 [inline] slab_alloc mm/slab.c:3365 [inline] kmem_cache_alloc+0x2c4/0x730 mm/slab.c:3539 __d_alloc+0xc8/0xb90 fs/dcache.c:1599 autofs_fill_super+0x15fb/0x1c30 fs/autofs/inode.c:352 d_alloc_anon fs/dcache.c:1698 [inline] d_make_root+0x43/0xc0 fs/dcache.c:1885 autofs_fill_super+0x6f1/0x1c30 fs/autofs/inode.c:273 mount_nodev+0x73/0x120 fs/super.c:1402 autofs_mount+0x34/0x40 fs/autofs/init.c:16 legacy_get_tree+0x12f/0x260 fs/fs_context.c:714 vfs_get_tree+0x1cb/0x5c0 fs/super.c:1795 do_new_mount fs/namespace.c:2716 [inline] do_mount+0x82a/0x1ff0 fs/namespace.c:3042 mount_nodev+0x73/0x120 fs/super.c:1402 autofs_mount+0x34/0x40 fs/autofs/init.c:16 legacy_get_tree+0x12f/0x260 fs/fs_context.c:714 vfs_get_tree+0x1cb/0x5c0 fs/super.c:1795 ksys_mount+0x12d/0x140 fs/namespace.c:3258 do_new_mount fs/namespace.c:2716 [inline] do_mount+0x82a/0x1ff0 fs/namespace.c:3042 __do_sys_mount fs/namespace.c:3272 [inline] __se_sys_mount fs/namespace.c:3269 [inline] __x64_sys_mount+0xbe/0x150 fs/namespace.c:3269 do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290 ksys_mount+0x12d/0x140 fs/namespace.c:3258 __do_sys_mount fs/namespace.c:3272 [inline] __se_sys_mount fs/namespace.c:3269 [inline] __x64_sys_mount+0xbe/0x150 fs/namespace.c:3269 entry_SYSCALL_64_after_hwframe+0x49/0xbe do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290 RIP: 0033:0x441be9 Code: e8 dc e6 ff ff 48 83 c4 18 c3 0f 1f 80 00 00 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 3b 08 fc ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:00007ffff6330f88 EFLAGS: 00000246 ORIG_RAX: 00000000000000a5 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 0000000000441be9 RDX: 0000000020000180 RSI: 0000000020000100 RDI: 0000000000000000 RBP: 00007ffff6330fe0 R08: 0000000000000000 R09: 0000000000000100 R10: 0000000000000000 R11: 0000000000000246 R12: ffffffffffffffff R13: 0000000000000003 R14: 0000000000000000 R15: 0000000000000000 entry_SYSCALL_64_after_hwframe+0x49/0xbe Modules linked in: RIP: 0033:0x441be9 ------------[ cut here ]------------ Code: e8 dc e6 ff ff 48 83 c4 18 c3 0f 1f 80 00 00 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 3b 08 fc ff c3 66 2e 0f 1f 84 00 00 00 00 kernel BUG at fs/inode.c:1566! RSP: 002b:00007ffff6330f88 EFLAGS: 00000246 ORIG_RAX: 00000000000000a5 invalid opcode: 0000 [#4] PREEMPT SMP KASAN RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 0000000000441be9 CPU: 0 PID: 6109 Comm: syz-executor637 Tainted: G D 4.20.0-rc6-next-20181214+ #171 RDX: 0000000020000180 RSI: 0000000020000100 RDI: 0000000000000000 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RBP: 00007ffff6330fe0 R08: 0000000000000000 R09: 0000000000000100 RIP: 0010:iput+0x915/0xa90 fs/inode.c:1566 R10: 0000000000000000 R11: 0000000000000246 R12: ffffffffffffffff Code: e4 0f 84 a8 fe ff ff e8 e9 fe a6 ff 48 89 df e8 61 f4 ff ff 48 8b bd f0 fe ff ff e8 35 41 08 06 e9 69 fd ff ff e8 cb fe a6 ff <0f> 0b e8 c4 fe a6 ff 0f 0b e9 d5 fb ff ff e8 b8 fe a6 ff 0f 0b e9 R13: 0000000000000003 R14: 0000000000000000 R15: 0000000000000000 RSP: 0000:ffff8881d2b476b8 EFLAGS: 00010293 ---[ end trace c981ed50117a38b3 ]--- RAX: ffff8881d96ec080 RBX: ffff8881b269a8c0 RCX: ffffffff81d8fc14 RIP: 0010:iput+0x915/0xa90 fs/inode.c:1566 RDX: 0000000000000000 RSI: ffffffff81d90455 RDI: 0000000000000007 RBP: ffff8881d2b477f0 R08: ffff8881d96ec080 R09: ffffed103b585b77 R10: ffffed103b585b77 R11: ffff8881dac2dbbb R12: 0000000000000040 R13: ffff8881d2b47910 R14: 00000000ffffffea R15: ffff8881d0c4a200 FS: 0000000001e1a880(0000) GS:ffff8881dac00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020000140 CR3: 00000001b7099000 CR4: 00000000001406f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 Code: e4 0f 84 a8 fe ff ff e8 e9 fe a6 ff 48 89 df e8 61 f4 ff ff 48 8b bd f0 fe ff ff e8 35 41 08 06 e9 69 fd ff ff e8 cb fe a6 ff <0f> 0b e8 c4 fe a6 ff 0f 0b e9 d5 fb ff ff e8 b8 fe a6 ff 0f 0b e9 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: RSP: 0018:ffff8881c0ff76b8 EFLAGS: 00010293 RAX: ffff8881c0fdc100 RBX: ffff8881b25f44a0 RCX: ffffffff81d8fc14 autofs_fill_super+0x15fb/0x1c30 fs/autofs/inode.c:352 RDX: 0000000000000000 RSI: ffffffff81d90455 RDI: 0000000000000007 RBP: ffff8881c0ff77f0 R08: ffff8881c0fdc100 R09: 0000000000000006 R10: 0000000000000000 R11: ffff8881c0fdc100 R12: 0000000000000040 R13: ffff8881c0ff7910 R14: 00000000ffffffea R15: ffff8881d0c4d200 mount_nodev+0x73/0x120 fs/super.c:1402 autofs_mount+0x34/0x40 fs/autofs/init.c:16 FS: 0000000001e1a880(0000) GS:ffff8881dad00000(0000) knlGS:0000000000000000 legacy_get_tree+0x12f/0x260 fs/fs_context.c:714 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 vfs_get_tree+0x1cb/0x5c0 fs/super.c:1795 do_new_mount fs/namespace.c:2716 [inline] do_mount+0x82a/0x1ff0 fs/namespace.c:3042 CR2: 0000000002497000 CR3: 00000001b3373000 CR4: 00000000001406e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 ksys_mount+0x12d/0x140 fs/namespace.c:3258 __do_sys_mount fs/namespace.c:3272 [inline] __se_sys_mount fs/namespace.c:3269 [inline] __x64_sys_mount+0xbe/0x150 fs/namespace.c:3269 --- This bug is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkaller@googlegroups.com. syzbot will keep track of this bug report. See: https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with syzbot. syzbot can test patches for this bug, for details see: https://goo.gl/tpsmEJ#testing-patches ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: kernel BUG at fs/inode.c:LINE! 2018-12-17 6:11 kernel BUG at fs/inode.c:LINE! syzbot @ 2018-12-17 7:21 ` Al Viro 2018-12-17 10:08 ` Dmitry Vyukov 2018-12-18 10:42 ` Ian Kent 2019-04-09 14:36 ` syzbot 1 sibling, 2 replies; 33+ messages in thread From: Al Viro @ 2018-12-17 7:21 UTC (permalink / raw) To: syzbot; +Cc: linux-fsdevel, linux-kernel, syzkaller-bugs On Sun, Dec 16, 2018 at 10:11:04PM -0800, syzbot wrote: > Hello, > > syzbot found the following crash on: > > HEAD commit: d14b746c6c1c Add linux-next specific files for 20181214 > git tree: linux-next > console output: https://syzkaller.appspot.com/x/log.txt?x=13706347400000 > kernel config: https://syzkaller.appspot.com/x/.config?x=1da6d2d18f803140 > dashboard link: https://syzkaller.appspot.com/bug?extid=5399ed0832693e29f392 > compiler: gcc (GCC) 8.0.1 20180413 (experimental) > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=101032b3400000 > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=16534063400000 > > IMPORTANT: if you fix the bug, please add the following tag to the commit: > Reported-by: syzbot+5399ed0832693e29f392@syzkaller.appspotmail.com > > slab_pre_alloc_hook mm/slab.h:423 [inline] > slab_alloc mm/slab.c:3365 [inline] > kmem_cache_alloc+0x2c4/0x730 mm/slab.c:3539 > __d_alloc+0xc8/0xb90 fs/dcache.c:1599 > ------------[ cut here ]------------ > kernel BUG at fs/inode.c:1566! > d_alloc_anon fs/dcache.c:1698 [inline] > d_make_root+0x43/0xc0 fs/dcache.c:1885 > autofs_fill_super+0x6f1/0x1c30 fs/autofs/inode.c:273 Huh? BUG is in iput(), AFAICS, so the stack trace is rather misreported. iput() can be called by d_make_root(), provided that dentry allocation fails. So the most straightforward interpretation would be that we had an allocation failure (injected?), followed by iput() of the inode passed to d_make_root(). Which happened to find I_CLEAR in ->i_state of that inode somehow, which should be impossible short of seriously buggered inode refcounting somewhere - the inode has just been returned by new_inode(), which clears i_state, and it would have to have passed clear_inode() (i.e. has been through inode eviction) since then... ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: kernel BUG at fs/inode.c:LINE! 2018-12-17 7:21 ` Al Viro @ 2018-12-17 10:08 ` Dmitry Vyukov 2018-12-18 10:40 ` Tetsuo Handa 2018-12-18 10:42 ` Ian Kent 1 sibling, 1 reply; 33+ messages in thread From: Dmitry Vyukov @ 2018-12-17 10:08 UTC (permalink / raw) To: Al Viro; +Cc: syzbot, linux-fsdevel, LKML, syzkaller-bugs On Mon, Dec 17, 2018 at 8:21 AM Al Viro <viro@zeniv.linux.org.uk> wrote: > > On Sun, Dec 16, 2018 at 10:11:04PM -0800, syzbot wrote: > > Hello, > > > > syzbot found the following crash on: > > > > HEAD commit: d14b746c6c1c Add linux-next specific files for 20181214 > > git tree: linux-next > > console output: https://syzkaller.appspot.com/x/log.txt?x=13706347400000 > > kernel config: https://syzkaller.appspot.com/x/.config?x=1da6d2d18f803140 > > dashboard link: https://syzkaller.appspot.com/bug?extid=5399ed0832693e29f392 > > compiler: gcc (GCC) 8.0.1 20180413 (experimental) > > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=101032b3400000 > > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=16534063400000 > > > > IMPORTANT: if you fix the bug, please add the following tag to the commit: > > Reported-by: syzbot+5399ed0832693e29f392@syzkaller.appspotmail.com > > > > slab_pre_alloc_hook mm/slab.h:423 [inline] > > slab_alloc mm/slab.c:3365 [inline] > > kmem_cache_alloc+0x2c4/0x730 mm/slab.c:3539 > > __d_alloc+0xc8/0xb90 fs/dcache.c:1599 > > ------------[ cut here ]------------ > > kernel BUG at fs/inode.c:1566! > > d_alloc_anon fs/dcache.c:1698 [inline] > > d_make_root+0x43/0xc0 fs/dcache.c:1885 > > autofs_fill_super+0x6f1/0x1c30 fs/autofs/inode.c:273 > > Huh? BUG is in iput(), AFAICS, so the stack trace is rather misreported. Yes, it's a known problem that kernel is generally incapable of producing parsable crash reports. I think Tetsuo is working on a solution, but it takes very large amount of discussions and months of time. > iput() can be called by d_make_root(), provided that dentry allocation > fails. So the most straightforward interpretation would be that we > had an allocation failure (injected?), followed by iput() of the inode > passed to d_make_root(). Which happened to find I_CLEAR in ->i_state > of that inode somehow, which should be impossible short of seriously > buggered inode refcounting somewhere - the inode has just been returned > by new_inode(), which clears i_state, and it would have to have passed > clear_inode() (i.e. has been through inode eviction) since then... Yes, there are injected failures in the log. And the repro says: #{..."fault":true,"fault_call":1,"fault_nth":36 ...} mkdir(&(0x7f0000000140)='./file0\x00', 0x0) mount(0x0, &(0x7f0000000100)='./file0\x00', &(0x7f0000000180)='autofs\x00', 0x0, 0x0) Since the repro is single-threaded, I would expect that the bug is directly on the error handling path of the failure allocation. ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: kernel BUG at fs/inode.c:LINE! 2018-12-17 10:08 ` Dmitry Vyukov @ 2018-12-18 10:40 ` Tetsuo Handa 0 siblings, 0 replies; 33+ messages in thread From: Tetsuo Handa @ 2018-12-18 10:40 UTC (permalink / raw) To: Dmitry Vyukov, Al Viro; +Cc: syzbot, linux-fsdevel, LKML, syzkaller-bugs On 2018/12/17 19:08, Dmitry Vyukov wrote: > On Mon, Dec 17, 2018 at 8:21 AM Al Viro <viro@zeniv.linux.org.uk> wrote: >>> slab_pre_alloc_hook mm/slab.h:423 [inline] >>> slab_alloc mm/slab.c:3365 [inline] >>> kmem_cache_alloc+0x2c4/0x730 mm/slab.c:3539 >>> __d_alloc+0xc8/0xb90 fs/dcache.c:1599 >>> ------------[ cut here ]------------ >>> kernel BUG at fs/inode.c:1566! >>> d_alloc_anon fs/dcache.c:1698 [inline] >>> d_make_root+0x43/0xc0 fs/dcache.c:1885 >>> autofs_fill_super+0x6f1/0x1c30 fs/autofs/inode.c:273 >> >> Huh? BUG is in iput(), AFAICS, so the stack trace is rather misreported. > > Yes, it's a known problem that kernel is generally incapable of > producing parsable crash reports. I think Tetsuo is working on a > solution, but it takes very large amount of discussions and months of > time. The solution, CONFIG_PRINTK_FROM option (which will be renamed to CONFIG_PRINTK_CALLER option tomorrow), just arrived at linux-next-20181218. We can try it... But currently syzbot cannot boot using linux-next-20181218 due to "Kernel panic - not syncing: Can't create rootfs" presumably due to changes merged by "Merge branches 'work.mount', 'work.misc', 'misc.misc' and 'work.iov_iter' into for-next". I think that we need to examine this "Can't create rootfs" problem, for the merge window is approaching... ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: kernel BUG at fs/inode.c:LINE! 2018-12-17 7:21 ` Al Viro 2018-12-17 10:08 ` Dmitry Vyukov @ 2018-12-18 10:42 ` Ian Kent 2018-12-18 11:01 ` Amir Goldstein ` (2 more replies) 1 sibling, 3 replies; 33+ messages in thread From: Ian Kent @ 2018-12-18 10:42 UTC (permalink / raw) To: Al Viro, syzbot, Andrew Morton, DmitryVyukov Cc: linux-fsdevel, linux-kernel, syzkaller-bugs On Mon, 2018-12-17 at 07:21 +0000, Al Viro wrote: > On Sun, Dec 16, 2018 at 10:11:04PM -0800, syzbot wrote: > > Hello, > > > > syzbot found the following crash on: > > > > HEAD commit: d14b746c6c1c Add linux-next specific files for 20181214 > > git tree: linux-next > > console output: https://syzkaller.appspot.com/x/log.txt?x=13706347400000 > > kernel config: https://syzkaller.appspot.com/x/.config?x=1da6d2d18f803140 > > dashboard link: https://syzkaller.appspot.com/bug?extid=5399ed0832693e29f392 > > compiler: gcc (GCC) 8.0.1 20180413 (experimental) > > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=101032b3400000 > > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=16534063400000 > > > > IMPORTANT: if you fix the bug, please add the following tag to the commit: > > Reported-by: syzbot+5399ed0832693e29f392@syzkaller.appspotmail.com > > > > slab_pre_alloc_hook mm/slab.h:423 [inline] > > slab_alloc mm/slab.c:3365 [inline] > > kmem_cache_alloc+0x2c4/0x730 mm/slab.c:3539 > > __d_alloc+0xc8/0xb90 fs/dcache.c:1599 > > ------------[ cut here ]------------ > > kernel BUG at fs/inode.c:1566! > > d_alloc_anon fs/dcache.c:1698 [inline] > > d_make_root+0x43/0xc0 fs/dcache.c:1885 > > autofs_fill_super+0x6f1/0x1c30 fs/autofs/inode.c:273 > > Huh? BUG is in iput(), AFAICS, so the stack trace is rather misreported. > iput() can be called by d_make_root(), provided that dentry allocation > fails. So the most straightforward interpretation would be that we > had an allocation failure (injected?), followed by iput() of the inode > passed to d_make_root(). Which happened to find I_CLEAR in ->i_state > of that inode somehow, which should be impossible short of seriously > buggered inode refcounting somewhere - the inode has just been returned > by new_inode(), which clears i_state, and it would have to have passed > clear_inode() (i.e. has been through inode eviction) since then... Sorry Al, that's my bad. See https://www.ozlabs.org/~akpm/mmotm/broken-out/autofs-fix-possible-inode-leak-in-autofs_fill_super.patch I think this will fix it, I'll forward it to Andrew if you agree: autofs - fix handling of d_make_root() return in autofs_fill_super() From: Ian Kent <raven@themaw.net> A previous change to handle a possible inode leak in autofs_fill_super() added an iput() on d_make_root() failure but d_make_root() already puts the passed in inode on failure. Reported-by: syzbot+5399ed0832693e29f392@syzkaller.appspotmail.com Signed-off-by: Ian Kent <raven@themaw.net> --- fs/autofs/inode.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/fs/autofs/inode.c b/fs/autofs/inode.c index 501833cc49a8..953f76b95172 100644 --- a/fs/autofs/inode.c +++ b/fs/autofs/inode.c @@ -271,7 +271,7 @@ int autofs_fill_super(struct super_block *s, void *data, int silent) } root = d_make_root(root_inode); if (!root) - goto fail_iput; + goto fail_ino; pipe = NULL; root->d_fsdata = ino; @@ -347,8 +347,6 @@ int autofs_fill_super(struct super_block *s, void *data, int silent) fail_dput: dput(root); goto fail_free; -fail_iput: - iput(root_inode); fail_ino: autofs_free_ino(ino); fail_free: ^ permalink raw reply related [flat|nested] 33+ messages in thread
* Re: kernel BUG at fs/inode.c:LINE! 2018-12-18 10:42 ` Ian Kent @ 2018-12-18 11:01 ` Amir Goldstein 2018-12-18 11:52 ` Ian Kent 2018-12-18 11:34 ` Ian Kent 2018-12-18 13:51 ` Al Viro 2 siblings, 1 reply; 33+ messages in thread From: Amir Goldstein @ 2018-12-18 11:01 UTC (permalink / raw) To: Ian Kent Cc: Al Viro, syzbot+5399ed0832693e29f392, Andrew Morton, Dmitry Vyukov, linux-fsdevel, linux-kernel, syzkaller-bugs On Tue, Dec 18, 2018 at 12:43 PM Ian Kent <raven@themaw.net> wrote: > > On Mon, 2018-12-17 at 07:21 +0000, Al Viro wrote: > > On Sun, Dec 16, 2018 at 10:11:04PM -0800, syzbot wrote: > > > Hello, > > > > > > syzbot found the following crash on: > > > > > > HEAD commit: d14b746c6c1c Add linux-next specific files for 20181214 > > > git tree: linux-next > > > console output: https://syzkaller.appspot.com/x/log.txt?x=13706347400000 > > > kernel config: https://syzkaller.appspot.com/x/.config?x=1da6d2d18f803140 > > > dashboard link: https://syzkaller.appspot.com/bug?extid=5399ed0832693e29f392 > > > compiler: gcc (GCC) 8.0.1 20180413 (experimental) > > > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=101032b3400000 > > > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=16534063400000 > > > > > > IMPORTANT: if you fix the bug, please add the following tag to the commit: > > > Reported-by: syzbot+5399ed0832693e29f392@syzkaller.appspotmail.com > > > > > > slab_pre_alloc_hook mm/slab.h:423 [inline] > > > slab_alloc mm/slab.c:3365 [inline] > > > kmem_cache_alloc+0x2c4/0x730 mm/slab.c:3539 > > > __d_alloc+0xc8/0xb90 fs/dcache.c:1599 > > > ------------[ cut here ]------------ > > > kernel BUG at fs/inode.c:1566! > > > d_alloc_anon fs/dcache.c:1698 [inline] > > > d_make_root+0x43/0xc0 fs/dcache.c:1885 > > > autofs_fill_super+0x6f1/0x1c30 fs/autofs/inode.c:273 > > > > Huh? BUG is in iput(), AFAICS, so the stack trace is rather misreported. > > iput() can be called by d_make_root(), provided that dentry allocation > > fails. So the most straightforward interpretation would be that we > > had an allocation failure (injected?), followed by iput() of the inode > > passed to d_make_root(). Which happened to find I_CLEAR in ->i_state > > of that inode somehow, which should be impossible short of seriously > > buggered inode refcounting somewhere - the inode has just been returned > > by new_inode(), which clears i_state, and it would have to have passed > > clear_inode() (i.e. has been through inode eviction) since then... > > Sorry Al, that's my bad. > > See https://www.ozlabs.org/~akpm/mmotm/broken-out/autofs-fix-possible-inode-leak-in-autofs_fill_super.patch > > I think this will fix it, I'll forward it to Andrew if you agree: > > autofs - fix handling of d_make_root() return in autofs_fill_super() You realize you can just revert that patch. d_make_root() can take NULL inode as argument. At the very least, please mention the offending commit with Fixes tag. Thanks, Amir. > > From: Ian Kent <raven@themaw.net> > > A previous change to handle a possible inode leak in autofs_fill_super() > added an iput() on d_make_root() failure but d_make_root() already puts > the passed in inode on failure. > > Reported-by: syzbot+5399ed0832693e29f392@syzkaller.appspotmail.com > Signed-off-by: Ian Kent <raven@themaw.net> > --- > fs/autofs/inode.c | 4 +--- > 1 file changed, 1 insertion(+), 3 deletions(-) > > diff --git a/fs/autofs/inode.c b/fs/autofs/inode.c > index 501833cc49a8..953f76b95172 100644 > --- a/fs/autofs/inode.c > +++ b/fs/autofs/inode.c > @@ -271,7 +271,7 @@ int autofs_fill_super(struct super_block *s, void *data, int silent) > } > root = d_make_root(root_inode); > if (!root) > - goto fail_iput; > + goto fail_ino; > pipe = NULL; > > root->d_fsdata = ino; > @@ -347,8 +347,6 @@ int autofs_fill_super(struct super_block *s, void *data, int silent) > fail_dput: > dput(root); > goto fail_free; > -fail_iput: > - iput(root_inode); > fail_ino: > autofs_free_ino(ino); > fail_free: > ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: kernel BUG at fs/inode.c:LINE! 2018-12-18 11:01 ` Amir Goldstein @ 2018-12-18 11:52 ` Ian Kent 0 siblings, 0 replies; 33+ messages in thread From: Ian Kent @ 2018-12-18 11:52 UTC (permalink / raw) To: Amir Goldstein Cc: Al Viro, syzbot+5399ed0832693e29f392, Andrew Morton, Dmitry Vyukov, linux-fsdevel, linux-kernel, syzkaller-bugs On Tue, 2018-12-18 at 13:01 +0200, Amir Goldstein wrote: > On Tue, Dec 18, 2018 at 12:43 PM Ian Kent <raven@themaw.net> wrote: > > > > On Mon, 2018-12-17 at 07:21 +0000, Al Viro wrote: > > > On Sun, Dec 16, 2018 at 10:11:04PM -0800, syzbot wrote: > > > > Hello, > > > > > > > > syzbot found the following crash on: > > > > > > > > HEAD commit: d14b746c6c1c Add linux-next specific files for 20181214 > > > > git tree: linux-next > > > > console output: https://syzkaller.appspot.com/x/log.txt?x=13706347400000 > > > > kernel config: > > > > https://syzkaller.appspot.com/x/.config?x=1da6d2d18f803140 > > > > dashboard link: > > > > https://syzkaller.appspot.com/bug?extid=5399ed0832693e29f392 > > > > compiler: gcc (GCC) 8.0.1 20180413 (experimental) > > > > syz repro: > > > > https://syzkaller.appspot.com/x/repro.syz?x=101032b3400000 > > > > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=16534063400000 > > > > > > > > IMPORTANT: if you fix the bug, please add the following tag to the > > > > commit: > > > > Reported-by: syzbot+5399ed0832693e29f392@syzkaller.appspotmail.com > > > > > > > > slab_pre_alloc_hook mm/slab.h:423 [inline] > > > > slab_alloc mm/slab.c:3365 [inline] > > > > kmem_cache_alloc+0x2c4/0x730 mm/slab.c:3539 > > > > __d_alloc+0xc8/0xb90 fs/dcache.c:1599 > > > > ------------[ cut here ]------------ > > > > kernel BUG at fs/inode.c:1566! > > > > d_alloc_anon fs/dcache.c:1698 [inline] > > > > d_make_root+0x43/0xc0 fs/dcache.c:1885 > > > > autofs_fill_super+0x6f1/0x1c30 fs/autofs/inode.c:273 > > > > > > Huh? BUG is in iput(), AFAICS, so the stack trace is rather misreported. > > > iput() can be called by d_make_root(), provided that dentry allocation > > > fails. So the most straightforward interpretation would be that we > > > had an allocation failure (injected?), followed by iput() of the inode > > > passed to d_make_root(). Which happened to find I_CLEAR in ->i_state > > > of that inode somehow, which should be impossible short of seriously > > > buggered inode refcounting somewhere - the inode has just been returned > > > by new_inode(), which clears i_state, and it would have to have passed > > > clear_inode() (i.e. has been through inode eviction) since then... > > > > Sorry Al, that's my bad. > > > > See > > https://www.ozlabs.org/~akpm/mmotm/broken-out/autofs-fix-possible-inode-leak-in-autofs_fill_super.patch > > > > I think this will fix it, I'll forward it to Andrew if you agree: > > > > autofs - fix handling of d_make_root() return in autofs_fill_super() > > You realize you can just revert that patch. > d_make_root() can take NULL inode as argument. > At the very least, please mention the offending commit with Fixes tag. Thanks Amir, I did get that after looking again once the panic of my stupid mistake passed, ;) > > Thanks, > Amir. > > > > > From: Ian Kent <raven@themaw.net> > > > > A previous change to handle a possible inode leak in autofs_fill_super() > > added an iput() on d_make_root() failure but d_make_root() already puts > > the passed in inode on failure. > > > > Reported-by: syzbot+5399ed0832693e29f392@syzkaller.appspotmail.com > > Signed-off-by: Ian Kent <raven@themaw.net> > > --- > > fs/autofs/inode.c | 4 +--- > > 1 file changed, 1 insertion(+), 3 deletions(-) > > > > diff --git a/fs/autofs/inode.c b/fs/autofs/inode.c > > index 501833cc49a8..953f76b95172 100644 > > --- a/fs/autofs/inode.c > > +++ b/fs/autofs/inode.c > > @@ -271,7 +271,7 @@ int autofs_fill_super(struct super_block *s, void *data, > > int silent) > > } > > root = d_make_root(root_inode); > > if (!root) > > - goto fail_iput; > > + goto fail_ino; > > pipe = NULL; > > > > root->d_fsdata = ino; > > @@ -347,8 +347,6 @@ int autofs_fill_super(struct super_block *s, void *data, > > int silent) > > fail_dput: > > dput(root); > > goto fail_free; > > -fail_iput: > > - iput(root_inode); > > fail_ino: > > autofs_free_ino(ino); > > fail_free: > > ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: kernel BUG at fs/inode.c:LINE! 2018-12-18 10:42 ` Ian Kent 2018-12-18 11:01 ` Amir Goldstein @ 2018-12-18 11:34 ` Ian Kent 2018-12-18 12:27 ` Dmitry Vyukov 2018-12-18 21:09 ` Andrew Morton 2018-12-18 13:51 ` Al Viro 2 siblings, 2 replies; 33+ messages in thread From: Ian Kent @ 2018-12-18 11:34 UTC (permalink / raw) To: Al Viro, syzbot, Andrew Morton, DmitryVyukov Cc: linux-fsdevel, linux-kernel, syzkaller-bugs On Tue, 2018-12-18 at 18:42 +0800, Ian Kent wrote: > On Mon, 2018-12-17 at 07:21 +0000, Al Viro wrote: > > On Sun, Dec 16, 2018 at 10:11:04PM -0800, syzbot wrote: > > > Hello, > > > > > > syzbot found the following crash on: > > > > > > HEAD commit: d14b746c6c1c Add linux-next specific files for 20181214 > > > git tree: linux-next > > > console output: https://syzkaller.appspot.com/x/log.txt?x=13706347400000 > > > kernel config: https://syzkaller.appspot.com/x/.config?x=1da6d2d18f803140 > > > dashboard link: > > > https://syzkaller.appspot.com/bug?extid=5399ed0832693e29f392 > > > compiler: gcc (GCC) 8.0.1 20180413 (experimental) > > > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=101032b3400000 > > > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=16534063400000 > > > > > > IMPORTANT: if you fix the bug, please add the following tag to the commit: > > > Reported-by: syzbot+5399ed0832693e29f392@syzkaller.appspotmail.com > > > > > > slab_pre_alloc_hook mm/slab.h:423 [inline] > > > slab_alloc mm/slab.c:3365 [inline] > > > kmem_cache_alloc+0x2c4/0x730 mm/slab.c:3539 > > > __d_alloc+0xc8/0xb90 fs/dcache.c:1599 > > > ------------[ cut here ]------------ > > > kernel BUG at fs/inode.c:1566! > > > d_alloc_anon fs/dcache.c:1698 [inline] > > > d_make_root+0x43/0xc0 fs/dcache.c:1885 > > > autofs_fill_super+0x6f1/0x1c30 fs/autofs/inode.c:273 > > > > Huh? BUG is in iput(), AFAICS, so the stack trace is rather misreported. > > iput() can be called by d_make_root(), provided that dentry allocation > > fails. So the most straightforward interpretation would be that we > > had an allocation failure (injected?), followed by iput() of the inode > > passed to d_make_root(). Which happened to find I_CLEAR in ->i_state > > of that inode somehow, which should be impossible short of seriously > > buggered inode refcounting somewhere - the inode has just been returned > > by new_inode(), which clears i_state, and it would have to have passed > > clear_inode() (i.e. has been through inode eviction) since then... > > Sorry Al, that's my bad. > > See > https://www.ozlabs.org/~akpm/mmotm/broken-out/autofs-fix-possible-inode-leak-in-autofs_fill_super.patch > > I think this will fix it, I'll forward it to Andrew if you agree: Actually, looking at it again the above patch is plain not needed, dropping it and updating the patch which follows it in the series is what needs to be done. Andrew, what should I do to make this easiest for you to handle, a respost with v2 in the subject of the patch affected by dropping the above patch? Or I could repost the series with above patch dropped and the affected patch corrected? > > autofs - fix handling of d_make_root() return in autofs_fill_super() > > From: Ian Kent <raven@themaw.net> > > A previous change to handle a possible inode leak in autofs_fill_super() > added an iput() on d_make_root() failure but d_make_root() already puts > the passed in inode on failure. > > Reported-by: syzbot+5399ed0832693e29f392@syzkaller.appspotmail.com > Signed-off-by: Ian Kent <raven@themaw.net> > --- > fs/autofs/inode.c | 4 +--- > 1 file changed, 1 insertion(+), 3 deletions(-) > > diff --git a/fs/autofs/inode.c b/fs/autofs/inode.c > index 501833cc49a8..953f76b95172 100644 > --- a/fs/autofs/inode.c > +++ b/fs/autofs/inode.c > @@ -271,7 +271,7 @@ int autofs_fill_super(struct super_block *s, void *data, > int silent) > } > root = d_make_root(root_inode); > if (!root) > - goto fail_iput; > + goto fail_ino; > pipe = NULL; > > root->d_fsdata = ino; > @@ -347,8 +347,6 @@ int autofs_fill_super(struct super_block *s, void *data, > int silent) > fail_dput: > dput(root); > goto fail_free; > -fail_iput: > - iput(root_inode); > fail_ino: > autofs_free_ino(ino); > fail_free: > ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: kernel BUG at fs/inode.c:LINE! 2018-12-18 11:34 ` Ian Kent @ 2018-12-18 12:27 ` Dmitry Vyukov 2018-12-18 12:42 ` Ian Kent 2018-12-18 21:09 ` Andrew Morton 1 sibling, 1 reply; 33+ messages in thread From: Dmitry Vyukov @ 2018-12-18 12:27 UTC (permalink / raw) To: Ian Kent Cc: Al Viro, syzbot, Andrew Morton, linux-fsdevel, LKML, syzkaller-bugs On Tue, Dec 18, 2018 at 12:35 PM Ian Kent <raven@themaw.net> wrote: > > On Tue, 2018-12-18 at 18:42 +0800, Ian Kent wrote: > > On Mon, 2018-12-17 at 07:21 +0000, Al Viro wrote: > > > On Sun, Dec 16, 2018 at 10:11:04PM -0800, syzbot wrote: > > > > Hello, > > > > > > > > syzbot found the following crash on: > > > > > > > > HEAD commit: d14b746c6c1c Add linux-next specific files for 20181214 > > > > git tree: linux-next > > > > console output: https://syzkaller.appspot.com/x/log.txt?x=13706347400000 > > > > kernel config: https://syzkaller.appspot.com/x/.config?x=1da6d2d18f803140 > > > > dashboard link: > > > > https://syzkaller.appspot.com/bug?extid=5399ed0832693e29f392 > > > > compiler: gcc (GCC) 8.0.1 20180413 (experimental) > > > > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=101032b3400000 > > > > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=16534063400000 > > > > > > > > IMPORTANT: if you fix the bug, please add the following tag to the commit: > > > > Reported-by: syzbot+5399ed0832693e29f392@syzkaller.appspotmail.com > > > > > > > > slab_pre_alloc_hook mm/slab.h:423 [inline] > > > > slab_alloc mm/slab.c:3365 [inline] > > > > kmem_cache_alloc+0x2c4/0x730 mm/slab.c:3539 > > > > __d_alloc+0xc8/0xb90 fs/dcache.c:1599 > > > > ------------[ cut here ]------------ > > > > kernel BUG at fs/inode.c:1566! > > > > d_alloc_anon fs/dcache.c:1698 [inline] > > > > d_make_root+0x43/0xc0 fs/dcache.c:1885 > > > > autofs_fill_super+0x6f1/0x1c30 fs/autofs/inode.c:273 > > > > > > Huh? BUG is in iput(), AFAICS, so the stack trace is rather misreported. > > > iput() can be called by d_make_root(), provided that dentry allocation > > > fails. So the most straightforward interpretation would be that we > > > had an allocation failure (injected?), followed by iput() of the inode > > > passed to d_make_root(). Which happened to find I_CLEAR in ->i_state > > > of that inode somehow, which should be impossible short of seriously > > > buggered inode refcounting somewhere - the inode has just been returned > > > by new_inode(), which clears i_state, and it would have to have passed > > > clear_inode() (i.e. has been through inode eviction) since then... > > > > Sorry Al, that's my bad. > > > > See > > https://www.ozlabs.org/~akpm/mmotm/broken-out/autofs-fix-possible-inode-leak-in-autofs_fill_super.patch > > > > I think this will fix it, I'll forward it to Andrew if you agree: > > Actually, looking at it again the above patch is plain not needed, > dropping it and updating the patch which follows it in the series > is what needs to be done. > > Andrew, what should I do to make this easiest for you to handle, > a respost with v2 in the subject of the patch affected by dropping > the above patch? > > Or I could repost the series with above patch dropped and the affected > patch corrected? Hi Ian, If you going to amend any commits, please add: Tested-by: syzbot+5399ed0832693e29f392@syzkaller.appspotmail.com otherwise: Reported-by: syzbot+5399ed0832693e29f392@syzkaller.appspotmail.com Thanks > > autofs - fix handling of d_make_root() return in autofs_fill_super() > > > > From: Ian Kent <raven@themaw.net> > > > > A previous change to handle a possible inode leak in autofs_fill_super() > > added an iput() on d_make_root() failure but d_make_root() already puts > > the passed in inode on failure. > > > > Reported-by: syzbot+5399ed0832693e29f392@syzkaller.appspotmail.com > > Signed-off-by: Ian Kent <raven@themaw.net> > > --- > > fs/autofs/inode.c | 4 +--- > > 1 file changed, 1 insertion(+), 3 deletions(-) > > > > diff --git a/fs/autofs/inode.c b/fs/autofs/inode.c > > index 501833cc49a8..953f76b95172 100644 > > --- a/fs/autofs/inode.c > > +++ b/fs/autofs/inode.c > > @@ -271,7 +271,7 @@ int autofs_fill_super(struct super_block *s, void *data, > > int silent) > > } > > root = d_make_root(root_inode); > > if (!root) > > - goto fail_iput; > > + goto fail_ino; > > pipe = NULL; > > > > root->d_fsdata = ino; > > @@ -347,8 +347,6 @@ int autofs_fill_super(struct super_block *s, void *data, > > int silent) > > fail_dput: > > dput(root); > > goto fail_free; > > -fail_iput: > > - iput(root_inode); > > fail_ino: > > autofs_free_ino(ino); > > fail_free: > > > ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: kernel BUG at fs/inode.c:LINE! 2018-12-18 12:27 ` Dmitry Vyukov @ 2018-12-18 12:42 ` Ian Kent 2018-12-18 13:19 ` Dmitry Vyukov 0 siblings, 1 reply; 33+ messages in thread From: Ian Kent @ 2018-12-18 12:42 UTC (permalink / raw) To: Dmitry Vyukov Cc: Al Viro, syzbot, Andrew Morton, linux-fsdevel, LKML, syzkaller-bugs On Tue, 2018-12-18 at 13:27 +0100, Dmitry Vyukov wrote: > On Tue, Dec 18, 2018 at 12:35 PM Ian Kent <raven@themaw.net> wrote: > > > > On Tue, 2018-12-18 at 18:42 +0800, Ian Kent wrote: > > > On Mon, 2018-12-17 at 07:21 +0000, Al Viro wrote: > > > > On Sun, Dec 16, 2018 at 10:11:04PM -0800, syzbot wrote: > > > > > Hello, > > > > > > > > > > syzbot found the following crash on: > > > > > > > > > > HEAD commit: d14b746c6c1c Add linux-next specific files for > > > > > 20181214 > > > > > git tree: linux-next > > > > > console output: > > > > > https://syzkaller.appspot.com/x/log.txt?x=13706347400000 > > > > > kernel config: > > > > > https://syzkaller.appspot.com/x/.config?x=1da6d2d18f803140 > > > > > dashboard link: > > > > > https://syzkaller.appspot.com/bug?extid=5399ed0832693e29f392 > > > > > compiler: gcc (GCC) 8.0.1 20180413 (experimental) > > > > > syz repro: > > > > > https://syzkaller.appspot.com/x/repro.syz?x=101032b3400000 > > > > > C reproducer: > > > > > https://syzkaller.appspot.com/x/repro.c?x=16534063400000 > > > > > > > > > > IMPORTANT: if you fix the bug, please add the following tag to the > > > > > commit: > > > > > Reported-by: syzbot+5399ed0832693e29f392@syzkaller.appspotmail.com > > > > > > > > > > slab_pre_alloc_hook mm/slab.h:423 [inline] > > > > > slab_alloc mm/slab.c:3365 [inline] > > > > > kmem_cache_alloc+0x2c4/0x730 mm/slab.c:3539 > > > > > __d_alloc+0xc8/0xb90 fs/dcache.c:1599 > > > > > ------------[ cut here ]------------ > > > > > kernel BUG at fs/inode.c:1566! > > > > > d_alloc_anon fs/dcache.c:1698 [inline] > > > > > d_make_root+0x43/0xc0 fs/dcache.c:1885 > > > > > autofs_fill_super+0x6f1/0x1c30 fs/autofs/inode.c:273 > > > > > > > > Huh? BUG is in iput(), AFAICS, so the stack trace is rather > > > > misreported. > > > > iput() can be called by d_make_root(), provided that dentry allocation > > > > fails. So the most straightforward interpretation would be that we > > > > had an allocation failure (injected?), followed by iput() of the inode > > > > passed to d_make_root(). Which happened to find I_CLEAR in ->i_state > > > > of that inode somehow, which should be impossible short of seriously > > > > buggered inode refcounting somewhere - the inode has just been returned > > > > by new_inode(), which clears i_state, and it would have to have passed > > > > clear_inode() (i.e. has been through inode eviction) since then... > > > > > > Sorry Al, that's my bad. > > > > > > See > > > https://www.ozlabs.org/~akpm/mmotm/broken-out/autofs-fix-possible-inode-leak-in-autofs_fill_super.patch > > > > > > I think this will fix it, I'll forward it to Andrew if you agree: > > > > Actually, looking at it again the above patch is plain not needed, > > dropping it and updating the patch which follows it in the series > > is what needs to be done. > > > > Andrew, what should I do to make this easiest for you to handle, > > a respost with v2 in the subject of the patch affected by dropping > > the above patch? > > > > Or I could repost the series with above patch dropped and the affected > > patch corrected? > > Hi Ian, > > If you going to amend any commits, please add: > Tested-by: syzbot+5399ed0832693e29f392@syzkaller.appspotmail.com > otherwise: > Reported-by: syzbot+5399ed0832693e29f392@syzkaller.appspotmail.com I was thinking about how to handle loosing that information. I don't think this amounts amending commits since Andrews mmotm is based on patch series so dropping a patch and updating patches before being merged won't capture this. Adding the "Tested-by" attribution to the updated patch prior to syzbot actually performing the test might be ok since it will get tested along the way. Although the problem patch itself won't exist any more so ... ? OTOH, if I repost the series I think I can send them to syzbot for testing before forwarding to Andrew (I've done something like that before but can't remember how now) and add the attribution to the series. But this all depends on what is best for Andrew and what Al would like to see done. > > Thanks > > > > autofs - fix handling of d_make_root() return in autofs_fill_super() > > > > > > From: Ian Kent <raven@themaw.net> > > > > > > A previous change to handle a possible inode leak in autofs_fill_super() > > > added an iput() on d_make_root() failure but d_make_root() already puts > > > the passed in inode on failure. > > > > > > Reported-by: syzbot+5399ed0832693e29f392@syzkaller.appspotmail.com > > > Signed-off-by: Ian Kent <raven@themaw.net> > > > --- > > > fs/autofs/inode.c | 4 +--- > > > 1 file changed, 1 insertion(+), 3 deletions(-) > > > > > > diff --git a/fs/autofs/inode.c b/fs/autofs/inode.c > > > index 501833cc49a8..953f76b95172 100644 > > > --- a/fs/autofs/inode.c > > > +++ b/fs/autofs/inode.c > > > @@ -271,7 +271,7 @@ int autofs_fill_super(struct super_block *s, void > > > *data, > > > int silent) > > > } > > > root = d_make_root(root_inode); > > > if (!root) > > > - goto fail_iput; > > > + goto fail_ino; > > > pipe = NULL; > > > > > > root->d_fsdata = ino; > > > @@ -347,8 +347,6 @@ int autofs_fill_super(struct super_block *s, void > > > *data, > > > int silent) > > > fail_dput: > > > dput(root); > > > goto fail_free; > > > -fail_iput: > > > - iput(root_inode); > > > fail_ino: > > > autofs_free_ino(ino); > > > fail_free: > > > ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: kernel BUG at fs/inode.c:LINE! 2018-12-18 12:42 ` Ian Kent @ 2018-12-18 13:19 ` Dmitry Vyukov 2018-12-18 14:40 ` Ian Kent 0 siblings, 1 reply; 33+ messages in thread From: Dmitry Vyukov @ 2018-12-18 13:19 UTC (permalink / raw) To: Ian Kent Cc: Al Viro, syzbot, Andrew Morton, linux-fsdevel, LKML, syzkaller-bugs On Tue, Dec 18, 2018 at 1:42 PM Ian Kent <raven@themaw.net> wrote: > > On Tue, 2018-12-18 at 13:27 +0100, Dmitry Vyukov wrote: > > On Tue, Dec 18, 2018 at 12:35 PM Ian Kent <raven@themaw.net> wrote: > > > > > > On Tue, 2018-12-18 at 18:42 +0800, Ian Kent wrote: > > > > On Mon, 2018-12-17 at 07:21 +0000, Al Viro wrote: > > > > > On Sun, Dec 16, 2018 at 10:11:04PM -0800, syzbot wrote: > > > > > > Hello, > > > > > > > > > > > > syzbot found the following crash on: > > > > > > > > > > > > HEAD commit: d14b746c6c1c Add linux-next specific files for > > > > > > 20181214 > > > > > > git tree: linux-next > > > > > > console output: > > > > > > https://syzkaller.appspot.com/x/log.txt?x=13706347400000 > > > > > > kernel config: > > > > > > https://syzkaller.appspot.com/x/.config?x=1da6d2d18f803140 > > > > > > dashboard link: > > > > > > https://syzkaller.appspot.com/bug?extid=5399ed0832693e29f392 > > > > > > compiler: gcc (GCC) 8.0.1 20180413 (experimental) > > > > > > syz repro: > > > > > > https://syzkaller.appspot.com/x/repro.syz?x=101032b3400000 > > > > > > C reproducer: > > > > > > https://syzkaller.appspot.com/x/repro.c?x=16534063400000 > > > > > > > > > > > > IMPORTANT: if you fix the bug, please add the following tag to the > > > > > > commit: > > > > > > Reported-by: syzbot+5399ed0832693e29f392@syzkaller.appspotmail.com > > > > > > > > > > > > slab_pre_alloc_hook mm/slab.h:423 [inline] > > > > > > slab_alloc mm/slab.c:3365 [inline] > > > > > > kmem_cache_alloc+0x2c4/0x730 mm/slab.c:3539 > > > > > > __d_alloc+0xc8/0xb90 fs/dcache.c:1599 > > > > > > ------------[ cut here ]------------ > > > > > > kernel BUG at fs/inode.c:1566! > > > > > > d_alloc_anon fs/dcache.c:1698 [inline] > > > > > > d_make_root+0x43/0xc0 fs/dcache.c:1885 > > > > > > autofs_fill_super+0x6f1/0x1c30 fs/autofs/inode.c:273 > > > > > > > > > > Huh? BUG is in iput(), AFAICS, so the stack trace is rather > > > > > misreported. > > > > > iput() can be called by d_make_root(), provided that dentry allocation > > > > > fails. So the most straightforward interpretation would be that we > > > > > had an allocation failure (injected?), followed by iput() of the inode > > > > > passed to d_make_root(). Which happened to find I_CLEAR in ->i_state > > > > > of that inode somehow, which should be impossible short of seriously > > > > > buggered inode refcounting somewhere - the inode has just been returned > > > > > by new_inode(), which clears i_state, and it would have to have passed > > > > > clear_inode() (i.e. has been through inode eviction) since then... > > > > > > > > Sorry Al, that's my bad. > > > > > > > > See > > > > > https://www.ozlabs.org/~akpm/mmotm/broken-out/autofs-fix-possible-inode-leak-in-autofs_fill_super.patch > > > > > > > > I think this will fix it, I'll forward it to Andrew if you agree: > > > > > > Actually, looking at it again the above patch is plain not needed, > > > dropping it and updating the patch which follows it in the series > > > is what needs to be done. > > > > > > Andrew, what should I do to make this easiest for you to handle, > > > a respost with v2 in the subject of the patch affected by dropping > > > the above patch? > > > > > > Or I could repost the series with above patch dropped and the affected > > > patch corrected? > > > > Hi Ian, > > > > If you going to amend any commits, please add: > > Tested-by: syzbot+5399ed0832693e29f392@syzkaller.appspotmail.com > > otherwise: > > Reported-by: syzbot+5399ed0832693e29f392@syzkaller.appspotmail.com > > I was thinking about how to handle loosing that information. > > I don't think this amounts amending commits since Andrews mmotm is > based on patch series so dropping a patch and updating patches before > being merged won't capture this. > > Adding the "Tested-by" attribution to the updated patch prior to syzbot > actually performing the test might be ok since it will get tested along > the way. Although the problem patch itself won't exist any more so ... ? I am a bit lost. There should be some patch that will fix this (new or amended). Either that patch needs to include Reporter/Tested-by tag, or we will need to tell syzbot about the fix manually with the "#syz fix:" command. > OTOH, if I repost the series I think I can send them to syzbot for testing > before forwarding to Andrew (I've done something like that before but can't > remember how now) and add the attribution to the series. > > But this all depends on what is best for Andrew and what Al would like to > see done. ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: kernel BUG at fs/inode.c:LINE! 2018-12-18 13:19 ` Dmitry Vyukov @ 2018-12-18 14:40 ` Ian Kent 0 siblings, 0 replies; 33+ messages in thread From: Ian Kent @ 2018-12-18 14:40 UTC (permalink / raw) To: Dmitry Vyukov Cc: Al Viro, syzbot, Andrew Morton, linux-fsdevel, LKML, syzkaller-bugs On Tue, 2018-12-18 at 14:19 +0100, Dmitry Vyukov wrote: > On Tue, Dec 18, 2018 at 1:42 PM Ian Kent <raven@themaw.net> wrote: > > > > On Tue, 2018-12-18 at 13:27 +0100, Dmitry Vyukov wrote: > > > On Tue, Dec 18, 2018 at 12:35 PM Ian Kent <raven@themaw.net> wrote: > > > > > > > > On Tue, 2018-12-18 at 18:42 +0800, Ian Kent wrote: > > > > > On Mon, 2018-12-17 at 07:21 +0000, Al Viro wrote: > > > > > > On Sun, Dec 16, 2018 at 10:11:04PM -0800, syzbot wrote: > > > > > > > Hello, > > > > > > > > > > > > > > syzbot found the following crash on: > > > > > > > > > > > > > > HEAD commit: d14b746c6c1c Add linux-next specific files for > > > > > > > 20181214 > > > > > > > git tree: linux-next > > > > > > > console output: > > > > > > > https://syzkaller.appspot.com/x/log.txt?x=13706347400000 > > > > > > > kernel config: > > > > > > > https://syzkaller.appspot.com/x/.config?x=1da6d2d18f803140 > > > > > > > dashboard link: > > > > > > > https://syzkaller.appspot.com/bug?extid=5399ed0832693e29f392 > > > > > > > compiler: gcc (GCC) 8.0.1 20180413 (experimental) > > > > > > > syz repro: > > > > > > > https://syzkaller.appspot.com/x/repro.syz?x=101032b3400000 > > > > > > > C reproducer: > > > > > > > https://syzkaller.appspot.com/x/repro.c?x=16534063400000 > > > > > > > > > > > > > > IMPORTANT: if you fix the bug, please add the following tag to the > > > > > > > commit: > > > > > > > Reported-by: syzbot+5399ed0832693e29f392@syzkaller.appspotmail.com > > > > > > > > > > > > > > slab_pre_alloc_hook mm/slab.h:423 [inline] > > > > > > > slab_alloc mm/slab.c:3365 [inline] > > > > > > > kmem_cache_alloc+0x2c4/0x730 mm/slab.c:3539 > > > > > > > __d_alloc+0xc8/0xb90 fs/dcache.c:1599 > > > > > > > ------------[ cut here ]------------ > > > > > > > kernel BUG at fs/inode.c:1566! > > > > > > > d_alloc_anon fs/dcache.c:1698 [inline] > > > > > > > d_make_root+0x43/0xc0 fs/dcache.c:1885 > > > > > > > autofs_fill_super+0x6f1/0x1c30 fs/autofs/inode.c:273 > > > > > > > > > > > > Huh? BUG is in iput(), AFAICS, so the stack trace is rather > > > > > > misreported. > > > > > > iput() can be called by d_make_root(), provided that dentry > > > > > > allocation > > > > > > fails. So the most straightforward interpretation would be that we > > > > > > had an allocation failure (injected?), followed by iput() of the > > > > > > inode > > > > > > passed to d_make_root(). Which happened to find I_CLEAR in > > > > > > ->i_state > > > > > > of that inode somehow, which should be impossible short of seriously > > > > > > buggered inode refcounting somewhere - the inode has just been > > > > > > returned > > > > > > by new_inode(), which clears i_state, and it would have to have > > > > > > passed > > > > > > clear_inode() (i.e. has been through inode eviction) since then... > > > > > > > > > > Sorry Al, that's my bad. > > > > > > > > > > See > > > > > > > > > https://www.ozlabs.org/~akpm/mmotm/broken-out/autofs-fix-possible-inode-leak-in-autofs_fill_super.patch > > > > > > > > > > I think this will fix it, I'll forward it to Andrew if you agree: > > > > > > > > Actually, looking at it again the above patch is plain not needed, > > > > dropping it and updating the patch which follows it in the series > > > > is what needs to be done. > > > > > > > > Andrew, what should I do to make this easiest for you to handle, > > > > a respost with v2 in the subject of the patch affected by dropping > > > > the above patch? > > > > > > > > Or I could repost the series with above patch dropped and the affected > > > > patch corrected? > > > > > > Hi Ian, > > > > > > If you going to amend any commits, please add: > > > Tested-by: syzbot+5399ed0832693e29f392@syzkaller.appspotmail.com > > > otherwise: > > > Reported-by: syzbot+5399ed0832693e29f392@syzkaller.appspotmail.com > > > > I was thinking about how to handle loosing that information. > > > > I don't think this amounts amending commits since Andrews mmotm is > > based on patch series so dropping a patch and updating patches before > > being merged won't capture this. > > > > Adding the "Tested-by" attribution to the updated patch prior to syzbot > > actually performing the test might be ok since it will get tested along > > the way. Although the problem patch itself won't exist any more so ... ? > > I am a bit lost. > There should be some patch that will fix this (new or amended). Either > that patch needs to include Reporter/Tested-by tag, or we will need to > tell syzbot about the fix manually with the "#syz fix:" command. One of the patches that I forwarded to Andrew was plain wrong, it isn't actually needed so it needs to be dropped altogether (this one caused the breakage). Doing so then requires a minor (unrelated) change to the next of my patches in the series I sent. Andrew forwards certain patches in his patch queue to to the linux-next tree. I'm not sure if that is done via a cumulative pull request or via actual patches. Whether dropping a patch from Andrews mmotm tree when forwarding his patch queue to linux-next requires a revert patch rather than just omitting the dropped patch (which would carry the annotation) or not I don't know, we'll have to wait and see what Andrew would like me to do. > > > OTOH, if I repost the series I think I can send them to syzbot for testing > > before forwarding to Andrew (I've done something like that before but can't > > remember how now) and add the attribution to the series. > > > > But this all depends on what is best for Andrew and what Al would like to > > see done. ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: kernel BUG at fs/inode.c:LINE! 2018-12-18 11:34 ` Ian Kent 2018-12-18 12:27 ` Dmitry Vyukov @ 2018-12-18 21:09 ` Andrew Morton 2018-12-19 0:05 ` Ian Kent 1 sibling, 1 reply; 33+ messages in thread From: Andrew Morton @ 2018-12-18 21:09 UTC (permalink / raw) To: Ian Kent Cc: Al Viro, syzbot, DmitryVyukov, linux-fsdevel, linux-kernel, syzkaller-bugs On Tue, 18 Dec 2018 19:34:57 +0800 Ian Kent <raven@themaw.net> wrote: > > See > > https://www.ozlabs.org/~akpm/mmotm/broken-out/autofs-fix-possible-inode-leak-in-autofs_fill_super.patch > > > > I think this will fix it, I'll forward it to Andrew if you agree: > > Actually, looking at it again the above patch is plain not needed, > dropping it and updating the patch which follows it in the series > is what needs to be done. > > Andrew, what should I do to make this easiest for you to handle, > a respost with v2 in the subject of the patch affected by dropping > the above patch? I dropped the patch and fixed up the fallout. The patch wasn't true anyway. "There is no check at all for a failure to allocate the root inode in autofs_fill_super(), handle it." In fact, d_make_root(NULL) will just return NULL and autofs_fill_super() handles that appropriately. However let's note that when autofs_get_inode() or d_make_root() fail, autofs_fill_super() will return -EINVAL. Should have been -ENOMEM, I guess? ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: kernel BUG at fs/inode.c:LINE! 2018-12-18 21:09 ` Andrew Morton @ 2018-12-19 0:05 ` Ian Kent 0 siblings, 0 replies; 33+ messages in thread From: Ian Kent @ 2018-12-19 0:05 UTC (permalink / raw) To: Andrew Morton Cc: Al Viro, syzbot, DmitryVyukov, linux-fsdevel, linux-kernel, syzkaller-bugs On Tue, 2018-12-18 at 13:09 -0800, Andrew Morton wrote: > On Tue, 18 Dec 2018 19:34:57 +0800 Ian Kent <raven@themaw.net> wrote: > > > > See > > > https://www.ozlabs.org/~akpm/mmotm/broken-out/autofs-fix-possible-inode-leak-in-autofs_fill_super.patch > > > > > > I think this will fix it, I'll forward it to Andrew if you agree: > > > > Actually, looking at it again the above patch is plain not needed, > > dropping it and updating the patch which follows it in the series > > is what needs to be done. > > > > Andrew, what should I do to make this easiest for you to handle, > > a respost with v2 in the subject of the patch affected by dropping > > the above patch? > > I dropped the patch and fixed up the fallout. Thanks Andrew, much appreciated. > > The patch wasn't true anyway. "There is no check at all for a failure > to allocate the root inode in autofs_fill_super(), handle it." In fact, > d_make_root(NULL) will just return NULL and autofs_fill_super() handles > that appropriately. The not so funny thing is that I'm sure I looked at this some time in the distant past and saw how d_make_root() behaved. The lesson for me is don't try and fix other things seen while working on something else, return later and do it properly. > > However let's note that when autofs_get_inode() or d_make_root() fail, > autofs_fill_super() will return -EINVAL. Should have been -ENOMEM, I > guess? > That's right, but I don't think that's urgent so I'll send a patch for it after the coming merge window. The strictexpire option addition is urgent for me so I don't want to upset any chance of that being merged sooner rather than later. Ian ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: kernel BUG at fs/inode.c:LINE! 2018-12-18 10:42 ` Ian Kent 2018-12-18 11:01 ` Amir Goldstein 2018-12-18 11:34 ` Ian Kent @ 2018-12-18 13:51 ` Al Viro 2 siblings, 0 replies; 33+ messages in thread From: Al Viro @ 2018-12-18 13:51 UTC (permalink / raw) To: Ian Kent Cc: syzbot, Andrew Morton, DmitryVyukov, linux-fsdevel, linux-kernel, syzkaller-bugs On Tue, Dec 18, 2018 at 06:42:35PM +0800, Ian Kent wrote: > Sorry Al, that's my bad. > > See https://www.ozlabs.org/~akpm/mmotm/broken-out/autofs-fix-possible-inode-leak-in-autofs_fill_super.patch > > I think this will fix it, I'll forward it to Andrew if you agree: Just drop it and be done with that. d_make_root(NULL) returns NULL, no need to check that in the caller. There is no leak in the mainline; the calling conventions for d_make_root() are chosen that way just for that reason - to minimize the amount of cleanups needed. ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: kernel BUG at fs/inode.c:LINE! 2018-12-17 6:11 kernel BUG at fs/inode.c:LINE! syzbot 2018-12-17 7:21 ` Al Viro @ 2019-04-09 14:36 ` syzbot 2019-04-10 0:26 ` Al Viro 1 sibling, 1 reply; 33+ messages in thread From: syzbot @ 2019-04-09 14:36 UTC (permalink / raw) To: akpm, amir73il, dvyukov, linux-fsdevel, linux-kernel, penguin-kernel, raven, syzkaller-bugs, viro Bisection is inconclusive: the first bad commit could be any of: cd4f2a66 lib/genalloc.c: fix allocation of aligned buffer from non-aligned chunk df3f18d3 fls: change parameter to unsigned int 9067c8d5 lib/find_bit_benchmark.c: align test_find_next_and_bit with others c2824829 include/linux/printk.h: drop silly "static inline asmlinkage" from dump_stack() 26e88a47 checkpatch: warn on const char foo[] = "bar"; declarations e98eceb8 drivers/dma-buf/udmabuf.c: convert to use vm_fault_t 5b6bf71d build_bug.h: remove most of dummy BUILD_BUG_ON stubs for Sparse f34c9474 fs/epoll: remove max_nests argument from ep_call_nested() 56f6c16e build_bug.h: remove negative-array fallback for BUILD_BUG_ON() cd2f11e6 fs/epoll: simplify ep_send_events_proc() ready-list loop 74a37b90 Documentation/process/coding-style.rst: don't use "extern" with function prototypes ab1909a8 fs/epoll: drop ovflist branch prediction 499aeb57 proc/sysctl: fix return error for proc_doulongvec_minmax() b7fa8017 fs/epoll: robustify ep->mtx held checks d877fd09 fs/proc/base.c: slightly faster /proc/*/limits f2c37862 fs/epoll: reduce the scope of wq lock in epoll_wait() 860705c8 fs-epoll-reduce-the-scope-of-wq-lock-in-epoll_wait-fix c62975fb fs/proc/inode.c: delete unnecessary variable in proc_alloc_inode() 9460069d fs/proc/util.c: include fs/proc/internal.h for name_to_int() ea5f967a fs/epoll: avoid barrier after an epoll_wait(2) timeout b61909d2 fs-epoll-avoid-barrier-after-an-epoll_wait2-timeout-fix c768eca0 fs/proc/base.c: use ns_capable instead of capable for timerslack_ns 81553cde fs/epoll: rename check_events label to send_events b6af7800 fs/buffer.c: add debug print for __getblk_gfp() stall problem 11193e16 mm/page_owner: align with pageblock_nr pages 349afd96 fs/epoll: deal with wait_queue only once 393af37c fs-epoll-deal-with-wait_queue-only-once-fix c20187bf mm/page_owner: align with pageblock_nr_pages 20fbef31 mm: don't expose page to fast gup before it's ready ad4f37b8 init/main.c: make "initcall_level_names[]" const char * 0bcbe611 autofs: improve ioctl sbi checks 69ab6b14 mm: fix race between swapoff and mincore b783d261 autofs-improve-ioctl-sbi-checks-fix de44564f mm, swap: fix race between swapoff and some swap operations 010a80ff mm, swap: fix race between swapoff and some swap operations 9c82e3b8 autofs: fix possible inode leak in autofs_fill_super() 855b7de1 mm/page_alloc.c: remove software prefetching in __free_pages_core() cd4d5fa9 autofs: simplify parse_options() function call e8fed666 memory_hotplug-free-pages-as-higher-order-fix-fix f7aa1250 autofs: change catatonic setting to a bit flag 578f6458 autofs: add strictexpire mount option 71e7f022 memory_hotplug-free-pages-as-higher-order-fix 8286148b mm/page_alloc.c: memory hotplug: free pages as higher order e5d8e894 hfsplus: return file attributes on statx 728804fa include/uapi/linux/msdos_fs.h: use MSDOS_NAME for volume label size e93a0c0d include/linux/memory_hotplug.h: remove duplicate declaration of offline_pages() 3d991a59 ptrace: take into account saved_sigmask in PTRACE_{GET,SET}SIGMASK a7b16608 mm/mmu_notifier: contextual information for event triggering invalidation v2 302092c9 mm-mmu_notifier-use-structure-for-invalidate_range_start-end-calls-v2-checkpatch-fixes cdd7a0aa fork: fix some -Wmissing-prototypes warnings 137d92bd mm/mmu_notifier: use structure for invalidate_range_start/end calls v2 b89cf731 exec: load_script: don't blindly truncate shebang string 42905641 mm-mmu_notifier-use-structure-for-invalidate_range_start-end-callback-fix-fix ad2539c7 exec: increase BINPRM_BUF_SIZE to 256 0db734c6 mm/mmu_notifier: use structure for invalidate_range_start/end callback c09b6daf exec: separate MM_ANONPAGES and RLIMIT_STACK accounting 37ba86cc hwpoison, memory_hotplug: allow hwpoisoned pages to be offlined dc98b124 exec-separate-mm_anonpages-and-rlimit_stack-accounting-fix 28286054 exec-separate-mm_anonpages-and-rlimit_stack-accounting-checkpatch-fixes b08acb20 mm-kmemleak-little-optimization-while-scanning-fix 27faeb70 bfs: extra sanity checking and static inode bitmap 79d0fd91 mm, kmemleak: little optimization while scanning 232619fc lib/ioremap: ensure break-before-make is used for huge p4d mappings 7a489f5d panic: add options to print system info when panic happens 784bedb5 kernel/sysctl: add panic_print into sysctl e5dfd59e lib/ioremap: ensure phys_addr actually corresponds to a physical address 5f8d4992 kernel/kcov.c: mark write_comp_data() as notrace 7bdcb055 x86/pgtable: drop pXd_none() checks from pXd_free_pYd_table() 0aa19fc1 arm64: mmu: drop pXd_present() checks from pXd_free_pYd_table() 7ab8b68a scripts/gdb: fix lx-version string output b2581b70 initramfs: cleanup incomplete rootfs ee095458 ioremap: rework pXd_free_pYd_page() API ce10bcf4 mm/page_alloc.c: calculate first_deferred_pfn directly efae8091 ipc: allow boot time extension of IPCMNI from 32k to 8M ab7db927 ipc-allow-boot-time-extension-of-ipcmni-from-32k-to-8m-checkpatch-fixes f163b82f mm/filemap.c: remove useless check in pagecache_get_page() 399e0a80 mm/page_io.c: fix polled swap page in d04978ca ipc: conserve sequence numbers in extended IPCMNI mode 07365469 Merge branch 'akpm-current/current' bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=15e1fc2b200000 start commit: [unknown git tree: linux-next dashboard link: https://syzkaller.appspot.com/bug?extid=5399ed0832693e29f392 syz repro: https://syzkaller.appspot.com/x/repro.syz?x=101032b3400000 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=16534063400000 For information about bisection process see: https://goo.gl/tpsmEJ#bisection ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: kernel BUG at fs/inode.c:LINE! 2019-04-09 14:36 ` syzbot @ 2019-04-10 0:26 ` Al Viro 2019-04-10 8:27 ` Dmitry Vyukov 0 siblings, 1 reply; 33+ messages in thread From: Al Viro @ 2019-04-10 0:26 UTC (permalink / raw) To: syzbot Cc: akpm, amir73il, dvyukov, linux-fsdevel, linux-kernel, penguin-kernel, raven, syzkaller-bugs On Tue, Apr 09, 2019 at 07:36:00AM -0700, syzbot wrote: > Bisection is inconclusive: the first bad commit could be any of: [snip the useless pile] > bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=15e1fc2b200000 > start commit: [unknown > git tree: linux-next > dashboard link: https://syzkaller.appspot.com/bug?extid=5399ed0832693e29f392 > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=101032b3400000 > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=16534063400000 > > For information about bisection process see: https://goo.gl/tpsmEJ#bisection If I'm not misreading the "crash report" there, it has injected an allocation failure in dentry allocation in d_make_root() from autofs_fill_super() ( root_inode = autofs_get_inode(s, S_IFDIR | 0755); root = d_make_root(root_inode); ) which has triggered iput() on the inode passed to d_make_root() (as it ought to). At which point it stepped into some BUG_ON() in fs/inode.c, but I've no idea which one it is - line numbers do not match anything in linux-next or in mainline. Reported line 1566 is if (inode->i_nlink && (inode->i_state & I_DIRTY_TIME)) { in all of them; as the matter of fact, the diff in fs/inode.c between -next and mainline is empty. There is a BUG_ON() several lines prior, and in 4.20 it used to be line 1566, so _probably_ that's what it is. With that assumption, it's BUG_ON(inode->i_state & I_CLEAR); IOW, we'd got I_CLEAR in the inode passed to d_make_root() there. Which should not happen - the inode must have come from new_inode(), which gets it from new_inode_pseudo(), which zeroes ->i_state. And I_CLEAR is set only in clear_inode(). For autofs inodes that can come only from autofs_evict_inode(), called as ->evict() from evict_inode(). Which should never ever be called for inode with positive ->i_count... It might be memory corruption; it might be a dangling inode pointer somewhere, it might be something else. To get any further we really need a confirmation of the identity of triggered BUG_ON(). As an aside, your "sample crash reports" would've been much more useful if they went with commit SHA1 in question, especially when they contain line numbers. ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: kernel BUG at fs/inode.c:LINE! 2019-04-10 0:26 ` Al Viro @ 2019-04-10 8:27 ` Dmitry Vyukov 2019-04-10 10:35 ` Ian Kent 0 siblings, 1 reply; 33+ messages in thread From: Dmitry Vyukov @ 2019-04-10 8:27 UTC (permalink / raw) To: Al Viro Cc: syzbot, Andrew Morton, Amir Goldstein, linux-fsdevel, LKML, Tetsuo Handa, Ian Kent, syzkaller-bugs On Wed, Apr 10, 2019 at 2:26 AM Al Viro <viro@zeniv.linux.org.uk> wrote: > > On Tue, Apr 09, 2019 at 07:36:00AM -0700, syzbot wrote: > > Bisection is inconclusive: the first bad commit could be any of: > > [snip the useless pile] > > > bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=15e1fc2b200000 > > start commit: [unknown > > git tree: linux-next > > dashboard link: https://syzkaller.appspot.com/bug?extid=5399ed0832693e29f392 > > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=101032b3400000 > > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=16534063400000 > > > > For information about bisection process see: https://goo.gl/tpsmEJ#bisection > > If I'm not misreading the "crash report" there, it has injected an allocation > failure in dentry allocation in d_make_root() from autofs_fill_super() ( > root_inode = autofs_get_inode(s, S_IFDIR | 0755); > root = d_make_root(root_inode); > ) which has triggered iput() on the inode passed to d_make_root() (as it ought > to). At which point it stepped into some BUG_ON() in fs/inode.c, but I've > no idea which one it is - line numbers do not match anything in linux-next > or in mainline. Reported line 1566 is > if (inode->i_nlink && (inode->i_state & I_DIRTY_TIME)) { > in all of them; as the matter of fact, the diff in fs/inode.c between > -next and mainline is empty. > > There is a BUG_ON() several lines prior, and in 4.20 it used to be line 1566, > so _probably_ that's what it is. With that assumption, it's > BUG_ON(inode->i_state & I_CLEAR); > IOW, we'd got I_CLEAR in the inode passed to d_make_root() there. Which > should not happen - the inode must have come from new_inode(), which > gets it from new_inode_pseudo(), which zeroes ->i_state. And I_CLEAR > is set only in clear_inode(). For autofs inodes that can come only > from autofs_evict_inode(), called as ->evict() from evict_inode(). > Which should never ever be called for inode with positive ->i_count... > > It might be memory corruption; it might be a dangling inode pointer > somewhere, it might be something else. > > To get any further we really need a confirmation of the identity of > triggered BUG_ON(). > > As an aside, your "sample crash reports" would've been much more useful if > they went with commit SHA1 in question, especially when they contain line > numbers. Hi Al, This is the commit for matching lines: > HEAD commit: d14b746c6c1c Add linux-next specific files for 20181214 > git tree: linux-next fs/inode.c:1566 points to: void iput(struct inode *inode) { ... BUG_ON(inode->i_state & I_CLEAR); The dashboard page provides kernel git repository and commit for each crash. ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: kernel BUG at fs/inode.c:LINE! 2019-04-10 8:27 ` Dmitry Vyukov @ 2019-04-10 10:35 ` Ian Kent 2019-04-10 11:40 ` Dmitry Vyukov 0 siblings, 1 reply; 33+ messages in thread From: Ian Kent @ 2019-04-10 10:35 UTC (permalink / raw) To: Dmitry Vyukov, Al Viro Cc: syzbot, Andrew Morton, Amir Goldstein, linux-fsdevel, LKML, Tetsuo Handa, syzkaller-bugs On Wed, 2019-04-10 at 10:27 +0200, Dmitry Vyukov wrote: > On Wed, Apr 10, 2019 at 2:26 AM Al Viro <viro@zeniv.linux.org.uk> wrote: > > > > On Tue, Apr 09, 2019 at 07:36:00AM -0700, syzbot wrote: > > > Bisection is inconclusive: the first bad commit could be any of: > > > > [snip the useless pile] > > > > > bisection log: > > > https://syzkaller.appspot.com/x/bisect.txt?x=15e1fc2b200000 > > > start commit: [unknown > > > git tree: linux-next > > > dashboard link: > > > https://syzkaller.appspot.com/bug?extid=5399ed0832693e29f392 > > > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=101032b3400000 > > > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=16534063400000 > > > > > > For information about bisection process see: > > > https://goo.gl/tpsmEJ#bisection > > > > If I'm not misreading the "crash report" there, it has injected an > > allocation > > failure in dentry allocation in d_make_root() from autofs_fill_super() ( > > root_inode = autofs_get_inode(s, S_IFDIR | 0755); > > root = d_make_root(root_inode); > > ) which has triggered iput() on the inode passed to d_make_root() (as it > > ought > > to). At which point it stepped into some BUG_ON() in fs/inode.c, but I've > > no idea which one it is - line numbers do not match anything in linux-next > > or in mainline. Reported line 1566 is > > if (inode->i_nlink && (inode->i_state & I_DIRTY_TIME)) { > > in all of them; as the matter of fact, the diff in fs/inode.c between > > -next and mainline is empty. > > > > There is a BUG_ON() several lines prior, and in 4.20 it used to be line > > 1566, > > so _probably_ that's what it is. With that assumption, it's > > BUG_ON(inode->i_state & I_CLEAR); > > IOW, we'd got I_CLEAR in the inode passed to d_make_root() there. Which > > should not happen - the inode must have come from new_inode(), which > > gets it from new_inode_pseudo(), which zeroes ->i_state. And I_CLEAR > > is set only in clear_inode(). For autofs inodes that can come only > > from autofs_evict_inode(), called as ->evict() from evict_inode(). > > Which should never ever be called for inode with positive ->i_count... > > > > It might be memory corruption; it might be a dangling inode pointer > > somewhere, it might be something else. > > > > To get any further we really need a confirmation of the identity of > > triggered BUG_ON(). > > > > As an aside, your "sample crash reports" would've been much more useful if > > they went with commit SHA1 in question, especially when they contain line > > numbers. > > Hi Al, > > This is the commit for matching lines: > > > HEAD commit: d14b746c6c1c Add linux-next specific files for 20181214 Are you sure? what does 20181214 mean? Looking at current next code (and several branches) it doesn't appear the problem is possible? > > git tree: linux-next But which branch is it really, master (which doesn't match the line numbers btw)? > > fs/inode.c:1566 points to: > > void iput(struct inode *inode) > { > ... > BUG_ON(inode->i_state & I_CLEAR); > > > The dashboard page provides kernel git repository and commit for each crash. Those links don't seem to make sense to me ... Help me out here! Ian ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: kernel BUG at fs/inode.c:LINE! 2019-04-10 10:35 ` Ian Kent @ 2019-04-10 11:40 ` Dmitry Vyukov 2019-04-10 11:57 ` Ian Kent 0 siblings, 1 reply; 33+ messages in thread From: Dmitry Vyukov @ 2019-04-10 11:40 UTC (permalink / raw) To: Ian Kent Cc: Al Viro, syzbot, Andrew Morton, Amir Goldstein, linux-fsdevel, LKML, Tetsuo Handa, syzkaller-bugs On Wed, Apr 10, 2019 at 12:35 PM Ian Kent <raven@themaw.net> wrote: > > On Wed, 2019-04-10 at 10:27 +0200, Dmitry Vyukov wrote: > > On Wed, Apr 10, 2019 at 2:26 AM Al Viro <viro@zeniv.linux.org.uk> wrote: > > > > > > On Tue, Apr 09, 2019 at 07:36:00AM -0700, syzbot wrote: > > > > Bisection is inconclusive: the first bad commit could be any of: > > > > > > [snip the useless pile] > > > > > > > bisection log: > > > > https://syzkaller.appspot.com/x/bisect.txt?x=15e1fc2b200000 > > > > start commit: [unknown > > > > git tree: linux-next > > > > dashboard link: > > > > https://syzkaller.appspot.com/bug?extid=5399ed0832693e29f392 > > > > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=101032b3400000 > > > > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=16534063400000 > > > > > > > > For information about bisection process see: > > > > https://goo.gl/tpsmEJ#bisection > > > > > > If I'm not misreading the "crash report" there, it has injected an > > > allocation > > > failure in dentry allocation in d_make_root() from autofs_fill_super() ( > > > root_inode = autofs_get_inode(s, S_IFDIR | 0755); > > > root = d_make_root(root_inode); > > > ) which has triggered iput() on the inode passed to d_make_root() (as it > > > ought > > > to). At which point it stepped into some BUG_ON() in fs/inode.c, but I've > > > no idea which one it is - line numbers do not match anything in linux-next > > > or in mainline. Reported line 1566 is > > > if (inode->i_nlink && (inode->i_state & I_DIRTY_TIME)) { > > > in all of them; as the matter of fact, the diff in fs/inode.c between > > > -next and mainline is empty. > > > > > > There is a BUG_ON() several lines prior, and in 4.20 it used to be line > > > 1566, > > > so _probably_ that's what it is. With that assumption, it's > > > BUG_ON(inode->i_state & I_CLEAR); > > > IOW, we'd got I_CLEAR in the inode passed to d_make_root() there. Which > > > should not happen - the inode must have come from new_inode(), which > > > gets it from new_inode_pseudo(), which zeroes ->i_state. And I_CLEAR > > > is set only in clear_inode(). For autofs inodes that can come only > > > from autofs_evict_inode(), called as ->evict() from evict_inode(). > > > Which should never ever be called for inode with positive ->i_count... > > > > > > It might be memory corruption; it might be a dangling inode pointer > > > somewhere, it might be something else. > > > > > > To get any further we really need a confirmation of the identity of > > > triggered BUG_ON(). > > > > > > As an aside, your "sample crash reports" would've been much more useful if > > > they went with commit SHA1 in question, especially when they contain line > > > numbers. > > > > Hi Al, > > > > This is the commit for matching lines: > > > > > HEAD commit: d14b746c6c1c Add linux-next specific files for 20181214 > > Are you sure? > what does 20181214 mean? Yes, I just copy-pasted from the report. "d14b746c6c1c" is the commit hash. "Add linux-next specific files for 20181214" is the commit subject. > Looking at current next code (and several branches) it doesn't > appear the problem is possible? > > > > git tree: linux-next > > But which branch is it really, master (which doesn't match the > line numbers btw)? This is d14b746c6c1c commit hash. I don't know if there is a branch with HEAD pointing to this commit or not, but it seems unimportant. Tree+commit is the identity of code state. > > fs/inode.c:1566 points to: > > > > void iput(struct inode *inode) > > { > > ... > > BUG_ON(inode->i_state & I_CLEAR); > > > > > > The dashboard page provides kernel git repository and commit for each crash. > > Those links don't seem to make sense to me ... > > Help me out here! There is git repo name provided and commit hash. It's meant to be self-explanatory. What exactly is unclear? ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: kernel BUG at fs/inode.c:LINE! 2019-04-10 11:40 ` Dmitry Vyukov @ 2019-04-10 11:57 ` Ian Kent 2019-04-10 12:02 ` Dmitry Vyukov 2019-04-10 12:07 ` Ian Kent 0 siblings, 2 replies; 33+ messages in thread From: Ian Kent @ 2019-04-10 11:57 UTC (permalink / raw) To: Dmitry Vyukov Cc: Al Viro, syzbot, Andrew Morton, Amir Goldstein, linux-fsdevel, LKML, Tetsuo Handa, syzkaller-bugs On Wed, 2019-04-10 at 13:40 +0200, Dmitry Vyukov wrote: > On Wed, Apr 10, 2019 at 12:35 PM Ian Kent <raven@themaw.net> wrote: > > > > On Wed, 2019-04-10 at 10:27 +0200, Dmitry Vyukov wrote: > > > On Wed, Apr 10, 2019 at 2:26 AM Al Viro <viro@zeniv.linux.org.uk> wrote: > > > > > > > > On Tue, Apr 09, 2019 at 07:36:00AM -0700, syzbot wrote: > > > > > Bisection is inconclusive: the first bad commit could be any of: > > > > > > > > [snip the useless pile] > > > > > > > > > bisection log: > > > > > https://syzkaller.appspot.com/x/bisect.txt?x=15e1fc2b200000 > > > > > start commit: [unknown > > > > > git tree: linux-next > > > > > dashboard link: > > > > > https://syzkaller.appspot.com/bug?extid=5399ed0832693e29f392 > > > > > syz repro: > > > > > https://syzkaller.appspot.com/x/repro.syz?x=101032b3400000 > > > > > C reproducer: > > > > > https://syzkaller.appspot.com/x/repro.c?x=16534063400000 > > > > > > > > > > For information about bisection process see: > > > > > https://goo.gl/tpsmEJ#bisection > > > > > > > > If I'm not misreading the "crash report" there, it has injected an > > > > allocation > > > > failure in dentry allocation in d_make_root() from autofs_fill_super() ( > > > > root_inode = autofs_get_inode(s, S_IFDIR | 0755); > > > > root = d_make_root(root_inode); > > > > ) which has triggered iput() on the inode passed to d_make_root() (as it > > > > ought > > > > to). At which point it stepped into some BUG_ON() in fs/inode.c, but > > > > I've > > > > no idea which one it is - line numbers do not match anything in linux- > > > > next > > > > or in mainline. Reported line 1566 is > > > > if (inode->i_nlink && (inode->i_state & I_DIRTY_TIME)) { > > > > in all of them; as the matter of fact, the diff in fs/inode.c between > > > > -next and mainline is empty. > > > > > > > > There is a BUG_ON() several lines prior, and in 4.20 it used to be line > > > > 1566, > > > > so _probably_ that's what it is. With that assumption, it's > > > > BUG_ON(inode->i_state & I_CLEAR); > > > > IOW, we'd got I_CLEAR in the inode passed to d_make_root() there. Which > > > > should not happen - the inode must have come from new_inode(), which > > > > gets it from new_inode_pseudo(), which zeroes ->i_state. And I_CLEAR > > > > is set only in clear_inode(). For autofs inodes that can come only > > > > from autofs_evict_inode(), called as ->evict() from evict_inode(). > > > > Which should never ever be called for inode with positive ->i_count... > > > > > > > > It might be memory corruption; it might be a dangling inode pointer > > > > somewhere, it might be something else. > > > > > > > > To get any further we really need a confirmation of the identity of > > > > triggered BUG_ON(). > > > > > > > > As an aside, your "sample crash reports" would've been much more useful > > > > if > > > > they went with commit SHA1 in question, especially when they contain > > > > line > > > > numbers. > > > > > > Hi Al, > > > > > > This is the commit for matching lines: > > > > > > > HEAD commit: d14b746c6c1c Add linux-next specific files for 20181214 > > > > Are you sure? > > what does 20181214 mean? > > Yes, I just copy-pasted from the report. "d14b746c6c1c" is the commit > hash. "Add linux-next specific files for 20181214" is the commit > subject. > > > > Looking at current next code (and several branches) it doesn't > > appear the problem is possible? > > > > > > git tree: linux-next > > > > But which branch is it really, master (which doesn't match the > > line numbers btw)? > > This is d14b746c6c1c commit hash. I don't know if there is a branch > with HEAD pointing to this commit or not, but it seems unimportant. > Tree+commit is the identity of code state. > > > > > fs/inode.c:1566 points to: > > > > > > void iput(struct inode *inode) > > > { > > > ... > > > BUG_ON(inode->i_state & I_CLEAR); > > > > > > > > > The dashboard page provides kernel git repository and commit for each > > > crash. > > > > Those links don't seem to make sense to me ... > > > > Help me out here! > > There is git repo name provided and commit hash. It's meant to be > self-explanatory. What exactly is unclear? I'm unable to find a branch matching the line numbers. Given that, on the face of it, the scenario is impossible I'm seeking clarification on what linux-next to look at for the sake of accuracy. So I'm wondering if this testing done using the master branch or one of the daily branches one would use to check for conflicts before posting? Or perhaps the master branch has been updated and the testing was done on something different. Ian ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: kernel BUG at fs/inode.c:LINE! 2019-04-10 11:57 ` Ian Kent @ 2019-04-10 12:02 ` Dmitry Vyukov 2019-04-10 12:03 ` Dmitry Vyukov 2019-04-10 12:07 ` Ian Kent 1 sibling, 1 reply; 33+ messages in thread From: Dmitry Vyukov @ 2019-04-10 12:02 UTC (permalink / raw) To: Ian Kent Cc: Al Viro, syzbot, Andrew Morton, Amir Goldstein, linux-fsdevel, LKML, Tetsuo Handa, syzkaller-bugs On Wed, Apr 10, 2019 at 1:57 PM Ian Kent <raven@themaw.net> wrote: > > > > > On Tue, Apr 09, 2019 at 07:36:00AM -0700, syzbot wrote: > > > > > > Bisection is inconclusive: the first bad commit could be any of: > > > > > > > > > > [snip the useless pile] > > > > > > > > > > > bisection log: > > > > > > https://syzkaller.appspot.com/x/bisect.txt?x=15e1fc2b200000 > > > > > > start commit: [unknown > > > > > > git tree: linux-next > > > > > > dashboard link: > > > > > > https://syzkaller.appspot.com/bug?extid=5399ed0832693e29f392 > > > > > > syz repro: > > > > > > https://syzkaller.appspot.com/x/repro.syz?x=101032b3400000 > > > > > > C reproducer: > > > > > > https://syzkaller.appspot.com/x/repro.c?x=16534063400000 > > > > > > > > > > > > For information about bisection process see: > > > > > > https://goo.gl/tpsmEJ#bisection > > > > > > > > > > If I'm not misreading the "crash report" there, it has injected an > > > > > allocation > > > > > failure in dentry allocation in d_make_root() from autofs_fill_super() ( > > > > > root_inode = autofs_get_inode(s, S_IFDIR | 0755); > > > > > root = d_make_root(root_inode); > > > > > ) which has triggered iput() on the inode passed to d_make_root() (as it > > > > > ought > > > > > to). At which point it stepped into some BUG_ON() in fs/inode.c, but > > > > > I've > > > > > no idea which one it is - line numbers do not match anything in linux- > > > > > next > > > > > or in mainline. Reported line 1566 is > > > > > if (inode->i_nlink && (inode->i_state & I_DIRTY_TIME)) { > > > > > in all of them; as the matter of fact, the diff in fs/inode.c between > > > > > -next and mainline is empty. > > > > > > > > > > There is a BUG_ON() several lines prior, and in 4.20 it used to be line > > > > > 1566, > > > > > so _probably_ that's what it is. With that assumption, it's > > > > > BUG_ON(inode->i_state & I_CLEAR); > > > > > IOW, we'd got I_CLEAR in the inode passed to d_make_root() there. Which > > > > > should not happen - the inode must have come from new_inode(), which > > > > > gets it from new_inode_pseudo(), which zeroes ->i_state. And I_CLEAR > > > > > is set only in clear_inode(). For autofs inodes that can come only > > > > > from autofs_evict_inode(), called as ->evict() from evict_inode(). > > > > > Which should never ever be called for inode with positive ->i_count... > > > > > > > > > > It might be memory corruption; it might be a dangling inode pointer > > > > > somewhere, it might be something else. > > > > > > > > > > To get any further we really need a confirmation of the identity of > > > > > triggered BUG_ON(). > > > > > > > > > > As an aside, your "sample crash reports" would've been much more useful > > > > > if > > > > > they went with commit SHA1 in question, especially when they contain > > > > > line > > > > > numbers. > > > > > > > > Hi Al, > > > > > > > > This is the commit for matching lines: > > > > > > > > > HEAD commit: d14b746c6c1c Add linux-next specific files for 20181214 > > > > > > Are you sure? > > > what does 20181214 mean? > > > > Yes, I just copy-pasted from the report. "d14b746c6c1c" is the commit > > hash. "Add linux-next specific files for 20181214" is the commit > > subject. > > > > > > > Looking at current next code (and several branches) it doesn't > > > appear the problem is possible? > > > > > > > > git tree: linux-next > > > > > > But which branch is it really, master (which doesn't match the > > > line numbers btw)? > > > > This is d14b746c6c1c commit hash. I don't know if there is a branch > > with HEAD pointing to this commit or not, but it seems unimportant. > > Tree+commit is the identity of code state. > > > > > > > > fs/inode.c:1566 points to: > > > > > > > > void iput(struct inode *inode) > > > > { > > > > ... > > > > BUG_ON(inode->i_state & I_CLEAR); > > > > > > > > > > > > The dashboard page provides kernel git repository and commit for each > > > > crash. > > > > > > Those links don't seem to make sense to me ... > > > > > > Help me out here! > > > > There is git repo name provided and commit hash. It's meant to be > > self-explanatory. What exactly is unclear? > > I'm unable to find a branch matching the line numbers. > > Given that, on the face of it, the scenario is impossible I'm > seeking clarification on what linux-next to look at for the > sake of accuracy. > > So I'm wondering if this testing done using the master branch > or one of the daily branches one would use to check for conflicts > before posting? > > Or perhaps the master branch has been updated and the testing was > done on something different. Ah, I see. syzbot continuously tests the master branch of linux-next. So d14b746c6c1c was once the HEAD of the master branch. I somehow have d14b746c6c1c locally, but if you don't have it you may need to fetch git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next-history.git with tags. That's linux-next specifics. ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: kernel BUG at fs/inode.c:LINE! 2019-04-10 12:02 ` Dmitry Vyukov @ 2019-04-10 12:03 ` Dmitry Vyukov 0 siblings, 0 replies; 33+ messages in thread From: Dmitry Vyukov @ 2019-04-10 12:03 UTC (permalink / raw) To: Ian Kent Cc: Al Viro, syzbot, Andrew Morton, Amir Goldstein, linux-fsdevel, LKML, Tetsuo Handa, syzkaller-bugs On Wed, Apr 10, 2019 at 2:02 PM Dmitry Vyukov <dvyukov@google.com> wrote: > > On Wed, Apr 10, 2019 at 1:57 PM Ian Kent <raven@themaw.net> wrote: > > > > > > On Tue, Apr 09, 2019 at 07:36:00AM -0700, syzbot wrote: > > > > > > > Bisection is inconclusive: the first bad commit could be any of: > > > > > > > > > > > > [snip the useless pile] > > > > > > > > > > > > > bisection log: > > > > > > > https://syzkaller.appspot.com/x/bisect.txt?x=15e1fc2b200000 > > > > > > > start commit: [unknown > > > > > > > git tree: linux-next > > > > > > > dashboard link: > > > > > > > https://syzkaller.appspot.com/bug?extid=5399ed0832693e29f392 > > > > > > > syz repro: > > > > > > > https://syzkaller.appspot.com/x/repro.syz?x=101032b3400000 > > > > > > > C reproducer: > > > > > > > https://syzkaller.appspot.com/x/repro.c?x=16534063400000 > > > > > > > > > > > > > > For information about bisection process see: > > > > > > > https://goo.gl/tpsmEJ#bisection > > > > > > > > > > > > If I'm not misreading the "crash report" there, it has injected an > > > > > > allocation > > > > > > failure in dentry allocation in d_make_root() from autofs_fill_super() ( > > > > > > root_inode = autofs_get_inode(s, S_IFDIR | 0755); > > > > > > root = d_make_root(root_inode); > > > > > > ) which has triggered iput() on the inode passed to d_make_root() (as it > > > > > > ought > > > > > > to). At which point it stepped into some BUG_ON() in fs/inode.c, but > > > > > > I've > > > > > > no idea which one it is - line numbers do not match anything in linux- > > > > > > next > > > > > > or in mainline. Reported line 1566 is > > > > > > if (inode->i_nlink && (inode->i_state & I_DIRTY_TIME)) { > > > > > > in all of them; as the matter of fact, the diff in fs/inode.c between > > > > > > -next and mainline is empty. > > > > > > > > > > > > There is a BUG_ON() several lines prior, and in 4.20 it used to be line > > > > > > 1566, > > > > > > so _probably_ that's what it is. With that assumption, it's > > > > > > BUG_ON(inode->i_state & I_CLEAR); > > > > > > IOW, we'd got I_CLEAR in the inode passed to d_make_root() there. Which > > > > > > should not happen - the inode must have come from new_inode(), which > > > > > > gets it from new_inode_pseudo(), which zeroes ->i_state. And I_CLEAR > > > > > > is set only in clear_inode(). For autofs inodes that can come only > > > > > > from autofs_evict_inode(), called as ->evict() from evict_inode(). > > > > > > Which should never ever be called for inode with positive ->i_count... > > > > > > > > > > > > It might be memory corruption; it might be a dangling inode pointer > > > > > > somewhere, it might be something else. > > > > > > > > > > > > To get any further we really need a confirmation of the identity of > > > > > > triggered BUG_ON(). > > > > > > > > > > > > As an aside, your "sample crash reports" would've been much more useful > > > > > > if > > > > > > they went with commit SHA1 in question, especially when they contain > > > > > > line > > > > > > numbers. > > > > > > > > > > Hi Al, > > > > > > > > > > This is the commit for matching lines: > > > > > > > > > > > HEAD commit: d14b746c6c1c Add linux-next specific files for 20181214 > > > > > > > > Are you sure? > > > > what does 20181214 mean? > > > > > > Yes, I just copy-pasted from the report. "d14b746c6c1c" is the commit > > > hash. "Add linux-next specific files for 20181214" is the commit > > > subject. > > > > > > > > > > Looking at current next code (and several branches) it doesn't > > > > appear the problem is possible? > > > > > > > > > > git tree: linux-next > > > > > > > > But which branch is it really, master (which doesn't match the > > > > line numbers btw)? > > > > > > This is d14b746c6c1c commit hash. I don't know if there is a branch > > > with HEAD pointing to this commit or not, but it seems unimportant. > > > Tree+commit is the identity of code state. > > > > > > > > > > > fs/inode.c:1566 points to: > > > > > > > > > > void iput(struct inode *inode) > > > > > { > > > > > ... > > > > > BUG_ON(inode->i_state & I_CLEAR); > > > > > > > > > > > > > > > The dashboard page provides kernel git repository and commit for each > > > > > crash. > > > > > > > > Those links don't seem to make sense to me ... > > > > > > > > Help me out here! > > > > > > There is git repo name provided and commit hash. It's meant to be > > > self-explanatory. What exactly is unclear? > > > > I'm unable to find a branch matching the line numbers. > > > > Given that, on the face of it, the scenario is impossible I'm > > seeking clarification on what linux-next to look at for the > > sake of accuracy. > > > > So I'm wondering if this testing done using the master branch > > or one of the daily branches one would use to check for conflicts > > before posting? > > > > Or perhaps the master branch has been updated and the testing was > > done on something different. > > > Ah, I see. syzbot continuously tests the master branch of linux-next. > So d14b746c6c1c was once the HEAD of the master branch. > I somehow have d14b746c6c1c locally, but if you don't have it you may > need to fetch git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next-history.git > with tags. That's linux-next specifics. Here it is: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next-history.git/commit/?id=d14b746c6c1c ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: kernel BUG at fs/inode.c:LINE! 2019-04-10 11:57 ` Ian Kent 2019-04-10 12:02 ` Dmitry Vyukov @ 2019-04-10 12:07 ` Ian Kent 2019-04-10 12:11 ` Al Viro 2019-04-10 12:39 ` Dmitry Vyukov 1 sibling, 2 replies; 33+ messages in thread From: Ian Kent @ 2019-04-10 12:07 UTC (permalink / raw) To: Dmitry Vyukov Cc: Al Viro, syzbot, Andrew Morton, Amir Goldstein, linux-fsdevel, LKML, Tetsuo Handa, syzkaller-bugs On Wed, 2019-04-10 at 19:57 +0800, Ian Kent wrote: > On Wed, 2019-04-10 at 13:40 +0200, Dmitry Vyukov wrote: > > On Wed, Apr 10, 2019 at 12:35 PM Ian Kent <raven@themaw.net> wrote: > > > > > > On Wed, 2019-04-10 at 10:27 +0200, Dmitry Vyukov wrote: > > > > On Wed, Apr 10, 2019 at 2:26 AM Al Viro <viro@zeniv.linux.org.uk> wrote: > > > > > > > > > > On Tue, Apr 09, 2019 at 07:36:00AM -0700, syzbot wrote: > > > > > > Bisection is inconclusive: the first bad commit could be any of: > > > > > > > > > > [snip the useless pile] > > > > > > > > > > > bisection log: > > > > > > https://syzkaller.appspot.com/x/bisect.txt?x=15e1fc2b200000 > > > > > > start commit: [unknown > > > > > > git tree: linux-next > > > > > > dashboard link: > > > > > > https://syzkaller.appspot.com/bug?extid=5399ed0832693e29f392 > > > > > > syz repro: > > > > > > https://syzkaller.appspot.com/x/repro.syz?x=101032b3400000 > > > > > > C reproducer: > > > > > > https://syzkaller.appspot.com/x/repro.c?x=16534063400000 > > > > > > > > > > > > For information about bisection process see: > > > > > > https://goo.gl/tpsmEJ#bisection > > > > > > > > > > If I'm not misreading the "crash report" there, it has injected an > > > > > allocation > > > > > failure in dentry allocation in d_make_root() from autofs_fill_super() > > > > > ( > > > > > root_inode = autofs_get_inode(s, S_IFDIR | 0755); > > > > > root = d_make_root(root_inode); > > > > > ) which has triggered iput() on the inode passed to d_make_root() (as > > > > > it > > > > > ought > > > > > to). At which point it stepped into some BUG_ON() in fs/inode.c, but > > > > > I've > > > > > no idea which one it is - line numbers do not match anything in linux- > > > > > next > > > > > or in mainline. Reported line 1566 is > > > > > if (inode->i_nlink && (inode->i_state & I_DIRTY_TIME)) > > > > > { > > > > > in all of them; as the matter of fact, the diff in fs/inode.c between > > > > > -next and mainline is empty. > > > > > > > > > > There is a BUG_ON() several lines prior, and in 4.20 it used to be > > > > > line > > > > > 1566, > > > > > so _probably_ that's what it is. With that assumption, it's > > > > > BUG_ON(inode->i_state & I_CLEAR); > > > > > IOW, we'd got I_CLEAR in the inode passed to d_make_root() > > > > > there. Which > > > > > should not happen - the inode must have come from new_inode(), which > > > > > gets it from new_inode_pseudo(), which zeroes ->i_state. And I_CLEAR > > > > > is set only in clear_inode(). For autofs inodes that can come only > > > > > from autofs_evict_inode(), called as ->evict() from evict_inode(). > > > > > Which should never ever be called for inode with positive ->i_count... > > > > > > > > > > It might be memory corruption; it might be a dangling inode pointer > > > > > somewhere, it might be something else. > > > > > > > > > > To get any further we really need a confirmation of the identity of > > > > > triggered BUG_ON(). > > > > > > > > > > As an aside, your "sample crash reports" would've been much more > > > > > useful > > > > > if > > > > > they went with commit SHA1 in question, especially when they contain > > > > > line > > > > > numbers. > > > > > > > > Hi Al, > > > > > > > > This is the commit for matching lines: > > > > > > > > > HEAD commit: d14b746c6c1c Add linux-next specific files for > > > > > 20181214 > > > > > > Are you sure? > > > what does 20181214 mean? > > > > Yes, I just copy-pasted from the report. "d14b746c6c1c" is the commit > > hash. "Add linux-next specific files for 20181214" is the commit > > subject. > > > > > > > Looking at current next code (and several branches) it doesn't > > > appear the problem is possible? > > > > > > > > git tree: linux-next > > > > > > But which branch is it really, master (which doesn't match the > > > line numbers btw)? > > > > This is d14b746c6c1c commit hash. I don't know if there is a branch > > with HEAD pointing to this commit or not, but it seems unimportant. > > Tree+commit is the identity of code state. > > > > > > > > fs/inode.c:1566 points to: > > > > > > > > void iput(struct inode *inode) > > > > { > > > > ... > > > > BUG_ON(inode->i_state & I_CLEAR); > > > > > > > > > > > > The dashboard page provides kernel git repository and commit for each > > > > crash. > > > > > > Those links don't seem to make sense to me ... > > > > > > Help me out here! > > > > There is git repo name provided and commit hash. It's meant to be > > self-explanatory. What exactly is unclear? > > I'm unable to find a branch matching the line numbers. > > Given that, on the face of it, the scenario is impossible I'm > seeking clarification on what linux-next to look at for the > sake of accuracy. > > So I'm wondering if this testing done using the master branch > or one of the daily branches one would use to check for conflicts > before posting? Sorry those are tags not branches. On a newly updated linux-next I get: [raven@pluto linux-next.git]$ git show d14b746c6c1c fatal: ambiguous argument 'd14b746c6c1c': unknown revision or path not in the working tree. Use '--' to separate paths from revisions, like this: 'git <command> [<revision>...] -- [<file>...]' So I guess I'm confused ... Are you sure some thing's not amiss somewhere here? > > Or perhaps the master branch has been updated and the testing was > done on something different. > > Ian ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: kernel BUG at fs/inode.c:LINE! 2019-04-10 12:07 ` Ian Kent @ 2019-04-10 12:11 ` Al Viro 2019-04-10 12:41 ` Dmitry Vyukov 2019-04-10 12:39 ` Dmitry Vyukov 1 sibling, 1 reply; 33+ messages in thread From: Al Viro @ 2019-04-10 12:11 UTC (permalink / raw) To: Ian Kent Cc: Dmitry Vyukov, syzbot, Andrew Morton, Amir Goldstein, linux-fsdevel, LKML, Tetsuo Handa, syzkaller-bugs On Wed, Apr 10, 2019 at 08:07:15PM +0800, Ian Kent wrote: > > I'm unable to find a branch matching the line numbers. > > > > Given that, on the face of it, the scenario is impossible I'm > > seeking clarification on what linux-next to look at for the > > sake of accuracy. > > > > So I'm wondering if this testing done using the master branch > > or one of the daily branches one would use to check for conflicts > > before posting? > > Sorry those are tags not branches. FWIW, that's next-20181214; it is what master had been in mid-December and master is rebased every day. Can it be reproduced with the current tree? ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: kernel BUG at fs/inode.c:LINE! 2019-04-10 12:11 ` Al Viro @ 2019-04-10 12:41 ` Dmitry Vyukov 2019-04-11 0:50 ` Ian Kent 0 siblings, 1 reply; 33+ messages in thread From: Dmitry Vyukov @ 2019-04-10 12:41 UTC (permalink / raw) To: Al Viro Cc: Ian Kent, syzbot, Andrew Morton, Amir Goldstein, linux-fsdevel, LKML, Tetsuo Handa, syzkaller-bugs On Wed, Apr 10, 2019 at 2:12 PM Al Viro <viro@zeniv.linux.org.uk> wrote: > > On Wed, Apr 10, 2019 at 08:07:15PM +0800, Ian Kent wrote: > > > > I'm unable to find a branch matching the line numbers. > > > > > > Given that, on the face of it, the scenario is impossible I'm > > > seeking clarification on what linux-next to look at for the > > > sake of accuracy. > > > > > > So I'm wondering if this testing done using the master branch > > > or one of the daily branches one would use to check for conflicts > > > before posting? > > > > Sorry those are tags not branches. > > FWIW, that's next-20181214; it is what master had been in mid-December > and master is rebased every day. Can it be reproduced with the current > tree? From the info on the dashboard we know that it happened only once on d14b746c (the second one is result of reproducing the first one). So it was either fixed or just hard to trigger. ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: kernel BUG at fs/inode.c:LINE! 2019-04-10 12:41 ` Dmitry Vyukov @ 2019-04-11 0:50 ` Ian Kent 2019-04-11 2:22 ` Al Viro 2019-04-12 10:59 ` Dmitry Vyukov 0 siblings, 2 replies; 33+ messages in thread From: Ian Kent @ 2019-04-11 0:50 UTC (permalink / raw) To: Dmitry Vyukov, Al Viro Cc: syzbot, Andrew Morton, Amir Goldstein, linux-fsdevel, LKML, Tetsuo Handa, syzkaller-bugs On Wed, 2019-04-10 at 14:41 +0200, Dmitry Vyukov wrote: > On Wed, Apr 10, 2019 at 2:12 PM Al Viro <viro@zeniv.linux.org.uk> wrote: > > > > On Wed, Apr 10, 2019 at 08:07:15PM +0800, Ian Kent wrote: > > > > > > I'm unable to find a branch matching the line numbers. > > > > > > > > Given that, on the face of it, the scenario is impossible I'm > > > > seeking clarification on what linux-next to look at for the > > > > sake of accuracy. > > > > > > > > So I'm wondering if this testing done using the master branch > > > > or one of the daily branches one would use to check for conflicts > > > > before posting? > > > > > > Sorry those are tags not branches. > > > > FWIW, that's next-20181214; it is what master had been in mid-December > > and master is rebased every day. Can it be reproduced with the current > > tree? > > From the info on the dashboard we know that it happened only once on > d14b746c (the second one is result of reproducing the first one). So > it was either fixed or just hard to trigger. Looking at the source of tag next-20181214 in linux-next-history I see this is mistake I made due to incorrect error handling which I fixed soon after (there was in fact a double iput()). I'm pretty sure this never made it to a released kernel so unless there's a report of this in a stable released kernel I'm going to move on. Thanks Ian ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: kernel BUG at fs/inode.c:LINE! 2019-04-11 0:50 ` Ian Kent @ 2019-04-11 2:22 ` Al Viro 2019-04-12 11:04 ` Dmitry Vyukov 2019-04-12 10:59 ` Dmitry Vyukov 1 sibling, 1 reply; 33+ messages in thread From: Al Viro @ 2019-04-11 2:22 UTC (permalink / raw) To: Ian Kent Cc: Dmitry Vyukov, syzbot, Andrew Morton, Amir Goldstein, linux-fsdevel, LKML, Tetsuo Handa, syzkaller-bugs On Thu, Apr 11, 2019 at 08:50:17AM +0800, Ian Kent wrote: > On Wed, 2019-04-10 at 14:41 +0200, Dmitry Vyukov wrote: > > On Wed, Apr 10, 2019 at 2:12 PM Al Viro <viro@zeniv.linux.org.uk> wrote: > > > > > > On Wed, Apr 10, 2019 at 08:07:15PM +0800, Ian Kent wrote: > > > > > > > > I'm unable to find a branch matching the line numbers. > > > > > > > > > > Given that, on the face of it, the scenario is impossible I'm > > > > > seeking clarification on what linux-next to look at for the > > > > > sake of accuracy. > > > > > > > > > > So I'm wondering if this testing done using the master branch > > > > > or one of the daily branches one would use to check for conflicts > > > > > before posting? > > > > > > > > Sorry those are tags not branches. > > > > > > FWIW, that's next-20181214; it is what master had been in mid-December > > > and master is rebased every day. Can it be reproduced with the current > > > tree? > > > > From the info on the dashboard we know that it happened only once on > > d14b746c (the second one is result of reproducing the first one). So > > it was either fixed or just hard to trigger. > > Looking at the source of tag next-20181214 in linux-next-history I see > this is mistake I made due to incorrect error handling which I fixed > soon after (there was in fact a double iput()). Right - "autofs: fix possible inode leak in autofs_fill_super()" had been broken (and completely pointless), leading to double iput() in that failure case. And yes, double iput() can trigger that BUG_ON(), and with non-zero odds do so with that stack trace. As far as I'm concerned, case closed - bug had been in a misguided "fix" for inexistent leak (coming from misreading the calling conventions for d_make_root()), introduced in -next at next-20181130 and kicked out of there in next-20181219. Dropped by Ian's request in Message-ID: <66d497c00cffb3e4109ca0d5287c8277954d7132.camel@themaw.net> which has fixed that crap. Moreover, that posting had been in reply to that very syzcaller report, AFAICS. I don't know how to tell the bot to STFU and close the report in this situation; up to you, folks. As an aside, the cause of that bug is that d_make_root() calling conventions are insufficiently documented. All we have is ||[mandatory] || d_alloc_root() is gone, along with a lot of bugs caused by code ||misusing it. Replacement: d_make_root(inode). The difference is, ||d_make_root() drops the reference to inode if dentry allocation fails. in Documentation/filesystems/porting, and that's not good enough. Anyone willing to take a shot at that? FWIW, the calling conventions are: d_make_root(inode) normally allocates and returns a new dentry. On failure NULL is returned. A reference to inode is consumed in all cases (on success it is transferred to new dentry, on failure it is dropped), so failure handling does not need anything done to inode. d_make_root(NULL) quietly returns NULL, which further simplifies the error handling in typical caller. Usually it's something like inode = foofs_new_inode(....); s->s_root = d_make_inode(inode); if (!s->s_root) bugger off, no need to undo inode allocation success We do not need to check if foofs_new_inode() has returned NULL and we do not need any special cleanups in case of failure - not for the undoing the inode allocation. If anyone cares to convert that into coherent (and printable) documentation, patches are welcome... ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: kernel BUG at fs/inode.c:LINE! 2019-04-11 2:22 ` Al Viro @ 2019-04-12 11:04 ` Dmitry Vyukov 2019-04-12 19:46 ` Eric Biggers 0 siblings, 1 reply; 33+ messages in thread From: Dmitry Vyukov @ 2019-04-12 11:04 UTC (permalink / raw) To: Al Viro Cc: Ian Kent, Dmitry Vyukov, syzbot, Andrew Morton, Amir Goldstein, linux-fsdevel, LKML, Tetsuo Handa, syzkaller-bugs On Thu, Apr 11, 2019 at 4:23 AM Al Viro <viro@zeniv.linux.org.uk> wrote: > > On Thu, Apr 11, 2019 at 08:50:17AM +0800, Ian Kent wrote: > > On Wed, 2019-04-10 at 14:41 +0200, Dmitry Vyukov wrote: > > > On Wed, Apr 10, 2019 at 2:12 PM Al Viro <viro@zeniv.linux.org.uk> wrote: > > > > > > > > On Wed, Apr 10, 2019 at 08:07:15PM +0800, Ian Kent wrote: > > > > > > > > > > I'm unable to find a branch matching the line numbers. > > > > > > > > > > > > Given that, on the face of it, the scenario is impossible I'm > > > > > > seeking clarification on what linux-next to look at for the > > > > > > sake of accuracy. > > > > > > > > > > > > So I'm wondering if this testing done using the master branch > > > > > > or one of the daily branches one would use to check for conflicts > > > > > > before posting? > > > > > > > > > > Sorry those are tags not branches. > > > > > > > > FWIW, that's next-20181214; it is what master had been in mid-December > > > > and master is rebased every day. Can it be reproduced with the current > > > > tree? > > > > > > From the info on the dashboard we know that it happened only once on > > > d14b746c (the second one is result of reproducing the first one). So > > > it was either fixed or just hard to trigger. > > > > Looking at the source of tag next-20181214 in linux-next-history I see > > this is mistake I made due to incorrect error handling which I fixed > > soon after (there was in fact a double iput()). > > Right - "autofs: fix possible inode leak in autofs_fill_super()" had been > broken (and completely pointless), leading to double iput() in that failure > case. And yes, double iput() can trigger that BUG_ON(), and with non-zero > odds do so with that stack trace. > > As far as I'm concerned, case closed - bug had been in a misguided "fix" > for inexistent leak (coming from misreading the calling conventions for > d_make_root()), introduced in -next at next-20181130 and kicked out of > there in next-20181219. Dropped by Ian's request in > Message-ID: <66d497c00cffb3e4109ca0d5287c8277954d7132.camel@themaw.net> > which has fixed that crap. Moreover, that posting had been in reply to > that very syzcaller report, AFAICS. > > I don't know how to tell the bot to STFU and close the report in this > situation; up to you, folks. Please see the following for this: > syzbot will keep track of this bug report. See: > https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with syzbot. There are just 3 operations: mark as fixed by a commit, mark as invalid, mark as duplicate. I won't be always around. Tracking statuses of bug reports is in the interests of kernel quality. > As an aside, the cause of that bug is that d_make_root() calling conventions > are insufficiently documented. All we have is > > ||[mandatory] > || d_alloc_root() is gone, along with a lot of bugs caused by code > ||misusing it. Replacement: d_make_root(inode). The difference is, > ||d_make_root() drops the reference to inode if dentry allocation fails. > > in Documentation/filesystems/porting, and that's not good enough. Anyone > willing to take a shot at that? FWIW, the calling conventions are: > > d_make_root(inode) normally allocates and returns a new dentry. > On failure NULL is returned. A reference to inode is consumed in all > cases (on success it is transferred to new dentry, on failure it is > dropped), so failure handling does not need anything done to inode. > d_make_root(NULL) quietly returns NULL, which further simplifies the > error handling in typical caller. Usually it's something like > inode = foofs_new_inode(....); > s->s_root = d_make_inode(inode); > if (!s->s_root) > bugger off, no need to undo inode allocation > success > We do not need to check if foofs_new_inode() has returned NULL and we > do not need any special cleanups in case of failure - not for the > undoing the inode allocation. > > If anyone cares to convert that into coherent (and printable) documentation, > patches are welcome... ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: kernel BUG at fs/inode.c:LINE! 2019-04-12 11:04 ` Dmitry Vyukov @ 2019-04-12 19:46 ` Eric Biggers 0 siblings, 0 replies; 33+ messages in thread From: Eric Biggers @ 2019-04-12 19:46 UTC (permalink / raw) To: Dmitry Vyukov Cc: Al Viro, Ian Kent, syzbot, Andrew Morton, Amir Goldstein, linux-fsdevel, LKML, Tetsuo Handa, syzkaller-bugs Hi Dmitry, On Fri, Apr 12, 2019 at 01:04:27PM +0200, 'Dmitry Vyukov' via syzkaller-bugs wrote: > On Thu, Apr 11, 2019 at 4:23 AM Al Viro <viro@zeniv.linux.org.uk> wrote: > > > > On Thu, Apr 11, 2019 at 08:50:17AM +0800, Ian Kent wrote: > > > On Wed, 2019-04-10 at 14:41 +0200, Dmitry Vyukov wrote: > > > > On Wed, Apr 10, 2019 at 2:12 PM Al Viro <viro@zeniv.linux.org.uk> wrote: > > > > > > > > > > On Wed, Apr 10, 2019 at 08:07:15PM +0800, Ian Kent wrote: > > > > > > > > > > > > I'm unable to find a branch matching the line numbers. > > > > > > > > > > > > > > Given that, on the face of it, the scenario is impossible I'm > > > > > > > seeking clarification on what linux-next to look at for the > > > > > > > sake of accuracy. > > > > > > > > > > > > > > So I'm wondering if this testing done using the master branch > > > > > > > or one of the daily branches one would use to check for conflicts > > > > > > > before posting? > > > > > > > > > > > > Sorry those are tags not branches. > > > > > > > > > > FWIW, that's next-20181214; it is what master had been in mid-December > > > > > and master is rebased every day. Can it be reproduced with the current > > > > > tree? > > > > > > > > From the info on the dashboard we know that it happened only once on > > > > d14b746c (the second one is result of reproducing the first one). So > > > > it was either fixed or just hard to trigger. > > > > > > Looking at the source of tag next-20181214 in linux-next-history I see > > > this is mistake I made due to incorrect error handling which I fixed > > > soon after (there was in fact a double iput()). > > > > Right - "autofs: fix possible inode leak in autofs_fill_super()" had been > > broken (and completely pointless), leading to double iput() in that failure > > case. And yes, double iput() can trigger that BUG_ON(), and with non-zero > > odds do so with that stack trace. > > > > As far as I'm concerned, case closed - bug had been in a misguided "fix" > > for inexistent leak (coming from misreading the calling conventions for > > d_make_root()), introduced in -next at next-20181130 and kicked out of > > there in next-20181219. Dropped by Ian's request in > > Message-ID: <66d497c00cffb3e4109ca0d5287c8277954d7132.camel@themaw.net> > > which has fixed that crap. Moreover, that posting had been in reply to > > that very syzcaller report, AFAICS. > > > > I don't know how to tell the bot to STFU and close the report in this > > situation; up to you, folks. > > > Please see the following for this: > > > syzbot will keep track of this bug report. See: > > https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with syzbot. > > There are just 3 operations: mark as fixed by a commit, mark as > invalid, mark as duplicate. > I won't be always around. Tracking statuses of bug reports is in the > interests of kernel quality. > As I suggested before, syzbot should automatically invalidate old bug reports, especially on linux-next, that are unlikely to still be real problems. And, syzbot should send remainders about bugs that are still occurring. Instead, currently developers have to waste time debugging bugs caused by patches that were in linux-next for a few days/weeks and then dropped months ago, and have to argue with you every time about how to tell syzbot to close the bug when it never made it into git history. And meanwhile, no one is looking into the bugs that are being hit on mainline every hour or even every 10 minutes for the past year. That's not a great strategy to actually get bugs fixed. - Eric ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: kernel BUG at fs/inode.c:LINE! 2019-04-11 0:50 ` Ian Kent 2019-04-11 2:22 ` Al Viro @ 2019-04-12 10:59 ` Dmitry Vyukov 2019-04-12 19:19 ` Al Viro 1 sibling, 1 reply; 33+ messages in thread From: Dmitry Vyukov @ 2019-04-12 10:59 UTC (permalink / raw) To: Ian Kent Cc: Al Viro, syzbot, Andrew Morton, Amir Goldstein, linux-fsdevel, LKML, Tetsuo Handa, syzkaller-bugs On Thu, Apr 11, 2019 at 2:50 AM Ian Kent <raven@themaw.net> wrote: > > On Wed, 2019-04-10 at 14:41 +0200, Dmitry Vyukov wrote: > > On Wed, Apr 10, 2019 at 2:12 PM Al Viro <viro@zeniv.linux.org.uk> wrote: > > > > > > On Wed, Apr 10, 2019 at 08:07:15PM +0800, Ian Kent wrote: > > > > > > > > I'm unable to find a branch matching the line numbers. > > > > > > > > > > Given that, on the face of it, the scenario is impossible I'm > > > > > seeking clarification on what linux-next to look at for the > > > > > sake of accuracy. > > > > > > > > > > So I'm wondering if this testing done using the master branch > > > > > or one of the daily branches one would use to check for conflicts > > > > > before posting? > > > > > > > > Sorry those are tags not branches. > > > > > > FWIW, that's next-20181214; it is what master had been in mid-December > > > and master is rebased every day. Can it be reproduced with the current > > > tree? > > > > From the info on the dashboard we know that it happened only once on > > d14b746c (the second one is result of reproducing the first one). So > > it was either fixed or just hard to trigger. > > Looking at the source of tag next-20181214 in linux-next-history I see > this is mistake I made due to incorrect error handling which I fixed > soon after (there was in fact a double iput()). > > I'm pretty sure this never made it to a released kernel so unless > there's a report of this in a stable released kernel I'm going to > move on. Please don't ignore the bug status tracking part. Or we will only have options of not testing kernel or dropping most of the bug reports on the floor. Both are equally harmful for kernel quality. Let's mark it as fixed by the next commit in series (which already made it into mainline): #syz fix: autofs: simplify parse_options() function call But I won't be around always. ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: kernel BUG at fs/inode.c:LINE! 2019-04-12 10:59 ` Dmitry Vyukov @ 2019-04-12 19:19 ` Al Viro 0 siblings, 0 replies; 33+ messages in thread From: Al Viro @ 2019-04-12 19:19 UTC (permalink / raw) To: Dmitry Vyukov Cc: Ian Kent, syzbot, Andrew Morton, Amir Goldstein, linux-fsdevel, LKML, Tetsuo Handa, syzkaller-bugs On Fri, Apr 12, 2019 at 12:59:30PM +0200, Dmitry Vyukov wrote: > Please don't ignore the bug status tracking part. Or we will only have > options of not testing kernel or dropping most of the bug reports on > the floor. Both are equally harmful for kernel quality. > > Let's mark it as fixed by the next commit in series (which already > made it into mainline): > > #syz fix: autofs: simplify parse_options() function call > > But I won't be around always. You might want to add something like "commit discarded"... ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: kernel BUG at fs/inode.c:LINE! 2019-04-10 12:07 ` Ian Kent 2019-04-10 12:11 ` Al Viro @ 2019-04-10 12:39 ` Dmitry Vyukov 1 sibling, 0 replies; 33+ messages in thread From: Dmitry Vyukov @ 2019-04-10 12:39 UTC (permalink / raw) To: Ian Kent Cc: Al Viro, syzbot, Andrew Morton, Amir Goldstein, linux-fsdevel, LKML, Tetsuo Handa, syzkaller-bugs On Wed, Apr 10, 2019 at 2:07 PM Ian Kent <raven@themaw.net> wrote: > > On Wed, 2019-04-10 at 19:57 +0800, Ian Kent wrote: > > On Wed, 2019-04-10 at 13:40 +0200, Dmitry Vyukov wrote: > > > On Wed, Apr 10, 2019 at 12:35 PM Ian Kent <raven@themaw.net> wrote: > > > > > > > > On Wed, 2019-04-10 at 10:27 +0200, Dmitry Vyukov wrote: > > > > > On Wed, Apr 10, 2019 at 2:26 AM Al Viro <viro@zeniv.linux.org.uk> wrote: > > > > > > > > > > > > On Tue, Apr 09, 2019 at 07:36:00AM -0700, syzbot wrote: > > > > > > > Bisection is inconclusive: the first bad commit could be any of: > > > > > > > > > > > > [snip the useless pile] > > > > > > > > > > > > > bisection log: > > > > > > > https://syzkaller.appspot.com/x/bisect.txt?x=15e1fc2b200000 > > > > > > > start commit: [unknown > > > > > > > git tree: linux-next > > > > > > > dashboard link: > > > > > > > https://syzkaller.appspot.com/bug?extid=5399ed0832693e29f392 > > > > > > > syz repro: > > > > > > > https://syzkaller.appspot.com/x/repro.syz?x=101032b3400000 > > > > > > > C reproducer: > > > > > > > https://syzkaller.appspot.com/x/repro.c?x=16534063400000 > > > > > > > > > > > > > > For information about bisection process see: > > > > > > > https://goo.gl/tpsmEJ#bisection > > > > > > > > > > > > If I'm not misreading the "crash report" there, it has injected an > > > > > > allocation > > > > > > failure in dentry allocation in d_make_root() from autofs_fill_super() > > > > > > ( > > > > > > root_inode = autofs_get_inode(s, S_IFDIR | 0755); > > > > > > root = d_make_root(root_inode); > > > > > > ) which has triggered iput() on the inode passed to d_make_root() (as > > > > > > it > > > > > > ought > > > > > > to). At which point it stepped into some BUG_ON() in fs/inode.c, but > > > > > > I've > > > > > > no idea which one it is - line numbers do not match anything in linux- > > > > > > next > > > > > > or in mainline. Reported line 1566 is > > > > > > if (inode->i_nlink && (inode->i_state & I_DIRTY_TIME)) > > > > > > { > > > > > > in all of them; as the matter of fact, the diff in fs/inode.c between > > > > > > -next and mainline is empty. > > > > > > > > > > > > There is a BUG_ON() several lines prior, and in 4.20 it used to be > > > > > > line > > > > > > 1566, > > > > > > so _probably_ that's what it is. With that assumption, it's > > > > > > BUG_ON(inode->i_state & I_CLEAR); > > > > > > IOW, we'd got I_CLEAR in the inode passed to d_make_root() > > > > > > there. Which > > > > > > should not happen - the inode must have come from new_inode(), which > > > > > > gets it from new_inode_pseudo(), which zeroes ->i_state. And I_CLEAR > > > > > > is set only in clear_inode(). For autofs inodes that can come only > > > > > > from autofs_evict_inode(), called as ->evict() from evict_inode(). > > > > > > Which should never ever be called for inode with positive ->i_count... > > > > > > > > > > > > It might be memory corruption; it might be a dangling inode pointer > > > > > > somewhere, it might be something else. > > > > > > > > > > > > To get any further we really need a confirmation of the identity of > > > > > > triggered BUG_ON(). > > > > > > > > > > > > As an aside, your "sample crash reports" would've been much more > > > > > > useful > > > > > > if > > > > > > they went with commit SHA1 in question, especially when they contain > > > > > > line > > > > > > numbers. > > > > > > > > > > Hi Al, > > > > > > > > > > This is the commit for matching lines: > > > > > > > > > > > HEAD commit: d14b746c6c1c Add linux-next specific files for > > > > > > 20181214 > > > > > > > > Are you sure? > > > > what does 20181214 mean? > > > > > > Yes, I just copy-pasted from the report. "d14b746c6c1c" is the commit > > > hash. "Add linux-next specific files for 20181214" is the commit > > > subject. > > > > > > > > > > Looking at current next code (and several branches) it doesn't > > > > appear the problem is possible? > > > > > > > > > > git tree: linux-next > > > > > > > > But which branch is it really, master (which doesn't match the > > > > line numbers btw)? > > > > > > This is d14b746c6c1c commit hash. I don't know if there is a branch > > > with HEAD pointing to this commit or not, but it seems unimportant. > > > Tree+commit is the identity of code state. > > > > > > > > > > > fs/inode.c:1566 points to: > > > > > > > > > > void iput(struct inode *inode) > > > > > { > > > > > ... > > > > > BUG_ON(inode->i_state & I_CLEAR); > > > > > > > > > > > > > > > The dashboard page provides kernel git repository and commit for each > > > > > crash. > > > > > > > > Those links don't seem to make sense to me ... > > > > > > > > Help me out here! > > > > > > There is git repo name provided and commit hash. It's meant to be > > > self-explanatory. What exactly is unclear? > > > > I'm unable to find a branch matching the line numbers. > > > > Given that, on the face of it, the scenario is impossible I'm > > seeking clarification on what linux-next to look at for the > > sake of accuracy. > > > > So I'm wondering if this testing done using the master branch > > or one of the daily branches one would use to check for conflicts > > before posting? > > Sorry those are tags not branches. > > On a newly updated linux-next I get: > [raven@pluto linux-next.git]$ git show d14b746c6c1c > fatal: ambiguous argument 'd14b746c6c1c': unknown revision or path not in the > working tree. > Use '--' to separate paths from revisions, like this: > 'git <command> [<revision>...] -- [<file>...]' > > So I guess I'm confused ... > > Are you sure some thing's not amiss somewhere here? \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ > > I somehow have d14b746c6c1c locally, but if you don't have it you may > > need to fetch git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next-history.git > > with tags. That's linux-next specifics. > > Here it is: > https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next-history.git/commit/?id=d14b746c6c1c ^ permalink raw reply [flat|nested] 33+ messages in thread
end of thread, other threads:[~2019-04-12 19:47 UTC | newest] Thread overview: 33+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2018-12-17 6:11 kernel BUG at fs/inode.c:LINE! syzbot 2018-12-17 7:21 ` Al Viro 2018-12-17 10:08 ` Dmitry Vyukov 2018-12-18 10:40 ` Tetsuo Handa 2018-12-18 10:42 ` Ian Kent 2018-12-18 11:01 ` Amir Goldstein 2018-12-18 11:52 ` Ian Kent 2018-12-18 11:34 ` Ian Kent 2018-12-18 12:27 ` Dmitry Vyukov 2018-12-18 12:42 ` Ian Kent 2018-12-18 13:19 ` Dmitry Vyukov 2018-12-18 14:40 ` Ian Kent 2018-12-18 21:09 ` Andrew Morton 2018-12-19 0:05 ` Ian Kent 2018-12-18 13:51 ` Al Viro 2019-04-09 14:36 ` syzbot 2019-04-10 0:26 ` Al Viro 2019-04-10 8:27 ` Dmitry Vyukov 2019-04-10 10:35 ` Ian Kent 2019-04-10 11:40 ` Dmitry Vyukov 2019-04-10 11:57 ` Ian Kent 2019-04-10 12:02 ` Dmitry Vyukov 2019-04-10 12:03 ` Dmitry Vyukov 2019-04-10 12:07 ` Ian Kent 2019-04-10 12:11 ` Al Viro 2019-04-10 12:41 ` Dmitry Vyukov 2019-04-11 0:50 ` Ian Kent 2019-04-11 2:22 ` Al Viro 2019-04-12 11:04 ` Dmitry Vyukov 2019-04-12 19:46 ` Eric Biggers 2019-04-12 10:59 ` Dmitry Vyukov 2019-04-12 19:19 ` Al Viro 2019-04-10 12:39 ` Dmitry Vyukov
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).