need supporte cgroups V2 #10

mxsky01 · 2022-09-21T09:43:57Z

need cgroups V2 to freeze apps，but this kernel jut supporte cgroup v1

Like other csets, init_css_set's dfl_cgrp is initialized when the cset gets linked. init_css_set gets linked in cgroup_init(). This has been fine till now but the recently added basic CPU usage accounting may end up accessing dfl_cgrp of init before cgroup_init() leading to the following oops. SELinux: Initializing. BUG: unable to handle kernel NULL pointer dereference at 00000000000000b0 IP: account_system_index_time+0x60/0x90 PGD 0 P4D 0 Oops: 0000 [#1] SMP Modules linked in: CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.14.0-rc2-00003-g041cd64 #10 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS +1.9.3-20161025_171302-gandalf 04/01/2014 task: ffffffff81e10480 task.stack: ffffffff81e00000 RIP: 0010:account_system_index_time+0x60/0x90 RSP: 0000:ffff880011e03cb8 EFLAGS: 00010002 RAX: ffffffff81ef8800 RBX: ffffffff81e10480 RCX: 0000000000000003 RDX: 0000000000000000 RSI: 00000000000f4240 RDI: 0000000000000000 RBP: ffff880011e03cc0 R08: 0000000000010000 R09: 0000000000000000 R10: 0000000000000020 R11: 0000003b9aca0000 R12: 000000000001c100 R13: 0000000000000000 R14: ffffffff81e10480 R15: ffffffff81e03cd8 FS: 0000000000000000(0000) GS:ffff880011e00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000000000b0 CR3: 0000000001e09000 CR4: 00000000000006b0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <IRQ> account_system_time+0x45/0x60 account_process_tick+0x5a/0x140 update_process_times+0x22/0x60 tick_periodic+0x2b/0x90 tick_handle_periodic+0x25/0x70 timer_interrupt+0x15/0x20 __handle_irq_event_percpu+0x7e/0x1b0 handle_irq_event_percpu+0x23/0x60 handle_irq_event+0x42/0x70 handle_level_irq+0x83/0x100 handle_irq+0x6f/0x110 do_IRQ+0x46/0xd0 common_interrupt+0x9d/0x9d Fix it by statically initializing init_css_set.dfl_cgrp so that init's default cgroup is accessible from the get-go. Fixes: 041cd640b2f3 ("cgroup: Implement cgroup2 basic CPU usage accounting") Reported-by: “[email protected]” <[email protected]> Signed-off-by: Tejun Heo <[email protected]> Change-Id: Ia754e3d34561ff09db126712e1a40d993b28f5d9 (cherry picked from commit 38683148828165ea0b66ace93a9fedc2d3281e27) Bug: 154548692 Signed-off-by: Marco Ballesio <[email protected]> Signed-off-by: Fiqri Ardyansyah <[email protected]> Signed-off-by: Edwiin Kusuma Jaya <[email protected]>

[ Upstream commit 6b9dbedbe3499fef862c4dff5217cf91f34e43b3 ] pty_write() invokes kmalloc() which may invoke a normal printk() to print failure message. This can cause a deadlock in the scenario reported by syz-bot below: CPU0 CPU1 CPU2 ---- ---- ---- lock(console_owner); lock(&port_lock_key); lock(&port->lock); lock(&port_lock_key); lock(&port->lock); lock(console_owner); As commit dbdda842fe96 ("printk: Add console owner and waiter logic to load balance console writes") said, such deadlock can be prevented by using printk_deferred() in kmalloc() (which is invoked in the section guarded by the port->lock). But there are too many printk() on the kmalloc() path, and kmalloc() can be called from anywhere, so changing printk() to printk_deferred() is too complicated and inelegant. Therefore, this patch chooses to specify __GFP_NOWARN to kmalloc(), so that printk() will not be called, and this deadlock problem can be avoided. Syzbot reported the following lockdep error: ====================================================== WARNING: possible circular locking dependency detected 5.4.143-00237-g08ccc19a-dirty #10 Not tainted ------------------------------------------------------ syz-executor.4/29420 is trying to acquire lock: ffffffff8aedb2a0 (console_owner){....}-{0:0}, at: console_trylock_spinning kernel/printk/printk.c:1752 [inline] ffffffff8aedb2a0 (console_owner){....}-{0:0}, at: vprintk_emit+0x2ca/0x470 kernel/printk/printk.c:2023 but task is already holding lock: ffff8880119c9158 (&port->lock){-.-.}-{2:2}, at: pty_write+0xf4/0x1f0 drivers/tty/pty.c:120 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #2 (&port->lock){-.-.}-{2:2}: __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline] _raw_spin_lock_irqsave+0x35/0x50 kernel/locking/spinlock.c:159 tty_port_tty_get drivers/tty/tty_port.c:288 [inline] <-- lock(&port->lock); tty_port_default_wakeup+0x1d/0xb0 drivers/tty/tty_port.c:47 serial8250_tx_chars+0x530/0xa80 drivers/tty/serial/8250/8250_port.c:1767 serial8250_handle_irq.part.0+0x31f/0x3d0 drivers/tty/serial/8250/8250_port.c:1854 serial8250_handle_irq drivers/tty/serial/8250/8250_port.c:1827 [inline] <-- lock(&port_lock_key); serial8250_default_handle_irq+0xb2/0x220 drivers/tty/serial/8250/8250_port.c:1870 serial8250_interrupt+0xfd/0x200 drivers/tty/serial/8250/8250_core.c:126 __handle_irq_event_percpu+0x109/0xa50 kernel/irq/handle.c:156 [...] -> #1 (&port_lock_key){-.-.}-{2:2}: __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline] _raw_spin_lock_irqsave+0x35/0x50 kernel/locking/spinlock.c:159 serial8250_console_write+0x184/0xa40 drivers/tty/serial/8250/8250_port.c:3198 <-- lock(&port_lock_key); call_console_drivers kernel/printk/printk.c:1819 [inline] console_unlock+0x8cb/0xd00 kernel/printk/printk.c:2504 vprintk_emit+0x1b5/0x470 kernel/printk/printk.c:2024 <-- lock(console_owner); vprintk_func+0x8d/0x250 kernel/printk/printk_safe.c:394 printk+0xba/0xed kernel/printk/printk.c:2084 register_console+0x8b3/0xc10 kernel/printk/printk.c:2829 univ8250_console_init+0x3a/0x46 drivers/tty/serial/8250/8250_core.c:681 console_init+0x49d/0x6d3 kernel/printk/printk.c:2915 start_kernel+0x5e9/0x879 init/main.c:713 secondary_startup_64+0xa4/0xb0 arch/x86/kernel/head_64.S:241 -> #0 (console_owner){....}-{0:0}: [...] lock_acquire+0x127/0x340 kernel/locking/lockdep.c:4734 console_trylock_spinning kernel/printk/printk.c:1773 [inline] <-- lock(console_owner); vprintk_emit+0x307/0x470 kernel/printk/printk.c:2023 vprintk_func+0x8d/0x250 kernel/printk/printk_safe.c:394 printk+0xba/0xed kernel/printk/printk.c:2084 fail_dump lib/fault-inject.c:45 [inline] should_fail+0x67b/0x7c0 lib/fault-inject.c:144 __should_failslab+0x152/0x1c0 mm/failslab.c:33 should_failslab+0x5/0x10 mm/slab_common.c:1224 slab_pre_alloc_hook mm/slab.h:468 [inline] slab_alloc_node mm/slub.c:2723 [inline] slab_alloc mm/slub.c:2807 [inline] __kmalloc+0x72/0x300 mm/slub.c:3871 kmalloc include/linux/slab.h:582 [inline] tty_buffer_alloc+0x23f/0x2a0 drivers/tty/tty_buffer.c:175 __tty_buffer_request_room+0x156/0x2a0 drivers/tty/tty_buffer.c:273 tty_insert_flip_string_fixed_flag+0x93/0x250 drivers/tty/tty_buffer.c:318 tty_insert_flip_string include/linux/tty_flip.h:37 [inline] pty_write+0x126/0x1f0 drivers/tty/pty.c:122 <-- lock(&port->lock); n_tty_write+0xa7a/0xfc0 drivers/tty/n_tty.c:2356 do_tty_write drivers/tty/tty_io.c:961 [inline] tty_write+0x512/0x930 drivers/tty/tty_io.c:1045 __vfs_write+0x76/0x100 fs/read_write.c:494 [...] other info that might help us debug this: Chain exists of: console_owner --> &port_lock_key --> &port->lock Link: https://lkml.kernel.org/r/[email protected] Link: https://lkml.kernel.org/r/[email protected] Fixes: b6da31b2c07c ("tty: Fix data race in tty_insert_flip_string_fixed_flag") Signed-off-by: Qi Zheng <[email protected]> Acked-by: Jiri Slaby <[email protected]> Acked-by: Greg Kroah-Hartman <[email protected]> Cc: Akinobu Mita <[email protected]> Cc: Vlastimil Babka <[email protected]> Cc: Steven Rostedt (Google) <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Sasha Levin <[email protected]>

A transaction of type BINDER_TYPE_WEAK_HANDLE can fail to increment the reference for a node. In this case, the target proc normally releases the failed reference upon close as expected. However, if the target is dying in parallel the call will race with binder_deferred_release(), so the target could have released all of its references by now leaving the cleanup of the new failed reference unhandled. The transaction then ends and the target proc gets released making the ref->proc now a dangling pointer. Later on, ref->node is closed and we attempt to take spin_lock(&ref->proc->inner_lock), which leads to the use-after-free bug reported below. Let's fix this by cleaning up the failed reference on the spot instead of relying on the target to do so. ================================================================== BUG: KASAN: use-after-free in _raw_spin_lock+0xa8/0x150 Write of size 4 at addr ffff5ca207094238 by task kworker/1:0/590 CPU: 1 PID: 590 Comm: kworker/1:0 Not tainted 5.19.0-rc8 #10 Hardware name: linux,dummy-virt (DT) Workqueue: events binder_deferred_func Call trace: dump_backtrace.part.0+0x1d0/0x1e0 show_stack+0x18/0x70 dump_stack_lvl+0x68/0x84 print_report+0x2e4/0x61c kasan_report+0xa4/0x110 kasan_check_range+0xfc/0x1a4 __kasan_check_write+0x3c/0x50 _raw_spin_lock+0xa8/0x150 binder_deferred_func+0x5e0/0x9b0 process_one_work+0x38c/0x5f0 worker_thread+0x9c/0x694 kthread+0x188/0x190 ret_from_fork+0x10/0x20 Signed-off-by: Carlos Llamas <[email protected]> Acked-by: Christian Brauner (Microsoft) <[email protected]> Bug: 239630375 Link: https://lore.kernel.org/all/[email protected]/ Signed-off-by: Carlos Llamas <[email protected]> Change-Id: I5085dd0dc805a780a64c057e5819f82dd8f02868 (cherry picked from commit ae3fa5d16a02ba7c7b170e0e1ab56d6f0ba33964)

commit a0e44c64b6061dda7e00b7c458e4523e2331b739 upstream. A transaction of type BINDER_TYPE_WEAK_HANDLE can fail to increment the reference for a node. In this case, the target proc normally releases the failed reference upon close as expected. However, if the target is dying in parallel the call will race with binder_deferred_release(), so the target could have released all of its references by now leaving the cleanup of the new failed reference unhandled. The transaction then ends and the target proc gets released making the ref->proc now a dangling pointer. Later on, ref->node is closed and we attempt to take spin_lock(&ref->proc->inner_lock), which leads to the use-after-free bug reported below. Let's fix this by cleaning up the failed reference on the spot instead of relying on the target to do so. ================================================================== BUG: KASAN: use-after-free in _raw_spin_lock+0xa8/0x150 Write of size 4 at addr ffff5ca207094238 by task kworker/1:0/590 CPU: 1 PID: 590 Comm: kworker/1:0 Not tainted 5.19.0-rc8 #10 Hardware name: linux,dummy-virt (DT) Workqueue: events binder_deferred_func Call trace: dump_backtrace.part.0+0x1d0/0x1e0 show_stack+0x18/0x70 dump_stack_lvl+0x68/0x84 print_report+0x2e4/0x61c kasan_report+0xa4/0x110 kasan_check_range+0xfc/0x1a4 __kasan_check_write+0x3c/0x50 _raw_spin_lock+0xa8/0x150 binder_deferred_func+0x5e0/0x9b0 process_one_work+0x38c/0x5f0 worker_thread+0x9c/0x694 kthread+0x188/0x190 ret_from_fork+0x10/0x20 Acked-by: Christian Brauner (Microsoft) <[email protected]> Signed-off-by: Carlos Llamas <[email protected]> Cc: stable <[email protected]> # 4.14+ Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

* doesn't work and ends up affining it to all cores instead * additionally affine spi irq's to big cluster (based on sultan's commit) Log: [ 0.529834] IRQ-234 not set for request with affinity flag [ 0.529848] ------------[ cut here ]------------ [ 0.529863] WARNING: CPU: 3 PID: 251 at kernel/power/qos.c:622 pm_qos_add_request+0x1b0/0x240 [ 0.529864] Modules linked in: [ 0.529873] CPU: 3 PID: 251 Comm: kworker/u16:7 Tainted: G S 4.14.227-QuicksilveR\xe2\x84\xa2-v2.5/92d5181c #10 [ 0.529875] Hardware name: Qualcomm Technologies, Inc. trinket pm6125 + pmi632 IDP (DT) [ 0.529889] Workqueue: events_unbound async_run_entry_fn [ 0.529893] task: 000000008c9ff257 task.stack: 00000000f1674f29 [ 0.529897] pc : pm_qos_add_request+0x1b0/0x240 [ 0.529900] lr : pm_qos_add_request+0x1b0/0x240 [ 0.529903] sp : ffffff800fc43bd0 pstate : 60000005 [ 0.529905] x29: ffffff800fc43bd0 x28: ffffffedb902b030 [ 0.529908] x27: ffffff9363206000 x26: ffffffedb932c880 [ 0.529912] x25: 00000000bb008905 x24: 0000000000000051 [ 0.529916] x23: 0000000000000001 x22: ffffff936373b000 [ 0.529919] x21: 0000000000000001 x20: ffffffedb7a5e7d8 [ 0.529923] x19: 00000000ffffffff x18: ffffff93634a728c [ 0.529926] x17: 00000000001f2e20 x16: 0000000000000000 [ 0.529930] x15: 0000000000000000 x14: 0000000000000082 [ 0.529933] x13: 0000000000000040 x12: 0000000000000000 [ 0.529937] x11: 0000000000000000 x10: ffffffffffffffff [ 0.529940] x9 : 69f5cb5eed6dba00 x8 : 69f5cb5eed6dba00 [ 0.529944] x7 : 0000000000000000 x6 : ffffff93634b44a2 [ 0.529947] x5 : 0000000000000000 x4 : 0000000000000000 [ 0.529951] x3 : 0000000000006761 x2 : 0000000000000002 [ 0.529954] x1 : 0000000000000000 x0 : 000000000000002e [ 0.529961] \x0aPC: 0xffffff9360f35f88: [ 0.529964] 5f88 a94257f6 f9400bf7 a8c47bfd d65f03c0 a9434ff4 a94257f6 f9400bf7 a8c47bfd [ 0.529975] 5fa8 d65f03c0 b9401281 f000cc20 52801fe8 91350c00 b900029f f9000688 9400131f [ 0.529986] 5fc8 d4210000 17ffffcd b000eca9 d538d088 91006129 900116ca b8696908 913d014a [ 0.529996] 5fe8 1100fd09 7100011f 1a88b129 13067d29 f869d949 9ac82528 3607f848 d5384116 [ 0.530009] \x0aLR: 0xffffff9360f35f88: [ 0.530010] 5f88 a94257f6 f9400bf7 a8c47bfd d65f03c0 a9434ff4 a94257f6 f9400bf7 a8c47bfd [ 0.530019] 5fa8 d65f03c0 b9401281 f000cc20 52801fe8 91350c00 b900029f f9000688 9400131f [ 0.530029] 5fc8 d4210000 17ffffcd b000eca9 d538d088 91006129 900116ca b8696908 913d014a [ 0.530039] 5fe8 1100fd09 7100011f 1a88b129 13067d29 f869d949 9ac82528 3607f848 d5384116 [ 0.530049] \x0aSP: 0xffffff800fc43b90: [ 0.530050] 3b90 60f35fc8 ffffff93 60000005 00000000 ffffffc8 ffffff80 ed6dba00 69f5cb5e [ 0.530060] 3bb0 ffffffff ffffffff 60f35fc8 ffffff93 0fc43bd0 ffffff80 60f35fc8 ffffff93 [ 0.530070] 3bd0 0fc43c10 ffffff80 61860b58 ffffff93 00000001 00000000 61860b1c ffffff93 [ 0.530079] 3bf0 6373b000 ffffff93 00000002 00000000 ffffffff 00000000 b7de6800 ffffffed [ 0.530089] [ 0.530091] Call trace: [ 0.530096] pm_qos_add_request+0x1b0/0x240 [ 0.530102] nvt_ts_probe+0x8a0/0xd10 [ 0.530108] spi_drv_probe+0xd4/0x100 [ 0.530114] driver_probe_device+0x424/0x460 [ 0.530117] __driver_attach+0xb8/0xe8 [ 0.530122] bus_for_each_dev+0xc0/0xf0 [ 0.530125] driver_attach+0x20/0x28 [ 0.530127] driver_attach_async+0xc/0x18 [ 0.530131] async_run_entry_fn+0x40/0x160 [ 0.530136] process_one_work+0x19c/0x430 [ 0.530139] worker_thread+0x2b0/0x658 [ 0.530143] kthread+0x1bc/0x1c8 [ 0.530148] ret_from_fork+0x10/0x1c [ 0.530154] ---[ end trace d4c11db9e3197763 ]--- Signed-off-by: Edwiin Kusuma Jaya <[email protected]>

…g the sock [ Upstream commit 3cf7203ca620682165706f70a1b12b5194607dce ] There is a race condition in vxlan that when deleting a vxlan device during receiving packets, there is a possibility that the sock is released after getting vxlan_sock vs from sk_user_data. Then in later vxlan_ecn_decapsulate(), vxlan_get_sk_family() we will got NULL pointer dereference. e.g. #0 [ffffa25ec6978a38] machine_kexec at ffffffff8c669757 #1 [ffffa25ec6978a90] __crash_kexec at ffffffff8c7c0a4d #2 [ffffa25ec6978b58] crash_kexec at ffffffff8c7c1c48 #3 [ffffa25ec6978b60] oops_end at ffffffff8c627f2b #4 [ffffa25ec6978b80] page_fault_oops at ffffffff8c678fcb #5 [ffffa25ec6978bd8] exc_page_fault at ffffffff8d109542 #6 [ffffa25ec6978c00] asm_exc_page_fault at ffffffff8d200b62 [exception RIP: vxlan_ecn_decapsulate+0x3b] RIP: ffffffffc1014e7b RSP: ffffa25ec6978cb0 RFLAGS: 00010246 RAX: 0000000000000008 RBX: ffff8aa000888000 RCX: 0000000000000000 RDX: 000000000000000e RSI: ffff8a9fc7ab803e RDI: ffff8a9fd1168700 RBP: ffff8a9fc7ab803e R8: 0000000000700000 R9: 00000000000010ae R10: ffff8a9fcb748980 R11: 0000000000000000 R12: ffff8a9fd1168700 R13: ffff8aa000888000 R14: 00000000002a0000 R15: 00000000000010ae ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018 #7 [ffffa25ec6978ce8] vxlan_rcv at ffffffffc10189cd [vxlan] #8 [ffffa25ec6978d90] udp_queue_rcv_one_skb at ffffffff8cfb6507 #9 [ffffa25ec6978dc0] udp_unicast_rcv_skb at ffffffff8cfb6e45 #10 [ffffa25ec6978dc8] __udp4_lib_rcv at ffffffff8cfb8807 #11 [ffffa25ec6978e20] ip_protocol_deliver_rcu at ffffffff8cf76951 #12 [ffffa25ec6978e48] ip_local_deliver at ffffffff8cf76bde #13 [ffffa25ec6978ea0] __netif_receive_skb_one_core at ffffffff8cecde9b #14 [ffffa25ec6978ec8] process_backlog at ffffffff8cece139 #15 [ffffa25ec6978f00] __napi_poll at ffffffff8ceced1a #16 [ffffa25ec6978f28] net_rx_action at ffffffff8cecf1f3 #17 [ffffa25ec6978fa0] __softirqentry_text_start at ffffffff8d4000ca #18 [ffffa25ec6978ff0] do_softirq at ffffffff8c6fbdc3 Reproducer: https://github.com/Mellanox/ovs-tests/blob/master/test-ovs-vxlan-remove-tunnel-during-traffic.sh Fix this by waiting for all sk_user_data reader to finish before releasing the sock. Reported-by: Jianlin Shi <[email protected]> Suggested-by: Jakub Sitnicki <[email protected]> Fixes: 6a93cc9 ("udp-tunnel: Add a few more UDP tunnel APIs") Signed-off-by: Hangbin Liu <[email protected]> Reviewed-by: Jiri Pirko <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]>

[ Upstream commit 05bb0167c80b8f93c6a4e0451b7da9b96db990c2 ] ACPICA commit 770653e3ba67c30a629ca7d12e352d83c2541b1e Before this change we see the following UBSAN stack trace in Fuchsia: #0 0x000021e4213b3302 in acpi_ds_init_aml_walk(struct acpi_walk_state*, union acpi_parse_object*, struct acpi_namespace_node*, u8*, u32, struct acpi_evaluate_info*, u8) ../../third_party/acpica/source/components/dispatcher/dswstate.c:682 <platform-bus-x86.so>+0x233302 #1.2 0x000020d0f660777f in ubsan_get_stack_trace() compiler-rt/lib/ubsan/ubsan_diag.cpp:41 <libclang_rt.asan.so>+0x3d77f #1.1 0x000020d0f660777f in maybe_print_stack_trace() compiler-rt/lib/ubsan/ubsan_diag.cpp:51 <libclang_rt.asan.so>+0x3d77f #1 0x000020d0f660777f in ~scoped_report() compiler-rt/lib/ubsan/ubsan_diag.cpp:387 <libclang_rt.asan.so>+0x3d77f #2 0x000020d0f660b96d in handlepointer_overflow_impl() compiler-rt/lib/ubsan/ubsan_handlers.cpp:809 <libclang_rt.asan.so>+0x4196d #3 0x000020d0f660b50d in compiler-rt/lib/ubsan/ubsan_handlers.cpp:815 <libclang_rt.asan.so>+0x4150d #4 0x000021e4213b3302 in acpi_ds_init_aml_walk(struct acpi_walk_state*, union acpi_parse_object*, struct acpi_namespace_node*, u8*, u32, struct acpi_evaluate_info*, u8) ../../third_party/acpica/source/components/dispatcher/dswstate.c:682 <platform-bus-x86.so>+0x233302 #5 0x000021e4213e2369 in acpi_ds_call_control_method(struct acpi_thread_state*, struct acpi_walk_state*, union acpi_parse_object*) ../../third_party/acpica/source/components/dispatcher/dsmethod.c:605 <platform-bus-x86.so>+0x262369 #6 0x000021e421437fac in acpi_ps_parse_aml(struct acpi_walk_state*) ../../third_party/acpica/source/components/parser/psparse.c:550 <platform-bus-x86.so>+0x2b7fac #7 0x000021e4214464d2 in acpi_ps_execute_method(struct acpi_evaluate_info*) ../../third_party/acpica/source/components/parser/psxface.c:244 <platform-bus-x86.so>+0x2c64d2 #8 0x000021e4213aa052 in acpi_ns_evaluate(struct acpi_evaluate_info*) ../../third_party/acpica/source/components/namespace/nseval.c:250 <platform-bus-x86.so>+0x22a052 #9 0x000021e421413dd8 in acpi_ns_init_one_device(acpi_handle, u32, void*, void**) ../../third_party/acpica/source/components/namespace/nsinit.c:735 <platform-bus-x86.so>+0x293dd8 #10 0x000021e421429e98 in acpi_ns_walk_namespace(acpi_object_type, acpi_handle, u32, u32, acpi_walk_callback, acpi_walk_callback, void*, void**) ../../third_party/acpica/source/components/namespace/nswalk.c:298 <platform-bus-x86.so>+0x2a9e98 #11 0x000021e4214131ac in acpi_ns_initialize_devices(u32) ../../third_party/acpica/source/components/namespace/nsinit.c:268 <platform-bus-x86.so>+0x2931ac #12 0x000021e42147c40d in acpi_initialize_objects(u32) ../../third_party/acpica/source/components/utilities/utxfinit.c:304 <platform-bus-x86.so>+0x2fc40d #13 0x000021e42126d603 in acpi::acpi_impl::initialize_acpi(acpi::acpi_impl*) ../../src/devices/board/lib/acpi/acpi-impl.cc:224 <platform-bus-x86.so>+0xed603 Add a simple check that avoids incrementing a pointer by zero, but otherwise behaves as before. Note that our findings are against ACPICA 20221020, but the same code exists on master. Link: acpica/acpica@770653e3 Signed-off-by: Bob Moore <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]> Signed-off-by: Sasha Levin <[email protected]>

[ Upstream commit a154f5f643c6ecddd44847217a7a3845b4350003 ] The following call trace shows a deadlock issue due to recursive locking of mutex "device_mutex". First lock acquire is in target_for_each_device() and second in target_free_device(). PID: 148266 TASK: ffff8be21ffb5d00 CPU: 10 COMMAND: "iscsi_ttx" #0 [ffffa2bfc9ec3b18] __schedule at ffffffffa8060e7f #1 [ffffa2bfc9ec3ba0] schedule at ffffffffa8061224 #2 [ffffa2bfc9ec3bb8] schedule_preempt_disabled at ffffffffa80615ee #3 [ffffa2bfc9ec3bc8] __mutex_lock at ffffffffa8062fd7 #4 [ffffa2bfc9ec3c40] __mutex_lock_slowpath at ffffffffa80631d3 #5 [ffffa2bfc9ec3c50] mutex_lock at ffffffffa806320c #6 [ffffa2bfc9ec3c68] target_free_device at ffffffffc0935998 [target_core_mod] #7 [ffffa2bfc9ec3c90] target_core_dev_release at ffffffffc092f975 [target_core_mod] #8 [ffffa2bfc9ec3ca0] config_item_put at ffffffffa79d250f #9 [ffffa2bfc9ec3cd0] config_item_put at ffffffffa79d2583 #10 [ffffa2bfc9ec3ce0] target_devices_idr_iter at ffffffffc0933f3a [target_core_mod] #11 [ffffa2bfc9ec3d00] idr_for_each at ffffffffa803f6fc #12 [ffffa2bfc9ec3d60] target_for_each_device at ffffffffc0935670 [target_core_mod] #13 [ffffa2bfc9ec3d98] transport_deregister_session at ffffffffc0946408 [target_core_mod] #14 [ffffa2bfc9ec3dc8] iscsit_close_session at ffffffffc09a44a6 [iscsi_target_mod] #15 [ffffa2bfc9ec3df0] iscsit_close_connection at ffffffffc09a4a88 [iscsi_target_mod] #16 [ffffa2bfc9ec3df8] finish_task_switch at ffffffffa76e5d07 #17 [ffffa2bfc9ec3e78] iscsit_take_action_for_connection_exit at ffffffffc0991c23 [iscsi_target_mod] #18 [ffffa2bfc9ec3ea0] iscsi_target_tx_thread at ffffffffc09a403b [iscsi_target_mod] #19 [ffffa2bfc9ec3f08] kthread at ffffffffa76d8080 #20 [ffffa2bfc9ec3f50] ret_from_fork at ffffffffa8200364 Fixes: 36d4cb460bcb ("scsi: target: Avoid that EXTENDED COPY commands trigger lock inversion") Signed-off-by: Junxiao Bi <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Mike Christie <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Sasha Levin <[email protected]>

* doesn't work and ends up affining it to all cores instead * additionally affine spi irq's to big cluster (based on sultan's commit) Log: [ 0.529834] IRQ-234 not set for request with affinity flag [ 0.529848] ------------[ cut here ]------------ [ 0.529863] WARNING: CPU: 3 PID: 251 at kernel/power/qos.c:622 pm_qos_add_request+0x1b0/0x240 [ 0.529864] Modules linked in: [ 0.529873] CPU: 3 PID: 251 Comm: kworker/u16:7 Tainted: G S 4.14.227-QuicksilveR\xe2\x84\xa2-v2.5/92d5181c #10 [ 0.529875] Hardware name: Qualcomm Technologies, Inc. trinket pm6125 + pmi632 IDP (DT) [ 0.529889] Workqueue: events_unbound async_run_entry_fn [ 0.529893] task: 000000008c9ff257 task.stack: 00000000f1674f29 [ 0.529897] pc : pm_qos_add_request+0x1b0/0x240 [ 0.529900] lr : pm_qos_add_request+0x1b0/0x240 [ 0.529903] sp : ffffff800fc43bd0 pstate : 60000005 [ 0.529905] x29: ffffff800fc43bd0 x28: ffffffedb902b030 [ 0.529908] x27: ffffff9363206000 x26: ffffffedb932c880 [ 0.529912] x25: 00000000bb008905 x24: 0000000000000051 [ 0.529916] x23: 0000000000000001 x22: ffffff936373b000 [ 0.529919] x21: 0000000000000001 x20: ffffffedb7a5e7d8 [ 0.529923] x19: 00000000ffffffff x18: ffffff93634a728c [ 0.529926] x17: 00000000001f2e20 x16: 0000000000000000 [ 0.529930] x15: 0000000000000000 x14: 0000000000000082 [ 0.529933] x13: 0000000000000040 x12: 0000000000000000 [ 0.529937] x11: 0000000000000000 x10: ffffffffffffffff [ 0.529940] x9 : 69f5cb5eed6dba00 x8 : 69f5cb5eed6dba00 [ 0.529944] x7 : 0000000000000000 x6 : ffffff93634b44a2 [ 0.529947] x5 : 0000000000000000 x4 : 0000000000000000 [ 0.529951] x3 : 0000000000006761 x2 : 0000000000000002 [ 0.529954] x1 : 0000000000000000 x0 : 000000000000002e [ 0.529961] \x0aPC: 0xffffff9360f35f88: [ 0.529964] 5f88 a94257f6 f9400bf7 a8c47bfd d65f03c0 a9434ff4 a94257f6 f9400bf7 a8c47bfd [ 0.529975] 5fa8 d65f03c0 b9401281 f000cc20 52801fe8 91350c00 b900029f f9000688 9400131f [ 0.529986] 5fc8 d4210000 17ffffcd b000eca9 d538d088 91006129 900116ca b8696908 913d014a [ 0.529996] 5fe8 1100fd09 7100011f 1a88b129 13067d29 f869d949 9ac82528 3607f848 d5384116 [ 0.530009] \x0aLR: 0xffffff9360f35f88: [ 0.530010] 5f88 a94257f6 f9400bf7 a8c47bfd d65f03c0 a9434ff4 a94257f6 f9400bf7 a8c47bfd [ 0.530019] 5fa8 d65f03c0 b9401281 f000cc20 52801fe8 91350c00 b900029f f9000688 9400131f [ 0.530029] 5fc8 d4210000 17ffffcd b000eca9 d538d088 91006129 900116ca b8696908 913d014a [ 0.530039] 5fe8 1100fd09 7100011f 1a88b129 13067d29 f869d949 9ac82528 3607f848 d5384116 [ 0.530049] \x0aSP: 0xffffff800fc43b90: [ 0.530050] 3b90 60f35fc8 ffffff93 60000005 00000000 ffffffc8 ffffff80 ed6dba00 69f5cb5e [ 0.530060] 3bb0 ffffffff ffffffff 60f35fc8 ffffff93 0fc43bd0 ffffff80 60f35fc8 ffffff93 [ 0.530070] 3bd0 0fc43c10 ffffff80 61860b58 ffffff93 00000001 00000000 61860b1c ffffff93 [ 0.530079] 3bf0 6373b000 ffffff93 00000002 00000000 ffffffff 00000000 b7de6800 ffffffed [ 0.530089] [ 0.530091] Call trace: [ 0.530096] pm_qos_add_request+0x1b0/0x240 [ 0.530102] nvt_ts_probe+0x8a0/0xd10 [ 0.530108] spi_drv_probe+0xd4/0x100 [ 0.530114] driver_probe_device+0x424/0x460 [ 0.530117] __driver_attach+0xb8/0xe8 [ 0.530122] bus_for_each_dev+0xc0/0xf0 [ 0.530125] driver_attach+0x20/0x28 [ 0.530127] driver_attach_async+0xc/0x18 [ 0.530131] async_run_entry_fn+0x40/0x160 [ 0.530136] process_one_work+0x19c/0x430 [ 0.530139] worker_thread+0x2b0/0x658 [ 0.530143] kthread+0x1bc/0x1c8 [ 0.530148] ret_from_fork+0x10/0x1c [ 0.530154] ---[ end trace d4c11db9e3197763 ]--- Signed-off-by: Edwiin Kusuma Jaya <[email protected]>

[ Upstream commit f8bbc07ac535593139c875ffa19af924b1084540 ] vhost_worker will call tun call backs to receive packets. If too many illegal packets arrives, tun_do_read will keep dumping packet contents. When console is enabled, it will costs much more cpu time to dump packet and soft lockup will be detected. net_ratelimit mechanism can be used to limit the dumping rate. PID: 33036 TASK: ffff949da6f20000 CPU: 23 COMMAND: "vhost-32980" #0 [fffffe00003fce50] crash_nmi_callback at ffffffff89249253 #1 [fffffe00003fce58] nmi_handle at ffffffff89225fa3 #2 [fffffe00003fceb0] default_do_nmi at ffffffff8922642e #3 [fffffe00003fced0] do_nmi at ffffffff8922660d #4 [fffffe00003fcef0] end_repeat_nmi at ffffffff89c01663 [exception RIP: io_serial_in+20] RIP: ffffffff89792594 RSP: ffffa655314979e8 RFLAGS: 00000002 RAX: ffffffff89792500 RBX: ffffffff8af428a0 RCX: 0000000000000000 RDX: 00000000000003fd RSI: 0000000000000005 RDI: ffffffff8af428a0 RBP: 0000000000002710 R8: 0000000000000004 R9: 000000000000000f R10: 0000000000000000 R11: ffffffff8acbf64f R12: 0000000000000020 R13: ffffffff8acbf698 R14: 0000000000000058 R15: 0000000000000000 ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018 #5 [ffffa655314979e8] io_serial_in at ffffffff89792594 #6 [ffffa655314979e8] wait_for_xmitr at ffffffff89793470 #7 [ffffa65531497a08] serial8250_console_putchar at ffffffff897934f6 #8 [ffffa65531497a20] uart_console_write at ffffffff8978b605 #9 [ffffa65531497a48] serial8250_console_write at ffffffff89796558 #10 [ffffa65531497ac8] console_unlock at ffffffff89316124 #11 [ffffa65531497b10] vprintk_emit at ffffffff89317c07 #12 [ffffa65531497b68] printk at ffffffff89318306 #13 [ffffa65531497bc8] print_hex_dump at ffffffff89650765 #14 [ffffa65531497ca8] tun_do_read at ffffffffc0b06c27 [tun] #15 [ffffa65531497d38] tun_recvmsg at ffffffffc0b06e34 [tun] #16 [ffffa65531497d68] handle_rx at ffffffffc0c5d682 [vhost_net] #17 [ffffa65531497ed0] vhost_worker at ffffffffc0c644dc [vhost] #18 [ffffa65531497f10] kthread at ffffffff892d2e72 #19 [ffffa65531497f50] ret_from_fork at ffffffff89c0022f Fixes: ef3db4a ("tun: avoid BUG, dump packet on GSO errors") Signed-off-by: Lei Chen <[email protected]> Reviewed-by: Willem de Bruijn <[email protected]> Acked-by: Jason Wang <[email protected]> Reviewed-by: Eric Dumazet <[email protected]> Acked-by: Michael S. Tsirkin <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]> (cherry picked from commit 68459b8e3ee554ce71878af9eb69659b9462c588) Signed-off-by: Vegard Nossum <[email protected]>

kutemeikito closed this as completed Sep 27, 2022

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

need supporte cgroups V2 #10

need supporte cgroups V2 #10

mxsky01 commented Sep 21, 2022

need supporte cgroups V2 #10

need supporte cgroups V2 #10

Comments

mxsky01 commented Sep 21, 2022