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

[merged mm-hotfixes-stable] mm-kmemleak-avoid-deadlock-by-moving-pr_warn-outside-kmemleak_lock.patch removed from -mm tree

by Andrew Morton

The quilt patch titled Subject: mm/kmemleak: avoid deadlock by moving pr_warn() outside kmemleak_lock has been removed from the -mm tree. Its filename was mm-kmemleak-avoid-deadlock-by-moving-pr_warn-outside-kmemleak_lock.patch This patch was dropped because it was merged into the mm-hotfixes-stable branch of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm ------------------------------------------------------ From: Breno Leitao <leitao(a)debian.org> Subject: mm/kmemleak: avoid deadlock by moving pr_warn() outside kmemleak_lock Date: Thu, 31 Jul 2025 02:57:18 -0700 When netpoll is enabled, calling pr_warn_once() while holding kmemleak_lock in mem_pool_alloc() can cause a deadlock due to lock inversion with the netconsole subsystem. This occurs because pr_warn_once() may trigger netpoll, which eventually leads to __alloc_skb() and back into kmemleak code, attempting to reacquire kmemleak_lock. This is the path for the deadlock. mem_pool_alloc() -> raw_spin_lock_irqsave(&kmemleak_lock, flags); -> pr_warn_once() -> netconsole subsystem -> netpoll -> __alloc_skb -> __create_object -> raw_spin_lock_irqsave(&kmemleak_lock, flags); Fix this by setting a flag and issuing the pr_warn_once() after kmemleak_lock is released. Link: https://lkml.kernel.org/r/20250731-kmemleak_lock-v1-1-728fd470198f@debian.o… Fixes: c5665868183f ("mm: kmemleak: use the memory pool for early allocations") Signed-off-by: Breno Leitao <leitao(a)debian.org> Reported-by: Jakub Kicinski <kuba(a)kernel.org> Acked-by: Catalin Marinas <catalin.marinas(a)arm.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/kmemleak.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) --- a/mm/kmemleak.c~mm-kmemleak-avoid-deadlock-by-moving-pr_warn-outside-kmemleak_lock +++ a/mm/kmemleak.c @@ -470,6 +470,7 @@ static struct kmemleak_object *mem_pool_ { unsigned long flags; struct kmemleak_object *object; + bool warn = false; /* try the slab allocator first */ if (object_cache) { @@ -488,8 +489,10 @@ static struct kmemleak_object *mem_pool_ else if (mem_pool_free_count) object = &mem_pool[--mem_pool_free_count]; else - pr_warn_once("Memory pool empty, consider increasing CONFIG_DEBUG_KMEMLEAK_MEM_POOL_SIZE\n"); + warn = true; raw_spin_unlock_irqrestore(&kmemleak_lock, flags); + if (warn) + pr_warn_once("Memory pool empty, consider increasing CONFIG_DEBUG_KMEMLEAK_MEM_POOL_SIZE\n"); return object; } _ Patches currently in -mm which might be from leitao(a)debian.org are

3 months, 3 weeks

1
0
0 0

[merged mm-hotfixes-stable] kasan-test-fix-protection-against-compiler-elision.patch removed from -mm tree

by Andrew Morton

