March 2024 - Linux-stable-mirror

[PATCH 4.19.y 0/9] Fix the UAF issue caused by the loop driver

by Genjian

From: Genjian Zhang <zhanggenjian(a)kylinos.cn> Hello! We found that 2035c770bfdb ("loop: Check for overflow while configuring loop") lost a unlock loop_ctl_mutex in loop_get_status(...). which caused syzbot to report a UAF issue. However, the upstream patch does not have this issue. So, we revert this patch and directly apply the unmodified upstream patch. Risk use-after-free as reported by syzbot： [ 174.437352] BUG: KASAN: use-after-free in __mutex_lock.isra.10+0xbc4/0xc30 [ 174.437772] Read of size 4 at addr ffff8880bac49ab8 by task syz-executor.0/13897 [ 174.438205] [ 174.438306] CPU: 1 PID: 13897 Comm: syz-executor.0 Not tainted 4.19.306 #1 [ 174.438712] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1kylin1 04/01/2014 [ 174.439236] Call Trace: [ 174.439392] dump_stack+0x94/0xc7 [ 174.439596] ? __mutex_lock.isra.10+0xbc4/0xc30 [ 174.439881] print_address_description+0x60/0x229 [ 174.440165] ? __mutex_lock.isra.10+0xbc4/0xc30 [ 174.440436] kasan_report.cold.6+0x241/0x2fd [ 174.440696] __mutex_lock.isra.10+0xbc4/0xc30 [ 174.440959] ? entry_SYSCALL_64_after_hwframe+0x5c/0xc1 [ 174.441272] ? mutex_trylock+0xa0/0xa0 [ 174.441500] ? entry_SYSCALL_64_after_hwframe+0x5c/0xc1 [ 174.441816] ? kobject_get_unless_zero+0x129/0x1c0 [ 174.442106] ? kset_unregister+0x30/0x30 [ 174.442351] ? find_symbol_in_section+0x310/0x310 [ 174.442634] ? __mutex_lock_slowpath+0x10/0x10 [ 174.442901] mutex_lock_killable+0xb0/0xf0 [ 174.443149] ? __mutex_lock_killable_slowpath+0x10/0x10 [ 174.443465] ? __mutex_lock_slowpath+0x10/0x10 [ 174.443732] ? _cond_resched+0x10/0x20 [ 174.443966] ? kobject_get+0x54/0xa0 [ 174.444190] lo_open+0x16/0xc0 [ 174.444382] __blkdev_get+0x273/0x10f0 [ 174.444612] ? lo_fallocate.isra.20+0x150/0x150 [ 174.444886] ? bdev_disk_changed+0x190/0x190 [ 174.445146] ? path_init+0x1030/0x1030 [ 174.445371] ? do_syscall_64+0x9a/0x2d0 [ 174.445608] ? deref_stack_reg+0xab/0xe0 [ 174.445852] blkdev_get+0x97/0x880 [ 174.446061] ? walk_component+0x297/0xdc0 [ 174.446303] ? __blkdev_get+0x10f0/0x10f0 [ 174.446547] ? __fsnotify_inode_delete+0x20/0x20 [ 174.446822] blkdev_open+0x1bd/0x240 [ 174.447040] do_dentry_open+0x448/0xf80 [ 174.447274] ? blkdev_get_by_dev+0x60/0x60 [ 174.447522] ? __x64_sys_fchdir+0x1a0/0x1a0 [ 174.447775] ? inode_permission+0x86/0x320 [ 174.448022] path_openat+0xa83/0x3ed0 [ 174.448248] ? path_mountpoint+0xb50/0xb50 [ 174.448495] ? kasan_kmalloc+0xbf/0xe0 [ 174.448723] ? kmem_cache_alloc+0xbc/0x1b0 [ 174.448971] ? getname_flags+0xc4/0x560 [ 174.449203] ? do_sys_open+0x1ce/0x3f0 [ 174.449432] ? do_syscall_64+0x9a/0x2d0 [ 174.449706] ? entry_SYSCALL_64_after_hwframe+0x5c/0xc1 [ 174.450022] ? __d_alloc+0x2a/0xa50 [ 174.450232] ? kasan_unpoison_shadow+0x30/0x40 [ 174.450510] ? should_fail+0x117/0x6c0 [ 174.450737] ? timespec64_trunc+0xc1/0x150 [ 174.450986] ? inode_init_owner+0x2e0/0x2e0 [ 174.451237] ? timespec64_trunc+0xc1/0x150 [ 174.451484] ? inode_init_owner+0x2e0/0x2e0 [ 174.451736] do_filp_open+0x197/0x270 [ 174.451959] ? may_open_dev+0xd0/0xd0 [ 174.452182] ? kasan_unpoison_shadow+0x30/0x40 [ 174.452448] ? kasan_kmalloc+0xbf/0xe0 [ 174.452672] ? __alloc_fd+0x1a3/0x4b0 [ 174.452895] do_sys_open+0x2c7/0x3f0 [ 174.453114] ? filp_open+0x60/0x60 [ 174.453320] do_syscall_64+0x9a/0x2d0 [ 174.453541] ? prepare_exit_to_usermode+0xf3/0x170 [ 174.453832] entry_SYSCALL_64_after_hwframe+0x5c/0xc1 [ 174.454136] RIP: 0033:0x41edee [ 174.454321] Code: 25 00 00 41 00 3d 00 00 41 00 74 48 48 c7 c0 a4 af 0b 01 8b 00 85 c0 75 69 89 f2 b8 01 01 00 00 48 89 fe bf 9c ff ff ff 0f 05 <48> 3d 00 f0 ff ff 0f 87 a6 00 00 00 48 8b 4c 24 28 64 48 33 0c5 [ 174.455404] RSP: 002b:00007ffd2501fbd0 EFLAGS: 00000246 ORIG_RAX: 0000000000000101 [ 174.455854] RAX: ffffffffffffffda RBX: 00007ffd2501fc90 RCX: 000000000041edee [ 174.456273] RDX: 0000000000000002 RSI: 00007ffd2501fcd0 RDI: 00000000ffffff9c [ 174.456698] RBP: 0000000000000003 R08: 0000000000000001 R09: 00007ffd2501f9a7 [ 174.457116] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000003 [ 174.457535] R13: 0000000000565e48 R14: 00007ffd2501fcd0 R15: 0000000000400510 [ 174.457955] [ 174.458052] Allocated by task 945: [ 174.458261] kasan_kmalloc+0xbf/0xe0 [ 174.458478] kmem_cache_alloc_node+0xb4/0x1d0 [ 174.458743] copy_process.part.57+0x14b0/0x7010 [ 174.459017] _do_fork+0x197/0x980 [ 174.459218] kernel_thread+0x2f/0x40 [ 174.459438] call_usermodehelper_exec_work+0xa8/0x240 [ 174.459742] process_one_work+0x933/0x13b0 [ 174.459986] worker_thread+0x8c/0x1000 [ 174.460212] kthread+0x343/0x410 [ 174.460408] ret_from_fork+0x35/0x40 [ 174.460621] [ 174.460716] Freed by task 22902: [ 174.460913] __kasan_slab_free+0x125/0x170 [ 174.461159] kmem_cache_free+0x6e/0x1b0 [ 174.461391] __put_task_struct+0x1c4/0x440 [ 174.461636] delayed_put_task_struct+0x135/0x170 [ 174.461915] rcu_process_callbacks+0x578/0x15c0 [ 174.462184] __do_softirq+0x175/0x60e [ 174.462403] [ 174.462501] The buggy address belongs to the object at ffff8880bac49a80 [ 174.462501] which belongs to the cache task_struct of size 3264 [ 174.463235] The buggy address is located 56 bytes inside of [ 174.463235] 3264-byte region [ffff8880bac49a80, ffff8880bac4a740) [ 174.463923] The buggy address belongs to the page: [ 174.464210] page:ffffea0002eb1200 count:1 mapcount:0 mapping:ffff888188ca0a00 index:0x0 compound_mapcount: 0 [ 174.464784] flags: 0x100000000008100(slab|head) [ 174.465079] raw: 0100000000008100 ffffea0002eaa400 0000000400000004 ffff888188ca0a00 [ 174.465533] raw: 0000000000000000 0000000000090009 00000001ffffffff 0000000000000000 [ 174.465988] page dumped because: kasan: bad access detected [ 174.466321] [ 174.466322] Memory state around the buggy address: [ 174.466325] ffff8880bac49980: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 174.466327] ffff8880bac49a00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 174.466329] >ffff8880bac49a80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 174.466329] ^ [ 174.466331] ffff8880bac49b00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 174.466333] ffff8880bac49b80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 174.466333] ================================================================== [ 174.466338] Disabling lock debugging due to kernel taint Best regards Genjian Genjian Zhang (1): Revert "loop: Check for overflow while configuring loop" Holger Hoffstätte (1): loop: properly observe rotational flag of underlying device Martijn Coenen (5): loop: Call loop_config_discard() only after new config is applied loop: Remove sector_t truncation checks loop: Factor out setting loop device size loop: Refactor loop_set_status() size calculation loop: Factor out configuring loop from status Siddh Raman Pant (1): loop: Check for overflow while configuring loop Zhong Jinghua (1): loop: loop_set_status_from_info() check before assignment drivers/block/loop.c | 204 ++++++++++++++++++++++++++----------------- 1 file changed, 123 insertions(+), 81 deletions(-) -- 2.25.1

