- Linux-stable-mirror - lists.linaro.org

[PATCH net 00/11] mptcp: misc fixes for v6.18-rc7

by Matthieu Baerts (NGI0)

Here are various unrelated fixes: - Patch 1: Fix window space computation for fallback connections which can affect ACK generation. A fix for v5.11. - Patch 2: Avoid unneeded subflow-level drops due to unsynced received window. A fix for v5.11. - Patch 3: Avoid premature close for fallback connections with PREEMPT kernels. A fix for v5.12. - Patch 4: Reset instead of fallback in case of data in the MPTCP out-of-order queue. A fix for v5.7. - Patches 5-7: Avoid also sending "plain" TCP reset when closing with an MP_FASTCLOSE. A fix for v6.1. - Patches 8-9: Longer timeout for background connections in MPTCP Join selftests. An additional fix for recent patches for v5.13/v6.1. - Patches 10-11: Fix typo in a check introduce in a recent refactoring. A fix for v6.15. Signed-off-by: Matthieu Baerts (NGI0) <matttbe(a)kernel.org> --- Gang Yan (2): mptcp: fix address removal logic in mptcp_pm_nl_rm_addr selftests: mptcp: add a check for 'add_addr_accepted' Matthieu Baerts (NGI0) (3): selftests: mptcp: join: fastclose: remove flaky marks selftests: mptcp: join: endpoints: longer timeout selftests: mptcp: join: userspace: longer timeout Paolo Abeni (6): mptcp: fix ack generation for fallback msk mptcp: avoid unneeded subflow-level drops mptcp: fix premature close in case of fallback mptcp: do not fallback when OoO is present mptcp: decouple mptcp fastclose from tcp close mptcp: fix duplicate reset on fastclose net/mptcp/options.c | 54 +++++++++++++++++++++- net/mptcp/pm_kernel.c | 2 +- net/mptcp/protocol.c | 59 +++++++++++++++++-------- net/mptcp/protocol.h | 3 +- tools/testing/selftests/net/mptcp/mptcp_join.sh | 27 ++++++----- 5 files changed, 113 insertions(+), 32 deletions(-) --- base-commit: 8e0a754b0836d996802713bbebc87bc1cc17925c change-id: 20251117-net-mptcp-misc-fixes-6-18-rc6-835d94cdc095 Best regards, -- Matthieu Baerts (NGI0) <matttbe(a)kernel.org>

2 weeks, 4 days

3
12
0 0

[PATCH] mm/huge_memory: fix NULL pointer deference when splitting shmem folio in swap cache

by Wei Yang

Commit c010d47f107f ("mm: thp: split huge page to any lower order pages") introduced an early check on the folio's order via mapping->flags before proceeding with the split work. This check introduced a bug: for shmem folios in the swap cache, the mapping pointer can be NULL. Accessing mapping->flags in this state leads directly to a NULL pointer dereference. This commit fixes the issue by moving the check for mapping != NULL before any attempt to access mapping->flags. This fix necessarily changes the return value from -EBUSY to -EINVAL when mapping is NULL. After reviewing current callers, they do not differentiate between these two error codes, making this change safe. Fixes: c010d47f107f ("mm: thp: split huge page to any lower order pages") Signed-off-by: Wei Yang <richard.weiyang(a)gmail.com> Cc: Zi Yan <ziy(a)nvidia.com> Cc: <stable(a)vger.kernel.org> --- This patch is based on current mm-new, latest commit: 056b93566a35 mm/vmalloc: warn only once when vmalloc detect invalid gfp flags Backport note: Current code evolved from original commit with following four changes. We should do proper adjustment respectively on backporting. commit c010d47f107f609b9f4d6a103b6dfc53889049e9 Author: Zi Yan <ziy(a)nvidia.com> Date: Mon Feb 26 15:55:33 2024 -0500 mm: thp: split huge page to any lower order pages commit 6a50c9b512f7734bc356f4bd47885a6f7c98491a Author: Ran Xiaokai <ran.xiaokai(a)zte.com.cn> Date: Fri Jun 7 17:40:48 2024 +0800 mm: huge_memory: fix misused mapping_large_folio_support() for anon folios commit 9b2f764933eb5e3ac9ebba26e3341529219c4401 Author: Zi Yan <ziy(a)nvidia.com> Date: Wed Jan 22 11:19:27 2025 -0500 mm/huge_memory: allow split shmem large folio to any lower order commit 58729c04cf1092b87aeef0bf0998c9e2e4771133 Author: Zi Yan <ziy(a)nvidia.com> Date: Fri Mar 7 12:39:57 2025 -0500 mm/huge_memory: add buddy allocator like (non-uniform) folio_split() --- mm/huge_memory.c | 68 +++++++++++++++++++++++++----------------------- 1 file changed, 35 insertions(+), 33 deletions(-) diff --git a/mm/huge_memory.c b/mm/huge_memory.c index 7c69572b6c3f..8701c3eef05f 100644 --- a/mm/huge_memory.c +++ b/mm/huge_memory.c @@ -3696,29 +3696,42 @@ bool folio_split_supported(struct folio *folio, unsigned int new_order, "Cannot split to order-1 folio"); if (new_order == 1) return false; - } else if (split_type == SPLIT_TYPE_NON_UNIFORM || new_order) { - if (IS_ENABLED(CONFIG_READ_ONLY_THP_FOR_FS) && - !mapping_large_folio_support(folio->mapping)) { - /* - * We can always split a folio down to a single page - * (new_order == 0) uniformly. - * - * For any other scenario - * a) uniform split targeting a large folio - * (new_order > 0) - * b) any non-uniform split - * we must confirm that the file system supports large - * folios. - * - * Note that we might still have THPs in such - * mappings, which is created from khugepaged when - * CONFIG_READ_ONLY_THP_FOR_FS is enabled. But in that - * case, the mapping does not actually support large - * folios properly. - */ - VM_WARN_ONCE(warns, - "Cannot split file folio to non-0 order"); + } else { + const struct address_space *mapping = folio->mapping; + + /* Truncated ? */ + /* + * TODO: add support for large shmem folio in swap cache. + * When shmem is in swap cache, mapping is NULL and + * folio_test_swapcache() is true. + */ + if (!mapping) return false; + + if (split_type == SPLIT_TYPE_NON_UNIFORM || new_order) { + if (IS_ENABLED(CONFIG_READ_ONLY_THP_FOR_FS) && + !mapping_large_folio_support(folio->mapping)) { + /* + * We can always split a folio down to a + * single page (new_order == 0) uniformly. + * + * For any other scenario + * a) uniform split targeting a large folio + * (new_order > 0) + * b) any non-uniform split + * we must confirm that the file system + * supports large folios. + * + * Note that we might still have THPs in such + * mappings, which is created from khugepaged + * when CONFIG_READ_ONLY_THP_FOR_FS is + * enabled. But in that case, the mapping does + * not actually support large folios properly. + */ + VM_WARN_ONCE(warns, + "Cannot split file folio to non-0 order"); + return false; + } } } @@ -3965,17 +3978,6 @@ static int __folio_split(struct folio *folio, unsigned int new_order, mapping = folio->mapping; - /* Truncated ? */ - /* - * TODO: add support for large shmem folio in swap cache. - * When shmem is in swap cache, mapping is NULL and - * folio_test_swapcache() is true. - */ - if (!mapping) { - ret = -EBUSY; - goto out; - } - min_order = mapping_min_folio_order(folio->mapping); if (new_order < min_order) { ret = -EINVAL; -- 2.34.1

2 weeks, 4 days

3
21
0 0

+ mm-huge_memory-fix-null-pointer-deference-when-splitting-folio.patch added to mm-hotfixes-unstable branch

by Andrew Morton

The patch titled Subject: mm/huge_memory: fix NULL pointer deference when splitting folio has been added to the -mm mm-hotfixes-unstable branch. Its filename is mm-huge_memory-fix-null-pointer-deference-when-splitting-folio.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: Wei Yang <richard.weiyang(a)gmail.com> Subject: mm/huge_memory: fix NULL pointer deference when splitting folio Date: Wed, 19 Nov 2025 23:53:02 +0000 Commit c010d47f107f ("mm: thp: split huge page to any lower order pages") introduced an early check on the folio's order via mapping->flags before proceeding with the split work. This check introduced a bug: for shmem folios in the swap cache and truncated folios, the mapping pointer can be NULL. Accessing mapping->flags in this state leads directly to a NULL pointer dereference. This commit fixes the issue by moving the check for mapping != NULL before any attempt to access mapping->flags. Link: https://lkml.kernel.org/r/20251119235302.24773-1-richard.weiyang@gmail.com Fixes: c010d47f107f ("mm: thp: split huge page to any lower order pages") Signed-off-by: Wei Yang <richard.weiyang(a)gmail.com> Reviewed-by: Zi Yan <ziy(a)nvidia.com> Cc: "David Hildenbrand (Red Hat)" <david(a)kernel.org> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/huge_memory.c | 22 ++++++++++------------ 1 file changed, 10 insertions(+), 12 deletions(-) --- a/mm/huge_memory.c~mm-huge_memory-fix-null-pointer-deference-when-splitting-folio +++ a/mm/huge_memory.c @@ -3619,6 +3619,16 @@ static int __folio_split(struct folio *f if (folio != page_folio(split_at) || folio != page_folio(lock_at)) return -EINVAL; + /* + * Folios that just got truncated cannot get split. Signal to the + * caller that there was a race. + * + * TODO: this will also currently refuse shmem folios that are in the + * swapcache. + */ + if (!is_anon && !folio->mapping) + return -EBUSY; + if (new_order >= folio_order(folio)) return -EINVAL; @@ -3659,18 +3669,6 @@ static int __folio_split(struct folio *f gfp_t gfp; mapping = folio->mapping; - - /* Truncated ? */ - /* - * TODO: add support for large shmem folio in swap cache. - * When shmem is in swap cache, mapping is NULL and - * folio_test_swapcache() is true. - */ - if (!mapping) { - ret = -EBUSY; - goto out; - } - min_order = mapping_min_folio_order(folio->mapping); if (new_order < min_order) { ret = -EINVAL; _ Patches currently in -mm which might be from richard.weiyang(a)gmail.com are mm-huge_memory-fix-null-pointer-deference-when-splitting-folio.patch mm-huge_memory-add-pmd-folio-to-ds_queue-in-do_huge_zero_wp_pmd.patch mm-khugepaged-unify-pmd-folio-installation-with-map_anon_folio_pmd.patch mm-huge_memory-only-get-folio_order-once-during-__folio_split.patch mm-huge_memory-introduce-enum-split_type-for-clarity.patch mm-huge_memory-merge-uniform_split_supported-and-non_uniform_split_supported.patch mm-khugepaged-remove-redundant-clearing-of-struct-collapse_control.patch mm-khugepaged-continue-to-collapse-on-scan_pmd_none.patch mm-khugepaged-unify-scan_pmd_none-and-scan_pmd_null-into-scan_no_pte_table.patch

2 weeks, 4 days

1
0
0 0

[merged] unshare-fix-nsproxy-leak-on-set_cred_ucounts-error-path.patch removed from -mm tree

by Andrew Morton

