user/sven/linux.git, branch v6.1.45

Linux 6.1.45

2023-08-11T10:08:27Z

Link: https://lore.kernel.org/r/20230809103636.615294317@linuxfoundation.org Tested-by: Miguel Ojeda # Rust Tested-by: Conor Dooley Tested-by: Ron Economos Tested-by: Takeshi Ogasawara Tested-by: Bagas Sanjaya Tested-by: SeongJae Park Tested-by: Joel Fernandes (Google) Signed-off-by: Greg Kroah-Hartman

x86/CPU/AMD: Do not leak quotient data after a division by 0

2023-08-11T10:08:27Z

commit 77245f1c3c6495521f6a3af082696ee2f8ce3921 upstream. Under certain circumstances, an integer division by 0 which faults, can leave stale quotient data from a previous division operation on Zen1 microarchitectures. Do a dummy division 0/1 before returning from the #DE exception handler in order to avoid any leaks of potentially sensitive data. Signed-off-by: Borislav Petkov (AMD) Cc: Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman

Revert "drm/i915: Disable DC states for all commits"

2023-08-11T10:08:27Z

This reverts commit 0fc6fea41c7122aa5f2088117f50144b507e13d7 which is commit a2b6e99d8a623544f3bdccd28ee35b9c1b00daa5 upstream. It is reported to cause regression issues, so it should be reverted from the 6.1.y tree for now. Reported-by: Thorsten Leemhuis Link: https://lore.kernel.org/r/f0870e8f-0c66-57fd-f95d-18d014a11939@leemhuis.info Link: https://gitlab.freedesktop.org/drm/intel/-/issues/8419 Cc: Manasi Navare Cc: Drew Davenport Cc: Jouni Högander Cc: Imre Deak Cc: Ville Syrjälä Cc: Jani Nikula Signed-off-by: Greg Kroah-Hartman

drm/amdgpu: Use apt name for FW reserved region

2023-08-11T10:08:27Z

commit db3b5cb64a9ca301d14ed027e470834316720e42 upstream Use the generic term fw_reserved_memory for FW reserve region. This region may also hold discovery TMR in addition to other reserve regions. This region size could be larger than discovery tmr size, hence don't change the discovery tmr size based on this. Signed-off-by: Lijo Lazar Reviewed-by: Le Ma Signed-off-by: Alex Deucher [ This change fixes reading IP discovery from debugfs. It needed to be hand modified because: * GC 9.4.3 support isn't introduced in older kernels until 228ce176434b ("drm/amdgpu: Handle VRAM dependencies on GFXIP9.4.3") * It also changed because of 58ab2c08d708 (drm/amdgpu: use VRAM|GTT for a bunch of kernel allocations) not being present. Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2748 ] Signed-off-by: Mario Limonciello Signed-off-by: Greg Kroah-Hartman

drm/amdgpu: Remove unnecessary domain argument

2023-08-11T10:08:27Z

commit 3273f11675ef11959d25a56df3279f712bcd41b7 upstream Remove the "domain" argument to amdgpu_bo_create_kernel_at() since this function takes an "offset" argument which is the offset off of VRAM, and as such allocation always takes place in VRAM. Thus, the "domain" argument is unnecessary. Cc: Alex Deucher Cc: Christian König Cc: AMD Graphics Signed-off-by: Luben Tuikov Reviewed-by: Christian König Signed-off-by: Alex Deucher Signed-off-by: Mario Limonciello Signed-off-by: Greg Kroah-Hartman

drm/amdgpu: add vram reservation based on vram_usagebyfirmware_v2_2

2023-08-11T10:08:26Z

commit 4864f2ee9ee2acf4a1009b58fbc62f17fa086d4e upstream Move TMR region from top of FB to 2MB for FFBM, so we need to reserve TMR region firstly to make sure TMR can be allocated at 2MB Signed-off-by: Tong Liu01 Acked-by: Christian König Signed-off-by: Alex Deucher Signed-off-by: Mario Limonciello Signed-off-by: Greg Kroah-Hartman

arm64/ptrace: Don't enable SVE when setting streaming SVE

2023-08-11T10:08:26Z

commit 045aecdfcb2e060db142d83a0f4082380c465d2c upstream. Systems which implement SME without also implementing SVE are architecturally valid but were not initially supported by the kernel, unfortunately we missed one issue in the ptrace code. The SVE register setting code is shared between SVE and streaming mode SVE. When we set full SVE register state we currently enable TIF_SVE unconditionally, in the case where streaming SVE is being configured on a system that supports vanilla SVE this is not an issue since we always initialise enough state for both vector lengths but on a system which only support SME it will result in us attempting to restore the SVE vector length after having set streaming SVE registers. Fix this by making the enabling of SVE conditional on setting SVE vector state. If we set streaming SVE state and SVE was not already enabled this will result in a SVE access trap on next use of normal SVE, this will cause us to flush our register state but this is fine since the only way to trigger a SVE access trap would be to exit streaming mode which will cause the in register state to be flushed anyway. Fixes: e12310a0d30f ("arm64/sme: Implement ptrace support for streaming mode SVE registers") Signed-off-by: Mark Brown Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20230803-arm64-fix-ptrace-ssve-no-sve-v1-1-49df214bfb3e@kernel.org Signed-off-by: Catalin Marinas [Fix up backport -- broonie] Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman

exfat: check if filename entries exceeds max filename length

2023-08-11T10:08:26Z

[ Upstream commit d42334578eba1390859012ebb91e1e556d51db49 ] exfat_extract_uni_name copies characters from a given file name entry into the 'uniname' variable. This variable is actually defined on the stack of the exfat_readdir() function. According to the definition of the 'exfat_uni_name' type, the file name should be limited 255 characters (+ null teminator space), but the exfat_get_uniname_from_ext_entry() function can write more characters because there is no check if filename entries exceeds max filename length. This patch add the check not to copy filename characters when exceeding max filename length. Cc: stable@vger.kernel.org Cc: Yuezhang Mo Reported-by: Maxim Suhanov Reviewed-by: Sungjong Seo Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin

f2fs: don't reset unchangable mount option in f2fs_remount()

2023-08-11T10:08:26Z

[ Upstream commit 458c15dfbce62c35fefd9ca637b20a051309c9f1 ] syzbot reports a bug as below: general protection fault, probably for non-canonical address 0xdffffc0000000009: 0000 [#1] PREEMPT SMP KASAN RIP: 0010:__lock_acquire+0x69/0x2000 kernel/locking/lockdep.c:4942 Call Trace: lock_acquire+0x1e3/0x520 kernel/locking/lockdep.c:5691 __raw_write_lock include/linux/rwlock_api_smp.h:209 [inline] _raw_write_lock+0x2e/0x40 kernel/locking/spinlock.c:300 __drop_extent_tree+0x3ac/0x660 fs/f2fs/extent_cache.c:1100 f2fs_drop_extent_tree+0x17/0x30 fs/f2fs/extent_cache.c:1116 f2fs_insert_range+0x2d5/0x3c0 fs/f2fs/file.c:1664 f2fs_fallocate+0x4e4/0x6d0 fs/f2fs/file.c:1838 vfs_fallocate+0x54b/0x6b0 fs/open.c:324 ksys_fallocate fs/open.c:347 [inline] __do_sys_fallocate fs/open.c:355 [inline] __se_sys_fallocate fs/open.c:353 [inline] __x64_sys_fallocate+0xbd/0x100 fs/open.c:353 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd The root cause is race condition as below: - since it tries to remount rw filesystem, so that do_remount won't call sb_prepare_remount_readonly to block fallocate, there may be race condition in between remount and fallocate. - in f2fs_remount(), default_options() will reset mount option to default one, and then update it based on result of parse_options(), so there is a hole which race condition can happen. Thread A Thread B - f2fs_fill_super - parse_options - clear_opt(READ_EXTENT_CACHE) - f2fs_remount - default_options - set_opt(READ_EXTENT_CACHE) - f2fs_fallocate - f2fs_insert_range - f2fs_drop_extent_tree - __drop_extent_tree - __may_extent_tree - test_opt(READ_EXTENT_CACHE) return true - write_lock(&et->lock) access NULL pointer - parse_options - clear_opt(READ_EXTENT_CACHE) Cc: Reported-by: syzbot+d015b6c2fbb5c383bf08@syzkaller.appspotmail.com Closes: https://lore.kernel.org/linux-f2fs-devel/20230522124203.3838360-1-chao@kernel.org Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin

f2fs: fix to set flush_merge opt and show noflush_merge

2023-08-11T10:08:26Z

[ Upstream commit 967eaad1fed5f6335ea97a47d45214744dc57925 ] Some minor modifications to flush_merge and related parameters: 1.The FLUSH_MERGE opt is set by default only in non-ro mode. 2.When ro and merge are set at the same time, an error is reported. 3.Display noflush_merge mount opt. Suggested-by: Chao Yu Signed-off-by: Yangtao Li Signed-off-by: Jaegeuk Kim Stable-dep-of: 458c15dfbce6 ("f2fs: don't reset unchangable mount option in f2fs_remount()") Signed-off-by: Sasha Levin