9 months, 2 weeks

3
12
0 0

[PATCH AUTOSEL 4.19 01/11] wifi: ath9k: fix LNA selection in ath_ant_try_scan()

by Sasha Levin

From: Dmitry Antipov <dmantipov(a)yandex.ru> [ Upstream commit d6b27eb997ef9a2aa51633b3111bc4a04748e6d3 ] In 'ath_ant_try_scan()', (most likely) the 2nd LNA's signal strength should be used in comparison against RSSI when selecting first LNA as the main one. Compile tested only. Found by Linux Verification Center (linuxtesting.org) with SVACE. Signed-off-by: Dmitry Antipov <dmantipov(a)yandex.ru> Acked-by: Toke Høiland-Jørgensen <toke(a)toke.dk> Signed-off-by: Kalle Valo <quic_kvalo(a)quicinc.com> Link: https://msgid.link/20231211172502.25202-1-dmantipov@yandex.ru Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/net/wireless/ath/ath9k/antenna.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/wireless/ath/ath9k/antenna.c b/drivers/net/wireless/ath/ath9k/antenna.c index a3668433dc02b..deac6184dd016 100644 --- a/drivers/net/wireless/ath/ath9k/antenna.c +++ b/drivers/net/wireless/ath/ath9k/antenna.c @@ -643,7 +643,7 @@ static void ath_ant_try_scan(struct ath_ant_comb *antcomb, conf->main_lna_conf = ATH_ANT_DIV_COMB_LNA1; conf->alt_lna_conf = ATH_ANT_DIV_COMB_LNA1_PLUS_LNA2; } else if (antcomb->rssi_sub > - antcomb->rssi_lna1) { + antcomb->rssi_lna2) { /* set to A-B */ conf->main_lna_conf = ATH_ANT_DIV_COMB_LNA1; conf->alt_lna_conf = ATH_ANT_DIV_COMB_LNA1_MINUS_LNA2; -- 2.43.0

9 months, 2 weeks

1
10
0 0

[PATCH AUTOSEL 5.4 01/15] wifi: ath9k: fix LNA selection in ath_ant_try_scan()

by Sasha Levin

From: Dmitry Antipov <dmantipov(a)yandex.ru> [ Upstream commit d6b27eb997ef9a2aa51633b3111bc4a04748e6d3 ] In 'ath_ant_try_scan()', (most likely) the 2nd LNA's signal strength should be used in comparison against RSSI when selecting first LNA as the main one. Compile tested only. Found by Linux Verification Center (linuxtesting.org) with SVACE. Signed-off-by: Dmitry Antipov <dmantipov(a)yandex.ru> Acked-by: Toke Høiland-Jørgensen <toke(a)toke.dk> Signed-off-by: Kalle Valo <quic_kvalo(a)quicinc.com> Link: https://msgid.link/20231211172502.25202-1-dmantipov@yandex.ru Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/net/wireless/ath/ath9k/antenna.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/wireless/ath/ath9k/antenna.c b/drivers/net/wireless/ath/ath9k/antenna.c index 988222cea9dfe..acc84e6711b0e 100644 --- a/drivers/net/wireless/ath/ath9k/antenna.c +++ b/drivers/net/wireless/ath/ath9k/antenna.c @@ -643,7 +643,7 @@ static void ath_ant_try_scan(struct ath_ant_comb *antcomb, conf->main_lna_conf = ATH_ANT_DIV_COMB_LNA1; conf->alt_lna_conf = ATH_ANT_DIV_COMB_LNA1_PLUS_LNA2; } else if (antcomb->rssi_sub > - antcomb->rssi_lna1) { + antcomb->rssi_lna2) { /* set to A-B */ conf->main_lna_conf = ATH_ANT_DIV_COMB_LNA1; conf->alt_lna_conf = ATH_ANT_DIV_COMB_LNA1_MINUS_LNA2; -- 2.43.0

9 months, 2 weeks

1
14
0 0

[PATCH AUTOSEL 5.10 01/17] wifi: ath9k: fix LNA selection in ath_ant_try_scan()

by Sasha Levin

From: Dmitry Antipov <dmantipov(a)yandex.ru> [ Upstream commit d6b27eb997ef9a2aa51633b3111bc4a04748e6d3 ] In 'ath_ant_try_scan()', (most likely) the 2nd LNA's signal strength should be used in comparison against RSSI when selecting first LNA as the main one. Compile tested only. Found by Linux Verification Center (linuxtesting.org) with SVACE. Signed-off-by: Dmitry Antipov <dmantipov(a)yandex.ru> Acked-by: Toke Høiland-Jørgensen <toke(a)toke.dk> Signed-off-by: Kalle Valo <quic_kvalo(a)quicinc.com> Link: https://msgid.link/20231211172502.25202-1-dmantipov@yandex.ru Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/net/wireless/ath/ath9k/antenna.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/wireless/ath/ath9k/antenna.c b/drivers/net/wireless/ath/ath9k/antenna.c index 988222cea9dfe..acc84e6711b0e 100644 --- a/drivers/net/wireless/ath/ath9k/antenna.c +++ b/drivers/net/wireless/ath/ath9k/antenna.c @@ -643,7 +643,7 @@ static void ath_ant_try_scan(struct ath_ant_comb *antcomb, conf->main_lna_conf = ATH_ANT_DIV_COMB_LNA1; conf->alt_lna_conf = ATH_ANT_DIV_COMB_LNA1_PLUS_LNA2; } else if (antcomb->rssi_sub > - antcomb->rssi_lna1) { + antcomb->rssi_lna2) { /* set to A-B */ conf->main_lna_conf = ATH_ANT_DIV_COMB_LNA1; conf->alt_lna_conf = ATH_ANT_DIV_COMB_LNA1_MINUS_LNA2; -- 2.43.0

9 months, 2 weeks

1
16
0 0

[PATCH AUTOSEL 5.15 01/20] wifi: ath9k: fix LNA selection in ath_ant_try_scan()

by Sasha Levin

From: Dmitry Antipov <dmantipov(a)yandex.ru> [ Upstream commit d6b27eb997ef9a2aa51633b3111bc4a04748e6d3 ] In 'ath_ant_try_scan()', (most likely) the 2nd LNA's signal strength should be used in comparison against RSSI when selecting first LNA as the main one. Compile tested only. Found by Linux Verification Center (linuxtesting.org) with SVACE. Signed-off-by: Dmitry Antipov <dmantipov(a)yandex.ru> Acked-by: Toke Høiland-Jørgensen <toke(a)toke.dk> Signed-off-by: Kalle Valo <quic_kvalo(a)quicinc.com> Link: https://msgid.link/20231211172502.25202-1-dmantipov@yandex.ru Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/net/wireless/ath/ath9k/antenna.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/wireless/ath/ath9k/antenna.c b/drivers/net/wireless/ath/ath9k/antenna.c index 988222cea9dfe..acc84e6711b0e 100644 --- a/drivers/net/wireless/ath/ath9k/antenna.c +++ b/drivers/net/wireless/ath/ath9k/antenna.c @@ -643,7 +643,7 @@ static void ath_ant_try_scan(struct ath_ant_comb *antcomb, conf->main_lna_conf = ATH_ANT_DIV_COMB_LNA1; conf->alt_lna_conf = ATH_ANT_DIV_COMB_LNA1_PLUS_LNA2; } else if (antcomb->rssi_sub > - antcomb->rssi_lna1) { + antcomb->rssi_lna2) { /* set to A-B */ conf->main_lna_conf = ATH_ANT_DIV_COMB_LNA1; conf->alt_lna_conf = ATH_ANT_DIV_COMB_LNA1_MINUS_LNA2; -- 2.43.0

9 months, 2 weeks

1
19
0 0

[PATCH AUTOSEL 6.1 01/31] wifi: ath9k: fix LNA selection in ath_ant_try_scan()

by Sasha Levin