The quilt patch titled Subject: kasan/test: fix protection against compiler elision has been removed from the -mm tree. Its filename was kasan-test-fix-protection-against-compiler-elision.patch This patch was dropped because it was merged into the mm-hotfixes-stable branch of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm ------------------------------------------------------ From: Jann Horn <jannh(a)google.com> Subject: kasan/test: fix protection against compiler elision Date: Mon, 28 Jul 2025 22:11:54 +0200 The kunit test is using assignments to "static volatile void *kasan_ptr_result" to prevent elision of memory loads, but that's not working: In this variable definition, the "volatile" applies to the "void", not to the pointer. To make "volatile" apply to the pointer as intended, it must follow after the "*". This makes the kasan_memchr test pass again on my system. The kasan_strings test is still failing because all the definitions of load_unaligned_zeropad() are lacking explicit instrumentation hooks and ASAN does not instrument asm() memory operands. Link: https://lkml.kernel.org/r/20250728-kasan-kunit-fix-volatile-v1-1-e7157c9af8… Fixes: 5f1c8108e7ad ("mm:kasan: fix sparse warnings: Should it be static?") Signed-off-by: Jann Horn <jannh(a)google.com> Cc: Alexander Potapenko <glider(a)google.com> Cc: Andrey Konovalov <andreyknvl(a)gmail.com> Cc: Andrey Ryabinin <ryabinin.a.a(a)gmail.com> Cc: Dmitriy Vyukov <dvyukov(a)google.com> Cc: Jann Horn <jannh(a)google.com> Cc: Nihar Chaithanya <niharchaithanya(a)gmail.com> Cc: Vincenzo Frascino <vincenzo.frascino(a)arm.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/kasan/kasan_test_c.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/mm/kasan/kasan_test_c.c~kasan-test-fix-protection-against-compiler-elision +++ a/mm/kasan/kasan_test_c.c @@ -47,7 +47,7 @@ static struct { * Some tests use these global variables to store return values from function * calls that could otherwise be eliminated by the compiler as dead code. */ -static volatile void *kasan_ptr_result; +static void *volatile kasan_ptr_result; static volatile int kasan_int_result; /* Probe for console output: obtains test_status lines of interest. */ _ Patches currently in -mm which might be from jannh(a)google.com are kasan-add-test-for-slab_typesafe_by_rcu-quarantine-skipping.patch kasan-add-test-for-slab_typesafe_by_rcu-quarantine-skipping-v2.patch

3 months, 3 weeks

1
0
0 0

[PATCH] NFSD: Fix destination buffer size in nfsd4_ssc_setup_dul()

by Thorsten Blum

Commit 5304877936c0 ("NFSD: Fix strncpy() fortify warning") replaced strncpy(,, sizeof(..)) with strlcpy(,, sizeof(..) - 1), but strlcpy() already guaranteed NUL-termination of the destination buffer and subtracting one byte potentially truncated the source string. The incorrect size was then carried over in commit 72f78ae00a8e ("NFSD: move from strlcpy with unused retval to strscpy") when switching from strlcpy() to strscpy(). Fix this off-by-one error by using the full size of the destination buffer again. Cc: stable(a)vger.kernel.org Fixes: 5304877936c0 ("NFSD: Fix strncpy() fortify warning") Signed-off-by: Thorsten Blum <thorsten.blum(a)linux.dev> --- fs/nfsd/nfs4proc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/nfsd/nfs4proc.c b/fs/nfsd/nfs4proc.c index 71b428efcbb5..32be002a248f 100644 --- a/fs/nfsd/nfs4proc.c +++ b/fs/nfsd/nfs4proc.c @@ -1469,7 +1469,7 @@ static __be32 nfsd4_ssc_setup_dul(struct nfsd_net *nn, char *ipaddr, return 0; } if (work) { - strscpy(work->nsui_ipaddr, ipaddr, sizeof(work->nsui_ipaddr) - 1); + strscpy(work->nsui_ipaddr, ipaddr); refcount_set(&work->nsui_refcnt, 2); work->nsui_busy = true; list_add_tail(&work->nsui_list, &nn->nfsd_ssc_mount_list); -- 2.50.1

3 months, 3 weeks

2
1
0 0

[PATCH AUTOSEL 6.16-6.6] mfd: axp20x: Set explicit ID for AXP313 regulator

by Sasha Levin

From: Chen-Yu Tsai <wens(a)csie.org> [ Upstream commit 88828c7e940dd45d139ad4a39d702b23840a37c5 ] On newer boards featuring the A523 SoC, the AXP323 (related to the AXP313) is paired with the AXP717 and serves as a secondary PMIC providing additional regulator outputs. However the MFD cells are all registered with PLATFORM_DEVID_NONE, which causes the regulator cells to conflict with each other. Commit e37ec3218870 ("mfd: axp20x: Allow multiple regulators") attempted to fix this by switching to PLATFORM_DEVID_AUTO so that the device names would all be different, however that broke IIO channel mapping, which is also tied to the device names. As a result the change was later reverted. Instead, here we attempt to make sure the AXP313/AXP323 regulator cell does not conflict by explicitly giving it an ID number. This was previously done for the AXP809+AXP806 pair used with the A80 SoC. Signed-off-by: Chen-Yu Tsai <wens(a)csie.org> Link: https://lore.kernel.org/r/20250619173207.3367126-1-wens@kernel.org Signed-off-by: Lee Jones <lee(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- LLM Generated explanations, may be completely bogus: Based on my analysis, here's my assessment: **Backport Status: YES** This commit is suitable for backporting to stable kernel trees for the following reasons: 1. **Fixes a real bug**: The commit addresses a device naming conflict issue when using AXP313/AXP323 PMICs alongside AXP717 as a secondary PMIC. Without this fix, the kernel produces a sysfs duplicate filename error and fails to properly register the secondary regulator device. 2. **Small and contained change**: The fix is minimal - it only changes one line of code from `MFD_CELL_NAME("axp20x-regulator")` to `MFD_CELL_BASIC("axp20x-regulator", NULL, NULL, 0, 1)`, which explicitly sets an ID of 1 for the AXP313 regulator cell. 3. **Follows established pattern**: The commit follows an existing pattern already used in the same driver for the AXP806 PMIC (lines 1173-1174 in axp806_cells), which also sets an explicit ID (2) to avoid conflicts when paired with AXP809. 4. **Minimal risk of regression**: The change only affects AXP313/AXP323 devices and doesn't touch other PMIC configurations. The explicit ID assignment is a safe approach that doesn't break existing IIO channel mappings (which was the problem with the previous PLATFORM_DEVID_AUTO approach mentioned in the commit message). 5. **Clear problem and solution**: The commit message clearly explains the issue (sysfs duplicate filename error) and references the history of previous attempts to fix similar issues (commit e37ec3218870 and its revert). The solution is targeted and doesn't introduce architectural changes. 6. **Hardware enablement fix**: This fix enables proper functioning of boards with the A523 SoC that use dual PMIC configurations (AXP323 + AXP717), which would otherwise fail to initialize properly. The commit meets the stable tree criteria of being an important bugfix with minimal risk and contained scope. It fixes a specific hardware configuration issue without introducing new features or making broad architectural changes. drivers/mfd/axp20x.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c index e9914e8a29a3..25c639b348cd 100644 --- a/drivers/mfd/axp20x.c +++ b/drivers/mfd/axp20x.c @@ -1053,7 +1053,8 @@ static const struct mfd_cell axp152_cells[] = { }; static struct mfd_cell axp313a_cells[] = { - MFD_CELL_NAME("axp20x-regulator"), + /* AXP323 is sometimes paired with AXP717 as sub-PMIC */ + MFD_CELL_BASIC("axp20x-regulator", NULL, NULL, 0, 1), MFD_CELL_RES("axp313a-pek", axp313a_pek_resources), }; -- 2.39.5

3 months, 3 weeks

2
72
0 0

[PATCH v3 0/4] kcov, usb: Fix invalid context sleep in softirq path on PREEMPT_RT

by Yunseong Kim

This patch series resolves a sleeping function called from invalid context bug that occurs when fuzzing USB with syzkaller on a PREEMPT_RT kernel. The regression was introduced by the interaction of two separate patches: one that made kcov's internal locks sleep on PREEMPT_RT for better latency (d5d2c51f1e5f), and another that wrapped a kcov call in the USB softirq path with local_irq_save() to prevent re-entrancy (f85d39dd7ed8). This combination resulted in an attempt to acquire a sleeping lock from within an atomic context, causing a kernel BUG. To resolve this, this series makes the kcov remote path fully compatible with atomic contexts by converting all its internal locking primitives to non-sleeping variants. This approach is more robust than conditional compilation as it creates a single, unified codebase that works correctly on both RT and non-RT kernels. The series is structured as follows: Patch 1 converts the global kcov locks (kcov->lock and kcov_remote_lock) to use the non-sleeping raw_spinlock_t. Patch 2 replace the PREEMPT_RT-specific per-CPU local_lock_t back to the original local_irq_save/restore primitives, making the per-CPU protection non-sleeping as well. Patches 3 and 4 are preparatory refactoring. They move the memory allocation for remote handles out of the locked sections in the KCOV_REMOTE_ENABLE ioctl path, which is a prerequisite for safely using raw_spinlock_t as it forbids sleeping functions like kmalloc within its critical section. With these changes, I have been able to run syzkaller fuzzing on a PREEMPT_RT kernel for a full day with no issues reported. Reproduction details in here. Link: https://lore.kernel.org/all/20250725201400.1078395-2-ysk@kzalloc.com/t/#u Signed-off-by: Yunseong Kim <ysk(a)kzalloc.com> --- Changes from v2: 1. Updated kcov_remote_reset() to use raw_spin_lock_irqsave() / raw_spin_unlock_irqrestore() instead of raw_spin_lock() / raw_spin_unlock(), following the interrupt disabling pattern used in the original function that guard kcov_remote_lock. Changes from v1: 1. Dropped the #ifdef-based PREEMPT_RT branching. 2. Convert kcov->lock and kcov_remote_lock from spinlock_t to raw_spinlock_t. This ensures they remain true, non-sleeping spinlocks even on PREEMPT_RT kernels. 3. Remove the local_lock_t protection for kcov_percpu_data in kcov_remote_start/stop(). Since local_lock_t can also sleep under RT, and the required protection is against local interrupts when accessing per-CPU data, it is replaced with explicit local_irq_save/restore(). 4. Refactor the KCOV_REMOTE_ENABLE path to move memory allocations out of the critical section. 5. Modify the ioctl handling logic to utilize these pre-allocated structures within the critical section. kcov_remote_add() is modified to accept a pre-allocated structure instead of allocating one internally. All necessary struct kcov_remote structures are now pre-allocated individually in kcov_ioctl() using GFP_KERNEL (allowing sleep) before acquiring the raw spinlocks. Changes from v0: 1. On PREEMPT_RT, separated the handling of kcov_remote_start_usb_softirq() and kcov_remote_stop_usb_softirq() to allow sleeping when entering kcov_remote_start_usb() / kcov_remote_stop(). Yunseong Kim (4): kcov: Use raw_spinlock_t for kcov->lock and kcov_remote_lock kcov: Replace per-CPU local_lock with local_irq_save/restore kcov: Separate KCOV_REMOTE_ENABLE ioctl helper function kcov: move remote handle allocation outside raw spinlock kernel/kcov.c | 248 +++++++++++++++++++++++++++----------------------- 1 file changed, 134 insertions(+), 114 deletions(-) base-commit: 186f3edfdd41f2ae87fc40a9ccba52a3bf930994 -- 2.50.0

3 months, 3 weeks

3
11
0 0

[PATCH v2] drm/xe: Defer buffer object shrinker write-backs and GPU waits

by Thomas Hellström

When the xe buffer-object shrinker allows GPU waits and write-back, (typically from kswapd), perform multiple passes, skipping subsequent passes if the shrinker number of scanned objects target is reached. 1) Without GPU waits and write-back 2) Without write-back 3) With both GPU-waits and write-back This is to avoid stalls and costly write- and readbacks unless they are really necessary. v2: - Don't test for scan completion twice. (Stuart Summers) - Update tags. Reported-by: melvyn <melvyn2(a)dnsense.pub> Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/5557 Cc: Summers Stuart <stuart.summers(a)intel.com> Fixes: 00c8efc3180f ("drm/xe: Add a shrinker for xe bos") Cc: <stable(a)vger.kernel.org> # v6.15+ Signed-off-by: Thomas Hellström <thomas.hellstrom(a)linux.intel.com> --- drivers/gpu/drm/xe/xe_shrinker.c | 51 +++++++++++++++++++++++++++++--- 1 file changed, 47 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/xe/xe_shrinker.c b/drivers/gpu/drm/xe/xe_shrinker.c index 1c3c04d52f55..90244fe59b59 100644 --- a/drivers/gpu/drm/xe/xe_shrinker.c +++ b/drivers/gpu/drm/xe/xe_shrinker.c @@ -54,10 +54,10 @@ xe_shrinker_mod_pages(struct xe_shrinker *shrinker, long shrinkable, long purgea write_unlock(&shrinker->lock); } -static s64 xe_shrinker_walk(struct xe_device *xe, - struct ttm_operation_ctx *ctx, - const struct xe_bo_shrink_flags flags, - unsigned long to_scan, unsigned long *scanned) +static s64 __xe_shrinker_walk(struct xe_device *xe, + struct ttm_operation_ctx *ctx, + const struct xe_bo_shrink_flags flags, + unsigned long to_scan, unsigned long *scanned) { unsigned int mem_type; s64 freed = 0, lret; @@ -93,6 +93,48 @@ static s64 xe_shrinker_walk(struct xe_device *xe, return freed; } +/* + * Try shrinking idle objects without writeback first, then if not sufficient, + * try also non-idle objects and finally if that's not sufficient either, + * add writeback. This avoids stalls and explicit writebacks with light or + * moderate memory pressure. + */ +static s64 xe_shrinker_walk(struct xe_device *xe, + struct ttm_operation_ctx *ctx, + const struct xe_bo_shrink_flags flags, + unsigned long to_scan, unsigned long *scanned) +{ + bool no_wait_gpu = true; + struct xe_bo_shrink_flags save_flags = flags; + s64 lret, freed; + + swap(no_wait_gpu, ctx->no_wait_gpu); + save_flags.writeback = false; + lret = __xe_shrinker_walk(xe, ctx, save_flags, to_scan, scanned); + swap(no_wait_gpu, ctx->no_wait_gpu); + if (lret < 0 || *scanned >= to_scan) + return lret; + + freed = lret; + if (!ctx->no_wait_gpu) { + lret = __xe_shrinker_walk(xe, ctx, save_flags, to_scan, scanned); + if (lret < 0) + return lret; + freed += lret; + if (*scanned >= to_scan) + return freed; + } + + if (flags.writeback) { + lret = __xe_shrinker_walk(xe, ctx, flags, to_scan, scanned); + if (lret < 0) + return lret; + freed += lret; + } + + return freed; +} + static unsigned long xe_shrinker_count(struct shrinker *shrink, struct shrink_control *sc) { @@ -199,6 +241,7 @@ static unsigned long xe_shrinker_scan(struct shrinker *shrink, struct shrink_con runtime_pm = xe_shrinker_runtime_pm_get(shrinker, true, 0, can_backup); shrink_flags.purge = false; + lret = xe_shrinker_walk(shrinker->xe, &ctx, shrink_flags, nr_to_scan, &nr_scanned); if (lret >= 0) -- 2.50.1

3 months, 3 weeks

3
2
0 0

[PATCH v2] RDMA/siw: Fix the sendmsg byte count in siw_tcp_sendpages

by Pedro Falcato

Ever since commit c2ff29e99a76 ("siw: Inline do_tcp_sendpages()"), we have been doing this: static int siw_tcp_sendpages(struct socket *s, struct page **page, int offset, size_t size) [...] /* Calculate the number of bytes we need to push, for this page * specifically */ size_t bytes = min_t(size_t, PAGE_SIZE - offset, size); /* If we can't splice it, then copy it in, as normal */ if (!sendpage_ok(page[i])) msg.msg_flags &= ~MSG_SPLICE_PAGES; /* Set the bvec pointing to the page, with len $bytes */ bvec_set_page(&bvec, page[i], bytes, offset); /* Set the iter to $size, aka the size of the whole sendpages (!!!) */ iov_iter_bvec(&msg.msg_iter, ITER_SOURCE, &bvec, 1, size); try_page_again: lock_sock(sk); /* Sendmsg with $size size (!!!) */ rv = tcp_sendmsg_locked(sk, &msg, size); This means we've been sending oversized iov_iters and tcp_sendmsg calls for a while. This has a been a benign bug because sendpage_ok() always returned true. With the recent slab allocator changes being slowly introduced into next (that disallow sendpage on large kmalloc allocations), we have recently hit out-of-bounds crashes, due to slight differences in iov_iter behavior between the MSG_SPLICE_PAGES and "regular" copy paths: (MSG_SPLICE_PAGES) skb_splice_from_iter iov_iter_extract_pages iov_iter_extract_bvec_pages uses i->nr_segs to correctly stop in its tracks before OoB'ing everywhere skb_splice_from_iter gets a "short" read (!MSG_SPLICE_PAGES) skb_copy_to_page_nocache copy=iov_iter_count [...] copy_from_iter /* this doesn't help */ if (unlikely(iter->count < len)) len = iter->count; iterate_bvec ... and we run off the bvecs Fix this by properly setting the iov_iter's byte count, plus sending the correct byte count to tcp_sendmsg_locked. Cc: stable(a)vger.kernel.org Fixes: c2ff29e99a76 ("siw: Inline do_tcp_sendpages()") Reported-by: kernel test robot <oliver.sang(a)intel.com> Closes: https://lore.kernel.org/oe-lkp/202507220801.50a7210-lkp@intel.com Reviewed-by: David Howells <dhowells(a)redhat.com> Signed-off-by: Pedro Falcato <pfalcato(a)suse.de> --- v2: - Add David Howells's Rb on the original patch - Remove the offset increment, since it's dead code drivers/infiniband/sw/siw/siw_qp_tx.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/infiniband/sw/siw/siw_qp_tx.c b/drivers/infiniband/sw/siw/siw_qp_tx.c index 3a08f57d2211..f7dd32c6e5ba 100644 --- a/drivers/infiniband/sw/siw/siw_qp_tx.c +++ b/drivers/infiniband/sw/siw/siw_qp_tx.c @@ -340,18 +340,17 @@ static int siw_tcp_sendpages(struct socket *s, struct page **page, int offset, if (!sendpage_ok(page[i])) msg.msg_flags &= ~MSG_SPLICE_PAGES; bvec_set_page(&bvec, page[i], bytes, offset); - iov_iter_bvec(&msg.msg_iter, ITER_SOURCE, &bvec, 1, size); + iov_iter_bvec(&msg.msg_iter, ITER_SOURCE, &bvec, 1, bytes); try_page_again: lock_sock(sk); - rv = tcp_sendmsg_locked(sk, &msg, size); + rv = tcp_sendmsg_locked(sk, &msg, bytes); release_sock(sk); if (rv > 0) { size -= rv; sent += rv; if (rv != bytes) { - offset += rv; bytes -= rv; goto try_page_again; } -- 2.50.1

3 months, 3 weeks

4
5
0 0

[PATCH v3] vhost/net: Protect ubufs with rcu read lock in vhost_net_ubuf_put()

by Nikolay Kuratov

When operating on struct vhost_net_ubuf_ref, the following execution sequence is theoretically possible: CPU0 is finalizing DMA operation CPU1 is doing VHOST_NET_SET_BACKEND // ubufs->refcount == 2 vhost_net_ubuf_put() vhost_net_ubuf_put_wait_and_free(oldubufs) vhost_net_ubuf_put_and_wait() vhost_net_ubuf_put() int r = atomic_sub_return(1, &ubufs->refcount); // r = 1 int r = atomic_sub_return(1, &ubufs->refcount); // r = 0 wait_event(ubufs->wait, !atomic_read(&ubufs->refcount)); // no wait occurs here because condition is already true kfree(ubufs); if (unlikely(!r)) wake_up(&ubufs->wait); // use-after-free This leads to use-after-free on ubufs access. This happens because CPU1 skips waiting for wake_up() when refcount is already zero. To prevent that use a read-side RCU critical section in vhost_net_ubuf_put(), as suggested by Hillf Danton. For this lock to take effect, free ubufs with kfree_rcu(). Cc: stable(a)vger.kernel.org Fixes: 0ad8b480d6ee9 ("vhost: fix ref cnt checking deadlock") Reported-by: Andrey Ryabinin <arbn(a)yandex-team.com> Suggested-by: Hillf Danton <hdanton(a)sina.com> Signed-off-by: Nikolay Kuratov <kniv(a)yandex-team.ru> --- v2: * move reinit_completion() into vhost_net_flush(), thanks to Hillf Danton * add Tested-by: Lei Yang * check that usages of put_and_wait() are consistent across LTS kernels v3: * use rcu_read_lock() with kfree_rcu() instead of completion, as suggested by Hillf Danton drivers/vhost/net.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c index 6edac0c1ba9b..c6508fe0d5c8 100644 --- a/drivers/vhost/net.c +++ b/drivers/vhost/net.c @@ -99,6 +99,7 @@ struct vhost_net_ubuf_ref { atomic_t refcount; wait_queue_head_t wait; struct vhost_virtqueue *vq; + struct rcu_head rcu; }; #define VHOST_NET_BATCH 64 @@ -250,9 +251,13 @@ vhost_net_ubuf_alloc(struct vhost_virtqueue *vq, bool zcopy) static int vhost_net_ubuf_put(struct vhost_net_ubuf_ref *ubufs) { - int r = atomic_sub_return(1, &ubufs->refcount); + int r; + + rcu_read_lock(); + r = atomic_sub_return(1, &ubufs->refcount); if (unlikely(!r)) wake_up(&ubufs->wait); + rcu_read_unlock(); return r; } @@ -265,7 +270,7 @@ static void vhost_net_ubuf_put_and_wait(struct vhost_net_ubuf_ref *ubufs) static void vhost_net_ubuf_put_wait_and_free(struct vhost_net_ubuf_ref *ubufs) { vhost_net_ubuf_put_and_wait(ubufs); - kfree(ubufs); + kfree_rcu(ubufs, rcu); } static void vhost_net_clear_ubuf_info(struct vhost_net *n) -- 2.34.1

3 months, 3 weeks

1
0
0 0

[PATCH v3 1/3] sched_ext: Mark scx_bpf_cpu_rq as NULL returnable

by Christian Loehle

scx_bpf_cpu_rq() obviously returns NULL on invalid cpu. Mark it as such. While kf_cpu_valid() will trigger scx_ops_error() that leads to the BPF scheduler exiting, this isn't guaranteed to be immediate, allowing for a dereference of a NULL scx_bpf_cpu_rq() return value. Cc: stable(a)vger.kernel.org Fixes: 6203ef73fa5c ("sched/ext: Add BPF function to fetch rq") Signed-off-by: Christian Loehle <christian.loehle(a)arm.com> Acked-by: Andrea Righi <arighi(a)nvidia.com> --- kernel/sched/ext.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/sched/ext.c b/kernel/sched/ext.c index 7dedc9a16281..3ea3f0f18030 100644 --- a/kernel/sched/ext.c +++ b/kernel/sched/ext.c @@ -7589,7 +7589,7 @@ BTF_ID_FLAGS(func, scx_bpf_get_online_cpumask, KF_ACQUIRE) BTF_ID_FLAGS(func, scx_bpf_put_cpumask, KF_RELEASE) BTF_ID_FLAGS(func, scx_bpf_task_running, KF_RCU) BTF_ID_FLAGS(func, scx_bpf_task_cpu, KF_RCU) -BTF_ID_FLAGS(func, scx_bpf_cpu_rq) +BTF_ID_FLAGS(func, scx_bpf_cpu_rq, KF_RET_NULL) #ifdef CONFIG_CGROUP_SCHED BTF_ID_FLAGS(func, scx_bpf_task_cgroup, KF_RCU | KF_ACQUIRE) #endif -- 2.34.1

3 months, 3 weeks

1
0
0 0

[PATCH] drm/amdgpu: Raven: don't allow mixing GTT and VRAM

by Brian Geffon

Commit 81d0bcf99009 ("drm/amdgpu: make display pinning more flexible (v2)") allowed for newer ASICs to mix GTT and VRAM, this change also noted that some older boards, such as Stoney and Carrizo do not support this. It appears that at least one additional ASIC does not support this which is Raven. We observed this issue when migrating a device from a 5.4 to 6.6 kernel and have confirmed that Raven also needs to be excluded from mixing GTT and VRAM. Fixes: 81d0bcf99009 ("drm/amdgpu: make display pinning more flexible (v2)") Cc: Luben Tuikov <luben.tuikov(a)amd.com> Cc: Christian König <christian.koenig(a)amd.com> Cc: Alex Deucher <alexander.deucher(a)amd.com> Cc: stable(a)vger.kernel.org # 6.1+ Tested-by: Thadeu Lima de Souza Cascardo <cascardo(a)igalia.com> Signed-off-by: Brian Geffon <bgeffon(a)google.com> --- drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c index 73403744331a..5d7f13e25b7c 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c @@ -1545,7 +1545,8 @@ uint32_t amdgpu_bo_get_preferred_domain(struct amdgpu_device *adev, uint32_t domain) { if ((domain == (AMDGPU_GEM_DOMAIN_VRAM | AMDGPU_GEM_DOMAIN_GTT)) && - ((adev->asic_type == CHIP_CARRIZO) || (adev->asic_type == CHIP_STONEY))) { + ((adev->asic_type == CHIP_CARRIZO) || (adev->asic_type == CHIP_STONEY) || + (adev->asic_type == CHIP_RAVEN))) { domain = AMDGPU_GEM_DOMAIN_VRAM; if (adev->gmc.real_vram_size <= AMDGPU_SG_THRESHOLD) domain = AMDGPU_GEM_DOMAIN_GTT; -- 2.50.0.727.gbf7dc18ff4-goog

3 months, 3 weeks

5
16
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror