v1->v2:
- Removed changes in pci-host-common.c, those were comitted
by mistake.
The first patch moves the initialization of cptlfs device info to the early
probe stage, also eliminate redundant initialization.
The second patch updates the driver to use a dynamically allocated
memory region for LMTST instead of the statically allocated memory
from firmware. It also adds myself as a maintainer.
Bharat Bhushan (2):
crypto: octeontx2: Initialize cptlfs device info once
crypto: octeontx2: Use dynamic allocated memory region for lmtst
MAINTAINERS | 1 +
drivers/crypto/marvell/octeontx2/cn10k_cpt.c | 89 ++++++++++++++-----
drivers/crypto/marvell/octeontx2/cn10k_cpt.h | 1 +
.../marvell/octeontx2/otx2_cpt_common.h | 1 +
.../marvell/octeontx2/otx2_cpt_mbox_common.c | 25 ++++++
drivers/crypto/marvell/octeontx2/otx2_cptlf.c | 5 +-
drivers/crypto/marvell/octeontx2/otx2_cptlf.h | 12 ++-
.../marvell/octeontx2/otx2_cptpf_main.c | 18 +++-
.../marvell/octeontx2/otx2_cptpf_mbox.c | 6 +-
.../marvell/octeontx2/otx2_cptpf_ucode.c | 2 -
.../marvell/octeontx2/otx2_cptvf_main.c | 19 ++--
.../marvell/octeontx2/otx2_cptvf_mbox.c | 1 +
12 files changed, 133 insertions(+), 47 deletions(-)
--
2.34.1
The patch below does not apply to the 6.12-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
To reproduce the conflict and resubmit, you may use the following commands:
git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.12.y
git checkout FETCH_HEAD
git cherry-pick -x 76a771ec4c9adfd75fe53c8505cf656a075d7101
# <resolve conflicts, build, test, etc.>
git commit -s
git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025051251-shawl-unmarked-03e8@gregkh' --subject-prefix 'PATCH 6.12.y' HEAD^..
Possible dependencies:
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From 76a771ec4c9adfd75fe53c8505cf656a075d7101 Mon Sep 17 00:00:00 2001
From: Koichiro Den <koichiro.den(a)canonical.com>
Date: Fri, 6 Dec 2024 10:10:47 +0900
Subject: [PATCH] virtio_net: ensure netdev_tx_reset_queue is called on bind
xsk for tx
virtnet_sq_bind_xsk_pool() flushes tx skbs and then resets tx queue, so
DQL counters need to be reset when flushing has actually occurred, Add
virtnet_sq_free_unused_buf_done() as a callback for virtqueue_resize()
to handle this.
Fixes: 21a4e3ce6dc7 ("virtio_net: xsk: bind/unbind xsk for tx")
Signed-off-by: Koichiro Den <koichiro.den(a)canonical.com>
Acked-by: Jason Wang <jasowang(a)redhat.com>
Reviewed-by: Xuan Zhuo <xuanzhuo(a)linux.alibaba.com>
Signed-off-by: Paolo Abeni <pabeni(a)redhat.com>
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index 5cf4b2b20431..7646ddd9bef7 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -5740,7 +5740,8 @@ static int virtnet_sq_bind_xsk_pool(struct virtnet_info *vi,
virtnet_tx_pause(vi, sq);
- err = virtqueue_reset(sq->vq, virtnet_sq_free_unused_buf, NULL);
+ err = virtqueue_reset(sq->vq, virtnet_sq_free_unused_buf,
+ virtnet_sq_free_unused_buf_done);
if (err) {
netdev_err(vi->dev, "reset tx fail: tx queue index: %d err: %d\n", qindex, err);
pool = NULL;
Hi,
On Sun, May 18, 2025 at 06:38:01AM -0400, Sasha Levin wrote:
> This is a note to let you know that I've just added the patch titled
>
> sched_ext: Fix missing rq lock in scx_bpf_cpuperf_set()
>
> to the 6.12-stable tree which can be found at:
> http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
>
> The filename of the patch is:
> sched_ext-fix-missing-rq-lock-in-scx_bpf_cpuperf_set.patch
> and it can be found in the queue-6.12 subdirectory.
>
> If you, or anyone else, feels it should not be added to the stable tree,
> please let <stable(a)vger.kernel.org> know about it.
This requires upstream commit 18853ba782bef ("sched_ext: Track currently
locked rq").
Thanks,
-Andrea
>
>
>
> commit b19ccb5dc4d3d35b83b94fe2514456dc0b3a9ba5
> Author: Andrea Righi <arighi(a)nvidia.com>
> Date: Tue Apr 22 10:26:33 2025 +0200
>
> sched_ext: Fix missing rq lock in scx_bpf_cpuperf_set()
>
> [ Upstream commit a11d6784d7316a6c77ca9f14fb1a698ebbb3c1fb ]
>
> scx_bpf_cpuperf_set() can be used to set a performance target level on
> any CPU. However, it doesn't correctly acquire the corresponding rq
> lock, which may lead to unsafe behavior and trigger the following
> warning, due to the lockdep_assert_rq_held() check:
>
> [ 51.713737] WARNING: CPU: 3 PID: 3899 at kernel/sched/sched.h:1512 scx_bpf_cpuperf_set+0x1a0/0x1e0
> ...
> [ 51.713836] Call trace:
> [ 51.713837] scx_bpf_cpuperf_set+0x1a0/0x1e0 (P)
> [ 51.713839] bpf_prog_62d35beb9301601f_bpfland_init+0x168/0x440
> [ 51.713841] bpf__sched_ext_ops_init+0x54/0x8c
> [ 51.713843] scx_ops_enable.constprop.0+0x2c0/0x10f0
> [ 51.713845] bpf_scx_reg+0x18/0x30
> [ 51.713847] bpf_struct_ops_link_create+0x154/0x1b0
> [ 51.713849] __sys_bpf+0x1934/0x22a0
>
> Fix by properly acquiring the rq lock when possible or raising an error
> if we try to operate on a CPU that is not the one currently locked.
>
> Fixes: d86adb4fc0655 ("sched_ext: Add cpuperf support")
> Signed-off-by: Andrea Righi <arighi(a)nvidia.com>
> Acked-by: Changwoo Min <changwoo(a)igalia.com>
> Signed-off-by: Tejun Heo <tj(a)kernel.org>
> Signed-off-by: Sasha Levin <sashal(a)kernel.org>
>
> diff --git a/kernel/sched/ext.c b/kernel/sched/ext.c
> index 7ed25654820fd..0147c4452f4df 100644
> --- a/kernel/sched/ext.c
> +++ b/kernel/sched/ext.c
> @@ -7018,13 +7018,32 @@ __bpf_kfunc void scx_bpf_cpuperf_set(s32 cpu, u32 perf)
> }
>
> if (ops_cpu_valid(cpu, NULL)) {
> - struct rq *rq = cpu_rq(cpu);
> + struct rq *rq = cpu_rq(cpu), *locked_rq = scx_locked_rq();
> + struct rq_flags rf;
> +
> + /*
> + * When called with an rq lock held, restrict the operation
> + * to the corresponding CPU to prevent ABBA deadlocks.
> + */
> + if (locked_rq && rq != locked_rq) {
> + scx_ops_error("Invalid target CPU %d", cpu);
> + return;
> + }
> +
> + /*
> + * If no rq lock is held, allow to operate on any CPU by
> + * acquiring the corresponding rq lock.
> + */
> + if (!locked_rq) {
> + rq_lock_irqsave(rq, &rf);
> + update_rq_clock(rq);
> + }
>
> rq->scx.cpuperf_target = perf;
> + cpufreq_update_util(rq, 0);
>
> - rcu_read_lock_sched_notrace();
> - cpufreq_update_util(cpu_rq(cpu), 0);
> - rcu_read_unlock_sched_notrace();
> + if (!locked_rq)
> + rq_unlock_irqrestore(rq, &rf);
> }
> }
>
Hello,
New build issue found on stable-rc/linux-6.6.y:
---
set_ftrace_ops_ro+0x46: relocation to !ENDBR: .text+0x16c578 in
vmlinux (vmlinux.o) [logspec:kbuild,kbuild.compiler.objtool]
---
- dashboard: https://d.kernelci.org/i/maestro:c49af145451f7a03012be6a37ed4b2bc44aa3470
- giturl: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
- commit HEAD: 615b9e10e3377467ced8f50592a1b5ba8ce053d8
Log excerpt:
=====================================================
vmlinux.o: warning: objtool: set_ftrace_ops_ro+0x46: relocation to
!ENDBR: .text+0x16c578
OBJCOPY modules.builtin.modinfo
GEN modules.builtin
GEN .vmlinux.objs
MODPOST vmlinux.symvers
CC .vmlinux.export.o
UPD include/generated/utsversion.h
CC init/version-timestamp.o
LD .tmp_vmlinux.kallsyms1
ld.lld: error: undefined symbol: its_static_thunk
>>> referenced by usercopy_64.c
>>> vmlinux.o:(emit_indirect_jump)
=====================================================
# Builds where the incident occurred:
## x86_64_defconfig+allmodconfig on (x86_64):
- compiler: clang-17
- dashboard: https://d.kernelci.org/build/maestro:6829871bfef071f536c1102b
#kernelci issue maestro:c49af145451f7a03012be6a37ed4b2bc44aa3470
Reported-by: kernelci.org bot <bot(a)kernelci.org>
--
This is an experimental report format. Please send feedback in!
Talk to us at kernelci(a)lists.linux.dev
Made with love by the KernelCI team - https://kernelci.org
Hi,
I just wanted to check in and see if you had the chance to review my previous email regarding All-Energy Exhibition and Conference 2025.
Looking forward to your reply.
Kind regards,
Jack Reacher
_____________________________________________________________________________________
From: Jack Reacher
Subject: All-Energy Exhibition and Conference 2025
Hi,
As an exhibiting company at All-Energy Exhibition and Conference 2025 we have access to the fully updated attendee list, including last-minute registrants who attended the show.
This exclusive list can help you:
✅ Connect with high-intent leads
✅ Follow up with attendees who visited (or missed) your booth
✅ Maximize your ROI from the event
If you're Interested, I’d love to share more details—and I can also provide pricing information.
Looking forward to your thoughts.
Regards,
Jack Reacher
Sr. Marketing Manager
If you do not wish to receive this newsletter reply as "Not interested"
Hello,
New build issue found on stable-rc/linux-6.6.y:
---
set_ftrace_ops_ro+0x46: relocation to !ENDBR: .text+0x16c578 in
vmlinux (vmlinux.o) [logspec:kbuild,kbuild.compiler.objtool]
---
- dashboard: https://d.kernelci.org/i/maestro:c49af145451f7a03012be6a37ed4b2bc44aa3470
- giturl: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
- commit HEAD: 615b9e10e3377467ced8f50592a1b5ba8ce053d8
Log excerpt:
=====================================================
vmlinux.o: warning: objtool: set_ftrace_ops_ro+0x46: relocation to
!ENDBR: .text+0x16c578
OBJCOPY modules.builtin.modinfo
GEN modules.builtin
GEN .vmlinux.objs
MODPOST vmlinux.symvers
CC .vmlinux.export.o
UPD include/generated/utsversion.h
CC init/version-timestamp.o
LD .tmp_vmlinux.kallsyms1
ld.lld: error: undefined symbol: its_static_thunk
>>> referenced by usercopy_64.c
>>> vmlinux.o:(emit_indirect_jump)
=====================================================
# Builds where the incident occurred:
## x86_64_defconfig+allmodconfig on (x86_64):
- compiler: clang-17
- dashboard: https://d.kernelci.org/build/maestro:6829871bfef071f536c1102b
#kernelci issue maestro:c49af145451f7a03012be6a37ed4b2bc44aa3470
Reported-by: kernelci.org bot <bot(a)kernelci.org>
--
This is an experimental report format. Please send feedback in!
Talk to us at kernelci(a)lists.linux.dev
Made with love by the KernelCI team - https://kernelci.org
Hello,
New build issue found on stable-rc/linux-6.6.y:
---
redefinition of 'its_static_thunk' in arch/x86/kernel/alternative.o
(arch/x86/kernel/alternative.c) [logspec:kbuild,kbuild.compiler.error]
---
- dashboard: https://d.kernelci.org/i/maestro:4e3244fcbf4c807ca7a60afea944a81fb0547730
- giturl: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
- commit HEAD: 615b9e10e3377467ced8f50592a1b5ba8ce053d8
Log excerpt:
=====================================================
arch/x86/kernel/alternative.c:1452:5: error: redefinition of 'its_static_thunk'
1452 | u8 *its_static_thunk(int reg)
| ^
./arch/x86/include/asm/alternative.h:143:19: note: previous definition is here
143 | static inline u8 *its_static_thunk(int reg)
| ^
CC drivers/pinctrl/bcm/pinctrl-bcm6318.o
1 error generated.
=====================================================
# Builds where the incident occurred:
## i386_defconfig+allmodconfig+CONFIG_FRAME_WARN=2048 on (i386):
- compiler: clang-17
- dashboard: https://d.kernelci.org/build/maestro:68298753fef071f536c11059
#kernelci issue maestro:4e3244fcbf4c807ca7a60afea944a81fb0547730
Reported-by: kernelci.org bot <bot(a)kernelci.org>
--
This is an experimental report format. Please send feedback in!
Talk to us at kernelci(a)lists.linux.dev
Made with love by the KernelCI team - https://kernelci.org
The irdma_puda_send() calls the irdma_puda_get_next_send_wqe() to get
entries, but does not clear the entries after the function call. This
could lead to wqe data inconsistency. A proper implementation can be
found in irdma_uk_send().
Add the irdma_clr_wqes() after irdma_puda_get_next_send_wqe(). Add the
headfile of the irdma_clr_wqes().
Fixes: a3a06db504d3 ("RDMA/irdma: Add privileged UDA queue implementation")
Cc: stable(a)vger.kernel.org # v5.14
Signed-off-by: Wentao Liang <vulab(a)iscas.ac.cn>
---
drivers/infiniband/hw/irdma/puda.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/infiniband/hw/irdma/puda.c b/drivers/infiniband/hw/irdma/puda.c
index 7e3f9bca2c23..1d113ad05500 100644
--- a/drivers/infiniband/hw/irdma/puda.c
+++ b/drivers/infiniband/hw/irdma/puda.c
@@ -7,6 +7,7 @@
#include "protos.h"
#include "puda.h"
#include "ws.h"
+#include "user.h"
static void irdma_ieq_receive(struct irdma_sc_vsi *vsi,
struct irdma_puda_buf *buf);
@@ -444,6 +445,8 @@ int irdma_puda_send(struct irdma_sc_qp *qp, struct irdma_puda_send_info *info)
if (!wqe)
return -ENOMEM;
+ irdma_clr_wqes(qp, wqe_idx);
+
qp->qp_uk.sq_wrtrk_array[wqe_idx].wrid = (uintptr_t)info->scratch;
/* Third line of WQE descriptor */
/* maclen is in words */
--
2.42.0.windows.2
The MANA driver's probe registers netdevice via the following call chain:
mana_probe()
register_netdev()
register_netdevice()
register_netdevice() calls notifier callback for netvsc driver,
holding the netdev mutex via netdev_lock_ops().
Further this netvsc notifier callback end up attempting to acquire the
same lock again in dev_xdp_propagate() leading to deadlock.
netvsc_netdev_event()
netvsc_vf_setxdp()
dev_xdp_propagate()
This deadlock was not observed so far because net_shaper_ops was never
set and this lock in noop in this case. Fix this by using
netif_xdp_propagate instead of dev_xdp_propagate to avoid recursive
locking in this path.
This issue has not observed so far because net_shaper_ops was unset,
making the lock path effectively a no-op. To prevent recursive locking
and avoid this deadlock, replace dev_xdp_propagate() with
netif_xdp_propagate(), which does not acquire the lock again.
Also, clean up the unregistration path by removing unnecessary call to
netvsc_vf_setxdp(), since unregister_netdevice_many_notify() already
performs this cleanup via dev_xdp_uninstall.
Fixes: 97246d6d21c2 ("net: hold netdev instance lock during ndo_bpf")
Cc: stable(a)vger.kernel.org
Signed-off-by: Saurabh Sengar <ssengar(a)linux.microsoft.com>
---
drivers/net/hyperv/netvsc_bpf.c | 2 +-
drivers/net/hyperv/netvsc_drv.c | 2 --
net/core/dev.c | 1 +
3 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/net/hyperv/netvsc_bpf.c b/drivers/net/hyperv/netvsc_bpf.c
index e01c5997a551..1dd3755d9e6d 100644
--- a/drivers/net/hyperv/netvsc_bpf.c
+++ b/drivers/net/hyperv/netvsc_bpf.c
@@ -183,7 +183,7 @@ int netvsc_vf_setxdp(struct net_device *vf_netdev, struct bpf_prog *prog)
xdp.command = XDP_SETUP_PROG;
xdp.prog = prog;
- ret = dev_xdp_propagate(vf_netdev, &xdp);
+ ret = netif_xdp_propagate(vf_netdev, &xdp);
if (ret && prog)
bpf_prog_put(prog);
diff --git a/drivers/net/hyperv/netvsc_drv.c b/drivers/net/hyperv/netvsc_drv.c
index d8b169ac0343..ee3aaf9c10e6 100644
--- a/drivers/net/hyperv/netvsc_drv.c
+++ b/drivers/net/hyperv/netvsc_drv.c
@@ -2462,8 +2462,6 @@ static int netvsc_unregister_vf(struct net_device *vf_netdev)
netdev_info(ndev, "VF unregistering: %s\n", vf_netdev->name);
- netvsc_vf_setxdp(vf_netdev, NULL);
-
reinit_completion(&net_device_ctx->vf_add);
netdev_rx_handler_unregister(vf_netdev);
netdev_upper_dev_unlink(vf_netdev, ndev);
diff --git a/net/core/dev.c b/net/core/dev.c
index fccf2167b235..8c6c9d7fba26 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -9953,6 +9953,7 @@ int netif_xdp_propagate(struct net_device *dev, struct netdev_bpf *bpf)
return dev->netdev_ops->ndo_bpf(dev, bpf);
}
+EXPORT_SYMBOL_GPL(netif_xdp_propagate);
u32 dev_xdp_prog_id(struct net_device *dev, enum bpf_xdp_mode mode)
{
--
2.43.0
The quilt patch titled
Subject: XArray: fix kmemleak false positive in xas_shrink()
has been removed from the -mm tree. Its filename was
xarray-fix-kmemleak-false-positive-in-xas_shrink.patch
This patch was dropped because an updated version will be issued
------------------------------------------------------
From: Jared Kangas <jkangas(a)redhat.com>
Subject: XArray: fix kmemleak false positive in xas_shrink()
Date: Mon, 12 May 2025 12:17:07 -0700
Kmemleak periodically produces a false positive report that resembles
the following:
unreferenced object 0xffff0000c105ed08 (size 576):
comm "swapper/0", pid 1, jiffies 4294937478
hex dump (first 32 bytes):
00 00 03 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
d8 e7 0a 8b 00 80 ff ff 20 ed 05 c1 00 00 ff ff ........ .......
backtrace (crc 69e99671):
kmemleak_alloc+0xb4/0xc4
kmem_cache_alloc_lru+0x1f0/0x244
xas_alloc+0x2a0/0x3a0
xas_expand.constprop.0+0x144/0x4dc
xas_create+0x2b0/0x484
xas_store+0x60/0xa00
__xa_alloc+0x194/0x280
__xa_alloc_cyclic+0x104/0x2e0
dev_index_reserve+0xd8/0x18c
register_netdevice+0x5e8/0xf90
register_netdev+0x28/0x50
loopback_net_init+0x68/0x114
ops_init+0x90/0x2c0
register_pernet_operations+0x20c/0x554
register_pernet_device+0x3c/0x8c
net_dev_init+0x5cc/0x7d8
This transient leak can be traced to xas_shrink(): when the xarray's
head is reassigned, kmemleak may have already started scanning the
xarray. When this happens, if kmemleak fails to scan the new xa_head
before it moves, kmemleak will see it as a leak until the xarray is
scanned again.
The report can be reproduced by running the xdp_bonding BPF selftest,
although it doesn't appear consistently due to the bug's transience.
In my testing, the following script has reliably triggered the report in
under an hour on a debug kernel with kmemleak enabled, where KSELFTESTS
is set to the install path for the kernel selftests:
#!/bin/sh
set -eu
echo 1 >/sys/module/kmemleak/parameters/verbose
echo scan=1 >/sys/kernel/debug/kmemleak
while :; do
$KSELFTESTS/bpf/test_progs -t xdp_bonding
done
To prevent this false positive report, mark the new xa_head in
xas_shrink() as a transient leak.
Link: https://lkml.kernel.org/r/20250512191707.245153-1-jkangas@redhat.com
Signed-off-by: Jared Kangas <jkangas(a)redhat.com>
Cc: Catalin Marinas <catalin.marinas(a)arm.com>
Cc: Matthew Wilcox (Oracle) <willy(a)infradead.org>
Cc: Lorenzo Stoakes <lorenzo.stoakes(a)oracle.com>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
lib/xarray.c | 2 ++
1 file changed, 2 insertions(+)
--- a/lib/xarray.c~xarray-fix-kmemleak-false-positive-in-xas_shrink
+++ a/lib/xarray.c
@@ -8,6 +8,7 @@
#include <linux/bitmap.h>
#include <linux/export.h>
+#include <linux/kmemleak.h>
#include <linux/list.h>
#include <linux/slab.h>
#include <linux/xarray.h>
@@ -476,6 +477,7 @@ static void xas_shrink(struct xa_state *
break;
node = xa_to_node(entry);
node->parent = NULL;
+ kmemleak_transient_leak(node);
}
}
_
Patches currently in -mm which might be from jkangas(a)redhat.com are
radix-tree-fix-kmemleak-false-positive-in-radix_tree_shrink.patch
The patch below does not apply to the 6.12-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
To reproduce the conflict and resubmit, you may use the following commands:
git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.12.y
git checkout FETCH_HEAD
git cherry-pick -x f063a28002e3350088b4577c5640882bf4ea17ea
# <resolve conflicts, build, test, etc.>
git commit -s
git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025051215-economist-traffic-fa57@gregkh' --subject-prefix 'PATCH 6.12.y' HEAD^..
Possible dependencies:
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From f063a28002e3350088b4577c5640882bf4ea17ea Mon Sep 17 00:00:00 2001
From: Luca Ceresoli <luca.ceresoli(a)bootlin.com>
Date: Fri, 21 Mar 2025 19:10:00 +0100
Subject: [PATCH] iio: light: opt3001: fix deadlock due to concurrent flag
access
The threaded IRQ function in this driver is reading the flag twice: once to
lock a mutex and once to unlock it. Even though the code setting the flag
is designed to prevent it, there are subtle cases where the flag could be
true at the mutex_lock stage and false at the mutex_unlock stage. This
results in the mutex not being unlocked, resulting in a deadlock.
Fix it by making the opt3001_irq() code generally more robust, reading the
flag into a variable and using the variable value at both stages.
Fixes: 94a9b7b1809f ("iio: light: add support for TI's opt3001 light sensor")
Cc: stable(a)vger.kernel.org
Signed-off-by: Luca Ceresoli <luca.ceresoli(a)bootlin.com>
Link: https://patch.msgid.link/20250321-opt3001-irq-fix-v1-1-6c520d851562@bootlin…
Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com>
diff --git a/drivers/iio/light/opt3001.c b/drivers/iio/light/opt3001.c
index 65b295877b41..393a3d2fbe1d 100644
--- a/drivers/iio/light/opt3001.c
+++ b/drivers/iio/light/opt3001.c
@@ -788,8 +788,9 @@ static irqreturn_t opt3001_irq(int irq, void *_iio)
int ret;
bool wake_result_ready_queue = false;
enum iio_chan_type chan_type = opt->chip_info->chan_type;
+ bool ok_to_ignore_lock = opt->ok_to_ignore_lock;
- if (!opt->ok_to_ignore_lock)
+ if (!ok_to_ignore_lock)
mutex_lock(&opt->lock);
ret = i2c_smbus_read_word_swapped(opt->client, OPT3001_CONFIGURATION);
@@ -826,7 +827,7 @@ static irqreturn_t opt3001_irq(int irq, void *_iio)
}
out:
- if (!opt->ok_to_ignore_lock)
+ if (!ok_to_ignore_lock)
mutex_unlock(&opt->lock);
if (wake_result_ready_queue)
Dear there [Email: linux-stable-mirror(a)lists.linaro.org],
I came across your website and really think it has great potential.
I'd love to share a proposal with you on how we can help improve your
website's visibility on Google — possibly even get it to the first page.
Would it be okay if I send you the proposal and pricing details?
Thanks,
Hi All,
I dropped Harry Yoo's Reviewed-by from this version.
Chages since v8:
- fixed page_owner=on issue preventing bulk allocations on x86
Chages since v7:
- drop "unnecessary free pages" optimization
- fix error path page leak
Chages since v6:
- do not unnecessary free pages across iterations
Chages since v5:
- full error message included into commit description
Chages since v4:
- unused pages leak is avoided
Chages since v3:
- pfn_to_virt() changed to page_to_virt() due to compile error
Chages since v2:
- page allocation moved out of the atomic context
Chages since v1:
- Fixes: and -stable tags added to the patch description
Thanks!
Alexander Gordeev (1):
kasan: Avoid sleepable page allocation from atomic context
mm/kasan/shadow.c | 92 +++++++++++++++++++++++++++++++++++++++--------
1 file changed, 78 insertions(+), 14 deletions(-)
--
2.45.2
Commit 6ccb83d6c497 ("usb: xhci: Implement xhci_handshake_check_state()
helper") introduced an optimization to xhci_reset() during xhci removal,
allowing it to bail out early without waiting for the reset to complete.
This behavior can cause issues on SNPS DWC3 USB controller with dual-role
capability. When the DWC3 controller exits host mode and removes xhci
while a reset is still in progress, and then tries to configure its
hardware for device mode, the ongoing reset leads to register access
issues; specifically, all register reads returns 0. These issues extend
beyond the xhci register space (which is expected during a reset) and
affect the entire DWC3 IP block, causing the DWC3 device mode to
malfunction.
To address this, introduce the `XHCI_FULL_RESET_ON_REMOVE` quirk. When this
quirk is set, xhci_reset() always completes its reset handshake, ensuring
the controller is in a fully reset state before proceeding.
Cc: stable(a)vger.kernel.org
Fixes: 6ccb83d6c497 ("usb: xhci: Implement xhci_handshake_check_state() helper")
Signed-off-by: Roy Luo <royluo(a)google.com>
---
drivers/usb/host/xhci-plat.c | 3 +++
drivers/usb/host/xhci.c | 8 +++++++-
drivers/usb/host/xhci.h | 1 +
3 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index 3155e3a842da..19c5c26a8e63 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -265,6 +265,9 @@ int xhci_plat_probe(struct platform_device *pdev, struct device *sysdev, const s
if (device_property_read_bool(tmpdev, "xhci-skip-phy-init-quirk"))
xhci->quirks |= XHCI_SKIP_PHY_INIT;
+ if (device_property_read_bool(tmpdev, "xhci-full-reset-on-remove-quirk"))
+ xhci->quirks |= XHCI_FULL_RESET_ON_REMOVE;
+
device_property_read_u32(tmpdev, "imod-interval-ns",
&xhci->imod_interval);
}
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 90eb491267b5..4f091d618c01 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -198,6 +198,7 @@ int xhci_reset(struct xhci_hcd *xhci, u64 timeout_us)
u32 command;
u32 state;
int ret;
+ unsigned int exit_state;
state = readl(&xhci->op_regs->status);
@@ -226,8 +227,13 @@ int xhci_reset(struct xhci_hcd *xhci, u64 timeout_us)
if (xhci->quirks & XHCI_INTEL_HOST)
udelay(1000);
+ if (xhci->quirks & XHCI_FULL_RESET_ON_REMOVE)
+ exit_state = 0;
+ else
+ exit_state = XHCI_STATE_REMOVING;
+
ret = xhci_handshake_check_state(xhci, &xhci->op_regs->command,
- CMD_RESET, 0, timeout_us, XHCI_STATE_REMOVING);
+ CMD_RESET, 0, timeout_us, exit_state);
if (ret)
return ret;
diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
index 242ab9fbc8ae..ac65af788298 100644
--- a/drivers/usb/host/xhci.h
+++ b/drivers/usb/host/xhci.h
@@ -1637,6 +1637,7 @@ struct xhci_hcd {
#define XHCI_WRITE_64_HI_LO BIT_ULL(47)
#define XHCI_CDNS_SCTX_QUIRK BIT_ULL(48)
#define XHCI_ETRON_HOST BIT_ULL(49)
+#define XHCI_FULL_RESET_ON_REMOVE BIT_ULL(50)
unsigned int num_active_eps;
unsigned int limit_active_eps;
--
2.49.0.1112.g889b7c5bd8-goog
If s390_wiggle_split_folio() returns 0 because splitting a large folio
succeeded, we will return 0 from make_hva_secure() even though a retry
is required. Return -EAGAIN in that case.
Otherwise, we'll return 0 from gmap_make_secure(), and consequently from
unpack_one(). In kvm_s390_pv_unpack(), we assume that unpacking
succeeded and skip unpacking this page. Later on, we run into issues
and fail booting the VM.
So far, this issue was only observed with follow-up patches where we
split large pagecache XFS folios. Maybe it can also be triggered with
shmem?
We'll cleanup s390_wiggle_split_folio() a bit next, to also return 0
if no split was required.
Fixes: d8dfda5af0be ("KVM: s390: pv: fix race when making a page secure")
Cc: stable(a)vger.kernel.org
Signed-off-by: David Hildenbrand <david(a)redhat.com>
---
arch/s390/kernel/uv.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/arch/s390/kernel/uv.c b/arch/s390/kernel/uv.c
index 9a5d5be8acf41..2cc3b599c7fe3 100644
--- a/arch/s390/kernel/uv.c
+++ b/arch/s390/kernel/uv.c
@@ -393,8 +393,11 @@ int make_hva_secure(struct mm_struct *mm, unsigned long hva, struct uv_cb_header
folio_walk_end(&fw, vma);
mmap_read_unlock(mm);
- if (rc == -E2BIG || rc == -EBUSY)
+ if (rc == -E2BIG || rc == -EBUSY) {
rc = s390_wiggle_split_folio(mm, folio, rc == -E2BIG);
+ if (!rc)
+ rc = -EAGAIN;
+ }
folio_put(folio);
return rc;
--
2.49.0
Generally PASID support requires ACS settings that usually create
single device groups, but there are some niche cases where we can get
multi-device groups and still have working PASID support. The primary
issue is that PCI switches are not required to treat PASID tagged TLPs
specially so appropriate ACS settings are required to route all TLPs to
the host bridge if PASID is going to work properly.
pci_enable_pasid() does check that each device that will use PASID has
the proper ACS settings to achieve this routing.
However, no-PASID devices can be combined with PASID capable devices
within the same topology using non-uniform ACS settings. In this case
the no-PASID devices may not have strict route to host ACS flags and
end up being grouped with the PASID devices.
This configuration fails to allow use of the PASID within the iommu
core code which wrongly checks if the no-PASID device supports PASID.
Fix this by ignoring no-PASID devices during the PASID validation. They
will never issue a PASID TLP anyhow so they can be ignored.
Fixes: c404f55c26fc ("iommu: Validate the PASID in iommu_attach_device_pasid()")
Cc: stable(a)vger.kernel.org
Signed-off-by: Tushar Dave <tdave(a)nvidia.com>
---
changes in v3:
- addressed review comment from Vasant.
drivers/iommu/iommu.c | 27 +++++++++++++++++++--------
1 file changed, 19 insertions(+), 8 deletions(-)
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index 60aed01e54f2..636fc68a8ec0 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -3329,10 +3329,12 @@ static int __iommu_set_group_pasid(struct iommu_domain *domain,
int ret;
for_each_group_device(group, device) {
- ret = domain->ops->set_dev_pasid(domain, device->dev,
- pasid, NULL);
- if (ret)
- goto err_revert;
+ if (device->dev->iommu->max_pasids > 0) {
+ ret = domain->ops->set_dev_pasid(domain, device->dev,
+ pasid, NULL);
+ if (ret)
+ goto err_revert;
+ }
}
return 0;
@@ -3342,7 +3344,8 @@ static int __iommu_set_group_pasid(struct iommu_domain *domain,
for_each_group_device(group, device) {
if (device == last_gdev)
break;
- iommu_remove_dev_pasid(device->dev, pasid, domain);
+ if (device->dev->iommu->max_pasids > 0)
+ iommu_remove_dev_pasid(device->dev, pasid, domain);
}
return ret;
}
@@ -3353,8 +3356,10 @@ static void __iommu_remove_group_pasid(struct iommu_group *group,
{
struct group_device *device;
- for_each_group_device(group, device)
- iommu_remove_dev_pasid(device->dev, pasid, domain);
+ for_each_group_device(group, device) {
+ if (device->dev->iommu->max_pasids > 0)
+ iommu_remove_dev_pasid(device->dev, pasid, domain);
+ }
}
/*
@@ -3391,7 +3396,13 @@ int iommu_attach_device_pasid(struct iommu_domain *domain,
mutex_lock(&group->mutex);
for_each_group_device(group, device) {
- if (pasid >= device->dev->iommu->max_pasids) {
+ /*
+ * Skip PASID validation for devices without PASID support
+ * (max_pasids = 0). These devices cannot issue transactions
+ * with PASID, so they don't affect group's PASID usage.
+ */
+ if ((device->dev->iommu->max_pasids > 0) &&
+ (pasid >= device->dev->iommu->max_pasids)) {
ret = -EINVAL;
goto out_unlock;
}
--
2.34.1