The quilt patch titled Subject: unshare: fix nsproxy leak on set_cred_ucounts() error path has been removed from the -mm tree. Its filename was unshare-fix-nsproxy-leak-on-set_cred_ucounts-error-path.patch This patch was dropped because it was merged into mainline or a subsystem tree ------------------------------------------------------ From: Pavel Tikhomirov <ptikhomirov(a)virtuozzo.com> Subject: unshare: fix nsproxy leak on set_cred_ucounts() error path Date: Tue, 18 Nov 2025 14:45:50 +0800 If unshare_nsproxy_namespaces() successfully creates the new_nsproxy, but then set_cred_ucounts() fails, on its error path there is no cleanup for new_nsproxy, so it is leaked. Let's fix that by freeing new_nsproxy if it's not NULL on this error path. Link: https://lkml.kernel.org/r/20251118064552.936962-1-ptikhomirov@virtuozzo.com Fixes: 905ae01c4ae2 ("Add a reference to ucounts for each cred") Signed-off-by: Pavel Tikhomirov <ptikhomirov(a)virtuozzo.com> Acked-by: Alexey Gladkov <legion(a)kernel.org> Reviewed-by: Liam R. Howlett <Liam.Howlett(a)oracle.com> Cc: Ben Segall <bsegall(a)google.com> Cc: Dietmar Eggemann <dietmar.eggemann(a)arm.com> Cc: Eric Biederman <ebiederm(a)xmission.com> Cc: Ingo Molnar <mingo(a)redhat.com> Cc: Juri Lelli <juri.lelli(a)redhat.com> Cc: Kees Cook <kees(a)kernel.org> Cc: Lorenzo Stoakes <lorenzo.stoakes(a)oracle.com> Cc: Mel Gorman <mgorman <mgorman(a)suse.de> Cc: Michal Hocko <mhocko(a)suse.com> Cc: Mike Rapoport <rppt(a)kernel.org> Cc: Peter Zijlstra <peterz(a)infradead.org> Cc: Steven Rostedt <rostedt(a)goodmis.org> Cc: Suren Baghdasaryan <surenb(a)google.com> Cc: Valentin Schneider <vschneid(a)redhat.com> Cc: Vincent Guittot <vincent.guittot(a)linaro.org> Cc: Vlastimil Babka <vbabka(a)suse.cz> Cc: Christian Brauner <brauner(a)kernel.org> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- kernel/fork.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) --- a/kernel/fork.c~unshare-fix-nsproxy-leak-on-set_cred_ucounts-error-path +++ a/kernel/fork.c @@ -3133,8 +3133,11 @@ int ksys_unshare(unsigned long unshare_f if (new_cred) { err = set_cred_ucounts(new_cred); - if (err) + if (err) { + if (new_nsproxy) + free_nsproxy(new_nsproxy); goto bad_unshare_cleanup_cred; + } } if (new_fs || new_fd || do_sysvsem || new_cred || new_nsproxy) { _ Patches currently in -mm which might be from ptikhomirov(a)virtuozzo.com are

2 weeks, 4 days

1
0
0 0

[patch 1/1] unshare: fix nsproxy leak on set_cred_ucounts() error path

by Andrew Morton

From: Pavel Tikhomirov <ptikhomirov(a)virtuozzo.com> Subject: unshare: fix nsproxy leak on set_cred_ucounts() error path Date: Tue, 18 Nov 2025 14:45:50 +0800 If unshare_nsproxy_namespaces() successfully creates the new_nsproxy, but then set_cred_ucounts() fails, on its error path there is no cleanup for new_nsproxy, so it is leaked. Let's fix that by freeing new_nsproxy if it's not NULL on this error path. Link: https://lkml.kernel.org/r/20251118064552.936962-1-ptikhomirov@virtuozzo.com Fixes: 905ae01c4ae2a ("Add a reference to ucounts for each cred") Signed-off-by: Pavel Tikhomirov <ptikhomirov(a)virtuozzo.com> Acked-by: Alexey Gladkov <legion(a)kernel.org> Reviewed-by: Liam R. Howlett <Liam.Howlett(a)oracle.com> Cc: Ben Segall <bsegall(a)google.com> Cc: Dietmar Eggemann <dietmar.eggemann(a)arm.com> Cc: Eric Biederman <ebiederm(a)xmission.com> Cc: Ingo Molnar <mingo(a)redhat.com> Cc: Juri Lelli <juri.lelli(a)redhat.com> Cc: Kees Cook <kees(a)kernel.org> Cc: Lorenzo Stoakes <lorenzo.stoakes(a)oracle.com> Cc: Mel Gorman <mgorman <mgorman(a)suse.de> Cc: Michal Hocko <mhocko(a)suse.com> Cc: Mike Rapoport <rppt(a)kernel.org> Cc: Peter Zijlstra <peterz(a)infradead.org> Cc: Steven Rostedt <rostedt(a)goodmis.org> Cc: Suren Baghdasaryan <surenb(a)google.com> Cc: Valentin Schneider <vschneid(a)redhat.com> Cc: Vincent Guittot <vincent.guittot(a)linaro.org> Cc: Vlastimil Babka <vbabka(a)suse.cz> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- kernel/fork.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) --- a/kernel/fork.c~unshare-fix-nsproxy-leak-on-set_cred_ucounts-error-path +++ a/kernel/fork.c @@ -3133,8 +3133,11 @@ int ksys_unshare(unsigned long unshare_f if (new_cred) { err = set_cred_ucounts(new_cred); - if (err) + if (err) { + if (new_nsproxy) + free_nsproxy(new_nsproxy); goto bad_unshare_cleanup_cred; + } } if (new_fs || new_fd || do_sysvsem || new_cred || new_nsproxy) { _

2 weeks, 4 days

1
0
0 0

[PATCH V1 6.1.y 0/2] Fix bad pmd due to race between change_prot_numa() and THP migration

by Harry Yoo

# TL;DR previous discussion: https://lore.kernel.org/linux-mm/b41ea29e-6b48-4f64-859c-73be095453ae@redha… A "bad pmd" error occurs due to race condition between change_prot_numa() and THP migration. The mainline kernel does not have this bug as commit 670ddd8cdc fixes the race condition. 6.1.y, 5.15.y, 5.10.y, 5.4.y are affected by this bug. Fixing this in -stable kernels is tricky because pte_map_offset_lock() has different semantics in pre-6.5 and post-6.5 kernels. I am trying to backport the same mechanism we have in the mainline kernel. Since the code looks bit different due to different semantics of pte_map_offset_lock(), it'd be best to get this reviewed by MM folks. # Testing I verified that the bug described below is not reproduced anymore (on a downstream kernel) after applying this patch series. It used to trigger in few days of intensive numa balancing testing, but it survived 2 weeks with this applied. # Bug Description It was reported that a bad pmd is seen when automatic NUMA balancing is marking page table entries as prot_numa: [2437548.196018] mm/pgtable-generic.c:50: bad pmd 00000000af22fc02(dffffffe71fbfe02) [2437548.235022] Call Trace: [2437548.238234] <TASK> [2437548.241060] dump_stack_lvl+0x46/0x61 [2437548.245689] panic+0x106/0x2e5 [2437548.249497] pmd_clear_bad+0x3c/0x3c [2437548.253967] change_pmd_range.isra.0+0x34d/0x3a7 [2437548.259537] change_p4d_range+0x156/0x20e [2437548.264392] change_protection_range+0x116/0x1a9 [2437548.269976] change_prot_numa+0x15/0x37 [2437548.274774] task_numa_work+0x1b8/0x302 [2437548.279512] task_work_run+0x62/0x95 [2437548.283882] exit_to_user_mode_loop+0x1a4/0x1a9 [2437548.289277] exit_to_user_mode_prepare+0xf4/0xfc [2437548.294751] ? sysvec_apic_timer_interrupt+0x34/0x81 [2437548.300677] irqentry_exit_to_user_mode+0x5/0x25 [2437548.306153] asm_sysvec_apic_timer_interrupt+0x16/0x1b This is due to a race condition between change_prot_numa() and THP migration because the kernel doesn't check is_swap_pmd() and pmd_trans_huge() atomically: change_prot_numa() THP migration ====================================================================== - change_pmd_range() -> is_swap_pmd() returns false, meaning it's not a PMD migration entry. - do_huge_pmd_numa_page() -> migrate_misplaced_page() sets migration entries for the THP. - change_pmd_range() -> pmd_none_or_clear_bad_unless_trans_huge() -> pmd_none() and pmd_trans_huge() returns false - pmd_none_or_clear_bad_unless_trans_huge() -> pmd_bad() returns true for the migration entry! The upstream commit 670ddd8cdcbd ("mm/mprotect: delete pmd_none_or_clear_bad_unless_trans_huge()") closes this race condition by checking is_swap_pmd() and pmd_trans_huge() atomically. # Backporting note commit a79390f5d6a7 ("mm/mprotect: use long for page accountings and retval") is backported to return an error code (negative value) in change_pte_range(). Unlike the mainline, pte_offset_map_lock() does not check if the pmd entry is a migration entry or a hugepage; acquires PTL unconditionally instead of returning failure. Therefore, it is necessary to keep the !is_swap_pmd() && !pmd_trans_huge() && !pmd_devmap() checks in change_pmd_range() before acquiring the PTL. After acquiring the lock, open-code the semantics of pte_offset_map_lock() in the mainline kernel; change_pte_range() fails if the pmd value has changed. This requires adding pmd_old parameter (pmd_t value that is read before calling the function) to change_pte_range(). Hugh Dickins (1): mm/mprotect: delete pmd_none_or_clear_bad_unless_trans_huge() Peter Xu (1): mm/mprotect: use long for page accountings and retval include/linux/hugetlb.h | 4 +- include/linux/mm.h | 2 +- mm/hugetlb.c | 4 +- mm/mempolicy.c | 2 +- mm/mprotect.c | 125 ++++++++++++++++++---------------------- 5 files changed, 61 insertions(+), 76 deletions(-) -- 2.43.0

