Merge pull request #1 from torvalds/master #275

nanszy · 2016-04-13T11:12:22Z

update

lkl: add dhcp client option

If a hashtab is accessed in both NMI and non-NMI contexts, it may cause deadlock in bucket->lock. LOCKDEP NMI warning highlighted this issue: ./test_progs -t stacktrace [ 74.828970] [ 74.828971] ================================ [ 74.828972] WARNING: inconsistent lock state [ 74.828973] 5.9.0-rc8+ torvalds#275 Not tainted [ 74.828974] -------------------------------- [ 74.828975] inconsistent {INITIAL USE} -> {IN-NMI} usage. [ 74.828976] taskset/1174 [HC2[2]:SC0[0]:HE0:SE1] takes: [ 74.828977] ffffc90000ee96b0 (&htab->buckets[i].raw_lock){....}-{2:2}, at: htab_map_update_elem+0x271/0x5a0 [ 74.828981] {INITIAL USE} state was registered at: [ 74.828982] lock_acquire+0x137/0x510 [ 74.828983] _raw_spin_lock_irqsave+0x43/0x90 [ 74.828984] htab_map_update_elem+0x271/0x5a0 [ 74.828984] 0xffffffffa0040b34 [ 74.828985] trace_call_bpf+0x159/0x310 [ 74.828986] perf_trace_run_bpf_submit+0x5f/0xd0 [ 74.828987] perf_trace_urandom_read+0x1be/0x220 [ 74.828988] urandom_read_nowarn.isra.0+0x26f/0x380 [ 74.828989] vfs_read+0xf8/0x280 [ 74.828989] ksys_read+0xc9/0x160 [ 74.828990] do_syscall_64+0x33/0x40 [ 74.828991] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 74.828992] irq event stamp: 1766 [ 74.828993] hardirqs last enabled at (1765): [<ffffffff82800ace>] asm_exc_page_fault+0x1e/0x30 [ 74.828994] hardirqs last disabled at (1766): [<ffffffff8267df87>] irqentry_enter+0x37/0x60 [ 74.828995] softirqs last enabled at (856): [<ffffffff81043e7c>] fpu__clear+0xac/0x120 [ 74.828996] softirqs last disabled at (854): [<ffffffff81043df0>] fpu__clear+0x20/0x120 [ 74.828997] [ 74.828998] other info that might help us debug this: [ 74.828999] Possible unsafe locking scenario: [ 74.828999] [ 74.829000] CPU0 [ 74.829001] ---- [ 74.829001] lock(&htab->buckets[i].raw_lock); [ 74.829003] <Interrupt> [ 74.829004] lock(&htab->buckets[i].raw_lock); [ 74.829006] [ 74.829006] *** DEADLOCK *** [ 74.829007] [ 74.829008] 1 lock held by taskset/1174: [ 74.829008] #0: ffff8883ec3fd020 (&cpuctx_lock){-...}-{2:2}, at: perf_event_task_tick+0x101/0x650 [ 74.829012] [ 74.829013] stack backtrace: [ 74.829014] CPU: 0 PID: 1174 Comm: taskset Not tainted 5.9.0-rc8+ torvalds#275 [ 74.829015] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014 [ 74.829016] Call Trace: [ 74.829016] <NMI> [ 74.829017] dump_stack+0x9a/0xd0 [ 74.829018] lock_acquire+0x461/0x510 [ 74.829019] ? lock_release+0x6b0/0x6b0 [ 74.829020] ? stack_map_get_build_id_offset+0x45e/0x800 [ 74.829021] ? htab_map_update_elem+0x271/0x5a0 [ 74.829022] ? rcu_read_lock_held_common+0x1a/0x50 [ 74.829022] ? rcu_read_lock_held+0x5f/0xb0 [ 74.829023] _raw_spin_lock_irqsave+0x43/0x90 [ 74.829024] ? htab_map_update_elem+0x271/0x5a0 [ 74.829025] htab_map_update_elem+0x271/0x5a0 [ 74.829026] bpf_prog_1fd9e30e1438d3c5_oncpu+0x9c/0xe88 [ 74.829027] bpf_overflow_handler+0x127/0x320 [ 74.829028] ? perf_event_text_poke_output+0x4d0/0x4d0 [ 74.829029] ? sched_clock_cpu+0x18/0x130 [ 74.829030] __perf_event_overflow+0xae/0x190 [ 74.829030] handle_pmi_common+0x34c/0x470 [ 74.829031] ? intel_pmu_save_and_restart+0x90/0x90 [ 74.829032] ? lock_acquire+0x3f8/0x510 [ 74.829033] ? lock_release+0x6b0/0x6b0 [ 74.829034] intel_pmu_handle_irq+0x11e/0x240 [ 74.829034] perf_event_nmi_handler+0x40/0x60 [ 74.829035] nmi_handle+0x110/0x360 [ 74.829036] ? __intel_pmu_enable_all.constprop.0+0x72/0xf0 [ 74.829037] default_do_nmi+0x6b/0x170 [ 74.829038] exc_nmi+0x106/0x130 [ 74.829038] end_repeat_nmi+0x16/0x55 [ 74.829039] RIP: 0010:__intel_pmu_enable_all.constprop.0+0x72/0xf0 [ 74.829042] Code: 2f 1f 03 48 8d bb b8 0c 00 00 e8 29 09 41 00 48 ... [ 74.829043] RSP: 0000:ffff8880a604fc90 EFLAGS: 00000002 [ 74.829044] RAX: 000000070000000f RBX: ffff8883ec2195a0 RCX: 000000000000038f [ 74.829045] RDX: 0000000000000007 RSI: ffffffff82e72c20 RDI: ffff8883ec21a258 [ 74.829046] RBP: 000000070000000f R08: ffffffff8101b013 R09: fffffbfff0a7982d [ 74.829047] R10: ffffffff853cc167 R11: fffffbfff0a7982c R12: 0000000000000000 [ 74.829049] R13: ffff8883ec3f0af0 R14: ffff8883ec3fd120 R15: ffff8883e9c92098 [ 74.829049] ? intel_pmu_lbr_enable_all+0x43/0x240 [ 74.829050] ? __intel_pmu_enable_all.constprop.0+0x72/0xf0 [ 74.829051] ? __intel_pmu_enable_all.constprop.0+0x72/0xf0 [ 74.829052] </NMI> [ 74.829053] perf_event_task_tick+0x48d/0x650 [ 74.829054] scheduler_tick+0x129/0x210 [ 74.829054] update_process_times+0x37/0x70 [ 74.829055] tick_sched_handle.isra.0+0x35/0x90 [ 74.829056] tick_sched_timer+0x8f/0xb0 [ 74.829057] __hrtimer_run_queues+0x364/0x7d0 [ 74.829058] ? tick_sched_do_timer+0xa0/0xa0 [ 74.829058] ? enqueue_hrtimer+0x1e0/0x1e0 [ 74.829059] ? recalibrate_cpu_khz+0x10/0x10 [ 74.829060] ? ktime_get_update_offsets_now+0x1a3/0x360 [ 74.829061] hrtimer_interrupt+0x1bb/0x360 [ 74.829062] ? rcu_read_lock_sched_held+0xa1/0xd0 [ 74.829063] __sysvec_apic_timer_interrupt+0xed/0x3d0 [ 74.829064] sysvec_apic_timer_interrupt+0x3f/0xd0 [ 74.829064] ? asm_sysvec_apic_timer_interrupt+0xa/0x20 [ 74.829065] asm_sysvec_apic_timer_interrupt+0x12/0x20 [ 74.829066] RIP: 0033:0x7fba18d579b4 [ 74.829068] Code: 74 54 44 0f b6 4a 04 41 83 e1 0f 41 80 f9 ... [ 74.829069] RSP: 002b:00007ffc9ba69570 EFLAGS: 00000206 [ 74.829071] RAX: 00007fba192084c0 RBX: 00007fba18c24d28 RCX: 00000000000007a4 [ 74.829072] RDX: 00007fba18c30488 RSI: 0000000000000000 RDI: 000000000000037b [ 74.829073] RBP: 00007fba18ca5760 R08: 00007fba18c248fc R09: 00007fba18c94c30 [ 74.829074] R10: 000000000000002f R11: 0000000000073c30 R12: 00007ffc9ba695e0 [ 74.829075] R13: 00000000000003f3 R14: 00007fba18c21ac8 R15: 00000000000058d6 However, such warning should not apply across multiple hashtabs. The system will not deadlock if one hashtab is used in NMI, while another hashtab is used in non-NMI. Use separate lockdep class for each hashtab, so that we don't get this false alert. Signed-off-by: Song Liu <[email protected]> Signed-off-by: Alexei Starovoitov <[email protected]> Link: https://lore.kernel.org/bpf/[email protected]

Song Liu says: ==================== LOCKDEP NMI warning highlighted potential deadlock of hashtab in NMI context: [ 74.828971] ================================ [ 74.828972] WARNING: inconsistent lock state [ 74.828973] 5.9.0-rc8+ torvalds#275 Not tainted [ 74.828974] -------------------------------- [ 74.828975] inconsistent {INITIAL USE} -> {IN-NMI} usage. [ 74.828976] taskset/1174 [HC2[2]:SC0[0]:HE0:SE1] takes: [...] [ 74.828999] Possible unsafe locking scenario: [ 74.828999] [ 74.829000] CPU0 [ 74.829001] ---- [ 74.829001] lock(&htab->buckets[i].raw_lock); [ 74.829003] <Interrupt> [ 74.829004] lock(&htab->buckets[i].raw_lock); Please refer to patch 1/2 for full trace. This warning is a false alert, as "INITIAL USE" and "IN-NMI" in the tests are from different hashtab. On the other hand, in theory, it is possible to deadlock when a hashtab is access from both non-NMI and NMI context. Patch 1/2 fixes this false alert by assigning separate lockdep class to each hashtab. Patch 2/2 introduces map_locked counters, which is similar to bpf_prog_active counter, to avoid hashtab deadlock in NMI context. ==================== Signed-off-by: Alexei Starovoitov <[email protected]>

…CKOPT Add verifier ctx test to call bpf_get_netns_cookie from cgroup/setsockopt. torvalds#269/p pass ctx or null check, 1: ctx Did not run the program (not supported) OK torvalds#270/p pass ctx or null check, 2: null Did not run the program (not supported) OK torvalds#271/p pass ctx or null check, 3: 1 OK torvalds#272/p pass ctx or null check, 4: ctx - const OK torvalds#273/p pass ctx or null check, 5: null (connect) Did not run the program (not supported) OK torvalds#274/p pass ctx or null check, 6: null (bind) Did not run the program (not supported) OK torvalds#275/p pass ctx or null check, 7: ctx (bind) Did not run the program (not supported) OK torvalds#276/p pass ctx or null check, 8: null (bind) OK torvalds#277/p pass ctx or null check, 9: ctx (cgroup/setsockopt) Did not run the program (not supported) OK torvalds#278/p pass ctx or null check, 10: null (cgroup/setsockopt) Did not run the program (not supported) OK Signed-off-by: Stanislav Fomichev <[email protected]>

