kernel BUG at fs/inode.c:LINE!

kernel BUG at fs/inode.c:LINE!

[syzbot]

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

Re: kernel BUG at fs/inode.c:LINE!

[Al Viro]

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...

Re: kernel BUG at fs/inode.c:LINE!

[Dmitry Vyukov]

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.

Re: kernel BUG at fs/inode.c:LINE!

[Tetsuo Handa]

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...

Re: kernel BUG at fs/inode.c:LINE!

[Ian Kent]

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:

Re: kernel BUG at fs/inode.c:LINE!

[Amir Goldstein]

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:
>

Re: kernel BUG at fs/inode.c:LINE!

[Ian Kent]

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:
> 

Re: kernel BUG at fs/inode.c:LINE!

[Ian Kent]

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:
> > 

Re: kernel BUG at fs/inode.c:LINE!

[Dmitry Vyukov]

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:
> >
>

Re: kernel BUG at fs/inode.c:LINE!

[Ian Kent]

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:
> > > 

Re: kernel BUG at fs/inode.c:LINE!

[Dmitry Vyukov]

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.

Re: kernel BUG at fs/inode.c:LINE!

[Al Viro]

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.

Re: kernel BUG at fs/inode.c:LINE!

[Ian Kent]

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.

Re: kernel BUG at fs/inode.c:LINE!

[Andrew Morton]

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?

Re: kernel BUG at fs/inode.c:LINE!

[Ian Kent]

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

Re: kernel BUG at fs/inode.c:LINE!

[syzbot]

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

Re: kernel BUG at fs/inode.c:LINE!

[Al Viro]

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.

Re: kernel BUG at fs/inode.c:LINE!

[Dmitry Vyukov]

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.

Re: kernel BUG at fs/inode.c:LINE!

[Ian Kent]

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

Re: kernel BUG at fs/inode.c:LINE!

[Dmitry Vyukov]

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?

Re: kernel BUG at fs/inode.c:LINE!

[Ian Kent]

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

Re: kernel BUG at fs/inode.c:LINE!

[Dmitry Vyukov]

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.

Re: kernel BUG at fs/inode.c:LINE!

[Dmitry Vyukov]

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

Re: kernel BUG at fs/inode.c:LINE!

[Ian Kent]

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

Re: kernel BUG at fs/inode.c:LINE!

[Al Viro]

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?

Re: kernel BUG at fs/inode.c:LINE!

[Dmitry Vyukov]

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

Re: kernel BUG at fs/inode.c:LINE!

[Dmitry Vyukov]

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.

Re: kernel BUG at fs/inode.c:LINE!

[Ian Kent]

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

Re: kernel BUG at fs/inode.c:LINE!

[Al Viro]

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...

Re: kernel BUG at fs/inode.c:LINE!

[Dmitry Vyukov]

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.

Re: kernel BUG at fs/inode.c:LINE!

[Dmitry Vyukov]

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...

Re: kernel BUG at fs/inode.c:LINE!

[Al Viro]

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"...

Re: kernel BUG at fs/inode.c:LINE!

[Eric Biggers]

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