The linux-next commit "fs/namei.c: keep track of nd->root refcount status” [1] causes boot panic on all
architectures here on today’s linux-next (0902). Reverted it will fix the issue.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=e013ec23b8231cf7f95605cbb0e47aa0e3d047a4
All config are here: https://github.com/cailca/linux-mm
[ 104.088693][ T1] Run /init as init process
[ 104.155068][ T1] ==================================================================
[ 104.163000][ T1] BUG: KASAN: invalid-access in dput+0x94/0x8d0
[ 104.169095][ T1] Read of size 4 at addr aaaaaaaaaaaaaaaa by task systemd/1
[ 104.176227][ T1]
[ 104.178416][ T1] CPU: 166 PID: 1 Comm: systemd Not tainted 5.3.0-rc6-next-20190902 #2
[ 104.186504][ T1] Hardware name: HPE Apollo 70 /C01_APACHE_MB , BIOS L50_5.13_1.11 06/18/2019
[ 104.196935][ T1] Call trace:
[ 104.200091][ T1] dump_backtrace+0x0/0x264
[ 104.204447][ T1] show_stack+0x20/0x2c
[ 104.208460][ T1] dump_stack+0xb0/0x104
[ 104.212558][ T1] __kasan_report+0x1fc/0x294
[ 104.217088][ T1] kasan_report+0x10/0x18
[ 104.221271][ T1] __hwasan_load4_noabort+0x84/0x8c
[ 104.226320][ T1] dput+0x94/0x8d0
[ 104.229902][ T1] path_put+0x24/0x40
[ 104.233739][ T1] terminate_walk+0x98/0x124
[ 104.238182][ T1] path_lookupat+0x1a8/0x3f8
[ 104.242624][ T1] filename_lookup+0x84/0x128
[ 104.247154][ T1] user_path_at_empty+0x54/0x68
[ 104.251869][ T1] __arm64_sys_name_to_handle_at+0xd4/0x63c
[ 104.257625][ T1] el0_svc_handler+0x16c/0x234
[ 104.262240][ T1] el0_svc+0x8/0xc
[ 104.265814][ T1] ==================================================================
[ 104.273726][ T1] Disabling lock debugging due to kernel taint
[ 104.279758][ T1] Unable to handle kernel paging request at virtual address aaaaaaaaaaaaaaaa
[ 104.288378][ T1] Mem abort info:
[ 104.291861][ T1] ESR = 0x96000004
[ 104.295619][ T1] EC = 0x25: DABT (current EL), IL = 32 bits
[ 104.301619][ T1] SET = 0, FnV = 0
[ 104.305375][ T1] EA = 0, S1PTW = 0
[ 104.309203][ T1] Data abort info:
[ 104.312773][ T1] ISV = 0, ISS = 0x00000004
[ 104.317310][ T1] CM = 0, WnR = 0
[ 104.320968][ T1] [aaaaaaaaaaaaaaaa] address between user and kernel address ranges
[ 104.328806][ T1] Internal error: Oops: 96000004 [#1] SMP
[ 104.334375][ T1] Modules linked in:
[ 104.338127][ T1] CPU: 166 PID: 1 Comm: systemd Tainted: G B 5.3.0-rc6-next-20190902 #2
[ 104.347601][ T1] Hardware name: HPE Apollo 70 /C01_APACHE_MB , BIOS L50_5.13_1.11 06/18/2019
[ 104.358033][ T1] pstate: 60400009 (nZCv daif +PAN -UAO)
[ 104.363514][ T1] pc : dput+0x94/0x8d0
[ 104.367433][ T1] lr : dput+0x94/0x8d0
[ 104.371349][ T1] sp : 29ff008b8054fb40
[ 104.375353][ T1] x29: 29ff008b8054fba0 x28: faff008b8052a0c0
[ 104.381357][ T1] x27: 0000000000080040 x26: 0000000000080060
[ 104.387361][ T1] x25: 0000000000000001 x24: faff008b8052a0c0
[ 104.393365][ T1] x23: 0000000000000001 x22: ffff9000129e5cb8
[ 104.399368][ T1] x21: ffff900010f4cb4a x20: faff008b8052a0d8
[ 104.405371][ T1] x19: aaaaaaaaaaaaaaaa x18: 0000000000000000
[ 104.411374][ T1] x17: 0000000000000000 x16: 0000000000000000
[ 104.417377][ T1] x15: 0000000000000000 x14: 4c20534f4942202c
[ 104.423380][ T1] x13: 2020202020202020 x12: ffffffffffffffff
[ 104.429383][ T1] x11: 00000000000000fa x10: ffff8008b8052a0e
[ 104.435387][ T1] x9 : 828cac3cb2455600 x8 : 828cac3cb2455600
[ 104.441389][ T1] x7 : 0000000000000000 x6 : ffff9000101dcf08
[ 104.447392][ T1] x5 : 0000000000000000 x4 : 0000000000000080
[ 104.453395][ T1] x3 : ffff9000101d0e8c x2 : 0000000000000001
[ 104.459398][ T1] x1 : 0000000000000001 x0 : faff008b8052a0d8
[ 104.465402][ T1] Call trace:
[ 104.468541][ T1] dput+0x94/0x8d0
[ 104.472112][ T1] path_put+0x24/0x40
[ 104.475945][ T1] terminate_walk+0x98/0x124
[ 104.480385][ T1] path_lookupat+0x1a8/0x3f8
[ 104.484826][ T1] filename_lookup+0x84/0x128
[ 104.489353][ T1] user_path_at_empty+0x54/0x68
[ 104.494055][ T1] __arm64_sys_name_to_handle_at+0xd4/0x63c
[ 104.499798][ T1] el0_svc_handler+0x16c/0x234
[ 104.504411][ T1] el0_svc+0x8/0xc
[ 104.507989][ T1] Code: aa1603e0 9400202a aa1303e0 97fdfb5c (39400268)
[ 104.515005][ T1] ---[ end trace 8f0e764e24e4db67 ]---
[ 104.520314][ T1] Kernel panic - not syncing: Fatal exception
[ 104.526386][ T1] SMP: stopping secondary CPUs
[ 104.531154][ T1] Kernel Offset: disabled
[ 104.535334][ T1] CPU features: 0x0002,20000c18
[ 104.540032][ T1] Memory Limit: none
[ 104.543936][ T1] ---[ end Kernel panic - not syncing: Fatal exception ]—
[ 18.850684][ T1] Run /init as init process
[ 18.865679][ T1] Kernel attempted to access user page (7ffffb9da7e8) - exploit attempt? (uid: 0)
[ 18.865702][ T1] BUG: Unable to handle kernel data access at 0x7ffffb9da7e8
[ 18.865714][ T1] Faulting instruction address: 0xc000000000472f98
[ 18.865734][ T1] Oops: Kernel access of bad area, sig: 11 [#1]
[ 18.865744][ T1] LE PAGE_SIZE=64K MMU=Radix MMU=Hash SMP NR_CPUS=256 DEBUG_PAGEALLOC NUMA PowerNV
[ 18.865766][ T1] Modules linked in:
[ 18.865786][ T1] CPU: 12 PID: 1 Comm: systemd Not tainted 5.3.0-rc6-next-20190902 #1
[ 18.865808][ T1] NIP: c000000000472f98 LR: c000000000472f94 CTR: 0000000000000000
[ 18.865828][ T1] REGS: c000200009d4f8c0 TRAP: 0300 Not tainted (5.3.0-rc6-next-20190902)
[ 18.865848][ T1] MSR: 9000000000009033 <SF,HV,EE,ME,IR,DR,RI,LE> CR: 24044842 XER: 00000000
[ 18.865874][ T1] CFAR: c00000000019c340 DAR: 00007ffffb9da7e8 DSISR: 08000000 IRQMASK: 0
[ 18.865874][ T1] GPR00: c000000000472f94 c000200009d4fb50 c000000001055f00 0000000000000000
[ 18.865874][ T1] GPR04: c000000001388ad8 0000000000000000 00000000b1fde0fa ffffffff000002ca
[ 18.865874][ T1] GPR08: 00000000b201b1b9 0000000000000000 0000000000000000 c00000002c128480
[ 18.865874][ T1] GPR12: 0000000000004000 c000001fffff5a00 0000000000000000 0000000000000fb1
[ 18.865874][ T1] GPR16: 00007ffffb9dffb1 000000012fbf8718 000000012fbf8728 000000012fbf8758
[ 18.865874][ T1] GPR20: 000000012fbf8768 00007ffffb9da7e8 00007ffffb9da7d8 00007ffffb9da440
[ 18.865874][ T1] GPR24: 0000000000080040 0000000000000001 c000000000472f4c c0000000009f5820
[ 18.865874][ T1] GPR28: c000000000f2bbe8 0000000000080060 00007ffffb9da868 00007ffffb9da7e8
[ 18.866054][ T1] NIP [c000000000472f98] dput.part.6+0xc8/0x4f0
[ 18.866082][ T1] LR [c000000000472f94] dput.part.6+0xc4/0x4f0
[ 18.866100][ T1] Call Trace:
[ 18.866118][ T1] [c000200009d4fb50] [c000000000472f94] dput.part.6+0xc4/0x4f0 (unreliable)
[ 18.866140][ T1] [c000200009d4fbc0] [c00000000045b17c] terminate_walk+0x17c/0x1c0
[ 18.866152][ T1] [c000200009d4fc00] [c000000000462178] path_lookupat+0xf8/0x2a0
[ 18.866163][ T1] [c000200009d4fc70] [c000000000464950] filename_lookup.part.12+0xa0/0x170
[ 18.866185][ T1] [c000200009d4fda0] [c000000000509074] sys_name_to_handle_at+0xd4/0x300
[ 18.866208][ T1] [c000200009d4fe20] [c00000000000b278] system_call+0x5c/0x68
[ 18.866237][ T1] Instruction dump:
[ 18.866253][ T1] 39290001 912a0000 39000000 7f49d378 7f83e378 38e00000 38c00002 38a00000
[ 18.866276][ T1] 38800000 3bdf0080 4bd29249 60000000 <813f0000> 7fc3f378 71290008 4082013c
[ 18.866300][ T1] ---[ end trace de9d3874b1f53267 ]---
[ 18.958525][ T1]
[ 19.958606][ T1] Kernel panic - not syncing: Fatal exception
[ 39.686666][ T1] UBSAN: Undefined behaviour in kernel/locking/lockdep_internals.h:224:2
[ 39.725420][ T1] index 841678955 is out of range for type 'long unsigned int [8192]'
[ 39.763094][ T1] CPU: 4 PID: 1 Comm: systemd Not tainted 5.3.0-rc6-next-20190902 #1
[ 39.800145][ T1] Hardware name: HP ProLiant XL420 Gen9/ProLiant XL420 Gen9, BIOS U19 12/27/2015
[ 39.842199][ T1] Call Trace:
[ 39.856929][ T1] dump_stack+0x62/0x9a
[ 39.875739][ T1] ubsan_epilogue+0xd/0x3a
[ 39.895416][ T1] __ubsan_handle_out_of_bounds+0x70/0x80
[ 39.921688][ T1] __lock_acquire.isra.13+0x808/0x830
[ 39.945869][ T1] ? __lock_acquire.isra.13+0x430/0x830
[ 39.971711][ T1] lock_acquire+0x107/0x220
[ 39.994163][ T1] ? dput.part.7+0x1c5/0x500
[ 40.016158][ T1] ? dput.part.7+0x30/0x500
[ 40.036582][ T1] _raw_spin_lock+0x2f/0x40
[ 40.057076][ T1] ? dput.part.7+0x1c5/0x500
[ 40.077507][ T1] dput.part.7+0x1c5/0x500
[ 40.097771][ T1] ? path_get+0x35/0x40
[ 40.116577][ T1] dput+0xe/0x10
[ 40.132493][ T1] terminate_walk+0x1a4/0x1d0
[ 40.153485][ T1] path_lookupat+0x156/0x420
[ 40.174134][ T1] ? link_path_walk.part.6+0x870/0x870
[ 40.199229][ T1] ? create_object+0x4a2/0x540
[ 40.220672][ T1] ? lock_downgrade+0x390/0x390
[ 40.242538][ T1] ? do_raw_write_lock+0x118/0x1d0
[ 40.265756][ T1] ? do_raw_read_unlock+0x60/0x60
[ 40.288700][ T1] ? create_object+0x22a/0x540
[ 40.310276][ T1] filename_lookup.part.10+0x11b/0x1f0
[ 40.335487][ T1] ? do_renameat2+0x7e0/0x7e0
[ 40.356858][ T1] ? __virt_addr_valid+0xdd/0x170
[ 40.379861][ T1] ? __phys_addr_symbol+0x27/0x42
[ 40.402344][ T1] ? strncpy_from_user+0x100/0x280
[ 40.425720][ T1] ? getname_flags+0xa7/0x220
[ 40.447134][ T1] user_path_at_empty+0x3e/0x50
[ 40.469048][ T1] __x64_sys_name_to_handle_at+0x113/0x340
[ 40.496646][ T1] ? kmem_cache_free+0x128/0x430
[ 40.520509][ T1] ? vfs_dentry_acceptable+0x10/0x10
[ 40.547313][ T1] ? putname+0x6b/0x80
[ 40.565905][ T1] ? do_sys_open+0x172/0x2c0
[ 40.586647][ T1] ? _raw_spin_unlock_irq+0x27/0x40
[ 40.610151][ T1] ? task_work_run+0xa1/0x100
[ 40.631407][ T1] do_syscall_64+0xc7/0x646
[ 40.651745][ T1] ? syscall_return_slowpath+0x140/0x140
[ 40.676512][ T1] ? __do_page_fault+0x49f/0x630
[ 40.698994][ T1] entry_SYSCALL_64_after_hwframe+0x44/0xa9
[ 40.725719][ T1] RIP: 0033:0x7f681e45cf3e
[ 40.745799][ T1] Code: 48 8b 0d 4d ff 2b 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 49 89 ca b8 2f 01 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 1a ff 2b 00 f7 d8 64 89 01 48
[ 40.837197][ T1] RSP: 002b:00007ffdc2968038 EFLAGS: 00000202 ORIG_RAX: 000000000000012f
[ 40.875888][ T1] RAX: ffffffffffffffda RBX: 0000000000000080 RCX: 00007f681e45cf3e
[ 40.912761][ T1] RDX: 000055bdc6e995b0 RSI: 00007f681fc203d6 RDI: 0000000000000004
[ 40.949212][ T1] RBP: 000055bdc6e995b0 R08: 0000000000001000 R09: 0000000000000003
[ 40.985257][ T1] R10: 00007ffdc2968064 R11: 0000000000000202 R12: 000055bdc6e994e1
[ 41.024224][ T1] R13: 00007f681fc203d6 R14: 0000000000000004 R15: 00007ffdc29680c8
[ 41.063027][ T1] ================================================================================
[ 41.105463][ T1] BUG: unable to handle page fault for address: ffff8885e379f7a0
[ 41.143820][ T1] #PF: supervisor write access in kernel mode
[ 41.171406][ T1] #PF: error_code(0x0002) - not-present page
[ 41.199505][ T1] PGD 656801067 P4D 656801067 PUD 87dd34067 PMD 87dc18067 PTE 800ffffa1c860060
[ 41.240827][ T1] Oops: 0002 [#1] SMP DEBUG_PAGEALLOC KASAN PTI
[ 41.270580][ T1] CPU: 4 PID: 1 Comm: systemd Not tainted 5.3.0-rc6-next-20190902 #1
[ 41.307810][ T1] Hardware name: HP ProLiant XL420 Gen9/ProLiant XL420 Gen9, BIOS U19 12/27/2015
[ 41.350005][ T1] RIP: 0010:__lock_acquire.isra.13+0x94/0x830
[ 41.377694][ T1] Code: 00 49 81 ec a0 b3 0b 88 48 b8 a3 8b 2e ba e8 a2 8b 2e 49 c1 fc 04 4c 0f af e0 4d 63 f4 49 81 fe ff 1f 00 00 0f 87 65 07 00 00 <65> 4a ff 04 f5 48 f4 01 00 49 8d 85 68 07 00 00 48 89 c7 48 89 45
[ 41.469635][ T1] RSP: 0018:ffff8882059bf8c8 EFLAGS: 00010082
[ 41.496954][ T1] RAX: ffff888486576040 RBX: 0000000000000000 RCX: ffffffff86758ea8
[ 41.534066][ T1] RDX: 1ffffffff0f872d0 RSI: dffffc0000000000 RDI: ffffffff87c39680
[ 41.572462][ T1] RBP: ffff8882059bf938 R08: fffffbfff0f872d1 R09: fffffbfff0f872d1
[ 41.610885][ T1] R10: fffffbfff0f872d0 R11: ffffffff87c39683 R12: ffffff52322b006b
[ 41.646423][ T1] R13: ffff888486576040 R14: 00000000322b006b R15: 0000000000000000
[ 41.683212][ T1] FS: 00007f682011f580(0000) GS:ffff888452200000(0000) knlGS:0000000000000000
[ 41.724248][ T1] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 41.754393][ T1] CR2: ffff8885e379f7a0 CR3: 000000031d4f8002 CR4: 00000000001606a0
[ 41.791003][ T1] Call Trace:
[ 41.805757][ T1] ? __lock_acquire.isra.13+0x430/0x830
[ 41.830925][ T1] lock_acquire+0x107/0x220
[ 41.851379][ T1] ? dput.part.7+0x1c5/0x500
[ 41.872014][ T1] ? dput.part.7+0x30/0x500
[ 41.893373][ T1] _raw_spin_lock+0x2f/0x40
[ 41.914209][ T1] ? dput.part.7+0x1c5/0x500
[ 41.935211][ T1] dput.part.7+0x1c5/0x500
[ 41.955220][ T1] ? path_get+0x35/0x40
[ 41.973805][ T1] dput+0xe/0x10
[ 41.989687][ T1] terminate_walk+0x1a4/0x1d0
[ 42.010467][ T1] path_lookupat+0x156/0x420
[ 42.031327][ T1] ? link_path_walk.part.6+0x870/0x870
[ 42.057145][ T1] ? create_object+0x4a2/0x540
[ 42.081409][ T1] ? lock_downgrade+0x390/0x390
[ 42.105227][ T1] ? do_raw_write_lock+0x118/0x1d0
[ 42.128399][ T1] ? do_raw_read_unlock+0x60/0x60
[ 42.151389][ T1] ? create_object+0x22a/0x540
[ 42.172907][ T1] filename_lookup.part.10+0x11b/0x1f0
[ 42.197856][ T1] ? do_renameat2+0x7e0/0x7e0
[ 42.218965][ T1] ? __virt_addr_valid+0xdd/0x170
[ 42.241783][ T1] ? __phys_addr_symbol+0x27/0x42
[ 42.264601][ T1] ? strncpy_from_user+0x100/0x280
[ 42.287801][ T1] ? getname_flags+0xa7/0x220
[ 42.309515][ T1] user_path_at_empty+0x3e/0x50
[ 42.331635][ T1] __x64_sys_name_to_handle_at+0x113/0x340
[ 42.358043][ T1] ? kmem_cache_free+0x128/0x430
[ 42.380461][ T1] ? vfs_dentry_acceptable+0x10/0x10
[ 42.404055][ T1] ? putname+0x6b/0x80
[ 42.421534][ T1] ? do_sys_open+0x172/0x2c0
[ 42.442060][ T1] ? _raw_spin_unlock_irq+0x27/0x40
[ 42.465673][ T1] ? task_work_run+0xa1/0x100
[ 42.486841][ T1] do_syscall_64+0xc7/0x646
[ 42.507390][ T1] ? syscall_return_slowpath+0x140/0x140
[ 42.533265][ T1] ? __do_page_fault+0x49f/0x630
[ 42.556144][ T1] entry_SYSCALL_64_after_hwframe+0x44/0xa9
[ 42.584451][ T1] RIP: 0033:0x7f681e45cf3e
[ 42.605521][ T1] Code: 48 8b 0d 4d ff 2b 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 49 89 ca b8 2f 01 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 1a ff 2b 00 f7 d8 64 89 01 48
[ 42.698743][ T1] RSP: 002b:00007ffdc2968038 EFLAGS: 00000202 ORIG_RAX: 000000000000012f
[ 42.737341][ T1] RAX: ffffffffffffffda RBX: 0000000000000080 RCX: 00007f681e45cf3e
[ 42.774197][ T1] RDX: 000055bdc6e995b0 RSI: 00007f681fc203d6 RDI: 0000000000000004
[ 42.809605][ T1] RBP: 000055bdc6e995b0 R08: 0000000000001000 R09: 0000000000000003
[ 42.845762][ T1] R10: 00007ffdc2968064 R11: 0000000000000202 R12: 000055bdc6e994e1
[ 42.882437][ T1] R13: 00007f681fc203d6 R14: 0000000000000004 R15: 00007ffdc29680c8
[ 42.918931][ T1] Modules linked in:
[ 42.935805][ T1] CR2: ffff8885e379f7a0
[ 42.954388][ T1] ---[ end trace cb4b0fb03ef6dea9 ]---
[ 42.979305][ T1] RIP: 0010:__lock_acquire.isra.13+0x94/0x830
[ 43.006969][ T1] Code: 00 49 81 ec a0 b3 0b 88 48 b8 a3 8b 2e ba e8 a2 8b 2e 49 c1 fc 04 4c 0f af e0 4d 63 f4 49 81 fe ff 1f 00 00 0f 87 65 07 00 00 <65> 4a ff 04 f5 48 f4 01 00 49 8d 85 68 07 00 00 48 89 c7 48 89 45
[ 43.100565][ T1] RSP: 0018:ffff8882059bf8c8 EFLAGS: 00010082
[ 43.130310][ T1] RAX: ffff888486576040 RBX: 0000000000000000 RCX: ffffffff86758ea8
[ 43.166789][ T1] RDX: 1ffffffff0f872d0 RSI: dffffc0000000000 RDI: ffffffff87c39680
[ 43.203516][ T1] RBP: ffff8882059bf938 R08: fffffbfff0f872d1 R09: fffffbfff0f872d1
[ 43.240056][ T1] R10: fffffbfff0f872d0 R11: ffffffff87c39683 R12: ffffff52322b006b
[ 43.276539][ T1] R13: ffff888486576040 R14: 00000000322b006b R15: 0000000000000000
[ 43.313154][ T1] FS: 00007f682011f580(0000) GS:ffff888452200000(0000) knlGS:0000000000000000
[ 43.353925][ T1] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 43.383756][ T1] CR2: ffff8885e379f7a0 CR3: 000000031d4f8002 CR4: 00000000001606a0
[ 43.420258][ T1] Kernel panic - not syncing: Fatal exception
[ 43.448058][ T1] Kernel Offset: 0x5600000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)
[ 43.501291][ T1] ---[ end Kernel panic - not syncing: Fatal exception ]---
On Mon, Sep 2, 2019 at 9:22 PM Qian Cai <[email protected]> wrote:
>
> The linux-next commit "fs/namei.c: keep track of nd->root refcount status” [1] causes boot panic on all
> architectures here on today’s linux-next (0902). Reverted it will fix the issue.
I believe I'm seeing the same issue with next-20190902 in a Linux VM
running on Hyper-V (next-20190830 is good).
git-bisect points to the same commit in linux-next:
e013ec23b823 ("fs/namei.c: keep track of nd->root refcount status")
I can reproduce the issue every time I reboot the system.
Thanks,
Dexuan
> From: Dexuan-Linux Cui <[email protected]>
> Sent: Monday, September 2, 2019 10:22 PM
> To: Qian Cai <[email protected]>
> Cc: Al Viro <[email protected]>; [email protected]; LKML
> <[email protected]>; Dexuan Cui <[email protected]>; Lili Deng
> (Wicresoft North America Ltd) <[email protected]>
> Subject: Re: "fs/namei.c: keep track of nd->root refcount status" causes boot
> panic
>
> On Mon, Sep 2, 2019 at 9:22 PM Qian Cai <[email protected]> wrote:
> >
> > The linux-next commit "fs/namei.c: keep track of nd->root refcount status”
> [1] causes boot panic on all
> > architectures here on today’s linux-next (0902). Reverted it will fix the issue.
>
> I believe I'm seeing the same issue with next-20190902 in a Linux VM
> running on Hyper-V (next-20190830 is good).
>
> git-bisect points to the same commit in linux-next:
> e013ec23b823 ("fs/namei.c: keep track of nd->root refcount status")
>
> I can reproduce the issue every time I reboot the system.
>
> Thanks,
> Dexuan
BTW, I tried the patch https://lkml.org/lkml/2019/8/31/158 -- not helpful at all.
FYI: this is my call-trace:
[ 16.843452] Run /init as init process
Loading, please wait...
starting version 239
[ 16.936476] ------------[ cut here ]------------
[ 16.937929] DEBUG_LOCKS_WARN_ON(!test_bit(class_idx, lock_classes_in_use))
[ 16.937929] WARNING: CPU: 10 PID: 366 at kernel/locking/lockdep.c:3850 __lock_acquire.isra.34+0x50c/0x560
[ 16.937929] Modules linked in:
[ 16.937929] CPU: 10 PID: 366 Comm: udevadm Not tainted 5.3.0-rc1+ #26
[ 16.937929] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS 090008 12/07/2018
[ 16.937929] RIP: 0010:__lock_acquire.isra.34+0x50c/0x560
[ 16.937929] Code: 00 85 c0 0f 84 72 fe ff ff 8b 1d af 5b 2b 01 85 db 0f 85 64 fe ff ff 48 c7 c6 08 97 07...
[ 16.937929] RSP: 0018:ffffc90003ff3c40 EFLAGS: 00010086
[ 16.937929] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
[ 16.937929] RDX: ffffffff810e3d63 RSI: 0000000000000001 RDI: ffffffff822628a0
[ 16.937929] RBP: 0000000000000000 R08: ffffffff82c0e420 R09: 0000000000039440
[ 16.937929] R10: 0000001209f646b6 R11: 000000000000016e R12: ffff888276440040
[ 16.937929] R13: 0000000000000000 R14: 0000000000000000 R15: ffff888276440818
[ 16.937929] FS: 00007f4ee2f0f8c0(0000) GS:ffff88827d700000(0000) knlGS:0000000000000000
[ 16.937929] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 16.937929] CR2: 000055dce7403000 CR3: 0000000276772003 CR4: 00000000003606e0
[ 16.937929] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 16.937929] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 16.937929] Call Trace:
[ 16.937929] lock_acquire+0xae/0x160
[ 16.937929] ? dput.part.34+0x164/0x380
[ 16.937929] ? dput.part.34+0x29/0x380
[ 16.937929] _raw_spin_lock+0x2c/0x40
[ 16.937929] ? dput.part.34+0x164/0x380
[ 16.937929] dput.part.34+0x164/0x380
[ 17.098529] terminate_walk+0xde/0x100
[ 17.098529] path_lookupat.isra.62+0xa3/0x220
[ 17.098529] filename_lookup.part.77+0xa0/0x170
[ 17.098529] ? kmem_cache_alloc+0x169/0x2a0
[ 17.098529] do_readlinkat+0x5d/0x110
[ 17.098529] __x64_sys_readlinkat+0x1a/0x20
[ 17.098529] do_syscall_64+0x5d/0x1c0
[ 17.098529] ? prepare_exit_to_usermode+0x7b/0xb0
[ 17.098529] entry_SYSCALL_64_after_hwframe+0x44/0xa9
[ 17.098529] RIP: 0033:0x7f4ee378da4a
[ 17.098529] Code: 48 8b 0d 49 84 0d 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 ...
[ 17.098529] RSP: 002b:00007fffbddb7968 EFLAGS: 00000202 ORIG_RAX: 000000000000010b
[ 17.098529] RAX: ffffffffffffffda RBX: 000055dce740b220 RCX: 00007f4ee378da4a
[ 17.098529] RDX: 000055dce740b220 RSI: 000055dce740b201 RDI: 0000000000000005
[ 17.098529] RBP: 0000000000000064 R08: 000055dce73fa010 R09: 0000000000000000
[ 17.098529] R10: 0000000000000063 R11: 0000000000000202 R12: 000055dce740b201
[ 17.098529] R13: 0000000000000005 R14: 00007fffbddb79f8 R15: 0000000000000063
[ 17.098529] ---[ end trace 6af6f6ebcc3937e8 ]---
It looks the aforementioned patch causes a memory corruption.
If I revert the patch, everything will be back to normal.
Thanks,
Dexuan
FYI: this is a slightly different call-trace. I believe this also show a memory corruption...
[ 17.848975] Run /init as init process
Loading, please wait...
starting version 239
[ 18.045913] BUG: unable to handle page fault for address: ffff8884bb8f4b98
[ 18.046012] #PF: supervisor write access in kernel mode
[ 18.046061] #PF: error_code(0x0002) - not-present page
[ 18.046124] PGD 3a02067 P4D 3a02067 PUD 505af0067 PMD 505913067 PTE 800ffffb4470b060
[ 18.046286] Oops: 0002 [#1] PREEMPT SMP DEBUG_PAGEALLOC PTI
[ 18.046355] CPU: 33 PID: 428 Comm: udevadm Not tainted 5.3.0-rc6-next-20190902+ #2
[ 18.046528] RIP: 0010:__lock_acquire+0xa8/0x16c0
[ 18.046590] Code: 48 89 c3 44 8b 4c 24 10 0f 84 13 04 00 00 48 81 eb 80 d7 a9 ...
[ 18.046782] RSP: 0018:ffffc900043ffc10 EFLAGS: 00010803
[ 18.046828] RAX: 2e8ba2e8ba2e8ba3 RBX: 466db384fa0cbc7a RCX: 0000000000000000
[ 18.046893] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff8884e3382458
[ 18.046959] RBP: ffff8884e289cc00 R08: 0000000000000001 R09: 0000000000000000
[ 18.047022] R10: 0000000000000001 R11: fffffffffa0cbc7a R12: 0000000000000000
[ 18.047101] R13: 0000000000000001 R14: 0000000000000000 R15: ffff8884e3382458
[ 18.047163] FS: 00007fd8183a88c0(0000) GS:ffff8884eb280000(0000) knlGS:0000000000000000
[ 18.047238] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 18.047287] CR2: ffff8884bb8f4b98 CR3: 00000004e3298005 CR4: 00000000003606e0
[ 18.047356] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 18.047424] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 18.047486] Call Trace:
[ 18.047543] lock_acquire+0xb5/0x1c0
[ 18.047639] _raw_spin_lock+0x2f/0x40
[ 18.047706] dput.part.33+0x1fb/0x4f0
[ 18.047736] terminate_walk+0x126/0x150
[ 18.047777] path_lookupat.isra.63+0xa3/0x220
[ 18.047826] filename_lookup.part.78+0xa0/0x170
[ 18.247277] do_readlinkat+0x5d/0x110
[ 18.247277] __x64_sys_readlinkat+0x1a/0x20
[ 18.247277] do_syscall_64+0x58/0x270
[ 18.247277] entry_SYSCALL_64_after_hwframe+0x49/0xbe
[ 18.247277] RIP: 0033:0x7fd818c26a4a
[ 18.247277] Code: 48 8b 0d 49 84 0d 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f ...
[ 18.247277] RSP: 002b:00007ffecb1bade8 EFLAGS: 00000202 ORIG_RAX: 000000000000010b
[ 18.247277] RAX: ffffffffffffffda RBX: 0000560d56bca220 RCX: 00007fd818c26a4a
[ 18.247277] RDX: 0000560d56bca220 RSI: 0000560d56bca201 RDI: 0000000000000005
[ 18.247277] RBP: 0000000000000064 R08: 0000560d56bb9010 R09: 0000000000000000
[ 18.247277] R10: 0000000000000063 R11: 0000000000000202 R12: 0000560d56bca201
[ 18.247277] R13: 0000000000000005 R14: 00007ffecb1bae78 R15: 0000000000000063
[ 18.247277] Modules linked in:
[ 18.247277] CR2: ffff8884bb8f4b98
Thanks,
-- Dexuan
On Tue, 3 Sep 2019 at 09:51, Qian Cai <[email protected]> wrote:
>
> The linux-next commit "fs/namei.c: keep track of nd->root refcount status” [1] causes boot panic on all
> architectures here on today’s linux-next (0902). Reverted it will fix the issue.
I have same problem and reverting this patch fixed the kernel crash.
>
> [1] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=e013ec23b8231cf7f95605cbb0e47aa0e3d047a4
>
FYI,
on x86_64 device I have noticed kernel bug [1].
[ 12.941007] Run /sbin/init as init process
[ 12.946381] random: fast init done
[ 13.023482] BUG: kernel NULL pointer dereference, address: 0000000000000235
[ 13.030444] #PF: supervisor read access in kernel mode
[ 13.035576] #PF: error_code(0x0000) - not-present page
[ 13.040725] PGD 0 P4D 0
[ 13.043263] Oops: 0000 [#1] SMP PTI
[ 13.046755] CPU: 2 PID: 1 Comm: systemd Not tainted
5.3.0-rc6-next-20190902 #1
[ 13.053966] Hardware name: Supermicro SYS-5019S-ML/X11SSH-F, BIOS
2.0b 07/27/2017
[ 13.061438] RIP: 0010:dput+0x72/0x4a0
[ 13.065101] Code: 68 0d 5f 41 56 31 d2 45 31 c9 45 31 c0 31 f6 b9
02 00 00 00 48 c7 c7 e0 dd 66 a2 e8 48 6c e1 ff e8 e3 9f e3 ff 85 c0
5a 75 76 <f6> 03 08 4c 8d a3 80 00 00 00 4c 89 e7 0f 85 7b 01 00 00 e8
16 66
[ 13.083838] RSP: 0018:ffffb16100027c00 EFLAGS: 00010202
[ 13.089055] RAX: 0000000000000001 RBX: 0000000000000235 RCX: 00000000fff78e19
[ 13.096180] RDX: ffffffffa0f3f630 RSI: 00000000ffffffff RDI: 0000000000000000
[ 13.103301] RBP: ffffb16100027c30 R08: 0000000000000000 R09: 0000000000000000
[ 13.110425] R10: 0000000000000000 R11: 0000000000000000 R12: ffffb16100027e30
[ 13.117550] R13: ffffffffa23a557f R14: ffffffffa0f3f630 R15: ffffb16100027e30
[ 13.124685] FS: 00007f2541dc4840(0000) GS:ffff9983dfb00000(0000)
knlGS:0000000000000000
[ 13.132767] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 13.138506] CR2: 0000000000000235 CR3: 000000045a2fe003 CR4: 00000000003606e0
[ 13.145630] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 13.152752] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 13.159875] Call Trace:
[ 13.162323] terminate_walk+0x104/0x160
[ 13.166162] path_lookupat+0xa4/0x210
[ 13.169828] filename_lookup+0xb6/0x180
[ 13.173682] ? fs_reclaim_release.part.107+0x5/0x30
[ 13.178581] ? getname_flags+0x4b/0x1e0
[ 13.182419] ? rcu_read_lock_sched_held+0x4f/0x80
[ 13.187116] ? kmem_cache_alloc+0x290/0x2c0
[ 13.191293] ? __might_fault+0x85/0x90
[ 13.195037] user_path_at_empty+0x36/0x40
[ 13.199041] ? user_path_at_empty+0x36/0x40
[ 13.203217] vfs_statx+0x76/0xe0
[ 13.206442] __do_sys_newfstatat+0x35/0x70
[ 13.210535] ? entry_SYSCALL_64_after_hwframe+0x3e/0xbe
[ 13.215758] ? trace_hardirqs_off_caller+0x22/0xf0
[ 13.220542] ? do_syscall_64+0x17/0x1c0
[ 13.224374] ? lockdep_hardirqs_on+0xf6/0x190
[ 13.228730] ? do_syscall_64+0x17/0x1c0
[ 13.232564] ? trace_hardirqs_on+0x4c/0x100
[ 13.236747] __x64_sys_newfstatat+0x1e/0x20
[ 13.240925] do_syscall_64+0x55/0x1c0
[ 13.244582] entry_SYSCALL_64_after_hwframe+0x49/0xbe
[ 13.249625] RIP: 0033:0x7f25405bba09
[ 13.253196] Code: 64 c7 00 16 00 00 00 b8 ff ff ff ff c3 0f 1f 40
00 89 f0 48 89 d6 83 ff 01 77 36 89 c7 45 89 c2 48 89 ca b8 06 01 00
00 0f 05 <48> 3d 00 f0 ff ff 77 07 c3 66 0f 1f 44 00 00 48 8b 15 59 94
2c 00
[ 13.271934] RSP: 002b:00007ffd6722dfc8 EFLAGS: 00000246 ORIG_RAX:
0000000000000106
[ 13.279490] RAX: ffffffffffffffda RBX: 0000000000000001 RCX: 00007f25405bba09
[ 13.286614] RDX: 00007ffd6722e090 RSI: 00007f25418c06d6 RDI: 0000000000000004
[ 13.293738] RBP: 0000000000000004 R08: 0000000000001000 R09: 0000000000000001
[ 13.300860] R10: 0000000000001000 R11: 0000000000000246 R12: 000055bd9f667281
[ 13.307984] R13: 0000000000000400 R14: 00007ffd6722e518 R15: 0000000000000001
[ 13.315111] Modules linked in:
[ 13.318170] CR2: 0000000000000235
[ 13.321489] ---[ end trace 2f1042f3cbf26726 ]---
[ 13.326107] RIP: 0010:dput+0x72/0x4a0
[ 13.329763] Code: 68 0d 5f 41 56 31 d2 45 31 c9 45 31 c0 31 f6 b9
02 00 00 00 48 c7 c7 e0 dd 66 a2 e8 48 6c e1 ff e8 e3 9f e3 ff 85 c0
5a 75 76 <f6> 03 08 4c 8d a3 80 00 00 00 4c 89 e7 0f 85 7b 01 00 00 e8
16 66
[ 13.348499] RSP: 0018:ffffb16100027c00 EFLAGS: 00010202
[ 13.353740] RAX: 0000000000000001 RBX: 0000000000000235 RCX: 00000000fff78e19
[ 13.360865] RDX: ffffffffa0f3f630 RSI: 00000000ffffffff RDI: 0000000000000000
[ 13.367990] RBP: ffffb16100027c30 R08: 0000000000000000 R09: 0000000000000000
[ 13.375115] R10: 0000000000000000 R11: 0000000000000000 R12: ffffb16100027e30
[ 13.382238] R13: ffffffffa23a557f R14: ffffffffa0f3f630 R15: ffffb16100027e30
[ 13.389361] FS: 00007f2541dc4840(0000) GS:ffff9983dfb00000(0000)
knlGS:0000000000000000
[ 13.397439] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 13.403176] CR2: 0000000000000235 CR3: 000000045a2fe003 CR4: 00000000003606e0
[ 13.410301] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 13.417422] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 13.424549] BUG: sleeping function called from invalid context at
/usr/src/kernel/include/linux/percpu-rwsem.h:38
[ 13.434793] in_atomic(): 1, irqs_disabled(): 1, pid: 1, name: systemd
[ 13.441222] INFO: lockdep is turned off.
[ 13.445138] irq event stamp: 1373108
[ 13.448740] hardirqs last enabled at (1373107):
[<ffffffffa0f3216b>] path_init+0x21b/0x520
[ 13.457083] hardirqs last disabled at (1373108):
[<ffffffffa0c01c9a>] trace_hardirqs_off_thunk+0x1a/0x20
[ 13.466555] softirqs last enabled at (1373040):
[<ffffffffa16ea835>] release_sock+0x85/0xb0
[ 13.474985] softirqs last disabled at (1373038):
[<ffffffffa16ea7ce>] release_sock+0x1e/0xb0
[ 13.483409] CPU: 2 PID: 1 Comm: systemd Tainted: G D
5.3.0-rc6-next-20190902 #1
[ 13.492007] Hardware name: Supermicro SYS-5019S-ML/X11SSH-F, BIOS
2.0b 07/27/2017
[ 13.499478] Call Trace:
[ 13.501923] dump_stack+0x70/0xa5
[ 13.505243] ___might_sleep+0x152/0x240
[ 13.509080] __might_sleep+0x4a/0x80
[ 13.512679] exit_signals+0x33/0x2e0
[ 13.516273] do_exit+0xb1/0xce0
[ 13.519410] ? do_syscall_64+0x17/0x1c0
[ 13.523240] ? trace_hardirqs_on+0x4c/0x100
[ 13.527419] rewind_stack_do_exit+0x17/0x20
[ 13.531595] RIP: 0033:0x7f25405bba09
[ 13.535166] Code: 64 c7 00 16 00 00 00 b8 ff ff ff ff c3 0f 1f 40
00 89 f0 48 89 d6 83 ff 01 77 36 89 c7 45 89 c2 48 89 ca b8 06 01 00
00 0f 05 <48> 3d 00 f0 ff ff 77 07 c3 66 0f 1f 44 00 00 48 8b 15 59 94
2c 00
[ 13.553900] RSP: 002b:00007ffd6722dfc8 EFLAGS: 00000246 ORIG_RAX:
0000000000000106
[ 13.561459] RAX: ffffffffffffffda RBX: 0000000000000001 RCX: 00007f25405bba09
[ 13.568581] RDX: 00007ffd6722e090 RSI: 00007f25418c06d6 RDI: 0000000000000004
[ 13.575735] RBP: 0000000000000004 R08: 0000000000001000 R09: 0000000000000001
[ 13.582865] R10: 0000000000001000 R11: 0000000000000246 R12: 000055bd9f667281
[ 13.589990] R13: 0000000000000400 R14: 00007ffd6722e518 R15: 0000000000000001
[ 13.597146] note: systemd[1] exited with preempt_count 1
[ 13.602674] Kernel panic - not syncing: Attempted to kill init!
exitcode=0x00000009
[ 13.610402] Kernel Offset: 0x1fc00000 from 0xffffffff81000000
(relocation range: 0xffffffff80000000-0xffffffffbfffffff)
Full test log,
[1] https://lkft.validation.linaro.org/scheduler/job/896370#L970
Best regards
Naresh Kamboju
> On 03-Sep-2019, at 1:43 PM, Naresh Kamboju <[email protected]> wrote:
>
> On Tue, 3 Sep 2019 at 09:51, Qian Cai <[email protected]> wrote:
>>
>> The linux-next commit "fs/namei.c: keep track of nd->root refcount status” [1] causes boot panic on all
>> architectures here on today’s linux-next (0902). Reverted it will fix the issue.
Similar problem is seen on ppc64le arch.
[ 0.493235] BUG: Kernel NULL pointer dereference at 0x00000cc0
[ 0.493241] Faulting instruction address: 0xc0000000003e9260
[ 0.493245] Oops: Kernel access of bad area, sig: 11 [#1]
[ 0.493250] LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA pSeries
[ 0.493254] Modules linked in:
[ 0.493260] CPU: 1 PID: 1 Comm: systemd Not tainted 5.3.0-rc6-next-20190902-autotest-autotest #1
[ 0.493265] NIP: c0000000003e9260 LR: c0000000003e925c CTR: 00000000000001fc
[ 0.493270] REGS: c0000004f85038c0 TRAP: 0300 Not tainted (5.3.0-rc6-next-20190902-autotest-autotest)
[ 0.493274] MSR: 8000000000009033 <SF,EE,ME,IR,DR,RI,LE> CR: 28002842 XER: 00000000
[ 0.493282] CFAR: c00000000000df44 DAR: 0000000000000cc0 DSISR: 40000000 IRQMASK: 0
[ 0.493282] GPR00: c0000000003e925c c0000004f8503b50 c000000001458e00 0000000000000000
[ 0.493282] GPR04: c0000004f8503ce0 0000000000000000 0000000000000064 0000000000000000
[ 0.493282] GPR08: 0000000000000000 c000000000ff7a65 0000000000000000 c0000004f70100c0
[ 0.493282] GPR12: 0000000000002200 c00000001ecaee00 0000000000000000 0000000000000000
[ 0.493282] GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
[ 0.493282] GPR20: 0000000000077624 0000000000000000 0000000000000000 00007fffa1099e20
[ 0.493282] GPR24: 0000000000000000 000000010f9572a4 0000000000000000 0000000000000001
[ 0.493282] GPR28: 0000000000080060 0000000000080040 0000000000000000 0000000000000cc0
[ 0.493327] NIP [c0000000003e9260] dput+0x70/0x4e0
[ 0.493332] LR [c0000000003e925c] dput+0x6c/0x4e0
[ 0.493334] Call Trace:
[ 0.493338] [c0000004f8503b50] [c0000000003e925c] dput+0x6c/0x4e0 (unreliable)
[ 0.493345] [c0000004f8503bc0] [c0000000003d5da4] terminate_walk+0x104/0x130
[ 0.493351] [c0000004f8503c00] [c0000000003da9d8] path_lookupat+0xe8/0x2b0
[ 0.493356] [c0000004f8503c70] [c0000000003dd668] filename_lookup+0xa8/0x1c0
[ 0.493362] [c0000004f8503da0] [c00000000046c4d4] sys_name_to_handle_at+0xe4/0x2d0
[ 0.493369] [c0000004f8503e20] [c00000000000b378] system_call+0x5c/0x68
[ 0.493373] Instruction dump:
[ 0.493376] f8010010 f821ff91 7c7f1b79 41820050 3d200008 3b600001 613c0060 613d0040
[ 0.493383] 3b400000 3b000000 48707b11 60000000 <813f0000> 3bdf0058 7fc3f378 71390008
[ 0.493391] ---[ end trace 7701d360352c734d ]—
Reverting the mentioned commit allows next to boot.
Thanks
-Sachin
On Tue, Sep 03, 2019 at 12:21:36AM -0400, Qian Cai wrote:
> The linux-next commit "fs/namei.c: keep track of nd->root refcount status” [1] causes boot panic on all
> architectures here on today’s linux-next (0902). Reverted it will fix the issue.
<swearing>
OK, I see what's going on. Incremental to be folded in:
diff --git a/include/linux/namei.h b/include/linux/namei.h
index 20ce2f917ef4..2ed0942a67f8 100644
--- a/include/linux/namei.h
+++ b/include/linux/namei.h
@@ -20,8 +20,8 @@ enum {LAST_NORM, LAST_ROOT, LAST_DOT, LAST_DOTDOT, LAST_BIND};
#define LOOKUP_FOLLOW 0x0001 /* follow links at the end */
#define LOOKUP_DIRECTORY 0x0002 /* require a directory */
#define LOOKUP_AUTOMOUNT 0x0004 /* force terminal automount */
-#define LOOKUP_EMPTY 0x4000 /* accept empty path [user_... only] */
-#define LOOKUP_DOWN 0x8000 /* follow mounts in the starting point */
+#define LOOKUP_EMPTY 0x8000 /* accept empty path [user_... only] */
+#define LOOKUP_DOWN 0x10000 /* follow mounts in the starting point */
#define LOOKUP_REVAL 0x0020 /* tell ->d_revalidate() to trust no cache */
#define LOOKUP_RCU 0x0040 /* RCU pathwalk mode; semi-internal */
On Tue, Sep 03, 2019 at 01:37:19PM +0100, Al Viro wrote:
> On Tue, Sep 03, 2019 at 12:21:36AM -0400, Qian Cai wrote:
> > The linux-next commit "fs/namei.c: keep track of nd->root refcount status” [1] causes boot panic on all
> > architectures here on today’s linux-next (0902). Reverted it will fix the issue.
>
> <swearing>
>
> OK, I see what's going on. Incremental to be folded in:
>
> diff --git a/include/linux/namei.h b/include/linux/namei.h
> index 20ce2f917ef4..2ed0942a67f8 100644
> --- a/include/linux/namei.h
> +++ b/include/linux/namei.h
> @@ -20,8 +20,8 @@ enum {LAST_NORM, LAST_ROOT, LAST_DOT, LAST_DOTDOT, LAST_BIND};
> #define LOOKUP_FOLLOW 0x0001 /* follow links at the end */
> #define LOOKUP_DIRECTORY 0x0002 /* require a directory */
> #define LOOKUP_AUTOMOUNT 0x0004 /* force terminal automount */
> -#define LOOKUP_EMPTY 0x4000 /* accept empty path [user_... only] */
> -#define LOOKUP_DOWN 0x8000 /* follow mounts in the starting point */
> +#define LOOKUP_EMPTY 0x8000 /* accept empty path [user_... only] */
> +#define LOOKUP_DOWN 0x10000 /* follow mounts in the starting point */
>
> #define LOOKUP_REVAL 0x0020 /* tell ->d_revalidate() to trust no cache */
> #define LOOKUP_RCU 0x0040 /* RCU pathwalk mode; semi-internal */
Any chance to keep these ordered numerically to avoid someone else
introdcing this kind of bug again later on?
On Tue, Sep 03, 2019 at 01:37:19PM +0100, Al Viro wrote:
> On Tue, Sep 03, 2019 at 12:21:36AM -0400, Qian Cai wrote:
> > The linux-next commit "fs/namei.c: keep track of nd->root refcount status” [1] causes boot panic on all
> > architectures here on today’s linux-next (0902). Reverted it will fix the issue.
>
> <swearing>
>
> OK, I see what's going on. Incremental to be folded in:
... or, better yet,
diff --git a/include/linux/namei.h b/include/linux/namei.h
index 20ce2f917ef4..397a08ade6a2 100644
--- a/include/linux/namei.h
+++ b/include/linux/namei.h
@@ -37,7 +37,7 @@ enum {LAST_NORM, LAST_ROOT, LAST_DOT, LAST_DOTDOT, LAST_BIND};
#define LOOKUP_NO_REVAL 0x0080
#define LOOKUP_JUMPED 0x1000
#define LOOKUP_ROOT 0x2000
-#define LOOKUP_ROOT_GRABBED 0x4000
+#define LOOKUP_ROOT_GRABBED 0x0008
extern int path_pts(struct path *path);
to avoid breaking out-of-tree stuff for now good reason.
Folded and pushed out.
On Tue, Sep 03, 2019 at 06:04:56AM -0700, Christoph Hellwig wrote:
> On Tue, Sep 03, 2019 at 01:37:19PM +0100, Al Viro wrote:
> > On Tue, Sep 03, 2019 at 12:21:36AM -0400, Qian Cai wrote:
> > > The linux-next commit "fs/namei.c: keep track of nd->root refcount status” [1] causes boot panic on all
> > > architectures here on today’s linux-next (0902). Reverted it will fix the issue.
> >
> > <swearing>
> >
> > OK, I see what's going on. Incremental to be folded in:
> >
> > diff --git a/include/linux/namei.h b/include/linux/namei.h
> > index 20ce2f917ef4..2ed0942a67f8 100644
> > --- a/include/linux/namei.h
> > +++ b/include/linux/namei.h
> > @@ -20,8 +20,8 @@ enum {LAST_NORM, LAST_ROOT, LAST_DOT, LAST_DOTDOT, LAST_BIND};
> > #define LOOKUP_FOLLOW 0x0001 /* follow links at the end */
> > #define LOOKUP_DIRECTORY 0x0002 /* require a directory */
> > #define LOOKUP_AUTOMOUNT 0x0004 /* force terminal automount */
> > -#define LOOKUP_EMPTY 0x4000 /* accept empty path [user_... only] */
> > -#define LOOKUP_DOWN 0x8000 /* follow mounts in the starting point */
> > +#define LOOKUP_EMPTY 0x8000 /* accept empty path [user_... only] */
> > +#define LOOKUP_DOWN 0x10000 /* follow mounts in the starting point */
> >
> > #define LOOKUP_REVAL 0x0020 /* tell ->d_revalidate() to trust no cache */
> > #define LOOKUP_RCU 0x0040 /* RCU pathwalk mode; semi-internal */
>
> Any chance to keep these ordered numerically to avoid someone else
> introdcing this kind of bug again later on?
Not sure what would be the best way to do it... I don't mind breaking
the out-of-tree modules, whatever their license is; what I would rather
avoid is _quiet_ breaking of such.
On Tue, Sep 03, 2019 at 02:48:32PM +0100, Al Viro wrote:
> Not sure what would be the best way to do it... I don't mind breaking
> the out-of-tree modules, whatever their license is; what I would rather
> avoid is _quiet_ breaking of such.
Any out of tree module running against an upstream kernel will need
a recompile for a new version anyway. So I would not worry about it
at all.
Hi
On Tue, 3 Sep 2019 at 19:01, Al Viro <[email protected]> wrote:
>
> On Tue, Sep 03, 2019 at 01:37:19PM +0100, Al Viro wrote:
> > On Tue, Sep 03, 2019 at 12:21:36AM -0400, Qian Cai wrote:
> > > The linux-next commit "fs/namei.c: keep track of nd->root refcount status” [1] causes boot panic on all
> > > architectures here on today’s linux-next (0902). Reverted it will fix the issue.
> >
> > <swearing>
> >
> > OK, I see what's going on. Incremental to be folded in:
>
> ... or, better yet,
>
> diff --git a/include/linux/namei.h b/include/linux/namei.h
> index 20ce2f917ef4..397a08ade6a2 100644
> --- a/include/linux/namei.h
> +++ b/include/linux/namei.h
> @@ -37,7 +37,7 @@ enum {LAST_NORM, LAST_ROOT, LAST_DOT, LAST_DOTDOT, LAST_BIND};
> #define LOOKUP_NO_REVAL 0x0080
> #define LOOKUP_JUMPED 0x1000
> #define LOOKUP_ROOT 0x2000
> -#define LOOKUP_ROOT_GRABBED 0x4000
> +#define LOOKUP_ROOT_GRABBED 0x0008
>
> extern int path_pts(struct path *path);
>
I have applied above patch and tested on arm64 juno-r2 and boot pass [1].
Thanks for the fix patch.
>
> to avoid breaking out-of-tree stuff for now good reason.
> Folded and pushed out.
[1] https://lkft.validation.linaro.org/scheduler/job/898187#L511
- Naresh
On Tue, Sep 03, 2019 at 06:50:24AM -0700, Christoph Hellwig wrote:
> On Tue, Sep 03, 2019 at 02:48:32PM +0100, Al Viro wrote:
> > Not sure what would be the best way to do it... I don't mind breaking
> > the out-of-tree modules, whatever their license is; what I would rather
> > avoid is _quiet_ breaking of such.
>
> Any out of tree module running against an upstream kernel will need
> a recompile for a new version anyway. So I would not worry about it
> at all.
There's much nastier situation than "new upstream kernel released,
need to rebuild" - it's bisect in mainline trying to locate something...
On Tue, Sep 03, 2019 at 02:53:54PM +0100, Al Viro wrote:
> On Tue, Sep 03, 2019 at 06:50:24AM -0700, Christoph Hellwig wrote:
> > On Tue, Sep 03, 2019 at 02:48:32PM +0100, Al Viro wrote:
> > > Not sure what would be the best way to do it... I don't mind breaking
> > > the out-of-tree modules, whatever their license is; what I would rather
> > > avoid is _quiet_ breaking of such.
> >
> > Any out of tree module running against an upstream kernel will need
> > a recompile for a new version anyway. So I would not worry about it
> > at all.
>
> There's much nastier situation than "new upstream kernel released,
> need to rebuild" - it's bisect in mainline trying to locate something...
I really don't get the point. And it's not like we've card about
this anywhere else. And jumping wildly around with the numeric values
for constants will lead to bugs like the one you added and fixed again
and again.
On Tue, Sep 03, 2019 at 08:39:30AM -0700, Christoph Hellwig wrote:
> > There's much nastier situation than "new upstream kernel released,
> > need to rebuild" - it's bisect in mainline trying to locate something...
>
> I really don't get the point. And it's not like we've card about
> this anywhere else. And jumping wildly around with the numeric values
> for constants will lead to bugs like the one you added and fixed again
> and again.
The thing is, there are several groups - it's not as if all additions
were guaranteed to be at the end. So either we play with renumbering
again and again, or we are back to the square one...
Is there any common trick that would allow to verify the lack of duplicates
at the build time?
Or we can reorder the list by constant value, with no grouping visible
anywhere...
On Tue, Sep 03, 2019 at 06:50:24AM -0700, Christoph Hellwig wrote:
> On Tue, Sep 03, 2019 at 02:48:32PM +0100, Al Viro wrote:
> > Not sure what would be the best way to do it... I don't mind breaking
> > the out-of-tree modules, whatever their license is; what I would rather
> > avoid is _quiet_ breaking of such.
>
> Any out of tree module running against an upstream kernel will need
> a recompile for a new version anyway. So I would not worry about it
> at all.
I'm really confused. What out-of-tree module are people needing to
use when doing linux-next testing? That seems like a recipe for disaster...
- Ted
On Tue, Sep 03, 2019 at 06:56:10PM +0100, Al Viro wrote:
> On Tue, Sep 03, 2019 at 08:39:30AM -0700, Christoph Hellwig wrote:
>
> > > There's much nastier situation than "new upstream kernel released,
> > > need to rebuild" - it's bisect in mainline trying to locate something...
> >
> > I really don't get the point. And it's not like we've card about
> > this anywhere else. And jumping wildly around with the numeric values
> > for constants will lead to bugs like the one you added and fixed again
> > and again.
>
> The thing is, there are several groups - it's not as if all additions
> were guaranteed to be at the end. So either we play with renumbering
> again and again, or we are back to the square one...
>
> Is there any common trick that would allow to verify the lack of duplicates
> at the build time?
>
> Or we can reorder the list by constant value, with no grouping visible
> anywhere...
Here is what I'd do. No validation of duplicates, but the 1 << bit
notation makes them very easy to spot:
diff --git a/include/linux/namei.h b/include/linux/namei.h
index 397a08ade6a2..a9536f90936c 100644
--- a/include/linux/namei.h
+++ b/include/linux/namei.h
@@ -16,28 +16,47 @@ enum { MAX_NESTED_LINKS = 8 };
*/
enum {LAST_NORM, LAST_ROOT, LAST_DOT, LAST_DOTDOT, LAST_BIND};
-/* pathwalk mode */
-#define LOOKUP_FOLLOW 0x0001 /* follow links at the end */
-#define LOOKUP_DIRECTORY 0x0002 /* require a directory */
-#define LOOKUP_AUTOMOUNT 0x0004 /* force terminal automount */
-#define LOOKUP_EMPTY 0x4000 /* accept empty path [user_... only] */
-#define LOOKUP_DOWN 0x8000 /* follow mounts in the starting point */
-
-#define LOOKUP_REVAL 0x0020 /* tell ->d_revalidate() to trust no cache */
-#define LOOKUP_RCU 0x0040 /* RCU pathwalk mode; semi-internal */
-
-/* These tell filesystem methods that we are dealing with the final component... */
-#define LOOKUP_OPEN 0x0100 /* ... in open */
-#define LOOKUP_CREATE 0x0200 /* ... in object creation */
-#define LOOKUP_EXCL 0x0400 /* ... in exclusive creation */
-#define LOOKUP_RENAME_TARGET 0x0800 /* ... in destination of rename() */
-
-/* internal use only */
-#define LOOKUP_PARENT 0x0010
-#define LOOKUP_NO_REVAL 0x0080
-#define LOOKUP_JUMPED 0x1000
-#define LOOKUP_ROOT 0x2000
-#define LOOKUP_ROOT_GRABBED 0x0008
+/*
+ * Pathwalk mode:
+ */
+
+/* follow links at the end */
+#define LOOKUP_FOLLOW (1 << 0)
+/* require a directory */
+#define LOOKUP_DIRECTORY (1 << 1)
+/* force terminal automount */
+#define LOOKUP_AUTOMOUNT (1 << 2)
+/* accept empty path [user_... only] */
+#define LOOKUP_EMPTY (1 << 3)
+/* follow mounts in the starting point */
+#define LOOKUP_DOWN (1 << 4)
+/* tell ->d_revalidate() to trust no cache */
+#define LOOKUP_REVAL (1 << 5)
+/* RCU pathwalk mode; semi-internal */
+#define LOOKUP_RCU (1 << 6)
+
+
+/*
+ * These tell filesystem methods that we are dealing with the final component:
+ */
+
+/* ... in open */
+#define LOOKUP_OPEN (1 << 10)
+/* ... in object creation */
+#define LOOKUP_CREATE (1 << 11)
+/* ... in exclusive creation */
+#define LOOKUP_EXCL (1 << 12)
+/* ... in destination of rename() */
+#define LOOKUP_RENAME_TARGET (1 << 13)
+
+/*
+ * Internal use only:
+ */
+#define LOOKUP_PARENT (1 << 20)
+#define LOOKUP_NO_REVAL (1 << 21)
+#define LOOKUP_JUMPED (1 << 22)
+#define LOOKUP_ROOT (1 << 23)
+#define LOOKUP_ROOT_GRABBED (1 << 24)
extern int path_pts(struct path *path);
Hi Christoph and Al Viro,
Linux next 20190904 boot PASS now.
May i know which patch fixed this problem ?
- Naresh
On Tue, Sep 03, 2019 at 06:56:10PM +0100, Al Viro wrote:
> On Tue, Sep 03, 2019 at 08:39:30AM -0700, Christoph Hellwig wrote:
>
> > > There's much nastier situation than "new upstream kernel released,
> > > need to rebuild" - it's bisect in mainline trying to locate something...
> >
> > I really don't get the point. And it's not like we've card about
> > this anywhere else. And jumping wildly around with the numeric values
> > for constants will lead to bugs like the one you added and fixed again
> > and again.
>
> The thing is, there are several groups - it's not as if all additions
> were guaranteed to be at the end. So either we play with renumbering
> again and again, or we are back to the square one...
>
> Is there any common trick that would allow to verify the lack of duplicates
> at the build time?
What about:
static_assert(
(LOOKUP_FOLLOW^LOOKUP_DIRECTORY^LOOKUP_AUTOMOUNT^LOOKUP_EMPTY^LOOKUP_DOWN^
LOOKUP_REVAL^LOOKUP_RCU^
LOOKUP_OPEN^LOOKUP_CREATE^LOOKUP_EXCL^LOOKUP_RENAME_TARGET^
LOOKUP_PARENT^LOOKUP_NO_REVAL^LOOKUP_JUMPED^LOOKUP_ROOT^LOOKUP_ROOT_GRABBED)
==
(LOOKUP_FOLLOW|LOOKUP_DIRECTORY|LOOKUP_AUTOMOUNT|LOOKUP_EMPTY|LOOKUP_DOWN|
LOOKUP_REVAL|LOOKUP_RCU|
LOOKUP_OPEN|LOOKUP_CREATE|LOOKUP_EXCL|LOOKUP_RENAME_TARGET|
LOOKUP_PARENT|LOOKUP_NO_REVAL|LOOKUP_JUMPED|LOOKUP_ROOT|LOOKUP_ROOT_GRABBED)
, "duplicated LOOKUP_* constant");
?
- Kevin
On Thu, Sep 05, 2019 at 02:43:12PM +0530, Naresh Kamboju wrote:
> Hi Christoph and Al Viro,
>
> Linux next 20190904 boot PASS now.
> May i know which patch fixed this problem ?
commit 84a2bd39405ffd5fa6d6d77e408c5b9210da98de
Author: Al Viro <[email protected]>
Date: Tue Jul 16 21:20:17 2019 -0400
fs/namei.c: keep track of nd->root refcount status
And I'm not going to abstain from folding the trivial fix
(LOOKUP_ROOT_GRABBED had been given the same value as LOOKUP_EMPTY)
into the commit. Sorry. I don't know how to tell CI systems out
there about cases like that ("earlier version of this commit used
to have a bug, fix folded in"). Something like
Supersedes: <list of sha1>
might or might not be useful for tracking; not sure.