WARNING: please, no spaces at the start of a line torvalds#249: FILE: mm/page-writeback.c:2089: + {$ ERROR: code indent should use tabs where possible torvalds#250: FILE: mm/page-writeback.c:2090: + .procname = "dirty_background_ratio",$ WARNING: please, no spaces at the start of a line torvalds#250: FILE: mm/page-writeback.c:2090: + .procname = "dirty_background_ratio",$ ERROR: code indent should use tabs where possible torvalds#251: FILE: mm/page-writeback.c:2091: + .data = &dirty_background_ratio,$ WARNING: please, no spaces at the start of a line torvalds#251: FILE: mm/page-writeback.c:2091: + .data = &dirty_background_ratio,$ ERROR: code indent should use tabs where possible torvalds#252: FILE: mm/page-writeback.c:2092: + .maxlen = sizeof(dirty_background_ratio),$ WARNING: please, no spaces at the start of a line torvalds#252: FILE: mm/page-writeback.c:2092: + .maxlen = sizeof(dirty_background_ratio),$ ERROR: code indent should use tabs where possible torvalds#253: FILE: mm/page-writeback.c:2093: + .mode = 0644,$ WARNING: please, no spaces at the start of a line torvalds#253: FILE: mm/page-writeback.c:2093: + .mode = 0644,$ ERROR: code indent should use tabs where possible torvalds#254: FILE: mm/page-writeback.c:2094: + .proc_handler = dirty_background_ratio_handler,$ WARNING: please, no spaces at the start of a line torvalds#254: FILE: mm/page-writeback.c:2094: + .proc_handler = dirty_background_ratio_handler,$ ERROR: code indent should use tabs where possible torvalds#255: FILE: mm/page-writeback.c:2095: + .extra1 = SYSCTL_ZERO,$ WARNING: please, no spaces at the start of a line torvalds#255: FILE: mm/page-writeback.c:2095: + .extra1 = SYSCTL_ZERO,$ ERROR: code indent should use tabs where possible torvalds#256: FILE: mm/page-writeback.c:2096: + .extra2 = SYSCTL_ONE_HUNDRED,$ WARNING: please, no spaces at the start of a line torvalds#256: FILE: mm/page-writeback.c:2096: + .extra2 = SYSCTL_ONE_HUNDRED,$ WARNING: please, no spaces at the start of a line torvalds#257: FILE: mm/page-writeback.c:2097: + },$ WARNING: please, no spaces at the start of a line torvalds#258: FILE: mm/page-writeback.c:2098: + {$ ERROR: code indent should use tabs where possible torvalds#259: FILE: mm/page-writeback.c:2099: + .procname = "dirty_background_bytes",$ WARNING: please, no spaces at the start of a line torvalds#259: FILE: mm/page-writeback.c:2099: + .procname = "dirty_background_bytes",$ ERROR: code indent should use tabs where possible torvalds#260: FILE: mm/page-writeback.c:2100: + .data = &dirty_background_bytes,$ WARNING: please, no spaces at the start of a line torvalds#260: FILE: mm/page-writeback.c:2100: + .data = &dirty_background_bytes,$ ERROR: code indent should use tabs where possible torvalds#261: FILE: mm/page-writeback.c:2101: + .maxlen = sizeof(dirty_background_bytes),$ WARNING: please, no spaces at the start of a line torvalds#261: FILE: mm/page-writeback.c:2101: + .maxlen = sizeof(dirty_background_bytes),$ ERROR: code indent should use tabs where possible torvalds#262: FILE: mm/page-writeback.c:2102: + .mode = 0644,$ WARNING: please, no spaces at the start of a line torvalds#262: FILE: mm/page-writeback.c:2102: + .mode = 0644,$ ERROR: code indent should use tabs where possible torvalds#263: FILE: mm/page-writeback.c:2103: + .proc_handler = dirty_background_bytes_handler,$ WARNING: please, no spaces at the start of a line torvalds#263: FILE: mm/page-writeback.c:2103: + .proc_handler = dirty_background_bytes_handler,$ ERROR: code indent should use tabs where possible torvalds#264: FILE: mm/page-writeback.c:2104: + .extra1 = SYSCTL_LONG_ONE,$ WARNING: please, no spaces at the start of a line torvalds#264: FILE: mm/page-writeback.c:2104: + .extra1 = SYSCTL_LONG_ONE,$ WARNING: please, no spaces at the start of a line torvalds#265: FILE: mm/page-writeback.c:2105: + },$ WARNING: please, no spaces at the start of a line torvalds#266: FILE: mm/page-writeback.c:2106: + {$ ERROR: code indent should use tabs where possible torvalds#267: FILE: mm/page-writeback.c:2107: + .procname = "dirty_ratio",$ WARNING: please, no spaces at the start of a line torvalds#267: FILE: mm/page-writeback.c:2107: + .procname = "dirty_ratio",$ ERROR: code indent should use tabs where possible torvalds#268: FILE: mm/page-writeback.c:2108: + .data = &vm_dirty_ratio,$ WARNING: please, no spaces at the start of a line torvalds#268: FILE: mm/page-writeback.c:2108: + .data = &vm_dirty_ratio,$ ERROR: code indent should use tabs where possible torvalds#269: FILE: mm/page-writeback.c:2109: + .maxlen = sizeof(vm_dirty_ratio),$ WARNING: please, no spaces at the start of a line torvalds#269: FILE: mm/page-writeback.c:2109: + .maxlen = sizeof(vm_dirty_ratio),$ ERROR: code indent should use tabs where possible torvalds#270: FILE: mm/page-writeback.c:2110: + .mode = 0644,$ WARNING: please, no spaces at the start of a line torvalds#270: FILE: mm/page-writeback.c:2110: + .mode = 0644,$ ERROR: code indent should use tabs where possible torvalds#271: FILE: mm/page-writeback.c:2111: + .proc_handler = dirty_ratio_handler,$ WARNING: please, no spaces at the start of a line torvalds#271: FILE: mm/page-writeback.c:2111: + .proc_handler = dirty_ratio_handler,$ ERROR: code indent should use tabs where possible torvalds#272: FILE: mm/page-writeback.c:2112: + .extra1 = SYSCTL_ZERO,$ WARNING: please, no spaces at the start of a line torvalds#272: FILE: mm/page-writeback.c:2112: + .extra1 = SYSCTL_ZERO,$ ERROR: code indent should use tabs where possible torvalds#273: FILE: mm/page-writeback.c:2113: + .extra2 = SYSCTL_ONE_HUNDRED,$ WARNING: please, no spaces at the start of a line torvalds#273: FILE: mm/page-writeback.c:2113: + .extra2 = SYSCTL_ONE_HUNDRED,$ WARNING: please, no spaces at the start of a line torvalds#274: FILE: mm/page-writeback.c:2114: + },$ WARNING: please, no spaces at the start of a line torvalds#275: FILE: mm/page-writeback.c:2115: + {$ ERROR: code indent should use tabs where possible torvalds#276: FILE: mm/page-writeback.c:2116: + .procname = "dirty_bytes",$ WARNING: please, no spaces at the start of a line torvalds#276: FILE: mm/page-writeback.c:2116: + .procname = "dirty_bytes",$ ERROR: code indent should use tabs where possible torvalds#277: FILE: mm/page-writeback.c:2117: + .data = &vm_dirty_bytes,$ WARNING: please, no spaces at the start of a line torvalds#277: FILE: mm/page-writeback.c:2117: + .data = &vm_dirty_bytes,$ ERROR: code indent should use tabs where possible torvalds#278: FILE: mm/page-writeback.c:2118: + .maxlen = sizeof(vm_dirty_bytes),$ WARNING: please, no spaces at the start of a line torvalds#278: FILE: mm/page-writeback.c:2118: + .maxlen = sizeof(vm_dirty_bytes),$ ERROR: code indent should use tabs where possible torvalds#279: FILE: mm/page-writeback.c:2119: + .mode = 0644,$ WARNING: please, no spaces at the start of a line torvalds#279: FILE: mm/page-writeback.c:2119: + .mode = 0644,$ ERROR: code indent should use tabs where possible torvalds#280: FILE: mm/page-writeback.c:2120: + .proc_handler = dirty_bytes_handler,$ WARNING: please, no spaces at the start of a line torvalds#280: FILE: mm/page-writeback.c:2120: + .proc_handler = dirty_bytes_handler,$ ERROR: code indent should use tabs where possible torvalds#281: FILE: mm/page-writeback.c:2121: + .extra1 = (void *)&dirty_bytes_min,$ WARNING: please, no spaces at the start of a line torvalds#281: FILE: mm/page-writeback.c:2121: + .extra1 = (void *)&dirty_bytes_min,$ WARNING: please, no spaces at the start of a line torvalds#282: FILE: mm/page-writeback.c:2122: + },$ WARNING: please, no spaces at the start of a line torvalds#283: FILE: mm/page-writeback.c:2123: + {$ ERROR: code indent should use tabs where possible torvalds#284: FILE: mm/page-writeback.c:2124: + .procname = "dirty_writeback_centisecs",$ WARNING: please, no spaces at the start of a line torvalds#284: FILE: mm/page-writeback.c:2124: + .procname = "dirty_writeback_centisecs",$ ERROR: code indent should use tabs where possible torvalds#285: FILE: mm/page-writeback.c:2125: + .data = &dirty_writeback_interval,$ WARNING: please, no spaces at the start of a line torvalds#285: FILE: mm/page-writeback.c:2125: + .data = &dirty_writeback_interval,$ ERROR: code indent should use tabs where possible torvalds#286: FILE: mm/page-writeback.c:2126: + .maxlen = sizeof(dirty_writeback_interval),$ WARNING: please, no spaces at the start of a line torvalds#286: FILE: mm/page-writeback.c:2126: + .maxlen = sizeof(dirty_writeback_interval),$ ERROR: code indent should use tabs where possible torvalds#287: FILE: mm/page-writeback.c:2127: + .mode = 0644,$ WARNING: please, no spaces at the start of a line torvalds#287: FILE: mm/page-writeback.c:2127: + .mode = 0644,$ ERROR: code indent should use tabs where possible torvalds#288: FILE: mm/page-writeback.c:2128: + .proc_handler = dirty_writeback_centisecs_handler,$ WARNING: please, no spaces at the start of a line torvalds#288: FILE: mm/page-writeback.c:2128: + .proc_handler = dirty_writeback_centisecs_handler,$ WARNING: please, no spaces at the start of a line torvalds#289: FILE: mm/page-writeback.c:2129: + },$ WARNING: please, no spaces at the start of a line torvalds#290: FILE: mm/page-writeback.c:2130: + {$ ERROR: code indent should use tabs where possible torvalds#291: FILE: mm/page-writeback.c:2131: + .procname = "dirty_expire_centisecs",$ WARNING: please, no spaces at the start of a line torvalds#291: FILE: mm/page-writeback.c:2131: + .procname = "dirty_expire_centisecs",$ ERROR: code indent should use tabs where possible torvalds#292: FILE: mm/page-writeback.c:2132: + .data = &dirty_expire_interval,$ WARNING: please, no spaces at the start of a line torvalds#292: FILE: mm/page-writeback.c:2132: + .data = &dirty_expire_interval,$ ERROR: code indent should use tabs where possible torvalds#293: FILE: mm/page-writeback.c:2133: + .maxlen = sizeof(dirty_expire_interval),$ WARNING: please, no spaces at the start of a line torvalds#293: FILE: mm/page-writeback.c:2133: + .maxlen = sizeof(dirty_expire_interval),$ ERROR: code indent should use tabs where possible torvalds#294: FILE: mm/page-writeback.c:2134: + .mode = 0644,$ WARNING: please, no spaces at the start of a line torvalds#294: FILE: mm/page-writeback.c:2134: + .mode = 0644,$ ERROR: code indent should use tabs where possible torvalds#295: FILE: mm/page-writeback.c:2135: + .proc_handler = proc_dointvec_minmax,$ WARNING: please, no spaces at the start of a line torvalds#295: FILE: mm/page-writeback.c:2135: + .proc_handler = proc_dointvec_minmax,$ ERROR: code indent should use tabs where possible torvalds#296: FILE: mm/page-writeback.c:2136: + .extra1 = SYSCTL_ZERO,$ WARNING: please, no spaces at the start of a line torvalds#296: FILE: mm/page-writeback.c:2136: + .extra1 = SYSCTL_ZERO,$ WARNING: please, no spaces at the start of a line torvalds#297: FILE: mm/page-writeback.c:2137: + },$ total: 37 errors, 49 warnings, 287 lines checked NOTE: For some of the reported defects, checkpatch may be able to mechanically convert to the typical style using --fix or --fix-inplace. NOTE: Whitespace errors detected. You may wish to use scripts/cleanpatch or scripts/cleanfile ./patches/mm-move-page-writeback-sysctls-to-is-own-file.patch has style problems, please review. NOTE: If any of the errors are false positives, please report them to the maintainer, see CHECKPATCH in MAINTAINERS. Please run checkpatch prior to sending patches Cc: Iurii Zaikin <[email protected]> Cc: Kees Cook <[email protected]> Cc: Luis Chamberlain <[email protected]> Cc: zhanglianjie <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Stephen Rothwell <[email protected]>

WARNING: please, no spaces at the start of a line torvalds#249: FILE: mm/page-writeback.c:2089: + {$ ERROR: code indent should use tabs where possible torvalds#250: FILE: mm/page-writeback.c:2090: + .procname = "dirty_background_ratio",$ WARNING: please, no spaces at the start of a line torvalds#250: FILE: mm/page-writeback.c:2090: + .procname = "dirty_background_ratio",$ ERROR: code indent should use tabs where possible torvalds#251: FILE: mm/page-writeback.c:2091: + .data = &dirty_background_ratio,$ WARNING: please, no spaces at the start of a line torvalds#251: FILE: mm/page-writeback.c:2091: + .data = &dirty_background_ratio,$ ERROR: code indent should use tabs where possible torvalds#252: FILE: mm/page-writeback.c:2092: + .maxlen = sizeof(dirty_background_ratio),$ WARNING: please, no spaces at the start of a line torvalds#252: FILE: mm/page-writeback.c:2092: + .maxlen = sizeof(dirty_background_ratio),$ ERROR: code indent should use tabs where possible torvalds#253: FILE: mm/page-writeback.c:2093: + .mode = 0644,$ WARNING: please, no spaces at the start of a line torvalds#253: FILE: mm/page-writeback.c:2093: + .mode = 0644,$ ERROR: code indent should use tabs where possible torvalds#254: FILE: mm/page-writeback.c:2094: + .proc_handler = dirty_background_ratio_handler,$ WARNING: please, no spaces at the start of a line torvalds#254: FILE: mm/page-writeback.c:2094: + .proc_handler = dirty_background_ratio_handler,$ ERROR: code indent should use tabs where possible torvalds#255: FILE: mm/page-writeback.c:2095: + .extra1 = SYSCTL_ZERO,$ WARNING: please, no spaces at the start of a line torvalds#255: FILE: mm/page-writeback.c:2095: + .extra1 = SYSCTL_ZERO,$ ERROR: code indent should use tabs where possible torvalds#256: FILE: mm/page-writeback.c:2096: + .extra2 = SYSCTL_ONE_HUNDRED,$ WARNING: please, no spaces at the start of a line torvalds#256: FILE: mm/page-writeback.c:2096: + .extra2 = SYSCTL_ONE_HUNDRED,$ WARNING: please, no spaces at the start of a line torvalds#257: FILE: mm/page-writeback.c:2097: + },$ WARNING: please, no spaces at the start of a line torvalds#258: FILE: mm/page-writeback.c:2098: + {$ ERROR: code indent should use tabs where possible torvalds#259: FILE: mm/page-writeback.c:2099: + .procname = "dirty_background_bytes",$ WARNING: please, no spaces at the start of a line torvalds#259: FILE: mm/page-writeback.c:2099: + .procname = "dirty_background_bytes",$ ERROR: code indent should use tabs where possible torvalds#260: FILE: mm/page-writeback.c:2100: + .data = &dirty_background_bytes,$ WARNING: please, no spaces at the start of a line torvalds#260: FILE: mm/page-writeback.c:2100: + .data = &dirty_background_bytes,$ ERROR: code indent should use tabs where possible torvalds#261: FILE: mm/page-writeback.c:2101: + .maxlen = sizeof(dirty_background_bytes),$ WARNING: please, no spaces at the start of a line torvalds#261: FILE: mm/page-writeback.c:2101: + .maxlen = sizeof(dirty_background_bytes),$ ERROR: code indent should use tabs where possible torvalds#262: FILE: mm/page-writeback.c:2102: + .mode = 0644,$ WARNING: please, no spaces at the start of a line torvalds#262: FILE: mm/page-writeback.c:2102: + .mode = 0644,$ ERROR: code indent should use tabs where possible torvalds#263: FILE: mm/page-writeback.c:2103: + .proc_handler = dirty_background_bytes_handler,$ WARNING: please, no spaces at the start of a line torvalds#263: FILE: mm/page-writeback.c:2103: + .proc_handler = dirty_background_bytes_handler,$ ERROR: code indent should use tabs where possible torvalds#264: FILE: mm/page-writeback.c:2104: + .extra1 = SYSCTL_LONG_ONE,$ WARNING: please, no spaces at the start of a line torvalds#264: FILE: mm/page-writeback.c:2104: + .extra1 = SYSCTL_LONG_ONE,$ WARNING: please, no spaces at the start of a line torvalds#265: FILE: mm/page-writeback.c:2105: + },$ WARNING: please, no spaces at the start of a line torvalds#266: FILE: mm/page-writeback.c:2106: + {$ ERROR: code indent should use tabs where possible torvalds#267: FILE: mm/page-writeback.c:2107: + .procname = "dirty_ratio",$ WARNING: please, no spaces at the start of a line torvalds#267: FILE: mm/page-writeback.c:2107: + .procname = "dirty_ratio",$ ERROR: code indent should use tabs where possible torvalds#268: FILE: mm/page-writeback.c:2108: + .data = &vm_dirty_ratio,$ WARNING: please, no spaces at the start of a line torvalds#268: FILE: mm/page-writeback.c:2108: + .data = &vm_dirty_ratio,$ ERROR: code indent should use tabs where possible torvalds#269: FILE: mm/page-writeback.c:2109: + .maxlen = sizeof(vm_dirty_ratio),$ WARNING: please, no spaces at the start of a line torvalds#269: FILE: mm/page-writeback.c:2109: + .maxlen = sizeof(vm_dirty_ratio),$ ERROR: code indent should use tabs where possible torvalds#270: FILE: mm/page-writeback.c:2110: + .mode = 0644,$ WARNING: please, no spaces at the start of a line torvalds#270: FILE: mm/page-writeback.c:2110: + .mode = 0644,$ ERROR: code indent should use tabs where possible torvalds#271: FILE: mm/page-writeback.c:2111: + .proc_handler = dirty_ratio_handler,$ WARNING: please, no spaces at the start of a line torvalds#271: FILE: mm/page-writeback.c:2111: + .proc_handler = dirty_ratio_handler,$ ERROR: code indent should use tabs where possible torvalds#272: FILE: mm/page-writeback.c:2112: + .extra1 = SYSCTL_ZERO,$ WARNING: please, no spaces at the start of a line torvalds#272: FILE: mm/page-writeback.c:2112: + .extra1 = SYSCTL_ZERO,$ ERROR: code indent should use tabs where possible torvalds#273: FILE: mm/page-writeback.c:2113: + .extra2 = SYSCTL_ONE_HUNDRED,$ WARNING: please, no spaces at the start of a line torvalds#273: FILE: mm/page-writeback.c:2113: + .extra2 = SYSCTL_ONE_HUNDRED,$ WARNING: please, no spaces at the start of a line torvalds#274: FILE: mm/page-writeback.c:2114: + },$ WARNING: please, no spaces at the start of a line torvalds#275: FILE: mm/page-writeback.c:2115: + {$ ERROR: code indent should use tabs where possible torvalds#276: FILE: mm/page-writeback.c:2116: + .procname = "dirty_bytes",$ WARNING: please, no spaces at the start of a line torvalds#276: FILE: mm/page-writeback.c:2116: + .procname = "dirty_bytes",$ ERROR: code indent should use tabs where possible torvalds#277: FILE: mm/page-writeback.c:2117: + .data = &vm_dirty_bytes,$ WARNING: please, no spaces at the start of a line torvalds#277: FILE: mm/page-writeback.c:2117: + .data = &vm_dirty_bytes,$ ERROR: code indent should use tabs where possible torvalds#278: FILE: mm/page-writeback.c:2118: + .maxlen = sizeof(vm_dirty_bytes),$ WARNING: please, no spaces at the start of a line torvalds#278: FILE: mm/page-writeback.c:2118: + .maxlen = sizeof(vm_dirty_bytes),$ ERROR: code indent should use tabs where possible torvalds#279: FILE: mm/page-writeback.c:2119: + .mode = 0644,$ WARNING: please, no spaces at the start of a line torvalds#279: FILE: mm/page-writeback.c:2119: + .mode = 0644,$ ERROR: code indent should use tabs where possible torvalds#280: FILE: mm/page-writeback.c:2120: + .proc_handler = dirty_bytes_handler,$ WARNING: please, no spaces at the start of a line torvalds#280: FILE: mm/page-writeback.c:2120: + .proc_handler = dirty_bytes_handler,$ ERROR: code indent should use tabs where possible torvalds#281: FILE: mm/page-writeback.c:2121: + .extra1 = (void *)&dirty_bytes_min,$ WARNING: please, no spaces at the start of a line torvalds#281: FILE: mm/page-writeback.c:2121: + .extra1 = (void *)&dirty_bytes_min,$ WARNING: please, no spaces at the start of a line torvalds#282: FILE: mm/page-writeback.c:2122: + },$ WARNING: please, no spaces at the start of a line torvalds#283: FILE: mm/page-writeback.c:2123: + {$ ERROR: code indent should use tabs where possible torvalds#284: FILE: mm/page-writeback.c:2124: + .procname = "dirty_writeback_centisecs",$ WARNING: please, no spaces at the start of a line torvalds#284: FILE: mm/page-writeback.c:2124: + .procname = "dirty_writeback_centisecs",$ ERROR: code indent should use tabs where possible torvalds#285: FILE: mm/page-writeback.c:2125: + .data = &dirty_writeback_interval,$ WARNING: please, no spaces at the start of a line torvalds#285: FILE: mm/page-writeback.c:2125: + .data = &dirty_writeback_interval,$ ERROR: code indent should use tabs where possible torvalds#286: FILE: mm/page-writeback.c:2126: + .maxlen = sizeof(dirty_writeback_interval),$ WARNING: please, no spaces at the start of a line torvalds#286: FILE: mm/page-writeback.c:2126: + .maxlen = sizeof(dirty_writeback_interval),$ ERROR: code indent should use tabs where possible torvalds#287: FILE: mm/page-writeback.c:2127: + .mode = 0644,$ WARNING: please, no spaces at the start of a line torvalds#287: FILE: mm/page-writeback.c:2127: + .mode = 0644,$ ERROR: code indent should use tabs where possible torvalds#288: FILE: mm/page-writeback.c:2128: + .proc_handler = dirty_writeback_centisecs_handler,$ WARNING: please, no spaces at the start of a line torvalds#288: FILE: mm/page-writeback.c:2128: + .proc_handler = dirty_writeback_centisecs_handler,$ WARNING: please, no spaces at the start of a line torvalds#289: FILE: mm/page-writeback.c:2129: + },$ WARNING: please, no spaces at the start of a line torvalds#290: FILE: mm/page-writeback.c:2130: + {$ ERROR: code indent should use tabs where possible torvalds#291: FILE: mm/page-writeback.c:2131: + .procname = "dirty_expire_centisecs",$ WARNING: please, no spaces at the start of a line torvalds#291: FILE: mm/page-writeback.c:2131: + .procname = "dirty_expire_centisecs",$ ERROR: code indent should use tabs where possible torvalds#292: FILE: mm/page-writeback.c:2132: + .data = &dirty_expire_interval,$ WARNING: please, no spaces at the start of a line torvalds#292: FILE: mm/page-writeback.c:2132: + .data = &dirty_expire_interval,$ ERROR: code indent should use tabs where possible torvalds#293: FILE: mm/page-writeback.c:2133: + .maxlen = sizeof(dirty_expire_interval),$ WARNING: please, no spaces at the start of a line torvalds#293: FILE: mm/page-writeback.c:2133: + .maxlen = sizeof(dirty_expire_interval),$ ERROR: code indent should use tabs where possible torvalds#294: FILE: mm/page-writeback.c:2134: + .mode = 0644,$ WARNING: please, no spaces at the start of a line torvalds#294: FILE: mm/page-writeback.c:2134: + .mode = 0644,$ ERROR: code indent should use tabs where possible torvalds#295: FILE: mm/page-writeback.c:2135: + .proc_handler = proc_dointvec_minmax,$ WARNING: please, no spaces at the start of a line torvalds#295: FILE: mm/page-writeback.c:2135: + .proc_handler = proc_dointvec_minmax,$ ERROR: code indent should use tabs where possible torvalds#296: FILE: mm/page-writeback.c:2136: + .extra1 = SYSCTL_ZERO,$ WARNING: please, no spaces at the start of a line torvalds#296: FILE: mm/page-writeback.c:2136: + .extra1 = SYSCTL_ZERO,$ WARNING: please, no spaces at the start of a line torvalds#297: FILE: mm/page-writeback.c:2137: + },$ total: 37 errors, 49 warnings, 287 lines checked NOTE: For some of the reported defects, checkpatch may be able to mechanically convert to the typical style using --fix or --fix-inplace. NOTE: Whitespace errors detected. You may wish to use scripts/cleanpatch or scripts/cleanfile ./patches/mm-move-page-writeback-sysctls-to-is-own-file.patch has style problems, please review. NOTE: If any of the errors are false positives, please report them to the maintainer, see CHECKPATCH in MAINTAINERS. Please run checkpatch prior to sending patches Cc: Iurii Zaikin <[email protected]> Cc: Kees Cook <[email protected]> Cc: Luis Chamberlain <[email protected]> Cc: zhanglianjie <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Mark Brown <[email protected]>

Add test coverage for reservations beyond the ring buffer size in order to validate that bpf_ringbuf_reserve() rejects the request with NULL, all other ring buffer tests keep passing as well: # ./vmtest.sh -- ./test_progs -t ringbuf [...] ./test_progs -t ringbuf [ 1.165434] bpf_testmod: loading out-of-tree module taints kernel. [ 1.165825] bpf_testmod: module verification failed: signature and/or required key missing - tainting kernel [ 1.284001] tsc: Refined TSC clocksource calibration: 3407.982 MHz [ 1.286871] clocksource: tsc: mask: 0xffffffffffffffff max_cycles: 0x311fc34e357, max_idle_ns: 440795379773 ns [ 1.289555] clocksource: Switched to clocksource tsc torvalds#274/1 ringbuf/ringbuf:OK torvalds#274/2 ringbuf/ringbuf_n:OK torvalds#274/3 ringbuf/ringbuf_map_key:OK torvalds#274/4 ringbuf/ringbuf_write:OK torvalds#274 ringbuf:OK torvalds#275 ringbuf_multi:OK [...] Signed-off-by: Daniel Borkmann <[email protected]> Signed-off-by: Andrii Nakryiko <[email protected]> Link: https://lore.kernel.org/bpf/[email protected]

Add test coverage for reservations beyond the ring buffer size in order to validate that bpf_ringbuf_reserve() rejects the request with NULL, all other ring buffer tests keep passing as well: # ./vmtest.sh -- ./test_progs -t ringbuf [...] ./test_progs -t ringbuf [ 1.165434] bpf_testmod: loading out-of-tree module taints kernel. [ 1.165825] bpf_testmod: module verification failed: signature and/or required key missing - tainting kernel [ 1.284001] tsc: Refined TSC clocksource calibration: 3407.982 MHz [ 1.286871] clocksource: tsc: mask: 0xffffffffffffffff max_cycles: 0x311fc34e357, max_idle_ns: 440795379773 ns [ 1.289555] clocksource: Switched to clocksource tsc torvalds#274/1 ringbuf/ringbuf:OK torvalds#274/2 ringbuf/ringbuf_n:OK torvalds#274/3 ringbuf/ringbuf_map_key:OK torvalds#274/4 ringbuf/ringbuf_write:OK torvalds#274 ringbuf:OK torvalds#275 ringbuf_multi:OK [...] Signed-off-by: Daniel Borkmann <[email protected]> Signed-off-by: Andrii Nakryiko <[email protected]> [ Test fixups for getting BPF CI back to work ] Signed-off-by: Daniel Borkmann <[email protected]> Link: https://lore.kernel.org/bpf/[email protected]

Add test coverage for reservations beyond the ring buffer size in order to validate that bpf_ringbuf_reserve() rejects the request with NULL, all other ring buffer tests keep passing as well: # ./vmtest.sh -- ./test_progs -t ringbuf [...] ./test_progs -t ringbuf [ 1.165434] bpf_testmod: loading out-of-tree module taints kernel. [ 1.165825] bpf_testmod: module verification failed: signature and/or required key missing - tainting kernel [ 1.284001] tsc: Refined TSC clocksource calibration: 3407.982 MHz [ 1.286871] clocksource: tsc: mask: 0xffffffffffffffff max_cycles: 0x311fc34e357, max_idle_ns: 440795379773 ns [ 1.289555] clocksource: Switched to clocksource tsc torvalds#274/1 ringbuf/ringbuf:OK torvalds#274/2 ringbuf/ringbuf_n:OK torvalds#274/3 ringbuf/ringbuf_map_key:OK torvalds#274/4 ringbuf/ringbuf_write:OK torvalds#274 ringbuf:OK torvalds#275 ringbuf_multi:OK [...] Signed-off-by: Daniel Borkmann <[email protected]>

@Dev-

uevent_show() wants to de-reference dev->driver->name. There is no clean way for a device attribute to de-reference dev->driver unless that attribute is defined via (struct device_driver).dev_groups. Instead, the anti-pattern of taking the device_lock() in the attribute handler risks deadlocks with code paths that remove device attributes while holding the lock. This deadlock is typically invisible to lockdep given the device_lock() is marked lockdep_set_novalidate_class(), but some subsystems allocate a local lockdep key for @Dev->mutex to reveal reports of the form: ====================================================== WARNING: possible circular locking dependency detected 6.10.0-rc7+ torvalds#275 Tainted: G OE N ------------------------------------------------------ modprobe/2374 is trying to acquire lock: ffff8c2270070de0 (kn->active#6){++++}-{0:0}, at: __kernfs_remove+0xde/0x220 but task is already holding lock: ffff8c22016e88f8 (&cxl_root_key){+.+.}-{3:3}, at: device_release_driver_internal+0x39/0x210 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (&cxl_root_key){+.+.}-{3:3}: __mutex_lock+0x99/0xc30 uevent_show+0xac/0x130 dev_attr_show+0x18/0x40 sysfs_kf_seq_show+0xac/0xf0 seq_read_iter+0x110/0x450 vfs_read+0x25b/0x340 ksys_read+0x67/0xf0 do_syscall_64+0x75/0x190 entry_SYSCALL_64_after_hwframe+0x76/0x7e -> #0 (kn->active#6){++++}-{0:0}: __lock_acquire+0x121a/0x1fa0 lock_acquire+0xd6/0x2e0 kernfs_drain+0x1e9/0x200 __kernfs_remove+0xde/0x220 kernfs_remove_by_name_ns+0x5e/0xa0 device_del+0x168/0x410 device_unregister+0x13/0x60 devres_release_all+0xb8/0x110 device_unbind_cleanup+0xe/0x70 device_release_driver_internal+0x1c7/0x210 driver_detach+0x47/0x90 bus_remove_driver+0x6c/0xf0 cxl_acpi_exit+0xc/0x11 [cxl_acpi] __do_sys_delete_module.isra.0+0x181/0x260 do_syscall_64+0x75/0x190 entry_SYSCALL_64_after_hwframe+0x76/0x7e The observation though is that driver objects are typically much longer lived than device objects. It is reasonable to perform lockless de-reference of a @driver pointer even if it is racing detach from a device. Given the infrequency of driver unregistration, use synchronize_rcu() in module_remove_driver() to close any potential races. It is potentially overkill to suffer synchronize_rcu() just to handle the rare module removal racing uevent_show() event. Thanks to Tetsuo Handa for the debug analysis of the syzbot report [1]. Fixes: c0a4009 ("drivers: core: synchronize really_probe() and dev_uevent()") Reported-by: [email protected] Reported-by: Tetsuo Handa <[email protected]> Closes: http://lore.kernel.org/[email protected] [1] Link: http://lore.kernel.org/[email protected] Cc: [email protected] Cc: Ashish Sangwan <[email protected]> Cc: Namjae Jeon <[email protected]> Cc: Dirk Behme <[email protected]> Cc: Greg Kroah-Hartman <[email protected]> Cc: Rafael J. Wysocki <[email protected]> Signed-off-by: Dan Williams <[email protected]> Link: https://lore.kernel.org/r/172081332794.577428.9738802016494057132.stgit@dwillia2-xfh.jf.intel.com Signed-off-by: Greg Kroah-Hartman <[email protected]>

@Dev-

commit 15fffc6 upstream. uevent_show() wants to de-reference dev->driver->name. There is no clean way for a device attribute to de-reference dev->driver unless that attribute is defined via (struct device_driver).dev_groups. Instead, the anti-pattern of taking the device_lock() in the attribute handler risks deadlocks with code paths that remove device attributes while holding the lock. This deadlock is typically invisible to lockdep given the device_lock() is marked lockdep_set_novalidate_class(), but some subsystems allocate a local lockdep key for @Dev->mutex to reveal reports of the form: ====================================================== WARNING: possible circular locking dependency detected 6.10.0-rc7+ torvalds#275 Tainted: G OE N ------------------------------------------------------ modprobe/2374 is trying to acquire lock: ffff8c2270070de0 (kn->active#6){++++}-{0:0}, at: __kernfs_remove+0xde/0x220 but task is already holding lock: ffff8c22016e88f8 (&cxl_root_key){+.+.}-{3:3}, at: device_release_driver_internal+0x39/0x210 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (&cxl_root_key){+.+.}-{3:3}: __mutex_lock+0x99/0xc30 uevent_show+0xac/0x130 dev_attr_show+0x18/0x40 sysfs_kf_seq_show+0xac/0xf0 seq_read_iter+0x110/0x450 vfs_read+0x25b/0x340 ksys_read+0x67/0xf0 do_syscall_64+0x75/0x190 entry_SYSCALL_64_after_hwframe+0x76/0x7e -> #0 (kn->active#6){++++}-{0:0}: __lock_acquire+0x121a/0x1fa0 lock_acquire+0xd6/0x2e0 kernfs_drain+0x1e9/0x200 __kernfs_remove+0xde/0x220 kernfs_remove_by_name_ns+0x5e/0xa0 device_del+0x168/0x410 device_unregister+0x13/0x60 devres_release_all+0xb8/0x110 device_unbind_cleanup+0xe/0x70 device_release_driver_internal+0x1c7/0x210 driver_detach+0x47/0x90 bus_remove_driver+0x6c/0xf0 cxl_acpi_exit+0xc/0x11 [cxl_acpi] __do_sys_delete_module.isra.0+0x181/0x260 do_syscall_64+0x75/0x190 entry_SYSCALL_64_after_hwframe+0x76/0x7e The observation though is that driver objects are typically much longer lived than device objects. It is reasonable to perform lockless de-reference of a @driver pointer even if it is racing detach from a device. Given the infrequency of driver unregistration, use synchronize_rcu() in module_remove_driver() to close any potential races. It is potentially overkill to suffer synchronize_rcu() just to handle the rare module removal racing uevent_show() event. Thanks to Tetsuo Handa for the debug analysis of the syzbot report [1]. Fixes: c0a4009 ("drivers: core: synchronize really_probe() and dev_uevent()") Reported-by: [email protected] Reported-by: Tetsuo Handa <[email protected]> Closes: http://lore.kernel.org/[email protected] [1] Link: http://lore.kernel.org/[email protected] Cc: [email protected] Cc: Ashish Sangwan <[email protected]> Cc: Namjae Jeon <[email protected]> Cc: Dirk Behme <[email protected]> Cc: Greg Kroah-Hartman <[email protected]> Cc: Rafael J. Wysocki <[email protected]> Signed-off-by: Dan Williams <[email protected]> Link: https://lore.kernel.org/r/172081332794.577428.9738802016494057132.stgit@dwillia2-xfh.jf.intel.com Signed-off-by: Greg Kroah-Hartman <[email protected]>

@Dev-

commit 15fffc6 upstream. uevent_show() wants to de-reference dev->driver->name. There is no clean way for a device attribute to de-reference dev->driver unless that attribute is defined via (struct device_driver).dev_groups. Instead, the anti-pattern of taking the device_lock() in the attribute handler risks deadlocks with code paths that remove device attributes while holding the lock. This deadlock is typically invisible to lockdep given the device_lock() is marked lockdep_set_novalidate_class(), but some subsystems allocate a local lockdep key for @Dev->mutex to reveal reports of the form: ====================================================== WARNING: possible circular locking dependency detected 6.10.0-rc7+ torvalds#275 Tainted: G OE N ------------------------------------------------------ modprobe/2374 is trying to acquire lock: ffff8c2270070de0 (kn->active#6){++++}-{0:0}, at: __kernfs_remove+0xde/0x220 but task is already holding lock: ffff8c22016e88f8 (&cxl_root_key){+.+.}-{3:3}, at: device_release_driver_internal+0x39/0x210 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (&cxl_root_key){+.+.}-{3:3}: __mutex_lock+0x99/0xc30 uevent_show+0xac/0x130 dev_attr_show+0x18/0x40 sysfs_kf_seq_show+0xac/0xf0 seq_read_iter+0x110/0x450 vfs_read+0x25b/0x340 ksys_read+0x67/0xf0 do_syscall_64+0x75/0x190 entry_SYSCALL_64_after_hwframe+0x76/0x7e -> #0 (kn->active#6){++++}-{0:0}: __lock_acquire+0x121a/0x1fa0 lock_acquire+0xd6/0x2e0 kernfs_drain+0x1e9/0x200 __kernfs_remove+0xde/0x220 kernfs_remove_by_name_ns+0x5e/0xa0 device_del+0x168/0x410 device_unregister+0x13/0x60 devres_release_all+0xb8/0x110 device_unbind_cleanup+0xe/0x70 device_release_driver_internal+0x1c7/0x210 driver_detach+0x47/0x90 bus_remove_driver+0x6c/0xf0 cxl_acpi_exit+0xc/0x11 [cxl_acpi] __do_sys_delete_module.isra.0+0x181/0x260 do_syscall_64+0x75/0x190 entry_SYSCALL_64_after_hwframe+0x76/0x7e The observation though is that driver objects are typically much longer lived than device objects. It is reasonable to perform lockless de-reference of a @driver pointer even if it is racing detach from a device. Given the infrequency of driver unregistration, use synchronize_rcu() in module_remove_driver() to close any potential races. It is potentially overkill to suffer synchronize_rcu() just to handle the rare module removal racing uevent_show() event. Thanks to Tetsuo Handa for the debug analysis of the syzbot report [1]. Fixes: c0a4009 ("drivers: core: synchronize really_probe() and dev_uevent()") Reported-by: [email protected] Reported-by: Tetsuo Handa <[email protected]> Closes: http://lore.kernel.org/[email protected] [1] Link: http://lore.kernel.org/[email protected] Cc: [email protected] Cc: Ashish Sangwan <[email protected]> Cc: Namjae Jeon <[email protected]> Cc: Dirk Behme <[email protected]> Cc: Greg Kroah-Hartman <[email protected]> Cc: Rafael J. Wysocki <[email protected]> Signed-off-by: Dan Williams <[email protected]> Link: https://lore.kernel.org/r/172081332794.577428.9738802016494057132.stgit@dwillia2-xfh.jf.intel.com Signed-off-by: Greg Kroah-Hartman <[email protected]>

@Dev-

commit 15fffc6 upstream. uevent_show() wants to de-reference dev->driver->name. There is no clean way for a device attribute to de-reference dev->driver unless that attribute is defined via (struct device_driver).dev_groups. Instead, the anti-pattern of taking the device_lock() in the attribute handler risks deadlocks with code paths that remove device attributes while holding the lock. This deadlock is typically invisible to lockdep given the device_lock() is marked lockdep_set_novalidate_class(), but some subsystems allocate a local lockdep key for @Dev->mutex to reveal reports of the form: ====================================================== WARNING: possible circular locking dependency detected 6.10.0-rc7+ torvalds#275 Tainted: G OE N ------------------------------------------------------ modprobe/2374 is trying to acquire lock: ffff8c2270070de0 (kn->active#6){++++}-{0:0}, at: __kernfs_remove+0xde/0x220 but task is already holding lock: ffff8c22016e88f8 (&cxl_root_key){+.+.}-{3:3}, at: device_release_driver_internal+0x39/0x210 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (&cxl_root_key){+.+.}-{3:3}: __mutex_lock+0x99/0xc30 uevent_show+0xac/0x130 dev_attr_show+0x18/0x40 sysfs_kf_seq_show+0xac/0xf0 seq_read_iter+0x110/0x450 vfs_read+0x25b/0x340 ksys_read+0x67/0xf0 do_syscall_64+0x75/0x190 entry_SYSCALL_64_after_hwframe+0x76/0x7e -> #0 (kn->active#6){++++}-{0:0}: __lock_acquire+0x121a/0x1fa0 lock_acquire+0xd6/0x2e0 kernfs_drain+0x1e9/0x200 __kernfs_remove+0xde/0x220 kernfs_remove_by_name_ns+0x5e/0xa0 device_del+0x168/0x410 device_unregister+0x13/0x60 devres_release_all+0xb8/0x110 device_unbind_cleanup+0xe/0x70 device_release_driver_internal+0x1c7/0x210 driver_detach+0x47/0x90 bus_remove_driver+0x6c/0xf0 cxl_acpi_exit+0xc/0x11 [cxl_acpi] __do_sys_delete_module.isra.0+0x181/0x260 do_syscall_64+0x75/0x190 entry_SYSCALL_64_after_hwframe+0x76/0x7e The observation though is that driver objects are typically much longer lived than device objects. It is reasonable to perform lockless de-reference of a @driver pointer even if it is racing detach from a device. Given the infrequency of driver unregistration, use synchronize_rcu() in module_remove_driver() to close any potential races. It is potentially overkill to suffer synchronize_rcu() just to handle the rare module removal racing uevent_show() event. Thanks to Tetsuo Handa for the debug analysis of the syzbot report [1]. Fixes: c0a4009 ("drivers: core: synchronize really_probe() and dev_uevent()") Reported-by: [email protected] Reported-by: Tetsuo Handa <[email protected]> Closes: http://lore.kernel.org/[email protected] [1] Link: http://lore.kernel.org/[email protected] Cc: [email protected] Cc: Ashish Sangwan <[email protected]> Cc: Namjae Jeon <[email protected]> Cc: Dirk Behme <[email protected]> Cc: Greg Kroah-Hartman <[email protected]> Cc: Rafael J. Wysocki <[email protected]> Signed-off-by: Dan Williams <[email protected]> Link: https://lore.kernel.org/r/172081332794.577428.9738802016494057132.stgit@dwillia2-xfh.jf.intel.com Signed-off-by: Greg Kroah-Hartman <[email protected]>

@Dev-

commit 15fffc6 upstream. uevent_show() wants to de-reference dev->driver->name. There is no clean way for a device attribute to de-reference dev->driver unless that attribute is defined via (struct device_driver).dev_groups. Instead, the anti-pattern of taking the device_lock() in the attribute handler risks deadlocks with code paths that remove device attributes while holding the lock. This deadlock is typically invisible to lockdep given the device_lock() is marked lockdep_set_novalidate_class(), but some subsystems allocate a local lockdep key for @Dev->mutex to reveal reports of the form: ====================================================== WARNING: possible circular locking dependency detected 6.10.0-rc7+ torvalds#275 Tainted: G OE N ------------------------------------------------------ modprobe/2374 is trying to acquire lock: ffff8c2270070de0 (kn->active#6){++++}-{0:0}, at: __kernfs_remove+0xde/0x220 but task is already holding lock: ffff8c22016e88f8 (&cxl_root_key){+.+.}-{3:3}, at: device_release_driver_internal+0x39/0x210 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (&cxl_root_key){+.+.}-{3:3}: __mutex_lock+0x99/0xc30 uevent_show+0xac/0x130 dev_attr_show+0x18/0x40 sysfs_kf_seq_show+0xac/0xf0 seq_read_iter+0x110/0x450 vfs_read+0x25b/0x340 ksys_read+0x67/0xf0 do_syscall_64+0x75/0x190 entry_SYSCALL_64_after_hwframe+0x76/0x7e -> #0 (kn->active#6){++++}-{0:0}: __lock_acquire+0x121a/0x1fa0 lock_acquire+0xd6/0x2e0 kernfs_drain+0x1e9/0x200 __kernfs_remove+0xde/0x220 kernfs_remove_by_name_ns+0x5e/0xa0 device_del+0x168/0x410 device_unregister+0x13/0x60 devres_release_all+0xb8/0x110 device_unbind_cleanup+0xe/0x70 device_release_driver_internal+0x1c7/0x210 driver_detach+0x47/0x90 bus_remove_driver+0x6c/0xf0 cxl_acpi_exit+0xc/0x11 [cxl_acpi] __do_sys_delete_module.isra.0+0x181/0x260 do_syscall_64+0x75/0x190 entry_SYSCALL_64_after_hwframe+0x76/0x7e The observation though is that driver objects are typically much longer lived than device objects. It is reasonable to perform lockless de-reference of a @driver pointer even if it is racing detach from a device. Given the infrequency of driver unregistration, use synchronize_rcu() in module_remove_driver() to close any potential races. It is potentially overkill to suffer synchronize_rcu() just to handle the rare module removal racing uevent_show() event. Thanks to Tetsuo Handa for the debug analysis of the syzbot report [1]. Fixes: c0a4009 ("drivers: core: synchronize really_probe() and dev_uevent()") Reported-by: [email protected] Reported-by: Tetsuo Handa <[email protected]> Closes: http://lore.kernel.org/[email protected] [1] Link: http://lore.kernel.org/[email protected] Cc: [email protected] Cc: Ashish Sangwan <[email protected]> Cc: Namjae Jeon <[email protected]> Cc: Dirk Behme <[email protected]> Cc: Greg Kroah-Hartman <[email protected]> Cc: Rafael J. Wysocki <[email protected]> Signed-off-by: Dan Williams <[email protected]> Link: https://lore.kernel.org/r/172081332794.577428.9738802016494057132.stgit@dwillia2-xfh.jf.intel.com Signed-off-by: Greg Kroah-Hartman <[email protected]>

@Dev-

commit 15fffc6 upstream. uevent_show() wants to de-reference dev->driver->name. There is no clean way for a device attribute to de-reference dev->driver unless that attribute is defined via (struct device_driver).dev_groups. Instead, the anti-pattern of taking the device_lock() in the attribute handler risks deadlocks with code paths that remove device attributes while holding the lock. This deadlock is typically invisible to lockdep given the device_lock() is marked lockdep_set_novalidate_class(), but some subsystems allocate a local lockdep key for @Dev->mutex to reveal reports of the form: ====================================================== WARNING: possible circular locking dependency detected 6.10.0-rc7+ torvalds#275 Tainted: G OE N ------------------------------------------------------ modprobe/2374 is trying to acquire lock: ffff8c2270070de0 (kn->active#6){++++}-{0:0}, at: __kernfs_remove+0xde/0x220 but task is already holding lock: ffff8c22016e88f8 (&cxl_root_key){+.+.}-{3:3}, at: device_release_driver_internal+0x39/0x210 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (&cxl_root_key){+.+.}-{3:3}: __mutex_lock+0x99/0xc30 uevent_show+0xac/0x130 dev_attr_show+0x18/0x40 sysfs_kf_seq_show+0xac/0xf0 seq_read_iter+0x110/0x450 vfs_read+0x25b/0x340 ksys_read+0x67/0xf0 do_syscall_64+0x75/0x190 entry_SYSCALL_64_after_hwframe+0x76/0x7e -> #0 (kn->active#6){++++}-{0:0}: __lock_acquire+0x121a/0x1fa0 lock_acquire+0xd6/0x2e0 kernfs_drain+0x1e9/0x200 __kernfs_remove+0xde/0x220 kernfs_remove_by_name_ns+0x5e/0xa0 device_del+0x168/0x410 device_unregister+0x13/0x60 devres_release_all+0xb8/0x110 device_unbind_cleanup+0xe/0x70 device_release_driver_internal+0x1c7/0x210 driver_detach+0x47/0x90 bus_remove_driver+0x6c/0xf0 cxl_acpi_exit+0xc/0x11 [cxl_acpi] __do_sys_delete_module.isra.0+0x181/0x260 do_syscall_64+0x75/0x190 entry_SYSCALL_64_after_hwframe+0x76/0x7e The observation though is that driver objects are typically much longer lived than device objects. It is reasonable to perform lockless de-reference of a @driver pointer even if it is racing detach from a device. Given the infrequency of driver unregistration, use synchronize_rcu() in module_remove_driver() to close any potential races. It is potentially overkill to suffer synchronize_rcu() just to handle the rare module removal racing uevent_show() event. Thanks to Tetsuo Handa for the debug analysis of the syzbot report [1]. Fixes: c0a4009 ("drivers: core: synchronize really_probe() and dev_uevent()") Reported-by: [email protected] Reported-by: Tetsuo Handa <[email protected]> Closes: http://lore.kernel.org/[email protected] [1] Link: http://lore.kernel.org/[email protected] Cc: [email protected] Cc: Ashish Sangwan <[email protected]> Cc: Namjae Jeon <[email protected]> Cc: Dirk Behme <[email protected]> Cc: Greg Kroah-Hartman <[email protected]> Cc: Rafael J. Wysocki <[email protected]> Signed-off-by: Dan Williams <[email protected]> Link: https://lore.kernel.org/r/172081332794.577428.9738802016494057132.stgit@dwillia2-xfh.jf.intel.com Signed-off-by: Greg Kroah-Hartman <[email protected]>

@Dev-

commit 15fffc6 upstream. uevent_show() wants to de-reference dev->driver->name. There is no clean way for a device attribute to de-reference dev->driver unless that attribute is defined via (struct device_driver).dev_groups. Instead, the anti-pattern of taking the device_lock() in the attribute handler risks deadlocks with code paths that remove device attributes while holding the lock. This deadlock is typically invisible to lockdep given the device_lock() is marked lockdep_set_novalidate_class(), but some subsystems allocate a local lockdep key for @Dev->mutex to reveal reports of the form: ====================================================== WARNING: possible circular locking dependency detected 6.10.0-rc7+ torvalds#275 Tainted: G OE N ------------------------------------------------------ modprobe/2374 is trying to acquire lock: ffff8c2270070de0 (kn->active#6){++++}-{0:0}, at: __kernfs_remove+0xde/0x220 but task is already holding lock: ffff8c22016e88f8 (&cxl_root_key){+.+.}-{3:3}, at: device_release_driver_internal+0x39/0x210 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (&cxl_root_key){+.+.}-{3:3}: __mutex_lock+0x99/0xc30 uevent_show+0xac/0x130 dev_attr_show+0x18/0x40 sysfs_kf_seq_show+0xac/0xf0 seq_read_iter+0x110/0x450 vfs_read+0x25b/0x340 ksys_read+0x67/0xf0 do_syscall_64+0x75/0x190 entry_SYSCALL_64_after_hwframe+0x76/0x7e -> #0 (kn->active#6){++++}-{0:0}: __lock_acquire+0x121a/0x1fa0 lock_acquire+0xd6/0x2e0 kernfs_drain+0x1e9/0x200 __kernfs_remove+0xde/0x220 kernfs_remove_by_name_ns+0x5e/0xa0 device_del+0x168/0x410 device_unregister+0x13/0x60 devres_release_all+0xb8/0x110 device_unbind_cleanup+0xe/0x70 device_release_driver_internal+0x1c7/0x210 driver_detach+0x47/0x90 bus_remove_driver+0x6c/0xf0 cxl_acpi_exit+0xc/0x11 [cxl_acpi] __do_sys_delete_module.isra.0+0x181/0x260 do_syscall_64+0x75/0x190 entry_SYSCALL_64_after_hwframe+0x76/0x7e The observation though is that driver objects are typically much longer lived than device objects. It is reasonable to perform lockless de-reference of a @driver pointer even if it is racing detach from a device. Given the infrequency of driver unregistration, use synchronize_rcu() in module_remove_driver() to close any potential races. It is potentially overkill to suffer synchronize_rcu() just to handle the rare module removal racing uevent_show() event. Thanks to Tetsuo Handa for the debug analysis of the syzbot report [1]. Fixes: c0a4009 ("drivers: core: synchronize really_probe() and dev_uevent()") Reported-by: [email protected] Reported-by: Tetsuo Handa <[email protected]> Closes: http://lore.kernel.org/[email protected] [1] Link: http://lore.kernel.org/[email protected] Cc: [email protected] Cc: Ashish Sangwan <[email protected]> Cc: Namjae Jeon <[email protected]> Cc: Dirk Behme <[email protected]> Cc: Greg Kroah-Hartman <[email protected]> Cc: Rafael J. Wysocki <[email protected]> Signed-off-by: Dan Williams <[email protected]> Link: https://lore.kernel.org/r/172081332794.577428.9738802016494057132.stgit@dwillia2-xfh.jf.intel.com Signed-off-by: Greg Kroah-Hartman <[email protected]>

@Dev-

commit 15fffc6 upstream. uevent_show() wants to de-reference dev->driver->name. There is no clean way for a device attribute to de-reference dev->driver unless that attribute is defined via (struct device_driver).dev_groups. Instead, the anti-pattern of taking the device_lock() in the attribute handler risks deadlocks with code paths that remove device attributes while holding the lock. This deadlock is typically invisible to lockdep given the device_lock() is marked lockdep_set_novalidate_class(), but some subsystems allocate a local lockdep key for @Dev->mutex to reveal reports of the form: ====================================================== WARNING: possible circular locking dependency detected 6.10.0-rc7+ torvalds#275 Tainted: G OE N ------------------------------------------------------ modprobe/2374 is trying to acquire lock: ffff8c2270070de0 (kn->active#6){++++}-{0:0}, at: __kernfs_remove+0xde/0x220 but task is already holding lock: ffff8c22016e88f8 (&cxl_root_key){+.+.}-{3:3}, at: device_release_driver_internal+0x39/0x210 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (&cxl_root_key){+.+.}-{3:3}: __mutex_lock+0x99/0xc30 uevent_show+0xac/0x130 dev_attr_show+0x18/0x40 sysfs_kf_seq_show+0xac/0xf0 seq_read_iter+0x110/0x450 vfs_read+0x25b/0x340 ksys_read+0x67/0xf0 do_syscall_64+0x75/0x190 entry_SYSCALL_64_after_hwframe+0x76/0x7e -> #0 (kn->active#6){++++}-{0:0}: __lock_acquire+0x121a/0x1fa0 lock_acquire+0xd6/0x2e0 kernfs_drain+0x1e9/0x200 __kernfs_remove+0xde/0x220 kernfs_remove_by_name_ns+0x5e/0xa0 device_del+0x168/0x410 device_unregister+0x13/0x60 devres_release_all+0xb8/0x110 device_unbind_cleanup+0xe/0x70 device_release_driver_internal+0x1c7/0x210 driver_detach+0x47/0x90 bus_remove_driver+0x6c/0xf0 cxl_acpi_exit+0xc/0x11 [cxl_acpi] __do_sys_delete_module.isra.0+0x181/0x260 do_syscall_64+0x75/0x190 entry_SYSCALL_64_after_hwframe+0x76/0x7e The observation though is that driver objects are typically much longer lived than device objects. It is reasonable to perform lockless de-reference of a @driver pointer even if it is racing detach from a device. Given the infrequency of driver unregistration, use synchronize_rcu() in module_remove_driver() to close any potential races. It is potentially overkill to suffer synchronize_rcu() just to handle the rare module removal racing uevent_show() event. Thanks to Tetsuo Handa for the debug analysis of the syzbot report [1]. Fixes: c0a4009 ("drivers: core: synchronize really_probe() and dev_uevent()") Reported-by: [email protected] Reported-by: Tetsuo Handa <[email protected]> Closes: http://lore.kernel.org/[email protected] [1] Link: http://lore.kernel.org/[email protected] Cc: [email protected] Cc: Ashish Sangwan <[email protected]> Cc: Namjae Jeon <[email protected]> Cc: Dirk Behme <[email protected]> Cc: Greg Kroah-Hartman <[email protected]> Cc: Rafael J. Wysocki <[email protected]> Signed-off-by: Dan Williams <[email protected]> Link: https://lore.kernel.org/r/172081332794.577428.9738802016494057132.stgit@dwillia2-xfh.jf.intel.com Signed-off-by: Greg Kroah-Hartman <[email protected]>

@Dev-

commit 15fffc6 upstream. uevent_show() wants to de-reference dev->driver->name. There is no clean way for a device attribute to de-reference dev->driver unless that attribute is defined via (struct device_driver).dev_groups. Instead, the anti-pattern of taking the device_lock() in the attribute handler risks deadlocks with code paths that remove device attributes while holding the lock. This deadlock is typically invisible to lockdep given the device_lock() is marked lockdep_set_novalidate_class(), but some subsystems allocate a local lockdep key for @Dev->mutex to reveal reports of the form: ====================================================== WARNING: possible circular locking dependency detected 6.10.0-rc7+ torvalds#275 Tainted: G OE N ------------------------------------------------------ modprobe/2374 is trying to acquire lock: ffff8c2270070de0 (kn->active#6){++++}-{0:0}, at: __kernfs_remove+0xde/0x220 but task is already holding lock: ffff8c22016e88f8 (&cxl_root_key){+.+.}-{3:3}, at: device_release_driver_internal+0x39/0x210 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (&cxl_root_key){+.+.}-{3:3}: __mutex_lock+0x99/0xc30 uevent_show+0xac/0x130 dev_attr_show+0x18/0x40 sysfs_kf_seq_show+0xac/0xf0 seq_read_iter+0x110/0x450 vfs_read+0x25b/0x340 ksys_read+0x67/0xf0 do_syscall_64+0x75/0x190 entry_SYSCALL_64_after_hwframe+0x76/0x7e -> #0 (kn->active#6){++++}-{0:0}: __lock_acquire+0x121a/0x1fa0 lock_acquire+0xd6/0x2e0 kernfs_drain+0x1e9/0x200 __kernfs_remove+0xde/0x220 kernfs_remove_by_name_ns+0x5e/0xa0 device_del+0x168/0x410 device_unregister+0x13/0x60 devres_release_all+0xb8/0x110 device_unbind_cleanup+0xe/0x70 device_release_driver_internal+0x1c7/0x210 driver_detach+0x47/0x90 bus_remove_driver+0x6c/0xf0 cxl_acpi_exit+0xc/0x11 [cxl_acpi] __do_sys_delete_module.isra.0+0x181/0x260 do_syscall_64+0x75/0x190 entry_SYSCALL_64_after_hwframe+0x76/0x7e The observation though is that driver objects are typically much longer lived than device objects. It is reasonable to perform lockless de-reference of a @driver pointer even if it is racing detach from a device. Given the infrequency of driver unregistration, use synchronize_rcu() in module_remove_driver() to close any potential races. It is potentially overkill to suffer synchronize_rcu() just to handle the rare module removal racing uevent_show() event. Thanks to Tetsuo Handa for the debug analysis of the syzbot report [1]. Fixes: c0a4009 ("drivers: core: synchronize really_probe() and dev_uevent()") Reported-by: [email protected] Reported-by: Tetsuo Handa <[email protected]> Closes: http://lore.kernel.org/[email protected] [1] Link: http://lore.kernel.org/[email protected] Cc: [email protected] Cc: Ashish Sangwan <[email protected]> Cc: Namjae Jeon <[email protected]> Cc: Dirk Behme <[email protected]> Cc: Greg Kroah-Hartman <[email protected]> Cc: Rafael J. Wysocki <[email protected]> Signed-off-by: Dan Williams <[email protected]> Link: https://lore.kernel.org/r/172081332794.577428.9738802016494057132.stgit@dwillia2-xfh.jf.intel.com Signed-off-by: Greg Kroah-Hartman <[email protected]>

@Dev-

commit 15fffc6 upstream. uevent_show() wants to de-reference dev->driver->name. There is no clean way for a device attribute to de-reference dev->driver unless that attribute is defined via (struct device_driver).dev_groups. Instead, the anti-pattern of taking the device_lock() in the attribute handler risks deadlocks with code paths that remove device attributes while holding the lock. This deadlock is typically invisible to lockdep given the device_lock() is marked lockdep_set_novalidate_class(), but some subsystems allocate a local lockdep key for @Dev->mutex to reveal reports of the form: ====================================================== WARNING: possible circular locking dependency detected 6.10.0-rc7+ torvalds#275 Tainted: G OE N ------------------------------------------------------ modprobe/2374 is trying to acquire lock: ffff8c2270070de0 (kn->active#6){++++}-{0:0}, at: __kernfs_remove+0xde/0x220 but task is already holding lock: ffff8c22016e88f8 (&cxl_root_key){+.+.}-{3:3}, at: device_release_driver_internal+0x39/0x210 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (&cxl_root_key){+.+.}-{3:3}: __mutex_lock+0x99/0xc30 uevent_show+0xac/0x130 dev_attr_show+0x18/0x40 sysfs_kf_seq_show+0xac/0xf0 seq_read_iter+0x110/0x450 vfs_read+0x25b/0x340 ksys_read+0x67/0xf0 do_syscall_64+0x75/0x190 entry_SYSCALL_64_after_hwframe+0x76/0x7e -> #0 (kn->active#6){++++}-{0:0}: __lock_acquire+0x121a/0x1fa0 lock_acquire+0xd6/0x2e0 kernfs_drain+0x1e9/0x200 __kernfs_remove+0xde/0x220 kernfs_remove_by_name_ns+0x5e/0xa0 device_del+0x168/0x410 device_unregister+0x13/0x60 devres_release_all+0xb8/0x110 device_unbind_cleanup+0xe/0x70 device_release_driver_internal+0x1c7/0x210 driver_detach+0x47/0x90 bus_remove_driver+0x6c/0xf0 cxl_acpi_exit+0xc/0x11 [cxl_acpi] __do_sys_delete_module.isra.0+0x181/0x260 do_syscall_64+0x75/0x190 entry_SYSCALL_64_after_hwframe+0x76/0x7e The observation though is that driver objects are typically much longer lived than device objects. It is reasonable to perform lockless de-reference of a @driver pointer even if it is racing detach from a device. Given the infrequency of driver unregistration, use synchronize_rcu() in module_remove_driver() to close any potential races. It is potentially overkill to suffer synchronize_rcu() just to handle the rare module removal racing uevent_show() event. Thanks to Tetsuo Handa for the debug analysis of the syzbot report [1]. Fixes: c0a4009 ("drivers: core: synchronize really_probe() and dev_uevent()") Reported-by: [email protected] Reported-by: Tetsuo Handa <[email protected]> Closes: http://lore.kernel.org/[email protected] [1] Link: http://lore.kernel.org/[email protected] Cc: [email protected] Cc: Ashish Sangwan <[email protected]> Cc: Namjae Jeon <[email protected]> Cc: Dirk Behme <[email protected]> Cc: Greg Kroah-Hartman <[email protected]> Cc: Rafael J. Wysocki <[email protected]> Signed-off-by: Dan Williams <[email protected]> Link: https://lore.kernel.org/r/172081332794.577428.9738802016494057132.stgit@dwillia2-xfh.jf.intel.com Signed-off-by: Greg Kroah-Hartman <[email protected]>

@Dev-

commit 15fffc6 upstream. uevent_show() wants to de-reference dev->driver->name. There is no clean way for a device attribute to de-reference dev->driver unless that attribute is defined via (struct device_driver).dev_groups. Instead, the anti-pattern of taking the device_lock() in the attribute handler risks deadlocks with code paths that remove device attributes while holding the lock. This deadlock is typically invisible to lockdep given the device_lock() is marked lockdep_set_novalidate_class(), but some subsystems allocate a local lockdep key for @Dev->mutex to reveal reports of the form: ====================================================== WARNING: possible circular locking dependency detected 6.10.0-rc7+ torvalds#275 Tainted: G OE N ------------------------------------------------------ modprobe/2374 is trying to acquire lock: ffff8c2270070de0 (kn->active#6){++++}-{0:0}, at: __kernfs_remove+0xde/0x220 but task is already holding lock: ffff8c22016e88f8 (&cxl_root_key){+.+.}-{3:3}, at: device_release_driver_internal+0x39/0x210 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (&cxl_root_key){+.+.}-{3:3}: __mutex_lock+0x99/0xc30 uevent_show+0xac/0x130 dev_attr_show+0x18/0x40 sysfs_kf_seq_show+0xac/0xf0 seq_read_iter+0x110/0x450 vfs_read+0x25b/0x340 ksys_read+0x67/0xf0 do_syscall_64+0x75/0x190 entry_SYSCALL_64_after_hwframe+0x76/0x7e -> #0 (kn->active#6){++++}-{0:0}: __lock_acquire+0x121a/0x1fa0 lock_acquire+0xd6/0x2e0 kernfs_drain+0x1e9/0x200 __kernfs_remove+0xde/0x220 kernfs_remove_by_name_ns+0x5e/0xa0 device_del+0x168/0x410 device_unregister+0x13/0x60 devres_release_all+0xb8/0x110 device_unbind_cleanup+0xe/0x70 device_release_driver_internal+0x1c7/0x210 driver_detach+0x47/0x90 bus_remove_driver+0x6c/0xf0 cxl_acpi_exit+0xc/0x11 [cxl_acpi] __do_sys_delete_module.isra.0+0x181/0x260 do_syscall_64+0x75/0x190 entry_SYSCALL_64_after_hwframe+0x76/0x7e The observation though is that driver objects are typically much longer lived than device objects. It is reasonable to perform lockless de-reference of a @driver pointer even if it is racing detach from a device. Given the infrequency of driver unregistration, use synchronize_rcu() in module_remove_driver() to close any potential races. It is potentially overkill to suffer synchronize_rcu() just to handle the rare module removal racing uevent_show() event. Thanks to Tetsuo Handa for the debug analysis of the syzbot report [1]. Fixes: c0a4009 ("drivers: core: synchronize really_probe() and dev_uevent()") Reported-by: [email protected] Reported-by: Tetsuo Handa <[email protected]> Closes: http://lore.kernel.org/[email protected] [1] Link: http://lore.kernel.org/[email protected] Cc: [email protected] Cc: Ashish Sangwan <[email protected]> Cc: Namjae Jeon <[email protected]> Cc: Dirk Behme <[email protected]> Cc: Greg Kroah-Hartman <[email protected]> Cc: Rafael J. Wysocki <[email protected]> Signed-off-by: Dan Williams <[email protected]> Link: https://lore.kernel.org/r/172081332794.577428.9738802016494057132.stgit@dwillia2-xfh.jf.intel.com Signed-off-by: Greg Kroah-Hartman <[email protected]>

Add test coverage for reservations beyond the ring buffer size in order to validate that bpf_ringbuf_reserve() rejects the request with NULL, all other ring buffer tests keep passing as well: # ./vmtest.sh -- ./test_progs -t ringbuf [...] ./test_progs -t ringbuf [ 1.165434] bpf_testmod: loading out-of-tree module taints kernel. [ 1.165825] bpf_testmod: module verification failed: signature and/or required key missing - tainting kernel [ 1.284001] tsc: Refined TSC clocksource calibration: 3407.982 MHz [ 1.286871] clocksource: tsc: mask: 0xffffffffffffffff max_cycles: 0x311fc34e357, max_idle_ns: 440795379773 ns [ 1.289555] clocksource: Switched to clocksource tsc torvalds#274/1 ringbuf/ringbuf:OK torvalds#274/2 ringbuf/ringbuf_n:OK torvalds#274/3 ringbuf/ringbuf_map_key:OK torvalds#274/4 ringbuf/ringbuf_write:OK torvalds#274 ringbuf:OK torvalds#275 ringbuf_multi:OK [...] Signed-off-by: Daniel Borkmann <[email protected]> Signed-off-by: Andrii Nakryiko <[email protected]> [ Test fixups for getting BPF CI back to work ] Signed-off-by: Daniel Borkmann <[email protected]> Link: https://lore.kernel.org/bpf/[email protected]

@Dev-

commit 15fffc6 upstream. uevent_show() wants to de-reference dev->driver->name. There is no clean way for a device attribute to de-reference dev->driver unless that attribute is defined via (struct device_driver).dev_groups. Instead, the anti-pattern of taking the device_lock() in the attribute handler risks deadlocks with code paths that remove device attributes while holding the lock. This deadlock is typically invisible to lockdep given the device_lock() is marked lockdep_set_novalidate_class(), but some subsystems allocate a local lockdep key for @Dev->mutex to reveal reports of the form: ====================================================== WARNING: possible circular locking dependency detected 6.10.0-rc7+ torvalds#275 Tainted: G OE N ------------------------------------------------------ modprobe/2374 is trying to acquire lock: ffff8c2270070de0 (kn->active#6){++++}-{0:0}, at: __kernfs_remove+0xde/0x220 but task is already holding lock: ffff8c22016e88f8 (&cxl_root_key){+.+.}-{3:3}, at: device_release_driver_internal+0x39/0x210 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (&cxl_root_key){+.+.}-{3:3}: __mutex_lock+0x99/0xc30 uevent_show+0xac/0x130 dev_attr_show+0x18/0x40 sysfs_kf_seq_show+0xac/0xf0 seq_read_iter+0x110/0x450 vfs_read+0x25b/0x340 ksys_read+0x67/0xf0 do_syscall_64+0x75/0x190 entry_SYSCALL_64_after_hwframe+0x76/0x7e -> #0 (kn->active#6){++++}-{0:0}: __lock_acquire+0x121a/0x1fa0 lock_acquire+0xd6/0x2e0 kernfs_drain+0x1e9/0x200 __kernfs_remove+0xde/0x220 kernfs_remove_by_name_ns+0x5e/0xa0 device_del+0x168/0x410 device_unregister+0x13/0x60 devres_release_all+0xb8/0x110 device_unbind_cleanup+0xe/0x70 device_release_driver_internal+0x1c7/0x210 driver_detach+0x47/0x90 bus_remove_driver+0x6c/0xf0 cxl_acpi_exit+0xc/0x11 [cxl_acpi] __do_sys_delete_module.isra.0+0x181/0x260 do_syscall_64+0x75/0x190 entry_SYSCALL_64_after_hwframe+0x76/0x7e The observation though is that driver objects are typically much longer lived than device objects. It is reasonable to perform lockless de-reference of a @driver pointer even if it is racing detach from a device. Given the infrequency of driver unregistration, use synchronize_rcu() in module_remove_driver() to close any potential races. It is potentially overkill to suffer synchronize_rcu() just to handle the rare module removal racing uevent_show() event. Thanks to Tetsuo Handa for the debug analysis of the syzbot report [1]. Fixes: c0a4009 ("drivers: core: synchronize really_probe() and dev_uevent()") Reported-by: [email protected] Reported-by: Tetsuo Handa <[email protected]> Closes: http://lore.kernel.org/[email protected] [1] Link: http://lore.kernel.org/[email protected] Cc: [email protected] Cc: Ashish Sangwan <[email protected]> Cc: Namjae Jeon <[email protected]> Cc: Dirk Behme <[email protected]> Cc: Greg Kroah-Hartman <[email protected]> Cc: Rafael J. Wysocki <[email protected]> Signed-off-by: Dan Williams <[email protected]> Link: https://lore.kernel.org/r/172081332794.577428.9738802016494057132.stgit@dwillia2-xfh.jf.intel.com Signed-off-by: Greg Kroah-Hartman <[email protected]>

@Dev-

commit 15fffc6 upstream. uevent_show() wants to de-reference dev->driver->name. There is no clean way for a device attribute to de-reference dev->driver unless that attribute is defined via (struct device_driver).dev_groups. Instead, the anti-pattern of taking the device_lock() in the attribute handler risks deadlocks with code paths that remove device attributes while holding the lock. This deadlock is typically invisible to lockdep given the device_lock() is marked lockdep_set_novalidate_class(), but some subsystems allocate a local lockdep key for @Dev->mutex to reveal reports of the form: ====================================================== WARNING: possible circular locking dependency detected 6.10.0-rc7+ torvalds#275 Tainted: G OE N ------------------------------------------------------ modprobe/2374 is trying to acquire lock: ffff8c2270070de0 (kn->active#6){++++}-{0:0}, at: __kernfs_remove+0xde/0x220 but task is already holding lock: ffff8c22016e88f8 (&cxl_root_key){+.+.}-{3:3}, at: device_release_driver_internal+0x39/0x210 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (&cxl_root_key){+.+.}-{3:3}: __mutex_lock+0x99/0xc30 uevent_show+0xac/0x130 dev_attr_show+0x18/0x40 sysfs_kf_seq_show+0xac/0xf0 seq_read_iter+0x110/0x450 vfs_read+0x25b/0x340 ksys_read+0x67/0xf0 do_syscall_64+0x75/0x190 entry_SYSCALL_64_after_hwframe+0x76/0x7e -> #0 (kn->active#6){++++}-{0:0}: __lock_acquire+0x121a/0x1fa0 lock_acquire+0xd6/0x2e0 kernfs_drain+0x1e9/0x200 __kernfs_remove+0xde/0x220 kernfs_remove_by_name_ns+0x5e/0xa0 device_del+0x168/0x410 device_unregister+0x13/0x60 devres_release_all+0xb8/0x110 device_unbind_cleanup+0xe/0x70 device_release_driver_internal+0x1c7/0x210 driver_detach+0x47/0x90 bus_remove_driver+0x6c/0xf0 cxl_acpi_exit+0xc/0x11 [cxl_acpi] __do_sys_delete_module.isra.0+0x181/0x260 do_syscall_64+0x75/0x190 entry_SYSCALL_64_after_hwframe+0x76/0x7e The observation though is that driver objects are typically much longer lived than device objects. It is reasonable to perform lockless de-reference of a @driver pointer even if it is racing detach from a device. Given the infrequency of driver unregistration, use synchronize_rcu() in module_remove_driver() to close any potential races. It is potentially overkill to suffer synchronize_rcu() just to handle the rare module removal racing uevent_show() event. Thanks to Tetsuo Handa for the debug analysis of the syzbot report [1]. Fixes: c0a4009 ("drivers: core: synchronize really_probe() and dev_uevent()") Reported-by: [email protected] Reported-by: Tetsuo Handa <[email protected]> Closes: http://lore.kernel.org/[email protected] [1] Link: http://lore.kernel.org/[email protected] Cc: [email protected] Cc: Ashish Sangwan <[email protected]> Cc: Namjae Jeon <[email protected]> Cc: Dirk Behme <[email protected]> Cc: Greg Kroah-Hartman <[email protected]> Cc: Rafael J. Wysocki <[email protected]> Signed-off-by: Dan Williams <[email protected]> Link: https://lore.kernel.org/r/172081332794.577428.9738802016494057132.stgit@dwillia2-xfh.jf.intel.com Signed-off-by: Greg Kroah-Hartman <[email protected]>

@Dev-

commit 15fffc6 upstream. uevent_show() wants to de-reference dev->driver->name. There is no clean way for a device attribute to de-reference dev->driver unless that attribute is defined via (struct device_driver).dev_groups. Instead, the anti-pattern of taking the device_lock() in the attribute handler risks deadlocks with code paths that remove device attributes while holding the lock. This deadlock is typically invisible to lockdep given the device_lock() is marked lockdep_set_novalidate_class(), but some subsystems allocate a local lockdep key for @Dev->mutex to reveal reports of the form: ====================================================== WARNING: possible circular locking dependency detected 6.10.0-rc7+ torvalds#275 Tainted: G OE N ------------------------------------------------------ modprobe/2374 is trying to acquire lock: ffff8c2270070de0 (kn->active#6){++++}-{0:0}, at: __kernfs_remove+0xde/0x220 but task is already holding lock: ffff8c22016e88f8 (&cxl_root_key){+.+.}-{3:3}, at: device_release_driver_internal+0x39/0x210 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (&cxl_root_key){+.+.}-{3:3}: __mutex_lock+0x99/0xc30 uevent_show+0xac/0x130 dev_attr_show+0x18/0x40 sysfs_kf_seq_show+0xac/0xf0 seq_read_iter+0x110/0x450 vfs_read+0x25b/0x340 ksys_read+0x67/0xf0 do_syscall_64+0x75/0x190 entry_SYSCALL_64_after_hwframe+0x76/0x7e -> #0 (kn->active#6){++++}-{0:0}: __lock_acquire+0x121a/0x1fa0 lock_acquire+0xd6/0x2e0 kernfs_drain+0x1e9/0x200 __kernfs_remove+0xde/0x220 kernfs_remove_by_name_ns+0x5e/0xa0 device_del+0x168/0x410 device_unregister+0x13/0x60 devres_release_all+0xb8/0x110 device_unbind_cleanup+0xe/0x70 device_release_driver_internal+0x1c7/0x210 driver_detach+0x47/0x90 bus_remove_driver+0x6c/0xf0 cxl_acpi_exit+0xc/0x11 [cxl_acpi] __do_sys_delete_module.isra.0+0x181/0x260 do_syscall_64+0x75/0x190 entry_SYSCALL_64_after_hwframe+0x76/0x7e The observation though is that driver objects are typically much longer lived than device objects. It is reasonable to perform lockless de-reference of a @driver pointer even if it is racing detach from a device. Given the infrequency of driver unregistration, use synchronize_rcu() in module_remove_driver() to close any potential races. It is potentially overkill to suffer synchronize_rcu() just to handle the rare module removal racing uevent_show() event. Thanks to Tetsuo Handa for the debug analysis of the syzbot report [1]. Fixes: c0a4009 ("drivers: core: synchronize really_probe() and dev_uevent()") Reported-by: [email protected] Reported-by: Tetsuo Handa <[email protected]> Closes: http://lore.kernel.org/[email protected] [1] Link: http://lore.kernel.org/[email protected] Cc: [email protected] Cc: Ashish Sangwan <[email protected]> Cc: Namjae Jeon <[email protected]> Cc: Dirk Behme <[email protected]> Cc: Greg Kroah-Hartman <[email protected]> Cc: Rafael J. Wysocki <[email protected]> Signed-off-by: Dan Williams <[email protected]> Link: https://lore.kernel.org/r/172081332794.577428.9738802016494057132.stgit@dwillia2-xfh.jf.intel.com Signed-off-by: Greg Kroah-Hartman <[email protected]>

@Dev-

commit 15fffc6 upstream. uevent_show() wants to de-reference dev->driver->name. There is no clean way for a device attribute to de-reference dev->driver unless that attribute is defined via (struct device_driver).dev_groups. Instead, the anti-pattern of taking the device_lock() in the attribute handler risks deadlocks with code paths that remove device attributes while holding the lock. This deadlock is typically invisible to lockdep given the device_lock() is marked lockdep_set_novalidate_class(), but some subsystems allocate a local lockdep key for @Dev->mutex to reveal reports of the form: ====================================================== WARNING: possible circular locking dependency detected 6.10.0-rc7+ torvalds#275 Tainted: G OE N ------------------------------------------------------ modprobe/2374 is trying to acquire lock: ffff8c2270070de0 (kn->active#6){++++}-{0:0}, at: __kernfs_remove+0xde/0x220 but task is already holding lock: ffff8c22016e88f8 (&cxl_root_key){+.+.}-{3:3}, at: device_release_driver_internal+0x39/0x210 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (&cxl_root_key){+.+.}-{3:3}: __mutex_lock+0x99/0xc30 uevent_show+0xac/0x130 dev_attr_show+0x18/0x40 sysfs_kf_seq_show+0xac/0xf0 seq_read_iter+0x110/0x450 vfs_read+0x25b/0x340 ksys_read+0x67/0xf0 do_syscall_64+0x75/0x190 entry_SYSCALL_64_after_hwframe+0x76/0x7e -> #0 (kn->active#6){++++}-{0:0}: __lock_acquire+0x121a/0x1fa0 lock_acquire+0xd6/0x2e0 kernfs_drain+0x1e9/0x200 __kernfs_remove+0xde/0x220 kernfs_remove_by_name_ns+0x5e/0xa0 device_del+0x168/0x410 device_unregister+0x13/0x60 devres_release_all+0xb8/0x110 device_unbind_cleanup+0xe/0x70 device_release_driver_internal+0x1c7/0x210 driver_detach+0x47/0x90 bus_remove_driver+0x6c/0xf0 cxl_acpi_exit+0xc/0x11 [cxl_acpi] __do_sys_delete_module.isra.0+0x181/0x260 do_syscall_64+0x75/0x190 entry_SYSCALL_64_after_hwframe+0x76/0x7e The observation though is that driver objects are typically much longer lived than device objects. It is reasonable to perform lockless de-reference of a @driver pointer even if it is racing detach from a device. Given the infrequency of driver unregistration, use synchronize_rcu() in module_remove_driver() to close any potential races. It is potentially overkill to suffer synchronize_rcu() just to handle the rare module removal racing uevent_show() event. Thanks to Tetsuo Handa for the debug analysis of the syzbot report [1]. Fixes: c0a4009 ("drivers: core: synchronize really_probe() and dev_uevent()") Reported-by: [email protected] Reported-by: Tetsuo Handa <[email protected]> Closes: http://lore.kernel.org/[email protected] [1] Link: http://lore.kernel.org/[email protected] Cc: [email protected] Cc: Ashish Sangwan <[email protected]> Cc: Namjae Jeon <[email protected]> Cc: Dirk Behme <[email protected]> Cc: Greg Kroah-Hartman <[email protected]> Cc: Rafael J. Wysocki <[email protected]> Signed-off-by: Dan Williams <[email protected]> Link: https://lore.kernel.org/r/172081332794.577428.9738802016494057132.stgit@dwillia2-xfh.jf.intel.com Signed-off-by: Greg Kroah-Hartman <[email protected]>

@Dev-

uevent_show() wants to de-reference dev->driver->name. There is no clean way for a device attribute to de-reference dev->driver unless that attribute is defined via (struct device_driver).dev_groups. Instead, the anti-pattern of taking the device_lock() in the attribute handler risks deadlocks with code paths that remove device attributes while holding the lock. This deadlock is typically invisible to lockdep given the device_lock() is marked lockdep_set_novalidate_class(), but some subsystems allocate a local lockdep key for @Dev->mutex to reveal reports of the form: ====================================================== WARNING: possible circular locking dependency detected 6.10.0-rc7+ torvalds#275 Tainted: G OE N ------------------------------------------------------ modprobe/2374 is trying to acquire lock: ffff8c2270070de0 (kn->active#6){++++}-{0:0}, at: __kernfs_remove+0xde/0x220 but task is already holding lock: ffff8c22016e88f8 (&cxl_root_key){+.+.}-{3:3}, at: device_release_driver_internal+0x39/0x210 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (&cxl_root_key){+.+.}-{3:3}: __mutex_lock+0x99/0xc30 uevent_show+0xac/0x130 dev_attr_show+0x18/0x40 sysfs_kf_seq_show+0xac/0xf0 seq_read_iter+0x110/0x450 vfs_read+0x25b/0x340 ksys_read+0x67/0xf0 do_syscall_64+0x75/0x190 entry_SYSCALL_64_after_hwframe+0x76/0x7e -> #0 (kn->active#6){++++}-{0:0}: __lock_acquire+0x121a/0x1fa0 lock_acquire+0xd6/0x2e0 kernfs_drain+0x1e9/0x200 __kernfs_remove+0xde/0x220 kernfs_remove_by_name_ns+0x5e/0xa0 device_del+0x168/0x410 device_unregister+0x13/0x60 devres_release_all+0xb8/0x110 device_unbind_cleanup+0xe/0x70 device_release_driver_internal+0x1c7/0x210 driver_detach+0x47/0x90 bus_remove_driver+0x6c/0xf0 cxl_acpi_exit+0xc/0x11 [cxl_acpi] __do_sys_delete_module.isra.0+0x181/0x260 do_syscall_64+0x75/0x190 entry_SYSCALL_64_after_hwframe+0x76/0x7e The observation though is that driver objects are typically much longer lived than device objects. It is reasonable to perform lockless de-reference of a @driver pointer even if it is racing detach from a device. Given the infrequency of driver unregistration, use synchronize_rcu() in module_remove_driver() to close any potential races. It is potentially overkill to suffer synchronize_rcu() just to handle the rare module removal racing uevent_show() event. Thanks to Tetsuo Handa for the debug analysis of the syzbot report [1]. Fixes: c0a4009 ("drivers: core: synchronize really_probe() and dev_uevent()") Reported-by: [email protected] Reported-by: Tetsuo Handa <[email protected]> Closes: http://lore.kernel.org/[email protected] [1] Link: http://lore.kernel.org/[email protected] Cc: [email protected] Cc: Ashish Sangwan <[email protected]> Cc: Namjae Jeon <[email protected]> Cc: Dirk Behme <[email protected]> Cc: Greg Kroah-Hartman <[email protected]> Cc: Rafael J. Wysocki <[email protected]> Signed-off-by: Dan Williams <[email protected]> Link: https://lore.kernel.org/r/172081332794.577428.9738802016494057132.stgit@dwillia2-xfh.jf.intel.com Signed-off-by: Greg Kroah-Hartman <[email protected]>

When we kexec into a new kernel from an old kernel with KHO enabled, the new kernel allocates vmemmap from the scratch area. If the KHO scratch size is too small, vmemmap allocation would fail and cause kernel panic, like the following, [ 0.027133] Faking a node at [mem 0x0000000000000000-0x00000004ffffffff] [ 0.027877] NODE_DATA(0) allocated [mem 0x4e4bd5a00-0x4e4bfffff] [ 0.029696] sparse_init_nid: node[0] memory map backing failed. Some memory will not be available. [ 0.029698] Zone ranges: [ 0.030974] DMA [mem 0x0000000000001000-0x0000000000ffffff] [ 0.031627] DMA32 [mem 0x0000000001000000-0x00000000ffffffff] [ 0.032281] Normal [mem 0x0000000100000000-0x00000004ffffffff] [ 0.032930] Device empty [ 0.033251] Movable zone start for each node [ 0.033710] Early memory node ranges [ 0.034108] node 0: [mem 0x0000000000001000-0x000000000007ffff] [ 0.034801] node 0: [mem 0x0000000000100000-0x00000000773fffff] [ 0.035461] node 0: [mem 0x0000000077400000-0x00000000775fffff] [ 0.036116] node 0: [mem 0x0000000077600000-0x000000007fffffff] [ 0.036768] node 0: [mem 0x0000000100000000-0x00000004ccbfffff] [ 0.037423] node 0: [mem 0x00000004ccc00000-0x00000004e4bfffff] [ 0.038111] BUG: kernel NULL pointer dereference, address: 0000000000000010 [ 0.038880] #PF: supervisor write access in kernel mode [ 0.039474] #PF: error_code(0x0002) - not-present page [ 0.040056] PGD 0 P4D 0 [ 0.040335] Oops: Oops: 0002 [#1] SMP [ 0.040745] CPU: 0 UID: 0 PID: 0 Comm: swapper Not tainted 6.15.0-rc4+ torvalds#275 NONE [ 0.041541] RIP: 0010:__bitmap_set+0x2b/0x80 [ 0.041992] Code: 0f 1e fa 55 48 89 e5 89 f1 89 f0 c1 e8 06 48 8d 04 c7 48 c7 c7 ff ff ff ff 48 d3 e7 41 89 f0 41 83 c8 c0 44 89 c6 01 d6 78 43 <48> 09 38 48 83 c0 08 83 fe 40 72 1a 41 8d 3c 10 83 c7 40 48 c7 00 [ 0.043986] RSP: 0000:ffffffff96203df0 EFLAGS: 00010047 [ 0.044546] RAX: 0000000000000010 RBX: 000000000000cc00 RCX: 0000000000000000 [ 0.045311] RDX: 0000000000000040 RSI: 0000000000000000 RDI: ffffffffffffffff [ 0.046075] RBP: ffffffff96203df0 R08: 00000000ffffffc0 R09: ffffffff9626c950 [ 0.046830] R10: 000000000002fffd R11: 0000000000000004 R12: 0000000000008000 [ 0.047574] R13: 0000000000000000 R14: 000000000000003f R15: 000000000000009b [ 0.048313] FS: 0000000000000000(0000) GS:0000000000000000(0000) knlGS:0000000000000000 [ 0.049151] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 0.049751] CR2: 0000000000000010 CR3: 00000004d123e000 CR4: 00000000000200b0 [ 0.050494] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 0.051238] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 0.051978] Call Trace: [ 0.052235] <TASK> [ 0.052455] subsection_map_init+0xe4/0x130 [ 0.052891] free_area_init+0x217/0x3d0 [ 0.053290] zone_sizes_init+0x5e/0x80 [ 0.053682] paging_init+0x27/0x30 [ 0.054046] setup_arch+0x307/0x3e0 [ 0.054422] start_kernel+0x59/0x390 [ 0.054820] x86_64_start_reservations+0x28/0x30 [ 0.055307] x86_64_start_kernel+0x70/0x80 [ 0.055736] common_startup_64+0x13b/0x140 [ 0.056165] </TASK> [ 0.056392] CR2: 0000000000000010 [ 0.056737] ---[ end trace 0000000000000000 ]--- [ 0.057218] RIP: 0010:__bitmap_set+0x2b/0x80 [ 0.057667] Code: 0f 1e fa 55 48 89 e5 89 f1 89 f0 c1 e8 06 48 8d 04 c7 48 c7 c7 ff ff ff ff 48 d3 e7 41 89 f0 41 83 c8 c0 44 89 c6 01 d6 78 43 <48> 09 38 48 83 c0 08 83 fe 40 72 1a 41 8d 3c 10 83 c7 40 48 c7 00 [ 0.059650] RSP: 0000:ffffffff96203df0 EFLAGS: 00010047 [ 0.060218] RAX: 0000000000000010 RBX: 000000000000cc00 RCX: 0000000000000000 [ 0.060985] RDX: 0000000000000040 RSI: 0000000000000000 RDI: ffffffffffffffff [ 0.061728] RBP: ffffffff96203df0 R08: 00000000ffffffc0 R09: ffffffff9626c950 [ 0.062486] R10: 000000000002fffd R11: 0000000000000004 R12: 0000000000008000 [ 0.063228] R13: 0000000000000000 R14: 000000000000003f R15: 000000000000009b [ 0.063968] FS: 0000000000000000(0000) GS:0000000000000000(0000) knlGS:0000000000000000 [ 0.064812] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 0.065423] CR2: 0000000000000010 CR3: 00000004d123e000 CR4: 00000000000200b0 [ 0.066175] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 0.066926] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 0.067678] Kernel panic - not syncing: Attempted to kill the idle task! [ 0.068403] ---[ end Kernel panic - not syncing: Attempted to kill the idle task! ]--- The panic above can be easily reproduced by the following steps, 1. booti a VM with 20GiB physical memory (or larger) and kernel command line "kho=on kho_scratch=kho=on kho_scratch=2m,256m,128m", 2. echo 1 > /sys/kernel/debug/kho/out/finalize 3. kexec to a new kernel, The current panic log above is confusing and it's hard to find the root cause. Add an error log to make it easier to debug such kinds of panics. Signed-off-by: Changyuan Lyu <[email protected]>

When we kexec into a new kernel from an old kernel with KHO enabled, the new kernel allocates vmemmap in the scratch area. If the KHO scratch size is too small, vmemmap allocation would fail and cause kernel panic, like the following, [ 0.027133] Faking a node at [mem 0x0000000000000000-0x00000004ffffffff] [ 0.027877] NODE_DATA(0) allocated [mem 0x4e4bd5a00-0x4e4bfffff] [ 0.029696] sparse_init_nid: node[0] memory map backing failed. Some memory will not be available. [ 0.029698] Zone ranges: [ 0.030974] DMA [mem 0x0000000000001000-0x0000000000ffffff] [ 0.031627] DMA32 [mem 0x0000000001000000-0x00000000ffffffff] [ 0.032281] Normal [mem 0x0000000100000000-0x00000004ffffffff] [ 0.032930] Device empty [ 0.033251] Movable zone start for each node [ 0.033710] Early memory node ranges [ 0.034108] node 0: [mem 0x0000000000001000-0x000000000007ffff] [ 0.034801] node 0: [mem 0x0000000000100000-0x00000000773fffff] [ 0.035461] node 0: [mem 0x0000000077400000-0x00000000775fffff] [ 0.036116] node 0: [mem 0x0000000077600000-0x000000007fffffff] [ 0.036768] node 0: [mem 0x0000000100000000-0x00000004ccbfffff] [ 0.037423] node 0: [mem 0x00000004ccc00000-0x00000004e4bfffff] [ 0.038111] BUG: kernel NULL pointer dereference, address: 0000000000000010 [ 0.038880] #PF: supervisor write access in kernel mode [ 0.039474] #PF: error_code(0x0002) - not-present page [ 0.040056] PGD 0 P4D 0 [ 0.040335] Oops: Oops: 0002 [#1] SMP [ 0.040745] CPU: 0 UID: 0 PID: 0 Comm: swapper Not tainted 6.15.0-rc4+ torvalds#275 NONE [ 0.041541] RIP: 0010:__bitmap_set+0x2b/0x80 [ 0.041992] Code: 0f 1e fa 55 48 89 e5 89 f1 89 f0 c1 e8 06 48 8d 04 c7 48 c7 c7 ff ff ff ff 48 d3 e7 41 89 f0 41 83 c8 c0 44 89 c6 01 d6 78 43 <48> 09 38 48 83 c0 08 83 fe 40 72 1a 41 8d 3c 10 83 c7 40 48 c7 00 [ 0.043986] RSP: 0000:ffffffff96203df0 EFLAGS: 00010047 [ 0.044546] RAX: 0000000000000010 RBX: 000000000000cc00 RCX: 0000000000000000 [ 0.045311] RDX: 0000000000000040 RSI: 0000000000000000 RDI: ffffffffffffffff [ 0.046075] RBP: ffffffff96203df0 R08: 00000000ffffffc0 R09: ffffffff9626c950 [ 0.046830] R10: 000000000002fffd R11: 0000000000000004 R12: 0000000000008000 [ 0.047574] R13: 0000000000000000 R14: 000000000000003f R15: 000000000000009b [ 0.048313] FS: 0000000000000000(0000) GS:0000000000000000(0000) knlGS:0000000000000000 [ 0.049151] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 0.049751] CR2: 0000000000000010 CR3: 00000004d123e000 CR4: 00000000000200b0 [ 0.050494] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 0.051238] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 0.051978] Call Trace: [ 0.052235] <TASK> [ 0.052455] subsection_map_init+0xe4/0x130 [ 0.052891] free_area_init+0x217/0x3d0 [ 0.053290] zone_sizes_init+0x5e/0x80 [ 0.053682] paging_init+0x27/0x30 [ 0.054046] setup_arch+0x307/0x3e0 [ 0.054422] start_kernel+0x59/0x390 [ 0.054820] x86_64_start_reservations+0x28/0x30 [ 0.055307] x86_64_start_kernel+0x70/0x80 [ 0.055736] common_startup_64+0x13b/0x140 [ 0.056165] </TASK> [ 0.056392] CR2: 0000000000000010 [ 0.056737] ---[ end trace 0000000000000000 ]--- [ 0.057218] RIP: 0010:__bitmap_set+0x2b/0x80 [ 0.057667] Code: 0f 1e fa 55 48 89 e5 89 f1 89 f0 c1 e8 06 48 8d 04 c7 48 c7 c7 ff ff ff ff 48 d3 e7 41 89 f0 41 83 c8 c0 44 89 c6 01 d6 78 43 <48> 09 38 48 83 c0 08 83 fe 40 72 1a 41 8d 3c 10 83 c7 40 48 c7 00 [ 0.059650] RSP: 0000:ffffffff96203df0 EFLAGS: 00010047 [ 0.060218] RAX: 0000000000000010 RBX: 000000000000cc00 RCX: 0000000000000000 [ 0.060985] RDX: 0000000000000040 RSI: 0000000000000000 RDI: ffffffffffffffff [ 0.061728] RBP: ffffffff96203df0 R08: 00000000ffffffc0 R09: ffffffff9626c950 [ 0.062486] R10: 000000000002fffd R11: 0000000000000004 R12: 0000000000008000 [ 0.063228] R13: 0000000000000000 R14: 000000000000003f R15: 000000000000009b [ 0.063968] FS: 0000000000000000(0000) GS:0000000000000000(0000) knlGS:0000000000000000 [ 0.064812] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 0.065423] CR2: 0000000000000010 CR3: 00000004d123e000 CR4: 00000000000200b0 [ 0.066175] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 0.066926] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 0.067678] Kernel panic - not syncing: Attempted to kill the idle task! [ 0.068403] ---[ end Kernel panic - not syncing: Attempted to kill the idle task! ]--- The panic above can be easily reproduced by the following steps, 1. boot a VM with 20GiB physical memory (or larger) and kernel command line "kho=on kho_scratch=2m,256m,128m" 2. echo 1 > /sys/kernel/debug/kho/out/finalize 3. kexec to a new kernel The current panic log above is confusing and it's hard to find the root cause. Add an error log to make it easier to debug such kind of panics. Fixes: d59f43b ("memblock: add support for scratch memory") Signed-off-by: Changyuan Lyu <[email protected]>

Merge pull request #1 from torvalds/master

550e249

update

nanszy closed this Apr 13, 2016

laijs pushed a commit to laijs/linux that referenced this pull request Feb 13, 2017

Merge pull request torvalds#275 from libos-nuse/feature-dhclient

e5d3c5c

lkl: add dhcp client option

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Merge pull request #1 from torvalds/master #275

Merge pull request #1 from torvalds/master #275

Uh oh!

nanszy commented Apr 13, 2016

Uh oh!

Uh oh!

Merge pull request #1 from torvalds/master #275

Merge pull request #1 from torvalds/master #275

Uh oh!

Conversation

nanszy commented Apr 13, 2016

Uh oh!

Uh oh!