From: Dmitry Antipov <dmantipov(a)yandex.ru> [ Upstream commit d6b27eb997ef9a2aa51633b3111bc4a04748e6d3 ] In 'ath_ant_try_scan()', (most likely) the 2nd LNA's signal strength should be used in comparison against RSSI when selecting first LNA as the main one. Compile tested only. Found by Linux Verification Center (linuxtesting.org) with SVACE. Signed-off-by: Dmitry Antipov <dmantipov(a)yandex.ru> Acked-by: Toke Høiland-Jørgensen <toke(a)toke.dk> Signed-off-by: Kalle Valo <quic_kvalo(a)quicinc.com> Link: https://msgid.link/20231211172502.25202-1-dmantipov@yandex.ru Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/net/wireless/ath/ath9k/antenna.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/wireless/ath/ath9k/antenna.c b/drivers/net/wireless/ath/ath9k/antenna.c index 988222cea9dfe..acc84e6711b0e 100644 --- a/drivers/net/wireless/ath/ath9k/antenna.c +++ b/drivers/net/wireless/ath/ath9k/antenna.c @@ -643,7 +643,7 @@ static void ath_ant_try_scan(struct ath_ant_comb *antcomb, conf->main_lna_conf = ATH_ANT_DIV_COMB_LNA1; conf->alt_lna_conf = ATH_ANT_DIV_COMB_LNA1_PLUS_LNA2; } else if (antcomb->rssi_sub > - antcomb->rssi_lna1) { + antcomb->rssi_lna2) { /* set to A-B */ conf->main_lna_conf = ATH_ANT_DIV_COMB_LNA1; conf->alt_lna_conf = ATH_ANT_DIV_COMB_LNA1_MINUS_LNA2; -- 2.43.0

9 months, 2 weeks

1
30
0 0

[PATCH AUTOSEL 6.6 01/52] wifi: ath9k: fix LNA selection in ath_ant_try_scan()

by Sasha Levin

From: Dmitry Antipov <dmantipov(a)yandex.ru> [ Upstream commit d6b27eb997ef9a2aa51633b3111bc4a04748e6d3 ] In 'ath_ant_try_scan()', (most likely) the 2nd LNA's signal strength should be used in comparison against RSSI when selecting first LNA as the main one. Compile tested only. Found by Linux Verification Center (linuxtesting.org) with SVACE. Signed-off-by: Dmitry Antipov <dmantipov(a)yandex.ru> Acked-by: Toke Høiland-Jørgensen <toke(a)toke.dk> Signed-off-by: Kalle Valo <quic_kvalo(a)quicinc.com> Link: https://msgid.link/20231211172502.25202-1-dmantipov@yandex.ru Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/net/wireless/ath/ath9k/antenna.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/wireless/ath/ath9k/antenna.c b/drivers/net/wireless/ath/ath9k/antenna.c index 988222cea9dfe..acc84e6711b0e 100644 --- a/drivers/net/wireless/ath/ath9k/antenna.c +++ b/drivers/net/wireless/ath/ath9k/antenna.c @@ -643,7 +643,7 @@ static void ath_ant_try_scan(struct ath_ant_comb *antcomb, conf->main_lna_conf = ATH_ANT_DIV_COMB_LNA1; conf->alt_lna_conf = ATH_ANT_DIV_COMB_LNA1_PLUS_LNA2; } else if (antcomb->rssi_sub > - antcomb->rssi_lna1) { + antcomb->rssi_lna2) { /* set to A-B */ conf->main_lna_conf = ATH_ANT_DIV_COMB_LNA1; conf->alt_lna_conf = ATH_ANT_DIV_COMB_LNA1_MINUS_LNA2; -- 2.43.0

9 months, 2 weeks

1
51
0 0

[PATCH AUTOSEL 6.8] x86/vdso: Fix rethunk patching for vdso-image-{32,64}.o

by Sasha Levin

From: Josh Poimboeuf <jpoimboe(a)kernel.org> [ Upstream commit b388e57d4628eb22782bdad4cd5b83ca87a1b7c9 ] For CONFIG_RETHUNK kernels, objtool annotates all the function return sites so they can be patched during boot. By design, after apply_returns() is called, all tail-calls to the compiler-generated default return thunk (__x86_return_thunk) should be patched out and replaced with whatever's needed for any mitigations (or lack thereof). The commit 4461438a8405 ("x86/retpoline: Ensure default return thunk isn't used at runtime") adds a runtime check and a WARN_ONCE() if the default return thunk ever gets executed after alternatives have been applied. This warning is a sanity check to make sure objtool and apply_returns() are doing their job. As Nathan reported, that check found something: Unpatched return thunk in use. This should not happen! WARNING: CPU: 0 PID: 1 at arch/x86/kernel/cpu/bugs.c:2856 __warn_thunk+0x27/0x40 RIP: 0010:__warn_thunk+0x27/0x40 Call Trace: <TASK> ? show_regs ? __warn ? __warn_thunk ? report_bug ? console_unlock ? handle_bug ? exc_invalid_op ? asm_exc_invalid_op ? ia32_binfmt_init ? __warn_thunk warn_thunk_thunk do_one_initcall kernel_init_freeable ? __pfx_kernel_init kernel_init ret_from_fork ? __pfx_kernel_init ret_from_fork_asm </TASK> Boris debugged to find that the unpatched return site was in init_vdso_image_64(), and its translation unit wasn't being analyzed by objtool, so it never got annotated. So it got ignored by apply_returns(). This is only a minor issue, as this function is only called during boot. Still, objtool needs full visibility to the kernel. Fix it by enabling objtool on vdso-image-{32,64}.o. Note this problem can only be seen with !CONFIG_X86_KERNEL_IBT, as that requires objtool to run individually on all translation units rather on vmlinux.o. [ bp: Massage commit message. ] Reported-by: Nathan Chancellor <nathan(a)kernel.org> Signed-off-by: Josh Poimboeuf <jpoimboe(a)kernel.org> Signed-off-by: Borislav Petkov (AMD) <bp(a)alien8.de> Link: https://lore.kernel.org/r/20240215032049.GA3944823@dev-arch.thelio-3990X Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- arch/x86/entry/vdso/Makefile | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/arch/x86/entry/vdso/Makefile b/arch/x86/entry/vdso/Makefile index b1b8dd1608f7e..4ee59121b9053 100644 --- a/arch/x86/entry/vdso/Makefile +++ b/arch/x86/entry/vdso/Makefile @@ -34,8 +34,12 @@ obj-y += vma.o extable.o KASAN_SANITIZE_vma.o := y UBSAN_SANITIZE_vma.o := y KCSAN_SANITIZE_vma.o := y -OBJECT_FILES_NON_STANDARD_vma.o := n -OBJECT_FILES_NON_STANDARD_extable.o := n + +OBJECT_FILES_NON_STANDARD_extable.o := n +OBJECT_FILES_NON_STANDARD_vdso-image-32.o := n +OBJECT_FILES_NON_STANDARD_vdso-image-64.o := n +OBJECT_FILES_NON_STANDARD_vdso32-setup.o := n +OBJECT_FILES_NON_STANDARD_vma.o := n # vDSO images to build vdso_img-$(VDSO64-y) += 64 @@ -43,7 +47,6 @@ vdso_img-$(VDSOX32-y) += x32 vdso_img-$(VDSO32-y) += 32 obj-$(VDSO32-y) += vdso32-setup.o -OBJECT_FILES_NON_STANDARD_vdso32-setup.o := n vobjs := $(foreach F,$(vobjs-y),$(obj)/$F) vobjs32 := $(foreach F,$(vobjs32-y),$(obj)/$F) -- 2.43.0

9 months, 2 weeks

1
0
0 0

[PATCH 5.15.y 0/2] fix softlockups in stage2_apply_range()

by Krister Johansen

Hi Stable Team, In 5.15, unmapping large kvm vms on arm64 can generate softlockups. My team has been hitting this when tearing down VMs > 100Gb in size. Oliver fixed this with the attached patches. They've been in mainline since 6.1. I tested on 5.15.150 with these patches applied. When they're present, both the dirty_log_perf_test detailed in the second patch, and kvm_page_table_test no longer generate softlockups when unmapping VMs with large memory configurations. Would you please consider these patches for inclusion in an upcoming 5.15 release? Thanks, -K Oliver Upton (2): KVM: arm64: Work out supported block level at compile time KVM: arm64: Limit stage2_apply_range() batch size to largest block arch/arm64/include/asm/kvm_pgtable.h | 18 +++++++++++++----- arch/arm64/include/asm/stage2_pgtable.h | 20 -------------------- arch/arm64/kvm/mmu.c | 9 ++++++++- 3 files changed, 21 insertions(+), 26 deletions(-) -- 2.25.1

9 months, 2 weeks

4
8
0 0

FAILED: patch "[PATCH] tty: serial: imx: Fix broken RS485" failed to apply to 6.1-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.1-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.1.y git checkout FETCH_HEAD git cherry-pick -x 672448ccf9b6a676f96f9352cbf91f4d35f4084a # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2024032746-stilt-vaporizer-fb22@gregkh' --subject-prefix 'PATCH 6.1.y' HEAD^.. Possible dependencies: 672448ccf9b6 ("tty: serial: imx: Fix broken RS485") ca530cfa968c ("serial: imx: Add support for RS485 RX_DURING_TX output GPIO") 79d0224f6bf2 ("tty: serial: imx: Handle RS485 DE signal active high") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 672448ccf9b6a676f96f9352cbf91f4d35f4084a Mon Sep 17 00:00:00 2001 From: Rickard x Andersson <rickaran(a)axis.com> Date: Wed, 21 Feb 2024 12:53:04 +0100 Subject: [PATCH] tty: serial: imx: Fix broken RS485 When about to transmit the function imx_uart_start_tx is called and in some RS485 configurations this function will call imx_uart_stop_rx. The problem is that imx_uart_stop_rx will enable loopback in order to release the RS485 bus, but when loopback is enabled transmitted data will just be looped to RX. This patch fixes the above problem by not enabling loopback when about to transmit. This driver now works well when used for RS485 half duplex master configurations. Fixes: 79d0224f6bf2 ("tty: serial: imx: Handle RS485 DE signal active high") Cc: stable <stable(a)kernel.org> Signed-off-by: Rickard x Andersson <rickaran(a)axis.com> Tested-by: Christoph Niedermaier <cniedermaier(a)dh-electronics.com> Link: https://lore.kernel.org/r/20240221115304.509811-1-rickaran@axis.com Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c index 4aa72d5aeafb..e14813250616 100644 --- a/drivers/tty/serial/imx.c +++ b/drivers/tty/serial/imx.c @@ -462,8 +462,7 @@ static void imx_uart_stop_tx(struct uart_port *port) } } -/* called with port.lock taken and irqs off */ -static void imx_uart_stop_rx(struct uart_port *port) +static void imx_uart_stop_rx_with_loopback_ctrl(struct uart_port *port, bool loopback) { struct imx_port *sport = (struct imx_port *)port; u32 ucr1, ucr2, ucr4, uts; @@ -485,7 +484,7 @@ static void imx_uart_stop_rx(struct uart_port *port) /* See SER_RS485_ENABLED/UTS_LOOP comment in imx_uart_probe() */ if (port->rs485.flags & SER_RS485_ENABLED && port->rs485.flags & SER_RS485_RTS_ON_SEND && - sport->have_rtscts && !sport->have_rtsgpio) { + sport->have_rtscts && !sport->have_rtsgpio && loopback) { uts = imx_uart_readl(sport, imx_uart_uts_reg(sport)); uts |= UTS_LOOP; imx_uart_writel(sport, uts, imx_uart_uts_reg(sport)); @@ -497,6 +496,16 @@ static void imx_uart_stop_rx(struct uart_port *port) imx_uart_writel(sport, ucr2, UCR2); } +/* called with port.lock taken and irqs off */ +static void imx_uart_stop_rx(struct uart_port *port) +{ + /* + * Stop RX and enable loopback in order to make sure RS485 bus + * is not blocked. Se comment in imx_uart_probe(). + */ + imx_uart_stop_rx_with_loopback_ctrl(port, true); +} + /* called with port.lock taken and irqs off */ static void imx_uart_enable_ms(struct uart_port *port) { @@ -682,9 +691,14 @@ static void imx_uart_start_tx(struct uart_port *port) imx_uart_rts_inactive(sport, &ucr2); imx_uart_writel(sport, ucr2, UCR2); + /* + * Since we are about to transmit we can not stop RX + * with loopback enabled because that will make our + * transmitted data being just looped to RX. + */ if (!(port->rs485.flags & SER_RS485_RX_DURING_TX) && !port->rs485_rx_during_tx_gpio) - imx_uart_stop_rx(port); + imx_uart_stop_rx_with_loopback_ctrl(port, false); sport->tx_state = WAIT_AFTER_RTS;

9 months, 2 weeks

3
2
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror March 2024