The function compliance_mode_recovery_timer_init() is called from
xhci_init() because the Compliance Mode Recovery Timer (CMRT) must be set
up before xhci_run() when the xhci driver is re-initialized.
To handle this case, the boolean flag 'comp_timer_running' was introduced
to track whether xhci_run() had already been called, ensuring that
xhci_resume() would not invoke compliance_mode_recovery_timer_init()
a second time.
This can be simplified by moving the 'done' label in xhci_resume() to
after the compliance_mode_recovery_timer_init() call. With this change,
the timer initialization runs only when the xhci driver has not been
re-initialized, making the 'comp_timer_running' flag unnecessary and
allowing it to be removed.
Michal Pecio [Thu, 2 Apr 2026 13:13:20 +0000 (16:13 +0300)]
usb: xhci: Fix debugfs bandwidth reporting
Replace kernel USB speed numbers with xHCI protocol IDs expected by HW.
They are numerically equal up to high speed, but instead of SuperSpeed
we were querying SuperSpeed+.
Gen1 hardware rejects such commands with TRB Error, which resulted in
zero available bandwidth being shown.
While at that, report failures properly. No attempt made at "tunneling"
all possible comp codes through errno, debugfs users may inspect the
result through event-ring/trbs.
Michal Pecio [Thu, 2 Apr 2026 13:13:19 +0000 (16:13 +0300)]
usb: xhci: Simplify clearing the Event Interrupt bit
USBSTS is mostly RW1C, so to clear EINT we should write just this
one bit. Remove pointless code which ORs the bit with current value
of the register, even though the bit is already known to be set,
and writes the result back, which clears all active RW1C flags.
We used to inadvertently clear PCD and SRE in this way. PCD isn't
used by the driver and SRE is only used at resume, so clearing them
should make no difference. Don't clear them anymore.
Tested by connecting and mounting a storage device on a few HCs.
Now that all the bits are properly addressed, provide a mechanism
for testing ESA mode guests in nested configurations.
Signed-off-by: Hendrik Brueckner <brueckner@linux.ibm.com>
[farman@us.ibm.com: Updated commit message] Reviewed-by: Janosch Frank <frankja@linux.ibm.com> Signed-off-by: Eric Farman <farman@linux.ibm.com> Signed-off-by: Janosch Frank <frankja@linux.ibm.com>
Eric Farman [Wed, 1 Apr 2026 15:12:20 +0000 (17:12 +0200)]
KVM: s390: vsie: Accommodate ESA prefix pages
The prefix page address occupies a different number
of bits for z/Architecture versus ESA mode. Adjust the
definition to cover both, and permit an ESA mode
address within the nested codepath.
Signed-off-by: Eric Farman <farman@linux.ibm.com> Reviewed-by: Hendrik Brueckner <brueckner@linux.ibm.com> Signed-off-by: Janosch Frank <frankja@linux.ibm.com>
Eric Farman [Wed, 1 Apr 2026 15:12:19 +0000 (17:12 +0200)]
KVM: s390: vsie: Disable some bits when in ESA mode
In the event that a nested guest is put in ESA mode,
ensure that some bits are scrubbed from the shadow SCB.
Reviewed-by: Christian Borntraeger <borntraeger@linux.ibm.com> Signed-off-by: Eric Farman <farman@linux.ibm.com> Reviewed-by: Hendrik Brueckner <brueckner@linux.ibm.com> Signed-off-by: Janosch Frank <frankja@linux.ibm.com>
Eric Farman [Wed, 1 Apr 2026 15:12:18 +0000 (17:12 +0200)]
KVM: s390: vsie: Allow non-zarch guests
Linux/KVM runs in z/Architecture-only mode. Although z/Architecture
is built upon a long history of hardware refinements, any other
CPU mode is not permitted.
Allow a userspace to explicitly enable the use of ESA mode for
nested guests, otherwise usage will be rejected.
Reviewed-by: Janosch Frank <frankja@linux.ibm.com> Signed-off-by: Eric Farman <farman@linux.ibm.com> Reviewed-by: Hendrik Brueckner <brueckner@linux.ibm.com> Reviewed-by: Christian Borntraeger <borntraeger@linux.ibm.com> Signed-off-by: Janosch Frank <frankja@linux.ibm.com>
tracing: Non-consuming read for trace remotes with an offline CPU
When a trace_buffer is created while a CPU is offline, this CPU is
cleared from the trace_buffer CPU mask, preventing the creation of a
non-consuming iterator (ring_buffer_iter). For trace remotes, it means
the iterator fails to be allocated (-ENOMEM) even though there are
available ring buffers in the trace_buffer.
For non-consuming reads of trace remotes, skip missing ring_buffer_iter
to allow reading the available ring buffers.
Lorenzo Bianconi [Tue, 31 Mar 2026 10:33:24 +0000 (12:33 +0200)]
net: airoha: Set REG_RX_CPU_IDX() once in airoha_qdma_fill_rx_queue()
It is not necessary to update REG_RX_CPU_IDX register for each iteration
of the descriptor loop in airoha_qdma_fill_rx_queue routine.
Move REG_RX_CPU_IDX configuration out of the descriptor loop and rely on
the last queue head value updated in the descriptor loop.
Xiang Mei [Tue, 31 Mar 2026 05:02:17 +0000 (22:02 -0700)]
selftests/tc-testing: add tests for cls_fw and cls_flow on shared blocks
Regression tests for the shared-block NULL derefs fixed in the previous
two patches:
- fw: attempt to attach an empty fw filter to a shared block and
verify the configuration is rejected with EINVAL.
- flow: create a flow filter on a shared block without a baseclass
and verify the configuration is rejected with EINVAL.
Signed-off-by: Xiang Mei <xmei5@asu.edu> Acked-by: Jamal Hadi Salim <jhs@mojatatu.com> Reviewed-by: Victor Nogueira <victor@mojatatu.com> Link: https://patch.msgid.link/20260331050217.504278-3-xmei5@asu.edu Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Xiang Mei [Tue, 31 Mar 2026 05:02:16 +0000 (22:02 -0700)]
net/sched: cls_flow: fix NULL pointer dereference on shared blocks
flow_change() calls tcf_block_q() and dereferences q->handle to derive
a default baseclass. Shared blocks leave block->q NULL, causing a NULL
deref when a flow filter without a fully qualified baseclass is created
on a shared block.
Check tcf_block_shared() before accessing block->q and return -EINVAL
for shared blocks. This avoids the null-deref shown below:
=======================================================================
KASAN: null-ptr-deref in range [0x0000000000000038-0x000000000000003f]
RIP: 0010:flow_change (net/sched/cls_flow.c:508)
Call Trace:
tc_new_tfilter (net/sched/cls_api.c:2432)
rtnetlink_rcv_msg (net/core/rtnetlink.c:6980)
[...]
=======================================================================
Fixes: 1abf272022cf ("net: sched: tcindex, fw, flow: use tcf_block_q helper to get struct Qdisc") Reported-by: Weiming Shi <bestswngs@gmail.com> Signed-off-by: Xiang Mei <xmei5@asu.edu> Acked-by: Jamal Hadi Salim <jhs@mojatatu.com> Link: https://patch.msgid.link/20260331050217.504278-2-xmei5@asu.edu Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Xiang Mei [Tue, 31 Mar 2026 05:02:15 +0000 (22:02 -0700)]
net/sched: cls_fw: fix NULL pointer dereference on shared blocks
The old-method path in fw_classify() calls tcf_block_q() and
dereferences q->handle. Shared blocks leave block->q NULL, causing a
NULL deref when an empty cls_fw filter is attached to a shared block
and a packet with a nonzero major skb mark is classified.
Reject the configuration in fw_change() when the old method (no
TCA_OPTIONS) is used on a shared block, since fw_classify()'s
old-method path needs block->q which is NULL for shared blocks.
The fixed null-ptr-deref calling stack:
KASAN: null-ptr-deref in range [0x0000000000000038-0x000000000000003f]
RIP: 0010:fw_classify (net/sched/cls_fw.c:81)
Call Trace:
tcf_classify (./include/net/tc_wrapper.h:197 net/sched/cls_api.c:1764 net/sched/cls_api.c:1860)
tc_run (net/core/dev.c:4401)
__dev_queue_xmit (net/core/dev.c:4535 net/core/dev.c:4790)
Fixes: 1abf272022cf ("net: sched: tcindex, fw, flow: use tcf_block_q helper to get struct Qdisc") Reported-by: Weiming Shi <bestswngs@gmail.com> Signed-off-by: Xiang Mei <xmei5@asu.edu> Acked-by: Jamal Hadi Salim <jhs@mojatatu.com> Link: https://patch.msgid.link/20260331050217.504278-1-xmei5@asu.edu Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Ming Lei [Thu, 26 Mar 2026 14:40:58 +0000 (22:40 +0800)]
bio: fix kmemleak false positives from percpu bio alloc cache
When a bio is allocated from the mempool with REQ_ALLOC_CACHE set and
later completed, bio_put() places it into the per-cpu bio_alloc_cache
via bio_put_percpu_cache() instead of freeing it back to the
mempool/slab. The slab allocation remains tracked by kmemleak, but the
only reference to the bio is through the percpu cache's free_list,
which kmemleak fails to trace through percpu memory. This causes
kmemleak to report the cached bios as unreferenced objects.
Use symmetric kmemleak_free()/kmemleak_alloc() calls to properly track
bios across percpu cache transitions:
- bio_put_percpu_cache: call kmemleak_free() when a bio enters the
cache, unregistering it from kmemleak tracking.
- bio_alloc_percpu_cache: call kmemleak_alloc() when a bio is taken
from the cache for reuse, re-registering it so that genuine leaks
of reused bios remain detectable.
- __bio_alloc_cache_prune: call kmemleak_alloc() before bio_free() so
that kmem_cache_free()'s internal kmemleak_free() has a matching
allocation to pair with.
Jinyu Tang [Fri, 27 Feb 2026 12:10:08 +0000 (20:10 +0800)]
KVM: riscv: Skip CSR restore if VCPU is reloaded on the same core
Currently, kvm_arch_vcpu_load() unconditionally restores guest CSRs,
HGATP, and AIA state. However, when a VCPU is loaded back on the same
physical CPU, and no other KVM VCPU has run on this CPU since it was
last put, the hardware CSRs and AIA registers are still valid.
This patch optimizes the vcpu_load path by skipping the expensive CSR
and AIA writes if all the following conditions are met:
1. It is being reloaded on the same CPU (vcpu->arch.last_exit_cpu == cpu).
2. The CSRs are not dirty (!vcpu->arch.csr_dirty).
3. No other VCPU used this CPU (vcpu == __this_cpu_read(kvm_former_vcpu)).
To ensure this fast-path doesn't break corner cases:
- Live migration and VCPU reset are naturally safe. KVM initializes
last_exit_cpu to -1, which guarantees the fast-path won't trigger.
- The 'csr_dirty' flag tracks runtime userspace interventions. If
userspace modifies guest configurations (e.g., hedeleg via
KVM_SET_GUEST_DEBUG, or CSRs including AIA via KVM_SET_ONE_REG),
the flag is set to skip the fast path.
With the 'csr_dirty' safeguard proven effective, it is safe to
include kvm_riscv_vcpu_aia_load() inside the skip logic now.
Signed-off-by: Jinyu Tang <tjytimi@163.com> Reviewed-by: Nutty Liu <nutty.liu@hotmail.com> Reviewed-by: Andrew Jones <andrew.jones@oss.qualcomm.com> Reviewed-by: Radim Krčmář <radim.krcmar@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260227121008.442241-1-tjytimi@163.com Signed-off-by: Anup Patel <anup@brainfault.org>
io_uring/rw: clean up __io_read() obsolete comment and early returns
After commit a9165b83c193 ("io_uring/rw: always setup io_async_rw for
read/write requests") which moved the iovec allocation into the prep
path and stores it in req->async_data where it now gets freed as part of
the request lifecycle, this comment is now outdated.
Pavel Begunkov [Tue, 31 Mar 2026 21:07:43 +0000 (22:07 +0100)]
io_uring/zcrx: use correct mmap off constants
zcrx was using IORING_OFF_PBUF_SHIFT during first iterations, but there
is now a separate constant it should use. Both are 16 so it doesn't
change anything, but improve it for the future.
Pavel Begunkov [Tue, 31 Mar 2026 21:07:42 +0000 (22:07 +0100)]
io_uring/zcrx: use dma_len for chunk size calculation
Buffers are now dma-mapped earlier and we can sg_dma_len(), otherwise,
since it's walking with for_each_sgtable_dma_sg(), it might wrongfully
reject some configurations. As a bonus, it'd now be able to use larger
chunks if dma addresses are coalesced e.g by iommu.
Pavel Begunkov [Tue, 31 Mar 2026 21:07:41 +0000 (22:07 +0100)]
io_uring/zcrx: don't clear not allocated niovs
Now that area->is_mapped is set earlier before niovs array is allocated,
io_zcrx_free_area -> io_zcrx_unmap_area in an error path can try to
clear dma addresses for unallocated niovs, fix it.
Xingjing Deng [Sat, 31 Jan 2026 06:55:39 +0000 (14:55 +0800)]
misc: fastrpc: check qcom_scm_assign_mem() return in rpmsg_probe
In the SDSP probe path, qcom_scm_assign_mem() is used to assign the
reserved memory to the configured VMIDs, but its return value was not checked.
Fail the probe if the SCM call fails to avoid continuing with an
unexpected/incorrect memory permission configuration.
This issue was found by an in-house analysis workflow that extracts AST-based
information and runs static checks, with LLM assistance for triage, and was
confirmed by manual code review.
No hardware testing was performed.
Fixes: c3c0363bc72d4 ("misc: fastrpc: support complete DMA pool access to the DSP") Cc: stable@vger.kernel.org # 6.11-rc1 Signed-off-by: Xingjing Deng <xjdeng@buaa.edu.cn> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://patch.msgid.link/20260131065539.2124047-1-xjdeng@buaa.edu.cn Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Xingjing Deng [Thu, 29 Jan 2026 23:41:40 +0000 (07:41 +0800)]
misc: fastrpc: possible double-free of cctx->remote_heap
fastrpc_init_create_static_process() may free cctx->remote_heap on the
err_map path but does not clear the pointer. Later, fastrpc_rpmsg_remove()
frees cctx->remote_heap again if it is non-NULL, which can lead to a
double-free if the INIT_CREATE_STATIC ioctl hits the error path and the rpmsg
device is subsequently removed/unbound.
Clear cctx->remote_heap after freeing it in the error path to prevent the
later cleanup from freeing it again.
This issue was found by an in-house analysis workflow that extracts AST-based
information and runs static checks, with LLM assistance for triage, and was
confirmed by manual code review.
No hardware testing was performed.
Fixes: 0871561055e66 ("misc: fastrpc: Add support for audiopd") Cc: stable@vger.kernel.org # 6.2+ Signed-off-by: Xingjing Deng <xjdeng@buaa.edu.cn> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://patch.msgid.link/20260129234140.410983-1-xjdeng@buaa.edu.cn Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
comedi: dt2815: add hardware detection to prevent crash
The dt2815 driver crashes when attached to I/O ports without actual
hardware present. This occurs because syzkaller or users can attach
the driver to arbitrary I/O addresses via COMEDI_DEVCONFIG ioctl.
When no hardware exists at the specified port, inb() operations return
0xff (floating bus), but outb() operations can trigger page faults due
to undefined behavior, especially under race conditions:
BUG: unable to handle page fault for address: 000000007fffff90
#PF: supervisor write access in kernel mode
#PF: error_code(0x0002) - not-present page
RIP: 0010:dt2815_attach+0x6e0/0x1110
Add hardware detection by reading the status register before attempting
any write operations. If the read returns 0xff, assume no hardware is
present and fail the attach with -ENODEV. This prevents crashes from
outb() operations on non-existent hardware.
comedi: runflags cannot determine whether to reclaim chanlist
syzbot reported a memory leak [1], because commit 4e1da516debb ("comedi:
Add reference counting for Comedi command handling") did not consider
the exceptional exit case in do_cmd_ioctl() where runflags is not set.
This caused chanlist not to be properly freed by do_become_nonbusy(),
as it only frees chanlist when runflags is correctly set.
Added a check in do_become_nonbusy() for the case where runflags is not
set, to properly free the chanlist memory.
Ian Abbott [Wed, 25 Feb 2026 13:24:27 +0000 (13:24 +0000)]
comedi: Reinit dev->spinlock between attachments to low-level drivers
`struct comedi_device` is the main controlling structure for a COMEDI
device created by the COMEDI subsystem. It contains a member `spinlock`
containing a spin-lock that is initialized by the COMEDI subsystem, but
is reserved for use by a low-level driver attached to the COMEDI device
(at least since commit 25436dc9d84f ("Staging: comedi: remove RT
code")).
Some COMEDI devices (those created on initialization of the COMEDI
subsystem when the "comedi.comedi_num_legacy_minors" parameter is
non-zero) can be attached to different low-level drivers over their
lifetime using the `COMEDI_DEVCONFIG` ioctl command. This can result in
inconsistent lock states being reported when there is a mismatch in the
spin-lock locking levels used by each low-level driver to which the
COMEDI device has been attached. Fix it by reinitializing
`dev->spinlock` before calling the low-level driver's `attach` function
pointer if `CONFIG_LOCKDEP` is enabled.
Ian Abbott [Thu, 5 Feb 2026 14:01:30 +0000 (14:01 +0000)]
comedi: me_daq: Fix potential overrun of firmware buffer
`me2600_xilinx_download()` loads the firmware that was requested by
`request_firmware()`. It is possible for it to overrun the source
buffer because it blindly trusts the file format. It reads a data
stream length from the first 4 bytes into variable `file_length` and
reads the data stream contents of length `file_length` from offset 16
onwards. Although it checks that the supplied firmware is at least 16
bytes long, it does not check that it is long enough to contain the data
stream.
Add a test to ensure that the supplied firmware is long enough to
contain the header and the data stream. On failure, log an error and
return `-EINVAL`.
Ian Abbott [Thu, 5 Feb 2026 13:39:49 +0000 (13:39 +0000)]
comedi: me4000: Fix potential overrun of firmware buffer
`me4000_xilinx_download()` loads the firmware that was requested by
`request_firmware()`. It is possible for it to overrun the source
buffer because it blindly trusts the file format. It reads a data
stream length from the first 4 bytes into variable `file_length` and
reads the data stream contents of length `file_length` from offset 16
onwards.
Add a test to ensure that the supplied firmware is long enough to
contain the header and the data stream. On failure, log an error and
return `-EINVAL`.
Note: The firmware loading was totally broken before commit ac584af59945
("staging: comedi: me4000: fix firmware downloading"), but that is the
most sensible target for this fix.
Ian Abbott [Wed, 28 Jan 2026 15:00:10 +0000 (15:00 +0000)]
comedi: ni_atmio16d: Fix invalid clean-up after failed attach
If the driver's COMEDI "attach" handler function (`atmio16d_attach()`)
returns an error, the COMEDI core will call the driver's "detach"
handler function (`atmio16d_detach()`) to clean up. This calls
`reset_atmio16d()` unconditionally, but depending on where the error
occurred in the attach handler, the device may not have been
sufficiently initialized to call `reset_atmio16d()`. It uses
`dev->iobase` as the I/O port base address and `dev->private` as the
pointer to the COMEDI device's private data structure. `dev->iobase`
may still be set to its initial value of 0, which would result in
undesired writes to low I/O port addresses. `dev->private` may still be
`NULL`, which would result in null pointer dereferences.
Fix `atmio16d_detach()` by checking that `dev->private` is valid
(non-null) before calling `reset_atmio16d()`. This implies that
`dev->iobase` was set correctly since that is set up before
`dev->private`.
Adam Crosser [Tue, 17 Mar 2026 12:25:28 +0000 (19:25 +0700)]
gpib: fix use-after-free in IO ioctl handlers
The IBRD, IBWRT, IBCMD, and IBWAIT ioctl handlers use a gpib_descriptor
pointer after board->big_gpib_mutex has been released. A concurrent
IBCLOSEDEV ioctl can free the descriptor via close_dev_ioctl() during
this window, causing a use-after-free.
The IO handlers (read_ioctl, write_ioctl, command_ioctl) explicitly
release big_gpib_mutex before calling their handler. wait_ioctl() is
called with big_gpib_mutex held, but ibwait() releases it internally
when wait_mask is non-zero. In all four cases, the descriptor pointer
obtained from handle_to_descriptor() becomes unprotected.
Fix this by introducing a kernel-only descriptor_busy reference count
in struct gpib_descriptor. Each handler atomically increments
descriptor_busy under file_priv->descriptors_mutex before releasing the
lock, and decrements it when done. close_dev_ioctl() checks
descriptor_busy under the same lock and rejects the close with -EBUSY
if the count is non-zero.
A reference count rather than a simple flag is necessary because
multiple handlers can operate on the same descriptor concurrently
(e.g. IBRD and IBWAIT on the same handle from different threads).
A separate counter is needed because io_in_progress can be cleared from
unprivileged userspace via the IBWAIT ioctl (through general_ibstatus()
with set_mask containing CMPL), which would allow an attacker to bypass
a check based solely on io_in_progress. The new descriptor_busy
counter is only modified by the kernel IO paths.
The lock ordering is consistent (big_gpib_mutex -> descriptors_mutex)
and the handlers only hold descriptors_mutex briefly during the lookup,
so there is no deadlock risk and no impact on IO throughput.
Signed-off-by: Adam Crosser <adam.crosser@praetorian.com> Cc: stable <stable@kernel.org> Reviewed-by: Dave Penkler <dpenkler@gmail.com> Tested-by: Dave Penkler <dpenkler@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Johan Hovold [Tue, 10 Mar 2026 10:51:27 +0000 (11:51 +0100)]
gpib: lpvo_usb: fix memory leak on disconnect
The driver iterates over the registered USB interfaces during GPIB
attach and takes a reference to their USB devices until a match is
found. These references are never released which leads to a memory leak
when devices are disconnected.
Fix the leak by dropping the unnecessary references.
Fixes: fce79512a96a ("staging: gpib: Add LPVO DIY USB GPIB driver") Cc: stable <stable@kernel.org> # 6.13 Cc: Dave Penkler <dpenkler@gmail.com> Signed-off-by: Johan Hovold <johan@kernel.org> Link: https://patch.msgid.link/20260310105127.17538-1-johan@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Dave Penkler [Mon, 2 Feb 2026 09:47:55 +0000 (10:47 +0100)]
gpib: Fix fluke driver s390 compile issue
The following errors were reported for a s390 randconfig build
of the fluke gpib driver:
>> drivers/gpib/eastwood/fluke_gpib.c:1002:23: error: call to undeclared function 'ioremap'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
1002 | nec_priv->mmiobase = ioremap(e_priv->gpib_iomem_res->start,
| ^
>> drivers/gpib/eastwood/fluke_gpib.c:1002:21: error: incompatible integer to pointer conversion assigning to 'void *' from 'int' [-Wint-conversion]
1002 | nec_priv->mmiobase = ioremap(e_priv->gpib_iomem_res->start,
| ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1003 | resource_size(e_priv->gpib_iomem_res));
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/gpib/eastwood/fluke_gpib.c:1036:33: error: incompatible integer to pointer conversion assigning to 'void *' from 'int' [-Wint-conversion]
1036 | e_priv->write_transfer_counter = ioremap(e_priv->write_transfer_counter_res->start,
| ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1037 | resource_size(e_priv->write_transfer_counter_res));
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Add HAS_IOMEM dependency to Kconfig for fluke driver option
Ian Rogers [Thu, 12 Mar 2026 19:43:05 +0000 (12:43 -0700)]
perf/x86: Fix potential bad container_of in intel_pmu_hw_config
Auto counter reload may have a group of events with software events
present within it. The software event PMU isn't the x86_hybrid_pmu and
a container_of operation in intel_pmu_set_acr_caused_constr (via the
hybrid helper) could cause out of bound memory reads. Avoid this by
guarding the call to intel_pmu_set_acr_caused_constr with an
is_x86_event check.
Fixes: ec980e4facef ("perf/x86/intel: Support auto counter reload") Signed-off-by: Ian Rogers <irogers@google.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: Thomas Falcon <thomas.falcon@intel.com> Link: https://patch.msgid.link/20260312194305.1834035-1-irogers@google.com
Peter Zijlstra [Wed, 1 Apr 2026 13:20:21 +0000 (15:20 +0200)]
sched/debug: Fix avg_vruntime() usage
John reported that stress-ng-yield could make his machine unhappy and
managed to bisect it to commit b3d99f43c72b ("sched/fair: Fix
zero_vruntime tracking").
The commit in question changes avg_vruntime() from a function that is
a pure reader, to a function that updates variables. This turns an
unlocked sched/debug usage of this function from a minor mistake into
a data corruptor.
Fixes: af4cf40470c2 ("sched/fair: Add cfs_rq::avg_vruntime") Fixes: b3d99f43c72b ("sched/fair: Fix zero_vruntime tracking") Reported-by: John Stultz <jstultz@google.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: Vincent Guittot <vincent.guittot@linaro.org> Tested-by: K Prateek Nayak <kprateek.nayak@amd.com> Tested-by: John Stultz <jstultz@google.com> Link: https://patch.msgid.link/20260401132355.196370805@infradead.org
Peter Zijlstra [Wed, 1 Apr 2026 13:20:20 +0000 (15:20 +0200)]
sched/fair: Fix zero_vruntime tracking fix
John reported that stress-ng-yield could make his machine unhappy and
managed to bisect it to commit b3d99f43c72b ("sched/fair: Fix
zero_vruntime tracking").
The combination of yield and that commit was specific enough to
hypothesize the following scenario:
Suppose we have 2 runnable tasks, both doing yield. Then one will be
eligible and one will not be, because the average position must be in
between these two entities.
Therefore, the runnable task will be eligible, and be promoted a full
slice (all the tasks do is yield after all). This causes it to jump over
the other task and now the other task is eligible and current is no
longer. So we schedule.
Since we are runnable, there is no {de,en}queue. All we have is the
__{en,de}queue_entity() from {put_prev,set_next}_task(). But per the
fingered commit, those two no longer move zero_vruntime.
All that moves zero_vruntime are tick and full {de,en}queue.
This means, that if the two tasks playing leapfrog can reach the
critical speed to reach the overflow point inside one tick's worth of
time, we're up a creek.
Additionally, when multiple cgroups are involved, there is no guarantee
the tick will in fact hit every cgroup in a timely manner. Statistically
speaking it will, but that same statistics does not rule out the
possibility of one cgroup not getting a tick for a significant amount of
time -- however unlikely.
Therefore, just like with the yield() case, force an update at the end
of every slice. This ensures the update is never more than a single
slice behind and the whole thing is within 2 lag bounds as per the
comment on entity_key().
Fixes: b3d99f43c72b ("sched/fair: Fix zero_vruntime tracking") Reported-by: John Stultz <jstultz@google.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: Vincent Guittot <vincent.guittot@linaro.org> Tested-by: K Prateek Nayak <kprateek.nayak@amd.com> Tested-by: John Stultz <jstultz@google.com> Link: https://patch.msgid.link/20260401132355.081530332@infradead.org
Martin Schiller [Tue, 31 Mar 2026 07:43:17 +0000 (09:43 +0200)]
net/x25: Fix potential double free of skb
When alloc_skb fails in x25_queue_rx_frame it calls kfree_skb(skb) at
line 48 and returns 1 (error).
This error propagates back through the call chain:
x25_queue_rx_frame returns 1
|
v
x25_state3_machine receives the return value 1 and takes the else
branch at line 278, setting queued=0 and returning 0
|
v
x25_process_rx_frame returns queued=0
|
v
x25_backlog_rcv at line 452 sees queued=0 and calls kfree_skb(skb)
again
This would free the same skb twice. Looking at x25_backlog_rcv:
====================
net: mctp: improvements for NULL-EID addressing
Currently, our focus for the MCTP routing implementation has been for
MCTP bus-owner devices. In this case, we will generally have an EID
assigned during local transmit, and have routes established before
expecting to receive.
We also want to handle non-bus-owner cases, where:
- we may need to send control protocol messages (like Discovery Notify)
before any local addresses have been assigned, particularly as part
of acquiring a local address assignment; and
- we will likely want to receive incoming messages before we have
routing established.
This series improves handling for these cases, by handling NULL EIDs
as source / destination addresses where possible.
Signed-off-by: Jeremy Kerr <jk@codeconstruct.com.au>
====================
Jeremy Kerr [Tue, 31 Mar 2026 07:41:08 +0000 (15:41 +0800)]
net: mctp: don't require a route for null-EID ingress
Currently, if we receive a physically-addressed packet for the local
stack, we perform a route_lookup_null to find a matching device-based
route. If a route is present, it will always have the ->output fn set to
mctp_dst_input, which provides our delivery mechanism.
However, if we don't yet have any local addresses assigned, we won't
have any local routes to lookup, so this will fail. One of the use-cases
for physical addressing is initial address assignment on endpoint nodes,
where we would have no addresses, and therefore no local routes.
Instead of iterating routes (looking for one matching the dev), just
create a suitable mctp_dst for the device directly.
Jeremy Kerr [Tue, 31 Mar 2026 07:41:07 +0000 (15:41 +0800)]
net: mctp: allow local TX with no address assigned
If we're operating as a non-bus-owner endpoint, we may want to perform
MCTP communication to get an address assigned. In this case, we'll have
no local addresses, but can TX just fine either with extended routing,
or where a direct route exists.
Jeremy Kerr [Tue, 31 Mar 2026 07:41:06 +0000 (15:41 +0800)]
net: mctp: perform source address lookups when we populate our dst
Rather than querying the output device for its address in
mctp_local_output, set up the source address when we're populating the
dst structure. If no address is assigned, use MCTP_ADDR_NULL.
This will allow us more flexibility when routing for NULL-source-eid
cases. For now though, we still reject a NULL source address in the
output path.
We need to update the tests a little, so that addresses are assigned
before we do the dst lookups.
Merge tag 'usb-serial-7.0-rc7' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial into usb-linus
Johan writes:
USB serial device ids for 7.0-rc7
Here are some new modem and io_edgeport device ids.
All have been in linux-next with no reported issues.
* tag 'usb-serial-7.0-rc7' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial:
USB: serial: option: add MeiG Smart SRM825WN
USB: serial: io_edgeport: add support for Blackbox IC135A
USB: serial: option: add support for Rolling Wireless RW135R-GL
Maíra Canal [Mon, 30 Mar 2026 17:51:46 +0000 (14:51 -0300)]
drm/vc4: Protect madv read in vc4_gem_object_mmap() with madv_lock
The mmap callback reads bo->madv without holding madv_lock, racing with
concurrent DRM_IOCTL_VC4_GEM_MADVISE calls that modify the field under
the same lock. Add the missing locking to prevent the data race.
Maíra Canal [Mon, 30 Mar 2026 17:51:44 +0000 (14:51 -0300)]
drm/vc4: Fix memory leak of BO array in hang state
The hang state's BO array is allocated separately with kzalloc() in
vc4_save_hang_state() but never freed in vc4_free_hang_state(). Add the
missing kfree() for the BO array before freeing the hang state struct.
Maíra Canal [Mon, 30 Mar 2026 17:51:43 +0000 (14:51 -0300)]
drm/vc4: Release runtime PM reference after binding V3D
The vc4_v3d_bind() function acquires a runtime PM reference via
pm_runtime_resume_and_get() to access V3D registers during setup.
However, this reference is never released after a successful bind.
This prevents the device from ever runtime suspending, since the
reference count never reaches zero.
Release the runtime PM reference by adding pm_runtime_put_autosuspend()
after autosuspend is configured, allowing the device to runtime suspend
after the delay.
====================
selftests: drivers: bash support for remote traffic generators
This patch set aims to add the necessary support so that bash written
selftests are also able to easily run with a remote traffic generator
system, either be it in another netns or one accessible through ssh.
This patch set is a result of the discussion from v1:
https://lore.kernel.org/all/20260303084330.340b6459@kernel.org/
Even though the python infrastructure is already established, some
things are easier in bash and it would be a shame to leave behind the
bash tests that we already have.
This support is based on the requirements described in the
tools/testing/selftests/drivers/net/README.rst file.
Mainly, the drivers/net selftests should be able to run on a interface
specified through the NETIF env variable. On top of that, variables such
as REMOTE_TYPE and REMOTE_ARGS define how the remote traffic generator
can be accessed. Patch 3/10 parses these env variables and constructs the
NETIFS array that bash tests are accustomed to. This is with the
intention of enabling already written tests to incur minimal changes.
The second patch also defines the TARGETS array which will hold the
necessary information about the target on which a specific interface
is located.
For example, a net.config which looks like below:
NETIF=eth0
LOCAL_V4=192.168.1.1
REMOTE_V4=192.168.1.2
REMOTE_TYPE=ssh
REMOTE_ARGS=root@192.168.1.2
will generate the NETIFS and TARGETS arrays with the following data.
The above will be true if on the remote target, the interface which has
the 192.168.1.2 address is named eth2.
The values held in the TARGETS array will be used by the new 'run_on'
helper added in patch 2/10 to know how to run a specific command, on the
local system, on another netns or by using ssh. Patch 4/10 updates some
helpers to use run_on so that, for example, lib.sh is able to ensure
stable MAC addresses even with the remote interface located in another
netns.
The next 5 patches, 5/10-9/10 update the ethtool_rmon.sh script so that it
can work with the kselftest infrastructure and the new
NETIF/REMOTE_TYPE etc way of working. Beside updating each ip link or
ethtool command to use the run_on helper, the patches also remove any
testing done on the remote interface.
The last patch adds a new test which checks the standard counters -
eth-ctrl, eth-mac and pause - and uses the new infrastructure put in
place by the first patches.
With this patch set, both tests can be run using a net.config file and
run_kselftest.sh as shown below.
$ ./run_kselftest.sh -t drivers/net/hw:ethtool_rmon.sh
TAP version 13
1..1
# timeout set to 0
# selftests: drivers/net/hw: ethtool_rmon.sh
# TAP version 13
# 1..14
# ok 1 ethtool_rmon.rx-pkts64to64
# ok 2 ethtool_rmon.rx-pkts65to127
# ok 3 ethtool_rmon.rx-pkts128to255
# ok 4 ethtool_rmon.rx-pkts256to511
# ok 5 ethtool_rmon.rx-pkts512to1023
# ok 6 ethtool_rmon.rx-pkts1024to1518
# ok 7 ethtool_rmon.rx-pkts1519to10240
# ok 8 ethtool_rmon.tx-pkts64to64
# ok 9 ethtool_rmon.tx-pkts65to127
# ok 10 ethtool_rmon.tx-pkts128to255
# ok 11 ethtool_rmon.tx-pkts256to511
# ok 12 ethtool_rmon.tx-pkts512to1023
# ok 13 ethtool_rmon.tx-pkts1024to1518
# ok 14 ethtool_rmon.tx-pkts1519to10240
# # Totals: pass:14 fail:0 xfail:0 xpass:0 skip:0 error:0
ok 1 selftests: drivers/net/hw: ethtool_rmon.sh
$ ./run_kselftest.sh -t drivers/net/hw:ethtool_std_stats.sh
TAP version 13
1..1
# timeout set to 0
# selftests: drivers/net/hw: ethtool_std_stats.sh
# TAP version 13
# 1..26
# ok 1 ethtool_std_stats.eth-ctrl-MACControlFramesTransmitted
# ok 2 ethtool_std_stats.eth-ctrl-MACControlFramesReceived
# ok 3 ethtool_std_stats.eth-mac-FrameCheckSequenceErrors
# ok 4 ethtool_std_stats.eth-mac-AlignmentErrors
# ok 5 ethtool_std_stats.eth-mac-FramesLostDueToIntMACXmitError
# ok 6 ethtool_std_stats.eth-mac-CarrierSenseErrors # SKIP
# ok 7 ethtool_std_stats.eth-mac-FramesLostDueToIntMACRcvError
# ok 8 ethtool_std_stats.eth-mac-InRangeLengthErrors # SKIP
# ok 9 ethtool_std_stats.eth-mac-OutOfRangeLengthField # SKIP
# ok 10 ethtool_std_stats.eth-mac-FrameTooLongErrors # SKIP
# ok 11 ethtool_std_stats.eth-mac-FramesAbortedDueToXSColls # SKIP
# ok 12 ethtool_std_stats.eth-mac-SingleCollisionFrames # SKIP
# ok 13 ethtool_std_stats.eth-mac-MultipleCollisionFrames # SKIP
# ok 14 ethtool_std_stats.eth-mac-FramesWithDeferredXmissions # SKIP
# ok 15 ethtool_std_stats.eth-mac-LateCollisions # SKIP
# ok 16 ethtool_std_stats.eth-mac-FramesWithExcessiveDeferral # SKIP
# ok 17 ethtool_std_stats.eth-mac-BroadcastFramesXmittedOK
# ok 18 ethtool_std_stats.eth-mac-OctetsTransmittedOK
# ok 19 ethtool_std_stats.eth-mac-BroadcastFramesReceivedOK
# ok 20 ethtool_std_stats.eth-mac-OctetsReceivedOK
# ok 21 ethtool_std_stats.eth-mac-FramesTransmittedOK
# ok 22 ethtool_std_stats.eth-mac-MulticastFramesXmittedOK
# ok 23 ethtool_std_stats.eth-mac-FramesReceivedOK
# ok 24 ethtool_std_stats.eth-mac-MulticastFramesReceivedOK
# ok 25 ethtool_std_stats.pause-tx_pause_frames
# ok 26 ethtool_std_stats.pause-rx_pause_frames
# # 10 skipped test(s) detected. Consider enabling relevant config options to improve coverage.
# # Totals: pass:16 fail:0 xfail:0 xpass:0 skip:10 error:0
ok 1 selftests: drivers/net/hw: ethtool_std_stats.sh
====================
Ioana Ciornei [Mon, 30 Mar 2026 15:29:33 +0000 (18:29 +0300)]
selftests: drivers: hw: add test for the ethtool standard counters
Add a new selftest - ethtool_std_stats.sh - which validates the
eth-ctrl, eth-mac and pause standard statistics exported by an
interface. Collision related eth-mac counters as well as the error ones
will be checked against zero since that is the most likely correct
scenario.
The central part of this patch is the traffic_test() function which
gathers the 'before' counter values, sends a batch of traffic and then
interrogates again the same counters in order to determine if the delta
is on target. The function receives an array through which the caller
can request what counters to be interrogated and, for each of them, what
is their target delta value.
The output from this selftest looks as follows on a LX2160ARDB board:
$ ./run_kselftest.sh -t drivers/net/hw:ethtool_std_stats.sh
TAP version 13
1..1
# timeout set to 0
# selftests: drivers/net/hw: ethtool_std_stats.sh
# TAP version 13
# 1..26
# ok 1 ethtool_std_stats.eth-ctrl-MACControlFramesTransmitted
# ok 2 ethtool_std_stats.eth-ctrl-MACControlFramesReceived
# ok 3 ethtool_std_stats.eth-mac-FrameCheckSequenceErrors
# ok 4 ethtool_std_stats.eth-mac-AlignmentErrors
# ok 5 ethtool_std_stats.eth-mac-FramesLostDueToIntMACXmitError
# ok 6 ethtool_std_stats.eth-mac-CarrierSenseErrors # SKIP
# ok 7 ethtool_std_stats.eth-mac-FramesLostDueToIntMACRcvError
# ok 8 ethtool_std_stats.eth-mac-InRangeLengthErrors # SKIP
# ok 9 ethtool_std_stats.eth-mac-OutOfRangeLengthField # SKIP
# ok 10 ethtool_std_stats.eth-mac-FrameTooLongErrors # SKIP
# ok 11 ethtool_std_stats.eth-mac-FramesAbortedDueToXSColls # SKIP
# ok 12 ethtool_std_stats.eth-mac-SingleCollisionFrames # SKIP
# ok 13 ethtool_std_stats.eth-mac-MultipleCollisionFrames # SKIP
# ok 14 ethtool_std_stats.eth-mac-FramesWithDeferredXmissions # SKIP
# ok 15 ethtool_std_stats.eth-mac-LateCollisions # SKIP
# ok 16 ethtool_std_stats.eth-mac-FramesWithExcessiveDeferral # SKIP
# ok 17 ethtool_std_stats.eth-mac-BroadcastFramesXmittedOK
# ok 18 ethtool_std_stats.eth-mac-OctetsTransmittedOK
# ok 19 ethtool_std_stats.eth-mac-BroadcastFramesReceivedOK
# ok 20 ethtool_std_stats.eth-mac-OctetsReceivedOK
# ok 21 ethtool_std_stats.eth-mac-FramesTransmittedOK
# ok 22 ethtool_std_stats.eth-mac-MulticastFramesXmittedOK
# ok 23 ethtool_std_stats.eth-mac-FramesReceivedOK
# ok 24 ethtool_std_stats.eth-mac-MulticastFramesReceivedOK
# ok 25 ethtool_std_stats.pause-tx_pause_frames
# ok 26 ethtool_std_stats.pause-rx_pause_frames
# # 10 skipped test(s) detected. Consider enabling relevant config options to improve coverage.
# # Totals: pass:16 fail:0 xfail:0 xpass:0 skip:10 error:0
ok 1 selftests: drivers/net/hw: ethtool_std_stats.sh
Please note that not all MACs are counting the software injected pause
frames as real Tx pause. For example, on a LS1028ARDB the selftest
output will reflect the fact that neither the ENETC MAC, nor the Felix
switch MAC are able to detect Tx pause frames injected by software.
$ ./run_kselftest.sh -t drivers/net/hw:ethtool_std_stats.sh
(...)
# # software sent pause frames not detected
# ok 25 ethtool_std_stats.pause-tx_pause_frames # XFAIL
# ok 26 ethtool_std_stats.pause-rx_pause_frames
Ioana Ciornei [Mon, 30 Mar 2026 15:29:32 +0000 (18:29 +0300)]
selftests: drivers: hw: update ethtool_rmon to work with a single local interface
This patch finalizes the transition to work with a single local
interface for the ethtool_rmon.sh test. Each 'ip link' and 'ethtool'
command used by the test is annotated with the necessary run_on in
order to be executed on the necessary target system, be it local, in
another network namespace or through ssh.
Since we need NETIF up and running also for control traffic, we now
expect that the interfaces are up and running and do not touch bring
them up or down at the end of the test. This is also documented in the
drivers/net/README.rst.
The ethtool_rmon.sh script can still be used in the older fashion by
passing two interfaces as command line arguments, the only restriction
is that those interfaces need to be already up.
$ ./run_kselftest.sh -t drivers/net/hw:ethtool_rmon.sh
TAP version 13
1..1
# timeout set to 0
# selftests: drivers/net/hw: ethtool_rmon.sh
# TAP version 13
# 1..14
# ok 1 ethtool_rmon.rx-pkts64to64
# ok 2 ethtool_rmon.rx-pkts65to127
# ok 3 ethtool_rmon.rx-pkts128to255
# ok 4 ethtool_rmon.rx-pkts256to511
# ok 5 ethtool_rmon.rx-pkts512to1023
# ok 6 ethtool_rmon.rx-pkts1024to1518
# ok 7 ethtool_rmon.rx-pkts1519to10240
# ok 8 ethtool_rmon.tx-pkts64to64
# ok 9 ethtool_rmon.tx-pkts65to127
# ok 10 ethtool_rmon.tx-pkts128to255
# ok 11 ethtool_rmon.tx-pkts256to511
# ok 12 ethtool_rmon.tx-pkts512to1023
# ok 13 ethtool_rmon.tx-pkts1024to1518
# ok 14 ethtool_rmon.tx-pkts1519to10240
# # Totals: pass:14 fail:0 xfail:0 xpass:0 skip:0 error:0
ok 1 selftests: drivers/net/hw: ethtool_rmon.sh
Ioana Ciornei [Mon, 30 Mar 2026 15:29:31 +0000 (18:29 +0300)]
selftests: drivers: hw: move to KTAP output
Update the ethtool_rmon.sh test so that it uses the KTAP format for its
output. This is achieved by using the helpers found in ktap_helpers.sh.
An example output can be found below.
$ ./ethtool_rmon.sh endpmac3 endpmac4
TAP version 13
1..14
ok 1 ethtool_rmon.rx-pkts64to64
ok 2 ethtool_rmon.rx-pkts65to127
ok 3 ethtool_rmon.rx-pkts128to255
ok 4 ethtool_rmon.rx-pkts256to511
ok 5 ethtool_rmon.rx-pkts512to1023
ok 6 ethtool_rmon.rx-pkts1024to1518
ok 7 ethtool_rmon.rx-pkts1519to10240
ok 8 ethtool_rmon.tx-pkts64to64
ok 9 ethtool_rmon.tx-pkts65to127
ok 10 ethtool_rmon.tx-pkts128to255
ok 11 ethtool_rmon.tx-pkts256to511
ok 12 ethtool_rmon.tx-pkts512to1023
ok 13 ethtool_rmon.tx-pkts1024to1518
ok 14 ethtool_rmon.tx-pkts1519to10240
# Totals: pass:14 fail:0 xfail:0 xpass:0 skip:0 error:0
Ioana Ciornei [Mon, 30 Mar 2026 15:29:30 +0000 (18:29 +0300)]
selftests: drivers: hw: replace counter upper limit with UINT32_MAX in rmon test
The ethtool_rmon.sh script checks that the number of packets sent /
received during a test matches the expected value with a 1% tolerance.
Since in the next patches this test will gain the capability to also be
run on systems with a single interface where the traffic generator is
accesible through ssh, use the UINT32_MAX as the upper limit. This is
necessary since the same interface will be used also for control traffic
(the ssh commands) as well as the mausezahn generated one.
Ioana Ciornei [Mon, 30 Mar 2026 15:29:29 +0000 (18:29 +0300)]
selftests: drivers: hw: test rmon counters only on first interface
The selftests in drivers/net are slowly transitioning to being able to
be used on systems with a single network interface. The first step for the
ethtool_rmon.sh test is to only validate that the rmon counters are
properly exported on the first interface supplied as an argument.
Remove the rmon_histogram calls which intend to test also the rmon
counters on the 2nd interface. This also removes the need for the remote
system, which should be used only to inject traffic, to also support
rmon counters.
Ioana Ciornei [Mon, 30 Mar 2026 15:29:27 +0000 (18:29 +0300)]
selftests: net: update some helpers to use run_on
Update some helpers so that they are capable to run commands on
different targets than the local one. This patch makes the necesasy
modification for those helpers / sections of code which are needed for
the ethtool_rmon.sh test that will be converted in the next patches.
For example, mac_addr_prepare() and mac_addr_restore() used when
STABLE_MAC_ADDRS=yes need to ensure stable MAC addresses on interfaces
located even in other namespaces. In order to do that, append the 'ip
link' commands with a 'run_on $dev' tag.
The same run_on is necessary also when verifying if all the interfaces
listed in NETIFS are indeed available.
Ioana Ciornei [Mon, 30 Mar 2026 15:29:26 +0000 (18:29 +0300)]
selftests: net: extend lib.sh to parse drivers/net/net.config
Extend lib.sh so that it's able to parse driver/net/net.config and
environment variables such as NETIF, REMOTE_TYPE, LOCAL_V4 etc described
in drivers/net/README.rst.
In order to make the transition towards running with a single local
interface smoother for the bash networking driver tests, beside sourcing
the net.config file also translate the new env variables into the old
style based on the NETIFS array. Since the NETIFS array only holds the
network interface names, also add a new array - TARGETS - which keeps
track of the target on which a specific interfaces resides - local,
netns or accesible through an ssh command.
The above will be true if on the remote target, the interface which has
the 192.168.1.2 address is named eth2.
Since the TARGETS array is indexed by the network interface name,
document a new restriction README.rst which states that the remote
interface cannot have the same name as the local one. Keep the old way
of populating the NETIFS variable based on the command line arguments.
This will be invoked in case DRIVER_TEST_CONFORMANT = "no".
Also add a couple of helpers which can be used by tests which need to
run a specific bash command on a different target than the local system,
be it either another netns or a remote system accessible through ssh.
The __run_on() function is passed through $1 the target on which the
command should be executed while run_on() is passed the name of the
interface that is then used to retrieve the target from the TARGETS
array.
Also add a stub run_on() function in net/lib.sh so that users of the
net/lib.sh are going through the stub only since neither NETIFS nor
TARGETS are valid in that circumstance.
Ioana Ciornei [Mon, 30 Mar 2026 15:29:25 +0000 (18:29 +0300)]
selftests: forwarding: extend ethtool_std_stats_get with pause statistics
Even though pause frame statistics are not exported through the same
ethtool command, there is no point in adding another helper just for
them. Extent the ethtool_std_stats_get() function so that we are able to
interrogate using the same helper all the standard statistics.
And since we are touching the function, convert the initial ethtool call
as well to the jq --arg form in order to be easier to read.
Magnus Kalland [Thu, 2 Apr 2026 07:42:50 +0000 (09:42 +0200)]
iommu/amd: Invalidate IRT cache for DMA aliases
DMA aliasing causes interrupt remapping table entries (IRTEs) to be shared
between multiple device IDs. See commit 3c124435e8dd
("iommu/amd: Support multiple PCI DMA aliases in IRQ Remapping") for more
information on this. However, the AMD IOMMU driver currently invalidates
IRTE cache entries on a per-device basis whenever an IRTE is updated, not
for each alias.
This approach leaves stale IRTE cache entries when an IRTE is cached under
one DMA alias but later updated and invalidated through a different alias.
In such cases, the original device ID is never invalidated, since it is
programmed via aliasing.
This incoherency bug has been observed when IRTEs are cached for one
Non-Transparent Bridge (NTB) DMA alias, later updated via another.
Fix this by invalidating the interrupt remapping table cache for all DMA
aliases when updating an IRTE.
Co-developed-by: Lars B. Kristiansen <larsk@dolphinics.com> Signed-off-by: Lars B. Kristiansen <larsk@dolphinics.com> Co-developed-by: Jonas Markussen <jonas@dolphinics.com> Signed-off-by: Jonas Markussen <jonas@dolphinics.com> Co-developed-by: Tore H. Larsen <torel@simula.no> Signed-off-by: Tore H. Larsen <torel@simula.no> Signed-off-by: Magnus Kalland <magnus@dolphinics.com> Link: https://lore.kernel.org/linux-iommu/9204da81-f821-4034-b8ad-501e43383b56@amd.com/ Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
thermal: core: Fix thermal zone device registration error path
If thermal_zone_device_register_with_trips() fails after registering
a thermal zone device, it needs to wait for the tz->removal completion
like thermal_zone_device_unregister(), in case user space has managed
to take a reference to the thermal zone device's kobject, in which case
thermal_release() may not be called by the error path itself and tz may
be freed prematurely.
Add the missing wait_for_completion() call to the thermal zone device
registration error path.
Fixes: 04e6ccfc93c5 ("thermal: core: Fix NULL pointer dereference in zone registration error path") Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Cc: All applicable <stable@vger.kernel.org> Reviewed-by: Lukasz Luba <lukasz.luba@arm.com> Tested-by: Lukasz Luba <lukasz.luba@arm.com> Link: https://patch.msgid.link/2849815.mvXUDI8C0e@rafael.j.wysocki
Mark Brown [Wed, 1 Apr 2026 16:57:34 +0000 (17:57 +0100)]
ALSA: compress: Refuse to update timestamps for unconfigured streams
There are a number of mechanisms, including the userspace accessible
timestamp and buffer availability ioctl()s, which allow us to trigger
a timestamp update on a stream before it has been configured. Since
drivers might rely on stream configuration for reporting of pcm_io_frames,
including potentially doing a division by the number of channels, and
these operations are not meaningful for an unconfigured stream reject
attempts to read timestamps before any configuration is done.
erofs: include the trailing NUL in FS_IOC_GETFSLABEL
erofs_ioctl_get_volume_label() passes strlen(sbi->volume_name) as
the length to copy_to_user(), which copies the label string without
the trailing NUL byte. Since FS_IOC_GETFSLABEL callers expect a
NUL-terminated string in the FSLABEL_MAX-sized buffer and may not
pre-zero the buffer, this can cause userspace to read past the label
into uninitialised stack memory.
Fix this by using strlen() + 1 to include the NUL terminator,
consistent with how ext4 and xfs implement FS_IOC_GETFSLABEL.
Zhan Xusheng [Tue, 31 Mar 2026 05:02:49 +0000 (13:02 +0800)]
erofs: ensure all folios are managed in erofs_try_to_free_all_cached_folios()
folio_trylock() in erofs_try_to_free_all_cached_folios() may
successfully acquire the folio lock, but the subsequent check
for erofs_folio_is_managed() can skip unlocking when the folio
is not managed by EROFS.
As Gao Xiang pointed out, this condition should not happen in
practice because compressed_bvecs[] only holds valid cached folios
at this point — any non-managed folio would have already been
detached by z_erofs_cache_release_folio() under folio lock.
Fix this by adding DBG_BUGON() to catch unexpected folios
and ensure folio_unlock() is always called.
Gao Xiang [Mon, 30 Mar 2026 02:29:29 +0000 (10:29 +0800)]
erofs: verify metadata accesses for file-backed mounts
For file-backed mounts, metadata is fetched via the page cache of
backing inodes to avoid double caching and redundant copy ops out
of RO uptodate folios, which is used by Android APEXes, ComposeFS,
containerd. However, rw_verify_area() was missing prior to
metadata accesses.
Similar to vfs_iocb_iter_read(), fix this by:
- Enabling fanotify pre-content hooks on metadata accesses;
- security_file_permission() for security modules.
Verified that fanotify pre-content hooks now works correctly.
Fixes: fb176750266a ("erofs: add file-backed mount support") Acked-by: Amir Goldstein <amir73il@gmail.com> Reviewed-by: Chunhai Guo <guochunhai@vivo.com> Signed-off-by: Gao Xiang <hsiangkao@linux.alibaba.com>
usb: gadget: f_hid: move list and spinlock inits from bind to alloc
There was an issue when you did the following:
- setup and bind an hid gadget
- open /dev/hidg0
- use the resulting fd in EPOLL_CTL_ADD
- unbind the UDC
- bind the UDC
- use the fd in EPOLL_CTL_DEL
When CONFIG_DEBUG_LIST was enabled, a list_del corruption was reported
within remove_wait_queue (via ep_remove_wait_queue). After some
debugging I found out that the queues, which f_hid registers via
poll_wait were the problem. These were initialized using
init_waitqueue_head inside hidg_bind. So effectively, the bind function
re-initialized the queues while there were still items in them.
The solution is to move the initialization from hidg_bind to hidg_alloc
to extend their lifetimes to the lifetime of the function instance.
Additionally, I found many other possibly problematic init calls in the
bind function, which I moved as well.
Kelvin Mbogo [Wed, 25 Mar 2026 10:36:40 +0000 (13:36 +0300)]
usb: usbip: fix OOB read/write in usbip_pad_iso()
usbip_pad_iso() repositions ISO frame data within the transfer buffer
via memmove(). Neither the source offset (actualoffset, derived by
subtracting wire-supplied actual_length values) nor the destination
offset (iso_frame_desc[i].offset, taken directly from the wire) is
bounds-checked.
If a crafted actual_length wraps actualoffset negative through the
subtraction (see patch 2/3 for the root cause), the memmove source
points before the allocation - slab OOB read, data returned to
userspace.
Independently, iso_frame_desc[i].offset is never validated against
transfer_buffer_length. Setting offset past the end of the buffer
gives a fully controlled OOB write into whatever sits next in the
slab - confirmed with offset=400 on a 392-byte buffer, 64-byte write.
Add bounds checks for both the source and destination ranges before
each memmove call. Use unsigned comparisons after the sign check on
actualoffset to avoid signed/unsigned conversion surprises.
A malicious server can send actual_length = 0xFFFFFFFC for one frame
and a small value for the other, making the signed sum wrap around to
match urb->actual_length. The sanity check passes, and usbip_pad_iso()
later computes a negative actualoffset, feeding it to memmove() as a
source pointer - reads before the allocation, leaked to userspace via
USBDEVFS_REAPURB.
Reject any frame whose actual_length exceeds transfer_buffer_length
(one frame can't carry more data than the whole buffer), and widen the
accumulator to u32 so that many moderately-large frames can't wrap it
either.
Kelvin Mbogo [Wed, 25 Mar 2026 10:36:38 +0000 (13:36 +0300)]
usb: usbip: fix integer overflow in usbip_recv_iso()
usbip_recv_iso() computes the iso descriptor buffer size as:
int size = np * sizeof(*iso);
where np comes straight from the wire (urb->number_of_packets, set by
usbip_pack_ret_submit() before we get here). With np = 0x10000001 and
sizeof(*iso) == 16 the product is 0x100000010 which truncates to 16 on
a 32-bit int. kzalloc(16) succeeds but the following receive loop
writes np * 16 bytes into it - game over.
USBIP_MAX_ISO_PACKETS (1024) already exists in usbip_common.h for the
submit path but was never enforced on the receive side.
Clamp np to [1, USBIP_MAX_ISO_PACKETS] and switch to kcalloc() so
the allocator itself can catch overflows in the future. Fold the
existing np == 0 early return into the new bounds check.
usbip_pack_ret_submit() already copied the bogus np into
urb->number_of_packets before we run, so just returning -EPROTO is
not enough - processcompl() in the HCD will still iterate that many
iso_frame_desc entries when it completes the failed URB. Zero out
urb->number_of_packets before bailing to prevent that secondary crash
(confirmed on 6.12.0, processcompl+0x63 with CR2 in unmapped slab).
Guan-Yu Lin [Wed, 1 Apr 2026 12:32:18 +0000 (12:32 +0000)]
usb: host: xhci-sideband: delegate offload_usage tracking to class drivers
Remove usb_offload_get() and usb_offload_put() from the xHCI sideband
interrupter creation and removal paths.
The responsibility of manipulating offload_usage now lies entirely with
the USB class drivers. They have the precise context of when an offload
data stream actually starts and stops, ensuring a much more accurate
representation of offload activity for power management.
Cc: stable <stable@kernel.org> Fixes: ef82a4803aab ("xhci: sideband: add api to trace sideband usage") Signed-off-by: Guan-Yu Lin <guanyulin@google.com> Tested-by: Hailong Liu <hailong.liu@oppo.com> Tested-by: hailong.liu@oppo.com Acked-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://patch.msgid.link/20260401123238.3790062-3-guanyulin@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Guan-Yu Lin [Wed, 1 Apr 2026 12:32:17 +0000 (12:32 +0000)]
usb: core: use dedicated spinlock for offload state
Replace the coarse USB device lock with a dedicated offload_lock
spinlock to reduce contention during offload operations. Use
offload_pm_locked to synchronize with PM transitions and replace
the legacy offload_at_suspend flag.
Optimize usb_offload_get/put by switching from auto-resume/suspend
to pm_runtime_get_if_active(). This ensures offload state is only
modified when the device is already active, avoiding unnecessary
power transitions.
Cc: stable <stable@kernel.org> Fixes: ef82a4803aab ("xhci: sideband: add api to trace sideband usage") Signed-off-by: Guan-Yu Lin <guanyulin@google.com> Tested-by: Hailong Liu <hailong.liu@oppo.com> Acked-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://patch.msgid.link/20260401123238.3790062-2-guanyulin@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
usb: cdns3: gadget: fix state inconsistency on gadget init failure
When cdns3_gadget_start() fails, the DRD hardware is left in gadget mode
while software state remains INACTIVE, creating hardware/software state
inconsistency.
When switching to host mode via sysfs:
echo host > /sys/class/usb_role/13180000.usb-role-switch/role
The role state is not set to CDNS_ROLE_STATE_ACTIVE due to the error,
so cdns_role_stop() skips cleanup because state is still INACTIVE.
This violates the DRD controller design specification (Figure22),
which requires returning to idle state before switching roles.
This leads to a synchronous external abort in xhci_gen_setup() when
setting up the host controller:
[ 516.440698] configfs-gadget 13180000.usb: failed to start g1: -19
[ 516.442035] cdns-usb3 13180000.usb: Failed to add gadget
[ 516.443278] cdns-usb3 13180000.usb: set role 2 has failed
...
[ 1301.375722] xhci-hcd xhci-hcd.1.auto: xHCI Host Controller
[ 1301.377716] Internal error: synchronous external abort: 96000010 [#1] PREEMPT SMP
[ 1301.382485] pc : xhci_gen_setup+0xa4/0x408
[ 1301.393391] backtrace:
...
xhci_gen_setup+0xa4/0x408 <-- CRASH
xhci_plat_setup+0x44/0x58
usb_add_hcd+0x284/0x678
...
cdns_role_set+0x9c/0xbc <-- Role switch
Fix by calling cdns_drd_gadget_off() in the error path to properly
clean up the DRD gadget state.
Xiaolei Wang [Wed, 1 Apr 2026 13:49:38 +0000 (21:49 +0800)]
usb: dwc3: imx8mp: fix memory leak on probe failure path
When platform_get_drvdata() returns NULL and probe defers, the error
path jumps to the 'depopulate' label, skipping put_device() for the
reference acquired by of_find_device_by_node(). This extra reference
prevents the child platform device from being freed when
of_platform_depopulate() is called, resulting in memory leaks reported
by kmemleak:
Guangshuo Li [Wed, 1 Apr 2026 02:51:42 +0000 (10:51 +0800)]
usb: ulpi: fix double free in ulpi_register_interface() error path
When device_register() fails, ulpi_register() calls put_device() on
ulpi->dev.
The device release callback ulpi_dev_release() drops the OF node
reference and frees ulpi, but the current error path in
ulpi_register_interface() then calls kfree(ulpi) again, causing a
double free.
Let put_device() handle the cleanup through ulpi_dev_release() and
avoid freeing ulpi again in ulpi_register_interface().
Fixes: 289fcff4bcdb1 ("usb: add bus type for USB ULPI") Cc: stable <stable@kernel.org> Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://patch.msgid.link/20260401025142.1398996-1-lgs201920130244@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jason Gunthorpe [Fri, 27 Mar 2026 15:22:10 +0000 (12:22 -0300)]
iommu/riscv: Remove overflows on the invalidation path
Since RISC-V supports a sign extended page table it should support
a gather->end of ULONG_MAX, but if this happens it will infinite loop
because of the overflow.
Also avoid overflow computing the length by moving the +1 to the other
side of the <
iommu/amd: Fix clone_alias() to use the original device's devid
Currently clone_alias() assumes first argument (pdev) is always the
original device pointer. This function is called by
pci_for_each_dma_alias() which based on topology decides to send
original or alias device details in first argument.
This meant that the source devid used to look up and copy the DTE
may be incorrect, leading to wrong or stale DTE entries being
propagated to alias device.
Fix this by passing the original pdev as the opaque data argument to
both the direct clone_alias() call and pci_for_each_dma_alias(). Inside
clone_alias(), retrieve the original device from data and compute devid
from it.
Fixes: 3332364e4ebc ("iommu/amd: Support multiple PCI DMA aliases in device table") Signed-off-by: Vasant Hegde <vasant.hegde@amd.com> Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
JP Hein [Tue, 31 Mar 2026 00:38:04 +0000 (17:38 -0700)]
USB: core: add NO_LPM quirk for Razer Kiyo Pro webcam
The Razer Kiyo Pro (1532:0e05) is a USB 3.0 UVC webcam whose firmware
does not handle USB Link Power Management transitions reliably. When LPM
is active, the device can enter a state where it fails to respond to
control transfers, producing EPIPE (-32) errors on UVC probe control
SET_CUR requests. In the worst case, the stalled endpoint triggers an
xHCI stop-endpoint command that times out, causing the host controller
to be declared dead and every USB device on the bus to be disconnected.
This has been reported as Ubuntu Launchpad Bug #2061177. The failure
mode is:
1. UVC probe control SET_CUR returns -32 (EPIPE)
2. xHCI host not responding to stop endpoint command
3. xHCI host controller not responding, assume dead
4. All USB devices on the affected xHCI controller disconnect
Disabling LPM prevents the firmware from entering the problematic low-
power states that precede the stall. This is the same approach used for
other webcams with similar firmware issues (e.g., Logitech HD Webcam C270).
Yongchao Wu [Tue, 31 Mar 2026 00:04:07 +0000 (08:04 +0800)]
usb: cdns3: gadget: fix NULL pointer dereference in ep_queue
When the gadget endpoint is disabled or not yet configured, the ep->desc
pointer can be NULL. This leads to a NULL pointer dereference when
__cdns3_gadget_ep_queue() is called, causing a kernel crash.
Add a check to return -ESHUTDOWN if ep->desc is NULL, which is the
standard return code for unconfigured endpoints.
This prevents potential crashes when ep_queue is called on endpoints
that are not ready.
iommu/vt-d: Remove dmar_writel() and dmar_writeq()
dmar_writel() and dmar_writeq() do nothing other than expand to the generic
writel() and writeq(), and the dmar_write*() wrappers are used
inconsistently.
Remove the dmar_write*() wrappers and use writel() and writeq() directly.
iommu/vt-d: Block PASID attachment to nested domain with dirty tracking
Kernel lacks dirty tracking support on nested domain attached to PASID,
fails the attachment early if nesting parent domain is dirty tracking
configured, otherwise dirty pages would be lost.
Cc: stable@vger.kernel.org Fixes: 67f6f56b5912 ("iommu/vt-d: Add set_dev_pasid callback for nested domain") Suggested-by: Kevin Tian <kevin.tian@intel.com> Signed-off-by: Zhenzhong Duan <zhenzhong.duan@intel.com> Reviewed-by: Kevin Tian <kevin.tian@intel.com> Reviewed-by: Yi Liu <yi.l.liu@intel.com> Link: https://lore.kernel.org/r/20260330101108.12594-2-zhenzhong.duan@intel.com Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com> Fixes: 67f6f56b5912 ("iommu/vt-d: Add set_dev_pasid callback for nested domain") Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
Gabor Juhos [Mon, 30 Mar 2026 15:02:42 +0000 (17:02 +0200)]
usb: core: phy: avoid double use of 'usb3-phy'
Commit 53a2d95df836 ("usb: core: add phy notify connect and disconnect")
causes double use of the 'usb3-phy' in certain cases.
Since that commit, if a generic PHY named 'usb3-phy' is specified in
the device tree, that is getting added to the 'phy_roothub' list of the
secondary HCD by the usb_phy_roothub_alloc_usb3_phy() function. However,
that PHY is getting added also to the primary HCD's 'phy_roothub' list
by usb_phy_roothub_alloc() if there is no generic PHY specified with
'usb2-phy' name.
This causes that the usb_add_hcd() function executes each phy operations
twice on the 'usb3-phy'. Once when the primary HCD is added, then once
again when the secondary HCD is added.
The issue affects the Marvell Armada 3700 platform at least, where a
custom name is used for the USB2 PHY:
Extend the usb_phy_roothub_alloc_usb3_phy() function to skip adding the
'usb3-phy' to the 'phy_roothub' list of the secondary HCD when 'usb2-phy'
is not specified in the device tree to avoid the double use.
Merge tag 'asoc-fix-v7.0-rc6' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus
ASoC: Fixes for v7.0
Another smallish batch of fixes and quirks, these days it's AMD that is
getting all the DMI entries added. We've got one core fix for a missing
list initialisation with auxiliary devices, otherwise it's all fairly
small things.
Pawel Laszczak [Tue, 31 Mar 2026 08:19:11 +0000 (10:19 +0200)]
usb: cdnsp: Add support for device-only configuration
This patch introduces support for operating the Cadence USBSSP (cdnsp)
controller in a peripheral-only mode, bypassing the Dual-Role Device (DRD)
logic.
The change in BAR indexing (from BAR 2 to BAR 1) is a direct
consequence of switching from 64-bit to 32-bit addressing in the
Peripheral-only configuration.
Tested on PCI platform with Device-only configuration. Platform-side
changes are included to support the PCI glue layer's property injection.
drm/ioc32: stop speculation on the drm_compat_ioctl path
The drm compat ioctl path takes a user controlled pointer, and then
dereferences it into a table of function pointers, the signature method
of spectre problems. Fix this up by calling array_index_nospec() on the
index to the function pointer list.
Fixes: 505b5240329b ("drm/ioctl: Fix Spectre v1 vulnerabilities") Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <mripard@kernel.org> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: David Airlie <airlied@gmail.com> Cc: Simona Vetter <simona@ffwll.ch> Cc: stable <stable@kernel.org> Assisted-by: gkh_clanker_2000 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Acked-by: Maxime Ripard <mripard@kernel.org> Reviewed-by: Simona Vetter <simona@ffwll.ch> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patch.msgid.link/2026032451-playing-rummage-8fa2@gregkh
wifi: rtw89: usb: fix TX flow control by tracking in-flight URBs
rtw89_usb_ops_check_and_reclaim_tx_resource() returns a hardcoded
placeholder value (42) instead of actual TX resource availability.
This violates mac80211's flow control contract, preventing backpressure
and causing uncontrolled URB accumulation under sustained TX load.
Fix by adding per-channel atomic counters (tx_inflight[]) that track
in-flight URBs. Increment before usb_submit_urb() with rollback on
failure, decrement in the completion callback, and return the
remaining capacity to mac80211. The firmware command channel (CH12)
always returns 1 since it has its own flow control.
The pre-increment pattern prevents a race where USB core completes the
URB on another CPU before the submitting code increments the counter.
128 URBs per channel provides headroom for RTL8832CU at 160 MHz
bandwidth. Tested on RTL8852AU (USB3 80 MHz) where 64 and 128 showed
equivalent throughput, and on RTL8832AU where 128 sustained full
throughput under 8-stream parallel load.
Tested on D-Link DWA-X1850 (RTL8832AU), kernel 6.19.8, Fedora 43:
Jiri Pirko [Wed, 25 Mar 2026 19:23:52 +0000 (20:23 +0100)]
dma-buf: heaps: system: add system_cc_shared heap for explicitly shared memory
Add a new "system_cc_shared" dma-buf heap to allow userspace to
allocate shared (decrypted) memory for confidential computing (CoCo)
VMs.
On CoCo VMs, guest memory is private by default. The hardware uses an
encryption bit in page table entries (C-bit on AMD SEV, "shared" bit on
Intel TDX) to control whether a given memory access is private or
shared. The kernel's direct map is set up as private,
so pages returned by alloc_pages() are private in the direct map
by default. To make this memory usable for devices that do not support
DMA to private memory (no TDISP support), it has to be explicitly
shared. A couple of things are needed to properly handle
shared memory for the dma-buf use case:
- set_memory_decrypted() on the direct map after allocation:
Besides clearing the encryption bit in the direct map PTEs, this
also notifies the hypervisor about the page state change. On free,
the inverse set_memory_encrypted() must be called before returning
pages to the allocator. If re-encryption fails, pages
are intentionally leaked to prevent shared memory from being
reused as private.
- pgprot_decrypted() for userspace and kernel virtual mappings:
Any new mapping of the shared pages, be it to userspace via
mmap or to kernel vmalloc space via vmap, creates PTEs independent
of the direct map. These must also have the encryption bit cleared,
otherwise accesses through them would see encrypted (garbage) data.
- DMA_ATTR_CC_SHARED for DMA mapping:
Since the pages are already shared, the DMA API needs to be
informed via DMA_ATTR_CC_SHARED so it can map them correctly
as unencrypted for device access.
On non-CoCo VMs, the system_cc_shared heap is not registered
to prevent misuse by userspace that does not understand
the security implications of explicitly shared memory.
Signed-off-by: Jiri Pirko <jiri@nvidia.com> Reviewed-by: T.J. Mercier <tjmercier@google.com> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Acked-by: Sumit Semwal <sumit.semwal@linaro.org> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Link: https://lore.kernel.org/r/20260325192352.437608-3-jiri@resnulli.us
projects / thirdparty / linux.git / log
