June 2025 - Linux-stable-mirror

[PATCH v3 1/5] drm/dp: Change AUX DPCD probe address from DPCD_REV to LANE0_1_STATUS

by Imre Deak

Reading DPCD registers has side-effects in general. In particular accessing registers outside of the link training register range (0x102-0x106, 0x202-0x207, 0x200c-0x200f, 0x2216) is explicitly forbidden by the DP v2.1 Standard, see 3.6.5.1 DPTX AUX Transaction Handling Mandates 3.6.7.4 128b/132b DP Link Layer LTTPR Link Training Mandates Based on my tests, accessing the DPCD_REV register during the link training of an UHBR TBT DP tunnel sink leads to link training failures. Solve the above by using the DP_LANE0_1_STATUS (0x202) register for the DPCD register access quirk. Cc: <stable(a)vger.kernel.org> Cc: Ville Syrjälä <ville.syrjala(a)linux.intel.com> Cc: Jani Nikula <jani.nikula(a)linux.intel.com> Acked-by: Jani Nikula <jani.nikula(a)linux.intel.com> Signed-off-by: Imre Deak <imre.deak(a)intel.com> --- drivers/gpu/drm/display/drm_dp_helper.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/display/drm_dp_helper.c b/drivers/gpu/drm/display/drm_dp_helper.c index f2a6559a27100..dc622c78db9d4 100644 --- a/drivers/gpu/drm/display/drm_dp_helper.c +++ b/drivers/gpu/drm/display/drm_dp_helper.c @@ -725,7 +725,7 @@ ssize_t drm_dp_dpcd_read(struct drm_dp_aux *aux, unsigned int offset, * monitor doesn't power down exactly after the throw away read. */ if (!aux->is_remote) { - ret = drm_dp_dpcd_probe(aux, DP_DPCD_REV); + ret = drm_dp_dpcd_probe(aux, DP_LANE0_1_STATUS); if (ret < 0) return ret; } -- 2.44.2

2 months, 2 weeks

1
0
0 0

[Compiler Error] 5.10.238 - Werror=incompatible-pointer-types

by Philip Müller

I see the following compiler error with: 2025-06-04T18:53:58.6366470Z CC net/core/skmsg.o 2025-06-04T18:53:58.7689837Z CC [M] sound/pci/ca0106/ca0106_proc.o 2025-06-04T18:53:58.9485675Z drivers/video/fbdev/core/dummyblit.c: In function ‘fbcon_set_dummyops’: 2025-06-04T18:53:58.9488404Z drivers/video/fbdev/core/dummyblit.c:78:20: error: assignment to ‘void (*)(struct vc_data *, struct fb_info *, int, int, int, int, int, int)’ from incompatible pointer type ‘void (*)(struct vc_data *, struct fb_info *, int, int, int, int)’ [-Werror=incompatible-pointer-types] 2025-06-04T18:53:58.9490536Z 78 | ops->clear = dummy_clear; 2025-06-04T18:53:58.9491362Z | ^ 2025-06-04T18:53:58.9492571Z drivers/video/fbdev/core/dummyblit.c:33:13: note: ‘dummy_clear’ declared here 2025-06-04T18:53:58.9494125Z 33 | static void dummy_clear(struct vc_data *vc, struct fb_info *info, int sy, 2025-06-04T18:53:58.9495247Z | ^~~~~~~~~~~ 2025-06-04T18:53:59.0185422Z cc1: some warnings being treated as errors 2025-06-04T18:53:59.0229239Z make[4]: *** [scripts/Makefile.build:286: drivers/video/fbdev/core/dummyblit.o] Error 1 2025-06-04T18:53:59.0235041Z make[3]: *** [scripts/Makefile.build:503: drivers/video/fbdev/core] Error 2 2025-06-04T18:53:59.0243143Z make[2]: *** [scripts/Makefile.build:503: drivers/video/fbdev] Error 2 2025-06-04T18:53:59.0257657Z make[1]: *** [scripts/Makefile.build:503: drivers/video] Error 2 2025-06-04T18:53:59.0262623Z make: *** [Makefile:1852: drivers] Error 2 Full build log attached; -- Best, Philip

2 months, 2 weeks

1
2
0 0

[PATCH v2 1/2] platform/loongarch: laptop: Get brightness setting from EC on probe

by Yao Zi

Previously during probe, 1 is unconditionally taken as current brightness value and set to props.brightness, which will be considered as the brightness before suspend and restored to EC on resume. Since a brightness value of 1 almost never matches EC's state on coldboot (my laptop's EC defaults to 80), this causes surprising changes of screen brightness on the first time of resume after coldboot. Let's get brightness from EC and take it as the current brightness on probe of the laptop driver to avoid the surprising behavior. Tested on TongFang L860-T2 3A5000 laptop. Cc: stable(a)vger.kernel.org Fixes: 6246ed09111f ("LoongArch: Add ACPI-based generic laptop driver") Signed-off-by: Yao Zi <ziyao(a)disroot.org> --- drivers/platform/loongarch/loongson-laptop.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/platform/loongarch/loongson-laptop.c b/drivers/platform/loongarch/loongson-laptop.c index 99203584949d..828bd62e3596 100644 --- a/drivers/platform/loongarch/loongson-laptop.c +++ b/drivers/platform/loongarch/loongson-laptop.c @@ -392,7 +392,7 @@ static int laptop_backlight_register(void) if (!acpi_evalf(hotkey_handle, &status, "ECLL", "d")) return -EIO; - props.brightness = 1; + props.brightness = ec_get_brightness(); props.max_brightness = status; props.type = BACKLIGHT_PLATFORM; -- 2.49.0

2 months, 2 weeks

1
0
0 0

Are you satisfied with your supplier?

by Ironman＠duwoal.cn

2 months, 2 weeks

1
0
0 0

[PATCH -stable,5.4 0/1] Netfilter fix for -stable

by Pablo Neira Ayuso

Hi Greg, Sasha, This batch contains backported fixes for 6.1 -stable. The following list shows the backported patch, I am using original commit IDs for reference: 1) 039b1f4f24ec ("netfilter: nft_socket: fix erroneous socket assignment") this is to fix a sk memleak. Please, apply, Thanks. Florian Westphal (1): netfilter: nft_socket: fix sk refcount leaks net/netfilter/nft_socket.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) -- 2.30.2

2 months, 2 weeks

1
2
0 0

[PATCH -stable,5.10 0/1] Netfilter fix for -stable

by Pablo Neira Ayuso

Hi Greg, Sasha, This batch contains backported fixes for 5.10 -stable. The following list shows the backported patch, I am using original commit IDs for reference: 1) 8b26ff7af8c3 ("netfilter: nft_socket: fix sk refcount leaks") This is to fix a sk memleak, backport patch posted by Denis Arefev. Please, apply, Thanks Florian Westphal (1): netfilter: nft_socket: fix sk refcount leaks net/netfilter/nft_socket.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) -- 2.30.2

2 months, 2 weeks

1
1
0 0

Backports for 6.1 and older due to clang -Qunused-arguments change

by Nathan Chancellor

Hi Greg and Sasha, Please find attached backports for commit feb843a469fb ("kbuild: add $(CLANG_FLAGS) to KBUILD_CPPFLAGS") and its dependent changes, commit d5c8d6e0fa61 ("kbuild: Update assembler calls to use proper flags and language target") and its dependent changes, and commit 7db038d9790e ("drm/amd/display: Do not add '-mhard-float' to dml_ccflags for clang") for 6.1 and earlier. The second listed change is already in 6.1 so that series is a little shorter. These changes are needed there due to an upstream LLVM change [1] that changes the behavior of -Qunused-arguments with unknown target options, which is only used in 6.1 and older since I removed it in commit 8d9acfce3332 ("kbuild: Stop using '-Qunused-arguments' with clang") in 6.3. Please let me know if there are any issues, I will try to pay attention for any issues that crop up in the stable review period from these changes but please ping me if you remember. Cheers, Nathan [1]: https://github.com/llvm/llvm-project/commit/a4b2f4a72aa9b4655ecc723838830e0…

2 months, 2 weeks

1
0
0 0

[PATCH] pidfs: never refuse ppid == 0 in PIDFD_GET_INFO

by Mike Yuan

In systemd we spotted an issue after switching to ioctl(PIDFD_GET_INFO) for obtaining pid number the pidfd refers to, that for processes with a parent from outer pidns PIDFD_GET_INFO unexpectedly yields -ESRCH [1]. It turned out that there's an arbitrary check blocking this, which is not really sensible given getppid() happily returns 0 for such processes. Just drop the spurious check and userspace ought to handle ppid == 0 properly everywhere. [1] https://github.com/systemd/systemd/issues/37715 Fixes: cdda1f26e74b ("pidfd: add ioctl to retrieve pid info") Signed-off-by: Mike Yuan <me(a)yhndnzj.com> Cc: Christian Brauner <brauner(a)kernel.org> Cc: Luca Boccassi <luca.boccassi(a)gmail.com> Cc: <stable(a)vger.kernel.org> --- fs/pidfs.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/pidfs.c b/fs/pidfs.c index c1f0a067be40..69919be1c9d8 100644 --- a/fs/pidfs.c +++ b/fs/pidfs.c @@ -366,7 +366,7 @@ static long pidfd_info(struct file *file, unsigned int cmd, unsigned long arg) kinfo.pid = task_pid_vnr(task); kinfo.mask |= PIDFD_INFO_PID; - if (kinfo.pid == 0 || kinfo.tgid == 0 || (kinfo.ppid == 0 && kinfo.pid != 1)) + if (kinfo.pid == 0 || kinfo.tgid == 0) return -ESRCH; copy_out: base-commit: 5abc7438f1e9d62e91ad775cc83c9594c48d2282 -- 2.49.0

2 months, 2 weeks

2
1
0 0

[PATCH] drm/amdgpu: fix NULL dereference in gfx_v9_0_kcq() and kiq_init_queue()

by Alexey Nepomnyashih

A potential NULL pointer dereference may occur when accessing tmp_mqd->cp_hqd_pq_control without verifying that tmp_mqd is non-NULL. This may happen if mqd_backup[mqd_idx] is unexpectedly NULL. Although a NULL check for mqd_backup[mqd_idx] existed previously, it was moved to a position after the dereference in a recent commit, which renders it ineffective. Add an explicit NULL check for tmp_mqd before dereferencing its members. Found by Linux Verification Center (linuxtesting.org) with SVACE. Cc: stable(a)vger.kernel.org # v5.13+ Fixes: a330b52a9e59 ("drm/amdgpu: Init the cp MQD if it's not be initialized before") Signed-off-by: Alexey Nepomnyashih <sdl(a)nppct.ru> --- drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 10 ++++------ 1 file changed, 4 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c index d7db4cb907ae..134cab16a00d 100644 --- a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c +++ b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c @@ -3817,10 +3817,9 @@ static int gfx_v9_0_kiq_init_queue(struct amdgpu_ring *ring) * check mqd->cp_hqd_pq_control since this value should not be 0 */ tmp_mqd = (struct v9_mqd *)adev->gfx.kiq[0].mqd_backup; - if (amdgpu_in_reset(adev) && tmp_mqd->cp_hqd_pq_control){ + if (amdgpu_in_reset(adev) && tmp_mqd && tmp_mqd->cp_hqd_pq_control) { /* for GPU_RESET case , reset MQD to a clean status */ - if (adev->gfx.kiq[0].mqd_backup) - memcpy(mqd, adev->gfx.kiq[0].mqd_backup, sizeof(struct v9_mqd_allocation)); + memcpy(mqd, adev->gfx.kiq[0].mqd_backup, sizeof(struct v9_mqd_allocation)); /* reset ring buffer */ ring->wptr = 0; @@ -3863,7 +3862,7 @@ static int gfx_v9_0_kcq_init_queue(struct amdgpu_ring *ring, bool restore) */ tmp_mqd = (struct v9_mqd *)adev->gfx.mec.mqd_backup[mqd_idx]; - if (!restore && (!tmp_mqd->cp_hqd_pq_control || + if (!restore && tmp_mqd && (!tmp_mqd->cp_hqd_pq_control || (!amdgpu_in_reset(adev) && !adev->in_suspend))) { memset((void *)mqd, 0, sizeof(struct v9_mqd_allocation)); ((struct v9_mqd_allocation *)mqd)->dynamic_cu_mask = 0xFFFFFFFF; @@ -3874,8 +3873,7 @@ static int gfx_v9_0_kcq_init_queue(struct amdgpu_ring *ring, bool restore) soc15_grbm_select(adev, 0, 0, 0, 0, 0); mutex_unlock(&adev->srbm_mutex); - if (adev->gfx.mec.mqd_backup[mqd_idx]) - memcpy(adev->gfx.mec.mqd_backup[mqd_idx], mqd, sizeof(struct v9_mqd_allocation)); + memcpy(adev->gfx.mec.mqd_backup[mqd_idx], mqd, sizeof(struct v9_mqd_allocation)); } else { /* restore MQD to a clean status */ if (adev->gfx.mec.mqd_backup[mqd_idx]) -- 2.43.0

2 months, 2 weeks

3
4
0 0

+ mm-userfaultfd-fix-race-of-userfaultfd_move-and-swap-cache.patch added to mm-hotfixes-unstable branch

by Andrew Morton

The patch titled Subject: mm: userfaultfd: fix race of userfaultfd_move and swap cache has been added to the -mm mm-hotfixes-unstable branch. Its filename is mm-userfaultfd-fix-race-of-userfaultfd_move-and-swap-cache.patch This patch will shortly appear at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patche… This patch will later appear in the mm-hotfixes-unstable branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next via the mm-everything branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm and is updated there every 2-3 working days ------------------------------------------------------ From: Kairui Song <kasong(a)tencent.com> Subject: mm: userfaultfd: fix race of userfaultfd_move and swap cache Date: Wed, 4 Jun 2025 23:10:38 +0800 On seeing a swap entry PTE, userfaultfd_move does a lockless swap cache lookup, and tries to move the found folio to the faulting vma. Currently, it relies on checking the PTE value to ensure that the moved folio still belongs to the src swap entry and that no new folio has been added to the swap cache, which turns out to be unreliable. While working and reviewing the swap table series with Barry, following existing races are observed and reproduced [1]: In the example below, move_pages_pte is moving src_pte to dst_pte, where src_pte is a swap entry PTE holding swap entry S1, and S1 is not in the swap cache: CPU1 CPU2 userfaultfd_move move_pages_pte() entry = pte_to_swp_entry(orig_src_pte); // Here it got entry = S1 ... < interrupted> ... <swapin src_pte, alloc and use folio A> // folio A is a new allocated folio // and get installed into src_pte <frees swap entry S1> // src_pte now points to folio A, S1 // has swap count == 0, it can be freed // by folio_swap_swap or swap // allocator's reclaim. <try to swap out another folio B> // folio B is a folio in another VMA. <put folio B to swap cache using S1 > // S1 is freed, folio B can use it // for swap out with no problem. ... folio = filemap_get_folio(S1) // Got folio B here !!! ... < interrupted again> ... <swapin folio B and free S1> // Now S1 is free to be used again. <swapout src_pte & folio A using S1> // Now src_pte is a swap entry PTE // holding S1 again. folio_trylock(folio) move_swap_pte double_pt_lock is_pte_pages_stable // Check passed because src_pte == S1 folio_move_anon_rmap(...) // Moved invalid folio B here !!! The race window is very short and requires multiple collisions of multiple rare events, so it's very unlikely to happen, but with a deliberately constructed reproducer and increased time window, it can be reproduced easily. This can be fixed by checking if the folio returned by filemap is the valid swap cache folio after acquiring the folio lock. Another similar race is possible: filemap_get_folio may return NULL, but folio (A) could be swapped in and then swapped out again using the same swap entry after the lookup. In such a case, folio (A) may remain in the swap cache, so it must be moved too: CPU1 CPU2 userfaultfd_move move_pages_pte() entry = pte_to_swp_entry(orig_src_pte); // Here it got entry = S1, and S1 is not in swap cache folio = filemap_get_folio(S1) // Got NULL ... < interrupted again> ... <swapin folio A and free S1> <swapout folio A re-using S1> move_swap_pte double_pt_lock is_pte_pages_stable // Check passed because src_pte == S1 folio_move_anon_rmap(...) // folio A is ignored !!! Fix this by checking the swap cache again after acquiring the src_pte lock. And to avoid the filemap overhead, we check swap_map directly [2]. The SWP_SYNCHRONOUS_IO path does make the problem more complex, but so far we don't need to worry about that, since folios can only be exposed to the swap cache in the swap out path, and this is covered in this patch by checking the swap cache again after acquiring the src_pte lock. Testing with a simple C program that allocates and moves several GB of memory did not show any observable performance change. Link: https://lkml.kernel.org/r/20250604151038.21968-1-ryncsn@gmail.com Fixes: adef440691ba ("userfaultfd: UFFDIO_MOVE uABI") Signed-off-by: Kairui Song <kasong(a)tencent.com> Closes: https://lore.kernel.org/linux-mm/CAMgjq7B1K=6OOrK2OUZ0-tqCzi+EJt+2_K97TPGoS… [1] Link: https://lore.kernel.org/all/CAGsJ_4yJhJBo16XhiC-nUzSheyX-V3-nFE+tAi=8Y560K8… [2] Reviewed-by: Lokesh Gidra <lokeshgidra(a)google.com> Acked-by: Peter Xu <peterx(a)redhat.com> Reviewed-by: Suren Baghdasaryan <surenb(a)google.com> Cc: Andrea Arcangeli <aarcange(a)redhat.com> Cc: Barry Song <21cnbao(a)gmail.com> Cc: David Hildenbrand <david(a)redhat.com> Cc: Kairui Song <kasong(a)tencent.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/userfaultfd.c | 33 +++++++++++++++++++++++++++++++-- 1 file changed, 31 insertions(+), 2 deletions(-) --- a/mm/userfaultfd.c~mm-userfaultfd-fix-race-of-userfaultfd_move-and-swap-cache +++ a/mm/userfaultfd.c @@ -1084,8 +1084,18 @@ static int move_swap_pte(struct mm_struc pte_t orig_dst_pte, pte_t orig_src_pte, pmd_t *dst_pmd, pmd_t dst_pmdval, spinlock_t *dst_ptl, spinlock_t *src_ptl, - struct folio *src_folio) + struct folio *src_folio, + struct swap_info_struct *si, swp_entry_t entry) { + /* + * Check if the folio still belongs to the target swap entry after + * acquiring the lock. Folio can be freed in the swap cache while + * not locked. + */ + if (src_folio && unlikely(!folio_test_swapcache(src_folio) || + entry.val != src_folio->swap.val)) + return -EAGAIN; + double_pt_lock(dst_ptl, src_ptl); if (!is_pte_pages_stable(dst_pte, src_pte, orig_dst_pte, orig_src_pte, @@ -1102,6 +1112,25 @@ static int move_swap_pte(struct mm_struc if (src_folio) { folio_move_anon_rmap(src_folio, dst_vma); src_folio->index = linear_page_index(dst_vma, dst_addr); + } else { + /* + * Check if the swap entry is cached after acquiring the src_pte + * lock. Otherwise, we might miss a newly loaded swap cache folio. + * + * Check swap_map directly to minimize overhead, READ_ONCE is sufficient. + * We are trying to catch newly added swap cache, the only possible case is + * when a folio is swapped in and out again staying in swap cache, using the + * same entry before the PTE check above. The PTL is acquired and released + * twice, each time after updating the swap_map's flag. So holding + * the PTL here ensures we see the updated value. False positive is possible, + * e.g. SWP_SYNCHRONOUS_IO swapin may set the flag without touching the + * cache, or during the tiny synchronization window between swap cache and + * swap_map, but it will be gone very quickly, worst result is retry jitters. + */ + if (READ_ONCE(si->swap_map[swp_offset(entry)]) & SWAP_HAS_CACHE) { + double_pt_unlock(dst_ptl, src_ptl); + return -EAGAIN; + } } orig_src_pte = ptep_get_and_clear(mm, src_addr, src_pte); @@ -1412,7 +1441,7 @@ retry: } err = move_swap_pte(mm, dst_vma, dst_addr, src_addr, dst_pte, src_pte, orig_dst_pte, orig_src_pte, dst_pmd, dst_pmdval, - dst_ptl, src_ptl, src_folio); + dst_ptl, src_ptl, src_folio, si, entry); } out: _ Patches currently in -mm which might be from kasong(a)tencent.com are mm-userfaultfd-fix-race-of-userfaultfd_move-and-swap-cache.patch

2 months, 2 weeks

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror June 2025