2 weeks, 4 days

2
4
0 0

[PATCH 1/2] drm/xe/uapi: disallow bind queue sharing

by Matthew Auld

From: Matthew Brost <matthew.brost(a)intel.com> Currently this is very broken if someone attempts to create a bind queue and share it across multiple VMs. For example currently we assume it is safe to acquire the user VM lock to protect some of the bind queue state, but if allow sharing the bind queue with multiple VMs then this quickly breaks down. To fix this reject using a bind queue with any VM that is not the same VM that was originally passed when creating the bind queue. This a uAPI change, however this was more of an oversight on kernel side that we didn't reject this, and expectation is that userspace shouldn't be using bind queues in this way, so in theory this change should go unnoticed. Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Reported-by: Thomas Hellström <thomas.hellstrom(a)linux.intel.com> Signed-off-by: Matthew Brost <matthew.brost(a)intel.com> Co-developed-by: Matthew Auld <matthew.auld(a)intel.com> Signed-off-by: Matthew Auld <matthew.auld(a)intel.com> Cc: Michal Mrozek <michal.mrozek(a)intel.com> Cc: Jose Souza <jose.souza(a)intel.com> Cc: Carl Zhang <carl.zhang(a)intel.com> Cc: <stable(a)vger.kernel.org> # v6.8+ --- drivers/gpu/drm/xe/xe_exec_queue.c | 27 +++++++++++++++++++++++- drivers/gpu/drm/xe/xe_exec_queue.h | 1 + drivers/gpu/drm/xe/xe_exec_queue_types.h | 6 ++++++ drivers/gpu/drm/xe/xe_sriov_vf_ccs.c | 2 +- drivers/gpu/drm/xe/xe_vm.c | 7 +++++- 5 files changed, 40 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/xe/xe_exec_queue.c b/drivers/gpu/drm/xe/xe_exec_queue.c index 8724f8de67e2..31bb051cbb78 100644 --- a/drivers/gpu/drm/xe/xe_exec_queue.c +++ b/drivers/gpu/drm/xe/xe_exec_queue.c @@ -328,6 +328,7 @@ struct xe_exec_queue *xe_exec_queue_create_class(struct xe_device *xe, struct xe * @xe: Xe device. * @tile: tile which bind exec queue belongs to. * @flags: exec queue creation flags + * @user_vm: The user VM which this exec queue belongs to * @extensions: exec queue creation extensions * * Normalize bind exec queue creation. Bind exec queue is tied to migration VM @@ -341,6 +342,7 @@ struct xe_exec_queue *xe_exec_queue_create_class(struct xe_device *xe, struct xe */ struct xe_exec_queue *xe_exec_queue_create_bind(struct xe_device *xe, struct xe_tile *tile, + struct xe_vm *user_vm, u32 flags, u64 extensions) { struct xe_gt *gt = tile->primary_gt; @@ -379,6 +381,9 @@ struct xe_exec_queue *xe_exec_queue_create_bind(struct xe_device *xe, } } + if (user_vm) + q->user_vm = xe_vm_get(user_vm); + return q; } ALLOW_ERROR_INJECTION(xe_exec_queue_create_bind, ERRNO); @@ -407,6 +412,8 @@ void xe_exec_queue_destroy(struct kref *ref) xe_exec_queue_put(eq); } + xe_vm_put(q->user_vm); + q->ops->destroy(q); } @@ -742,6 +749,23 @@ int xe_exec_queue_create_ioctl(struct drm_device *dev, void *data, XE_IOCTL_DBG(xe, eci[0].engine_instance != 0)) return -EINVAL; + vm = xe_vm_lookup(xef, args->vm_id); + if (XE_IOCTL_DBG(xe, !vm)) + return -ENOENT; + + err = down_read_interruptible(&vm->lock); + if (err) { + xe_vm_put(vm); + return err; + } + + if (XE_IOCTL_DBG(xe, xe_vm_is_closed_or_banned(vm))) { + up_read(&vm->lock); + xe_vm_put(vm); + return -ENOENT; + } + up_read(&vm->lock); + for_each_tile(tile, xe, id) { struct xe_exec_queue *new; @@ -749,7 +773,7 @@ int xe_exec_queue_create_ioctl(struct drm_device *dev, void *data, if (id) flags |= EXEC_QUEUE_FLAG_BIND_ENGINE_CHILD; - new = xe_exec_queue_create_bind(xe, tile, flags, + new = xe_exec_queue_create_bind(xe, tile, vm, flags, args->extensions); if (IS_ERR(new)) { err = PTR_ERR(new); @@ -763,6 +787,7 @@ int xe_exec_queue_create_ioctl(struct drm_device *dev, void *data, list_add_tail(&new->multi_gt_list, &q->multi_gt_link); } + xe_vm_put(vm); } else { logical_mask = calc_validate_logical_mask(xe, eci, args->width, diff --git a/drivers/gpu/drm/xe/xe_exec_queue.h b/drivers/gpu/drm/xe/xe_exec_queue.h index fda4d4f9bda8..37a9da22f420 100644 --- a/drivers/gpu/drm/xe/xe_exec_queue.h +++ b/drivers/gpu/drm/xe/xe_exec_queue.h @@ -28,6 +28,7 @@ struct xe_exec_queue *xe_exec_queue_create_class(struct xe_device *xe, struct xe u32 flags, u64 extensions); struct xe_exec_queue *xe_exec_queue_create_bind(struct xe_device *xe, struct xe_tile *tile, + struct xe_vm *user_vm, u32 flags, u64 extensions); void xe_exec_queue_fini(struct xe_exec_queue *q); diff --git a/drivers/gpu/drm/xe/xe_exec_queue_types.h b/drivers/gpu/drm/xe/xe_exec_queue_types.h index 771ffe35cd0c..3a4263c92b3d 100644 --- a/drivers/gpu/drm/xe/xe_exec_queue_types.h +++ b/drivers/gpu/drm/xe/xe_exec_queue_types.h @@ -54,6 +54,12 @@ struct xe_exec_queue { struct kref refcount; /** @vm: VM (address space) for this exec queue */ struct xe_vm *vm; + /** + * @user_vm: User VM (address space) for this exec queue (bind queues + * only) + */ + struct xe_vm *user_vm; + /** @class: class of this exec queue */ enum xe_engine_class class; /** diff --git a/drivers/gpu/drm/xe/xe_sriov_vf_ccs.c b/drivers/gpu/drm/xe/xe_sriov_vf_ccs.c index 33f4238604e1..f7b7c44cf2f6 100644 --- a/drivers/gpu/drm/xe/xe_sriov_vf_ccs.c +++ b/drivers/gpu/drm/xe/xe_sriov_vf_ccs.c @@ -350,7 +350,7 @@ int xe_sriov_vf_ccs_init(struct xe_device *xe) flags = EXEC_QUEUE_FLAG_KERNEL | EXEC_QUEUE_FLAG_PERMANENT | EXEC_QUEUE_FLAG_MIGRATE; - q = xe_exec_queue_create_bind(xe, tile, flags, 0); + q = xe_exec_queue_create_bind(xe, tile, NULL, flags, 0); if (IS_ERR(q)) { err = PTR_ERR(q); goto err_ret; diff --git a/drivers/gpu/drm/xe/xe_vm.c b/drivers/gpu/drm/xe/xe_vm.c index f9989a7a710c..7973d654540a 100644 --- a/drivers/gpu/drm/xe/xe_vm.c +++ b/drivers/gpu/drm/xe/xe_vm.c @@ -1614,7 +1614,7 @@ struct xe_vm *xe_vm_create(struct xe_device *xe, u32 flags, struct xe_file *xef) if (!vm->pt_root[id]) continue; - q = xe_exec_queue_create_bind(xe, tile, create_flags, 0); + q = xe_exec_queue_create_bind(xe, tile, vm, create_flags, 0); if (IS_ERR(q)) { err = PTR_ERR(q); goto err_close; @@ -3571,6 +3571,11 @@ int xe_vm_bind_ioctl(struct drm_device *dev, void *data, struct drm_file *file) } } + if (XE_IOCTL_DBG(xe, q && vm != q->user_vm)) { + err = -EINVAL; + goto put_exec_queue; + } + /* Ensure all UNMAPs visible */ xe_svm_flush(vm); -- 2.51.1

2 weeks, 4 days

3
2
0 0

[PATCH 1/2] hid: hid-pl: handle probe errors

by Oliver Neukum

Errors in init must be reported back or we'll follow a NULL pointer the first time FF is used. Fixes: 20eb127906709 ("hid: force feedback driver for PantherLord USB/PS2 2in1 Adapter") Cc: <stable(a)vger.kernel.org> Signed-off-by: Oliver Neukum <oneukum(a)suse.com> --- drivers/hid/hid-pl.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/hid/hid-pl.c b/drivers/hid/hid-pl.c index 3c8827081dea..dc11d5322fc0 100644 --- a/drivers/hid/hid-pl.c +++ b/drivers/hid/hid-pl.c @@ -194,9 +194,14 @@ static int pl_probe(struct hid_device *hdev, const struct hid_device_id *id) goto err; } - plff_init(hdev); + ret = plff_init(hdev); + if (ret) + goto stop; return 0; + +stop: + hid_hw_stop(hdev); err: return ret; } -- 2.51.1

2 weeks, 4 days

2
1
0 0

[PATCH] drm/arcgpu: fix device node leak

by Luca Ceresoli

This function gets a device_node reference via of_graph_get_remote_port_parent() and stores it in encoder_node, but necer puts that reference. Add it. There used to be a of_node_put(encoder_node) but it has been removed by mistake during a rework in commit 3ea66a794fdc ("drm/arc: Inline arcpgu_drm_hdmi_init"). Fixes: 3ea66a794fdc ("drm/arc: Inline arcpgu_drm_hdmi_init") Cc: stable(a)vger.kernel.org Signed-off-by: Luca Ceresoli <luca.ceresoli(a)bootlin.com> --- drivers/gpu/drm/tiny/arcpgu.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/tiny/arcpgu.c b/drivers/gpu/drm/tiny/arcpgu.c index 7cf0f0ea1bfe..c74466ea2535 100644 --- a/drivers/gpu/drm/tiny/arcpgu.c +++ b/drivers/gpu/drm/tiny/arcpgu.c @@ -250,7 +250,8 @@ DEFINE_DRM_GEM_DMA_FOPS(arcpgu_drm_ops); static int arcpgu_load(struct arcpgu_drm_private *arcpgu) { struct platform_device *pdev = to_platform_device(arcpgu->drm.dev); - struct device_node *encoder_node = NULL, *endpoint_node = NULL; + struct device_node *encoder_node __free(device_node) = NULL; + struct device_node *endpoint_node = NULL; struct drm_connector *connector = NULL; struct drm_device *drm = &arcpgu->drm; int ret; --- base-commit: 949f1fd2225baefbea2995afa807dba5cbdb6bd3 change-id: 20251119-drm-arcgpu-fix-device-node-leak-f909bc1f7fbb Best regards, -- Luca Ceresoli <luca.ceresoli(a)bootlin.com>

2 weeks, 5 days

2
1
0 0

RFQ-062573

by Thomas Pierre

Good day, I am reaching out to invite your company to provide a quotation for the products detailed in the attached request. We recognise that some of these items may not align with your usual supplies, but we expect your expertise in sourcing and supplying these products. Please note that this is a one-time tender, and we require the product and its components delivered on or before the date specified in the attached document. We anticipate your prompt response to enable us to proceed to the next step. Thank you and looking forward to reviewing your proposal soonest. Thomas Pierre Procurement Manager Phone: +1-713-564-2377 fax: +1-713-969-7350 Email: totalenergiesbids(a)contractor.net Note: This message, including any attachments, is intended solely for the use of the individual or entity to whom it is addressed and may contain confidential, proprietary, or legally privileged information. Any unauthorized review, use, disclosure, distribution, reproduction, or any form of dissemination of this communication is strictly prohibited.If you are not the intended recipient, please notify the sender immediately, delete this message from your system, and do not retain, copy, or distribute it.Please note that any views or opinions expressed in this communication are those of the sender and do not necessarily reflect the official views or policies of the company. "Please consider the environment before printing this email."

2 weeks, 5 days

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror