kernel/linux.git, branch v6.11.10

Linux 6.11.10

2024-11-22T14:39:56+00:00

Link: https://lore.kernel.org/r/20241120125629.681745345@linuxfoundation.org Tested-by: Ronald Warsow Tested-by: Mark Brown Tested-by: SeongJae Park Tested-by: Florian Fainelli Tested-by: Shuah Khan Tested-by: Ron Economos Tested-by: Pavel Machek (CIP) Tested-by: Linux Kernel Functional Testing Tested-by: Salvatore Bonaccorso Tested-by: Justin M. Forbes Tested-by: kernelci.org bot Tested-by: Jon Hunter Signed-off-by: Greg Kroah-Hartman

media: dvbdev: fix the logic when DVB_DYNAMIC_MINORS is not set

2024-11-22T14:39:56+00:00

commit a4aebaf6e6efff548b01a3dc49b4b9074751c15b upstream. When CONFIG_DVB_DYNAMIC_MINORS, ret is not initialized, and a semaphore is left at the wrong state, in case of errors. Make the code simpler and avoid mistakes by having just one error check logic used weather DVB_DYNAMIC_MINORS is used or not. Reported-by: kernel test robot Reported-by: Dan Carpenter Closes: https://lore.kernel.org/r/202410201717.ULWWdJv8-lkp@intel.com/ Signed-off-by: Mauro Carvalho Chehab Link: https://lore.kernel.org/r/9e067488d8935b8cf00959764a1fa5de85d65725.1730926254.git.mchehab+huawei@kernel.org Cc: Nathan Chancellor Signed-off-by: Greg Kroah-Hartman

net: sched: u32: Add test case for systematic hnode IDR leaks

2024-11-22T14:39:56+00:00

commit ca34aceb322bfcd6ab498884f1805ee12f983259 upstream. Add a tdc test case to exercise the just-fixed systematic leak of IDR entries in u32 hnode disposal. Given the IDR in question is confined to the range [1..0x7FF], it is sufficient to create/delete the same filter 2048 times to fill it up and get a nonzero exit status from "tc filter add". Signed-off-by: Alexandre Ferrieux Acked-by: Jamal Hadi Salim Reviewed-by: Victor Nogueira Link: https://patch.msgid.link/20241113100428.360460-1-alexandre.ferrieux@orange.com Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman

lib/buildid: Fix build ID parsing logic

2024-11-22T14:39:56+00:00

The parse_build_id_buf does not account Elf32_Nhdr header size when getting the build id data pointer and returns wrong build id data as result. This is problem only for stable trees that merged 768d731b8a0d fix, the upstream build id code was refactored and returns proper build id. Acked-by: Andrii Nakryiko Fixes: 768d731b8a0d ("lib/buildid: harden build ID parsing logic") Signed-off-by: Jiri Olsa Signed-off-by: Greg Kroah-Hartman

drm/xe: improve hibernation on igpu

2024-11-22T14:39:55+00:00

[ Upstream commit 46f1f4b0f3c2a2dff9887de7c66ccc7ef482bd83 ] The GGTT looks to be stored inside stolen memory on igpu which is not treated as normal RAM. The core kernel skips this memory range when creating the hibernation image, therefore when coming back from hibernation the GGTT programming is lost. This seems to cause issues with broken resume where GuC FW fails to load: [drm] *ERROR* GT0: load failed: status = 0x400000A0, time = 10ms, freq = 1250MHz (req 1300MHz), done = -1 [drm] *ERROR* GT0: load failed: status: Reset = 0, BootROM = 0x50, UKernel = 0x00, MIA = 0x00, Auth = 0x01 [drm] *ERROR* GT0: firmware signature verification failed [drm] *ERROR* CRITICAL: Xe has declared device 0000:00:02.0 as wedged. Current GGTT users are kernel internal and tracked as pinned, so it should be possible to hook into the existing save/restore logic that we use for dgpu, where the actual evict is skipped but on restore we importantly restore the GGTT programming. This has been confirmed to fix hibernation on at least ADL and MTL, though likely all igpu platforms are affected. This also means we have a hole in our testing, where the existing s4 tests only really test the driver hooks, and don't go as far as actually rebooting and restoring from the hibernation image and in turn powering down RAM (and therefore losing the contents of stolen). v2 (Brost) - Remove extra newline and drop unnecessary parentheses. Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Link: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/3275 Signed-off-by: Matthew Auld Cc: Matthew Brost Cc: # v6.8+ Reviewed-by: Matthew Brost Reviewed-by: Lucas De Marchi Signed-off-by: Matthew Brost Link: https://patchwork.freedesktop.org/patch/msgid/20241101170156.213490-2-matthew.auld@intel.com (cherry picked from commit f2a6b8e396666d97ada8e8759dfb6a69d8df6380) Signed-off-by: Lucas De Marchi Signed-off-by: Sasha Levin

drm/xe: Restore system memory GGTT mappings

2024-11-22T14:39:55+00:00

[ Upstream commit dd886a63d6e2ce5c16e662c07547c067ad7d91f5 ] GGTT mappings reside on the device and this state is lost during suspend / d3cold thus this state must be restored resume regardless if the BO is in system memory or VRAM. v2: - Unnecessary parentheses around bo->placements[0] (Checkpatch) Signed-off-by: Matthew Brost Reviewed-by: Matthew Auld Link: https://patchwork.freedesktop.org/patch/msgid/20241031182257.2949579-1-matthew.brost@intel.com (cherry picked from commit a19d1db9a3fa89fabd7c83544b84f393ee9b851f) Signed-off-by: Lucas De Marchi Stable-dep-of: 46f1f4b0f3c2 ("drm/xe: improve hibernation on igpu") Signed-off-by: Sasha Levin

mm: refactor arch_calc_vm_flag_bits() and arm64 MTE handling

2024-11-22T14:39:55+00:00

[ Upstream commit 5baf8b037debf4ec60108ccfeccb8636d1dbad81 ] Currently MTE is permitted in two circumstances (desiring to use MTE having been specified by the VM_MTE flag) - where MAP_ANONYMOUS is specified, as checked by arch_calc_vm_flag_bits() and actualised by setting the VM_MTE_ALLOWED flag, or if the file backing the mapping is shmem, in which case we set VM_MTE_ALLOWED in shmem_mmap() when the mmap hook is activated in mmap_region(). The function that checks that, if VM_MTE is set, VM_MTE_ALLOWED is also set is the arm64 implementation of arch_validate_flags(). Unfortunately, we intend to refactor mmap_region() to perform this check earlier, meaning that in the case of a shmem backing we will not have invoked shmem_mmap() yet, causing the mapping to fail spuriously. It is inappropriate to set this architecture-specific flag in general mm code anyway, so a sensible resolution of this issue is to instead move the check somewhere else. We resolve this by setting VM_MTE_ALLOWED much earlier in do_mmap(), via the arch_calc_vm_flag_bits() call. This is an appropriate place to do this as we already check for the MAP_ANONYMOUS case here, and the shmem file case is simply a variant of the same idea - we permit RAM-backed memory. This requires a modification to the arch_calc_vm_flag_bits() signature to pass in a pointer to the struct file associated with the mapping, however this is not too egregious as this is only used by two architectures anyway - arm64 and parisc. So this patch performs this adjustment and removes the unnecessary assignment of VM_MTE_ALLOWED in shmem_mmap(). [akpm@linux-foundation.org: fix whitespace, per Catalin] Link: https://lkml.kernel.org/r/ec251b20ba1964fb64cf1607d2ad80c47f3873df.1730224667.git.lorenzo.stoakes@oracle.com Fixes: deb0f6562884 ("mm/mmap: undo ->mmap() when arch_validate_flags() fails") Signed-off-by: Lorenzo Stoakes Suggested-by: Catalin Marinas Reported-by: Jann Horn Reviewed-by: Catalin Marinas Reviewed-by: Vlastimil Babka Cc: Andreas Larsson Cc: David S. Miller Cc: Helge Deller Cc: James E.J. Bottomley Cc: Liam R. Howlett Cc: Linus Torvalds Cc: Mark Brown Cc: Peter Xu Cc: Will Deacon Cc: Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin

drm/amd/display: Fix failure to read vram info due to static BP_RESULT

2024-11-22T14:39:55+00:00

commit 4bb2f52ac01b8d45d64c7c04881207722e5e6fe4 upstream. The static declaration causes the check to fail. Remove it. Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3678 Fixes: 00c391102abc ("drm/amd/display: Add misc DC changes for DCN401") Reviewed-by: Harry Wentland Signed-off-by: Hamish Claxton Signed-off-by: Alex Deucher Cc: aurabindo.pillai@amd.com Cc: hamishclaxton@gmail.com (cherry picked from commit 91314e7dfd83345b8b820b782b2511c9c32866cd) Cc: stable@vger.kernel.org # 6.11.x Signed-off-by: Greg Kroah-Hartman

drm/amd/display: Handle dml allocation failure to avoid crash

2024-11-22T14:39:55+00:00

commit 6825cb07b79ffeb1d90ffaa7a1227462cdca34ae upstream. [Why] In the case where a dml allocation fails for any reason, the current state's dml contexts would no longer be valid. Then subsequent calls dc_state_copy_internal would shallow copy invalid memory and if the new state was released, a double free would occur. [How] Reset dml pointers in new_state to NULL and avoid invalid pointer Reviewed-by: Dillon Varone Signed-off-by: Ryan Seto Signed-off-by: Hamza Mahfooz Signed-off-by: Alex Deucher (cherry picked from commit bcafdc61529a48f6f06355d78eb41b3aeda5296c) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman

drm/amd/display: Require minimum VBlank size for stutter optimization

2024-11-22T14:39:55+00:00

commit 9fc0cbcb6e45d6fc96ffd3bb7b6d6d28d693ff4d upstream. If the nominal VBlank is too small, optimizing for stutter can cause the prefetch bandwidth to increase drasticaly, resulting in higher clock and power requirements. Only optimize if it is >3x the stutter latency. Reviewed-by: Austin Zheng Signed-off-by: Dillon Varone Signed-off-by: Hamza Mahfooz Signed-off-by: Alex Deucher (cherry picked from commit 003215f962cdf2265f126a3f4c9ad20917f87fca) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman