Jouni Högander [Fri, 15 May 2026 09:57:55 +0000 (12:57 +0300)]
drm/i915/psr: Apply Intel DPCD workaround when SDP on prior line used
There is Intel specific workaround DPCD address containing workaround for
case where SDP is on prior line. Apply this workaround according to values
in the offset.
Jouni Högander [Fri, 15 May 2026 09:57:54 +0000 (12:57 +0300)]
drm/i915/psr: Read Intel DPCD workaround register
Read Intel DPCD workaround register and store it into
intel_connector->dp.psr_caps. psr_caps was chosen as currently it contains
only PSR workaround for PSR2 SDP on prior scanline implementation.
Jouni Högander [Fri, 15 May 2026 09:57:53 +0000 (12:57 +0300)]
drm/i915/psr: Add defininitions for INTEL_WA_REGISTER_CAPS DPCD register
EDP specification says:
"If either VSC SDP is unable to be transmitted 100 ns before the SU region,
the Source device may optionally transmit the VSC SDP during the prior
video scan line’s HBlank period There is a Intel specific drm dp register
currently containing bits related how TCON can support PSR2 with SDP on
prior line."
Unfortunately many panels are having problems in implementing this. So
there is a custom Intel specific DPCD register (INTEL_WA_REGISTER_CAPS) to
figure out if this is properly implemented on a panel or if panel doesn't
require that 100 ns delay before the SU region. Here are the definitions in
this custom DPCD address:
0 = Panel doesn't support SDP on prior line
1 = Panel supports SDP on prior line
2 = Panel doesn't have 100ns requirement
3 = Reserved
Add definitions for this new register and it's values into new header
intel_dpcd.h.
David Carlier [Sat, 28 Mar 2026 15:14:52 +0000 (15:14 +0000)]
media: mali-c55: Disable pm_runtime on probe error
When mali_c55_media_frameworks_init() fails, the goto target jumps to
err_free_context_registers, skipping pm_runtime_disable() despite
pm_runtime having already been enabled earlier in the function.
Fix this by adding an err_pm_runtime_disable label and redirecting the
frameworks init failure to it, so pm_runtime is properly unwound on
that error path. The runtime PM status is also set back to suspended
before disabling, to undo the pm_runtime_set_active() from probe.
David Carlier [Sat, 28 Mar 2026 15:14:51 +0000 (15:14 +0000)]
media: mali-c55: Power-off the peripheral in remove()
The Mali C55 driver doesn't depend on PM. For this reason, if pm_runtime
is not compiled in it is required to manually power-off the peripheral
during the driver's remove() handler.
Also pm_runtime_enable() is called during probe but mali_c55_remove()
never calls pm_runtime_disable(), leaving the device's runtime PM state
enabled after the driver is unbound.
Manually power-off the peripheral in remove() if the peripheral has not
been suspended using runtime_pm and disable runtime pm.
mali_c55_probe() calls of_reserved_mem_device_init() to associate
reserved memory regions with the device. This function allocates a
struct rmem_assigned_device and adds it to a global linked list, which
must be explicitly released via of_reserved_mem_device_release() — there
is no devm variant of this API.
However, neither the probe error paths nor mali_c55_remove() called
of_reserved_mem_device_release(). Any probe failure after the
of_reserved_mem_device_init() call, as well as every normal device
removal, leaked the reserved memory association on the global list.
Fix this by adding an err_release_mem label at the end of the probe
error chain and calling of_reserved_mem_device_release() in
mali_c55_remove(). The remove teardown order is also corrected to call
mali_c55_media_frameworks_deinit() before kfree(), mirroring the probe
init order in reverse.
Alper Ak [Sat, 7 Feb 2026 09:18:22 +0000 (12:18 +0300)]
media: mali-c55: Fix possible ERR_PTR in enable_streams
The media_pad_remote_pad_unique() function returns either a valid
pointer or an ERR_PTR() on failure (-ENOTUNIQ if multiple links are
enabled, -ENOLINK if no connected pad is found). The return value
was assigned directly to isp->remote_src and dereferenced in the
next line without checking for errors, which could lead to an
ERR_PTR dereference.
Add proper error checking with IS_ERR() before dereferencing the
pointer. Also set isp->remote_src to NULL on error to maintain
consistency with other error paths in the function.
Cc: stable@vger.kernel.org Fixes: d5f281f3dd29 ("media: mali-c55: Add Mali-C55 ISP driver") Signed-off-by: Alper Ak <alperyasinak1@gmail.com> Reviewed-by: Jacopo Mondi <jacopo.mondi+renesas@ideasonboard.com> Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com> Signed-off-by: Jacopo Mondi <jacopo.mondi+renesas@ideasonboard.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Chen Ni [Thu, 15 Jan 2026 02:35:16 +0000 (10:35 +0800)]
media: mali-c55: core: Remove redundant dev_err()
The platform_get_irq_byname() function already prints an error message
internally upon failure using dev_err_probe(). Therefore, the explicit
dev_err() is redundant and results in duplicate error logs.
Remove the redundant dev_err() call to clean up the error path.
Signed-off-by: Chen Ni <nichen@iscas.ac.cn> Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo.mondi+renesas@ideasonboard.com> Signed-off-by: Jacopo Mondi <jacopo.mondi+renesas@ideasonboard.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
jempty.liang [Tue, 13 Jan 2026 07:57:22 +0000 (07:57 +0000)]
media: mali-c55: Initialise dev for tpg/rsz/isp subdevs
The subdevices registered by the Mali-C55 driver do not have their
'struct device *dev' member initialized. This is visibile when looking
at debug message, as in example:
"(NULL device *): collect_streams: sub-device 'mali-c55 tpg' does not
support streams"
Fix this by initializing the *dev field for each subdevice registered
by the Mali-C55 driver.
Signed-off-by: jempty.liang <imntjempty@163.com> Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo.mondi+renesas@ideasonboard.com> Signed-off-by: Jacopo Mondi <jacopo.mondi+renesas@ideasonboard.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Jacopo Mondi [Sat, 28 Mar 2026 16:34:51 +0000 (17:34 +0100)]
media: rzv2h-ivc: Wait for frame end in stop_streaming
The rzv2h-ivc driver fails to handle back-2-back streaming sessions that
do not go through a peripheral reset. As the driver uses an autosuspend
delay of 2 seconds, it is quite possible that two consecutive streaming
sessions won't go through a suspend/resume sequence.
If the peripheral is not reset the second streaming session hangs and no
frames are delivered to the ISP.
This is because the stop_streaming() procedure implemented in the driver
doesn't match what's prescribed by the chip datasheet:
1) The chip manual suggests to poll the RZV2H_IVC_FM_INT_STAT_STPEND bit
of RZV2H_IVC_REG_FM_INT_STA instead of polling on RZV2H_IVC_REG_FM_STOP
and prescribes to clear the bit after polling has completed
2) More importantly: the RZV2H_IVC_REG_FM_STOP_FSTOP bit has to be set
on RZV2H_IVC_REG_FM_STOP -only- if a frame transfer to the ISP is in
progress. Setting the RZV2H_IVC_REG_FM_STOP_FSTOP bit when no frame is
being transferred causes the polling routine to timeout and the next
streaming session fails to start
As a frame transfer of an image in 1920x1080@10bi takes 5 milliseconds
at most, it is quite possible that the frame transfer completion interrupt
races with the stop procedure.
Instead of forcing a frame transfer abort, simply wait for the
in-progress transfer to complete by polling the ivc->vvalid_ifp status
variable in an hand-rolled loop that allows to inspect the variable
while holding the spinlock, to allow the irq handler to complete the
current buffer.
With this change, streaming back-2-back without suspending the
peripheral works successfully.
Cc: stable@vger.kernel.org Fixes: f0b3984d821b ("media: platform: Add Renesas Input Video Control block driver") Signed-off-by: Jacopo Mondi <jacopo.mondi+renesas@ideasonboard.com> Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Jacopo Mondi [Tue, 31 Mar 2026 08:03:47 +0000 (10:03 +0200)]
media: rzg2l-cru: Remove debug printouts from irq
Using dev_dbg() in irq handlers to debug per-frame events is marginally
useful and possibly not the best idea, as using printk-based helpers
introduce latencies that impact the drivers operations.
If any tracing/debugging has to be performed around frame events
in interrupt handlers, the tracing subsystem offers better alternatives.
Drop dev_dgb() calls from the CRU interrupt handlers.
Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com> Signed-off-by: Jacopo Mondi <jacopo.mondi+renesas@ideasonboard.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Jacopo Mondi [Wed, 11 Feb 2026 14:27:37 +0000 (15:27 +0100)]
media: rzg2l-cru: Remove the 'state' variable
The cru driver uses a 'state' variable for debugging purpose in the
interrupt handler. The state is used to detect invalid usage conditions
that are not meant to happen unless the driver has a bug in handling the
stop and start conditions.
Remove the state variable which seems to be a debugging leftover.
Signed-off-by: Jacopo Mondi <jacopo.mondi+renesas@ideasonboard.com> Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com> Tested-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Daniel Scally [Thu, 18 Sep 2025 11:02:06 +0000 (12:02 +0100)]
media: rzg2l-cru: Rework rzg2l_cru_fill_hw_slot()
The current implementation of rzg2l_cru_fill_hw_slot() results in the
artificial loss of frames. At present whenever a frame-complete IRQ
is received the driver fills the hardware slot that was just written
to with the address of the next buffer in the driver's queue. If the
queue is empty, that hardware slot's address is set to the address of
the scratch buffer to enable the capture loop to keep running. There
is a minimum of a two-frame delay before that slot will be written to
however, and in the intervening period userspace may queue more
buffers which could be used.
To resolve the issue rework rzg2l_cru_fill_hw_slot() so that it
iteratively fills all slots from the queue which currently do not
have a buffer assigned, until the queue is empty. The scratch
buffer is only resorted to in the event that the queue is empty and
the next slot that will be written to does not already have a buffer
assigned.
Signed-off-by: Daniel Scally <dan.scally+renesas@ideasonboard.com> Signed-off-by: Jacopo Mondi <jacopo.mondi+renesas@ideasonboard.com> Tested-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Jacopo Mondi [Wed, 11 Feb 2026 09:57:11 +0000 (10:57 +0100)]
media: rz2gl-cru: Return pending buffers in order
Buffers are programmed into slots in queueing order.
When returning pending buffers we can't simply start from the first slot
but we should actually iterate slots starting from the one is use. The
rzg3e_cru_irq() handler already uses 'active_slot', make rzg2l_cru_irq()
use it as well to know where to start iterating from.
As the pattern of iterating over slots in order will be used for slots
programming in the next patches, provide an helper macro to do that.
While at it, rename return_unused_buffers() to rzg2l_cru_return_buffers().
Signed-off-by: Jacopo Mondi <jacopo.mondi+renesas@ideasonboard.com> Tested-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com> Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Jacopo Mondi [Wed, 11 Feb 2026 08:55:00 +0000 (09:55 +0100)]
media: rzg2l-cru: Manually track active slot number
The CRU cycles over the hardware slots where the destination address for
the next frame has to be programmed.
The RZ/G2L version of the IP has a register that tells which is the
last used slot by the hardware but, unfortunately, such register is not
available on RZ/G3E and RZ/V2H(P).
The driver currently compares the value of the AMnMADRSL/H register
which report "the memory address which the current video data was
written to" and compares it with the address programmed in the slots.
This heuristic requires a bit of book keeping and proper locking. As the
driver handles the FrameEnd interrupt, it's way easier to keep track
of the slot that has been used by ourselves with a driver variable.
Jacopo Mondi [Wed, 11 Feb 2026 08:50:10 +0000 (09:50 +0100)]
media: rzg2l-cru: Split hw locking from buffers
Split the locking between a spinlock dedicated to protect the hardware
slots programming (hw_lock) and one lock (qlock) to protect the queue of
buffers submitted by userspace.
Do not rework the locking strategy yet but start simply by splitting the
locking in two.
Signed-off-by: Jacopo Mondi <jacopo.mondi+renesas@ideasonboard.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Jacopo Mondi [Thu, 12 Feb 2026 14:38:38 +0000 (15:38 +0100)]
media: rzg2l-cru: Do not use irqsave when not needed
The return_unused_buffers() and rzg2l_cru_buffer_queue() functions
are never called from an interrupt context, hence they do not need to
use the irqsave version of the spinlock primitives.
Jacopo Mondi [Thu, 12 Feb 2026 14:38:11 +0000 (15:38 +0100)]
media: rzg2l-cru: Remove locking from start/stop routines
The start/stop streaming routines do not need to lock the whole function
body against possible concurrent accesses to the CRU buffers or hardware
registers.
The stop function starts by disabling interrupts, and only this portion
needs to be protected not to race against a possible IRQ.
Once interrupts are disabled, nothing in the video device driver can race
and once the peripheral has been disabled we can release all pending
buffers.
Jacopo Mondi [Wed, 11 Feb 2026 08:24:06 +0000 (09:24 +0100)]
media: rzg2l-cru: Modernize locking usage with guards
Use more modern lock guard constructs to express the locking sequences
in the rzg2l driver. Also include spinlock.h and mutex.h that were
previously missing.
Tommaso Merciai [Tue, 30 Dec 2025 17:09:16 +0000 (18:09 +0100)]
media: rzg2l-cru: Use only frame end interrupts
On RZ/G3E the CRU driver relies on the frame end interrupt to detect the
completion of an active frame transfer when stopping DMA.
Update the driver to enable only frame end interrupts (CRUnIE2_FExE),
dropping the usage of the frame start interrupts, which is not required
for this operations flow.
Fix the interrupt status handling in the DMA stopping state by checking
the correct frame end status bits (FExS) instead of the frame start one
(FSxS). Add a dedicated CRUnINTS2_FExS() macro to reflect the actual
register bit layout and drop the now unused CRUnIE2_FSxE() and
CRUnINTS2_FSxS() macros.
This ensures that DMA stopping is triggered by the intended frame end
events and avoids incorrect interrupt handling.
Tommaso Merciai [Tue, 30 Dec 2025 17:09:15 +0000 (18:09 +0100)]
media: rzg2l-cru: Skip ICnMC configuration when ICnSVC is used
When the CRU is configured to use ICnSVC for virtual channel mapping,
as on the RZ/{G3E, V2H/P} SoC, the ICnMC register must not be
programmed.
Return early after setting up ICnSVC to avoid overriding the ICnMC
register, which is not applicable in this mode.
This prevents unintended register programming when ICnSVC is enabled.
Cc: stable@vger.kernel.org Fixes: 3c5ca0a48bb0 ("media: rzg2l-cru: Drop function pointer to configure CSI") Signed-off-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com>
[Rework to not break image format programming] Signed-off-by: Jacopo Mondi <jacopo.mondi+renesas@ideasonboard.com> Reviewed-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
pidfd: refuse access to tasks that have started exiting harder
The recent ptrace fix closed a hole where someone could rely on task->mm
becoming NULL during do_exit() to bypass dumpability checks. This api
here leans on on the very same check and so inherits the fix.
But there is no good reason to let it succeed at all once the target has
entered do_exit(). PF_EXITING is set by exit_signals() at the very top
of do_exit(), before exit_mm() and exit_files() run. Once we observe it,
the task is committed to dying and exit_files() will release the fdtable
shortly.
drm/i915/display: Copy color pipeline from plane in the primary joiner pipe
When copying plane color state in a joiner configuration, use the plane in
the primary joiner pipe since it carries the pipeline number selected by
the user-space.
This assumes that all pipes in the joiner are symmetric in their plane
color capabilities.
Cc: stable@vger.kernel.org # v6.19+ Fixes: a78f1b6baf4d ("drm/i915/color: Add framework to program CSC") Tested-by: Vidya Srinivas <vidya.srinivas@intel.com> Signed-off-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Link: https://patch.msgid.link/20260511053213.3122314-2-chaitanya.kumar.borah@intel.com
(cherry picked from commit e8308fb5e05ca08ddfb8b46f6d947a6e3fd80cd7) Signed-off-by: Tvrtko Ursulin <tursulin@ursulin.net>
Sven Eckelmann [Thu, 14 May 2026 17:22:02 +0000 (19:22 +0200)]
batman-adv: mcast: fix use-after-free in orig_node RCU release
batadv_mcast_purge_orig() removes entries from RCU-protected hlists but
does not wait for an RCU grace period before returning. Concurrent RCU
readers may still accesses references to those entries at the point of
removal. RCU-protected readers trying to operate on entries like
orig->mcast_want_all_ipv6_node will then access already freed memory.
Fix this by moving batadv_mcast_purge_orig() to batadv_orig_node_release(),
just before the call_rcu() invocation. This ensures RCU readers that were
active at purge time have drained before the orig_node memory is reclaimed.
Sven Eckelmann [Sat, 16 May 2026 10:33:41 +0000 (12:33 +0200)]
batman-adv: tp_meter: avoid role confusion in tp_list
Session lookups in tp_list matched only on destination address (and
optionally session ID), leaving role validation to the caller. If two
sessions with the same other_end coexisted (one as sender, one as receiver)
a lookup could silently return the wrong one, causing the caller's role to
bail out early, potentially skipping necessary cleanup.
Move the role check into the lookup functions themselves so the correct
entry is always returned, or none at all. Since batadv_tp_start()
legitimately needs to detect any active session to a destination regardless
of role, introduce a dedicated helper for that case rather than bending the
existing lookup semantics.
Cc: stable@kernel.org Fixes: 33a3bb4a3345 ("batman-adv: throughput meter implementation") Signed-off-by: Sven Eckelmann <sven@narfation.org>
Sven Eckelmann [Wed, 13 May 2026 21:38:54 +0000 (23:38 +0200)]
batman-adv: tp_meter: fix race condition in send error reporting
batadv_tp_sender_shutdown() previously used two separate variables to track
session state: sending (an atomic flag indicating whether the session was
active) and reason (a plain enum storing the stop reason). This introduced
a race window between the two writes: after sending was cleared to 0,
batadv_tp_send() could observe the stopped state and call
batadv_tp_sender_end() before reason was written, causing the wrong stop
reason to be reported to the caller.
Fix this by consolidating both variables into a single atomic send_result,
which holds 0 while the session is running and the stop reason once it
ends.
Cc: stable@kernel.org Fixes: 33a3bb4a3345 ("batman-adv: throughput meter implementation") Signed-off-by: Sven Eckelmann <sven@narfation.org>
Sven Eckelmann [Sat, 9 May 2026 19:55:29 +0000 (21:55 +0200)]
batman-adv: tvlv: reject oversized TVLV packets
batadv_tvlv_container_ogm_append() builds a TVLV packet section from
the tvlv.container_list. The total size of this section is computed by
batadv_tvlv_container_list_size(), which sums the sizes of all registered
containers.
The return type and accumulator in batadv_tvlv_container_list_size() were
u16. If the accumulated size exceeds U16_MAX, the value wraps around,
causing the subsequent allocation in batadv_tvlv_container_ogm_append()
to be undersized. The memcpy-style copy that follows would then write
beyond the end of the allocated buffer, corrupting kernel memory.
Fix this by widening the return type of batadv_tvlv_container_list_size()
to size_t. In batadv_tvlv_container_ogm_append(), check the computed length
against U16_MAX before proceeding, and bail out as if the allocation had
failed when the limit is exceeded.
Cc: stable@kernel.org Fixes: ef26157747d4 ("batman-adv: tvlv - basic infrastructure") Reported-by: Yuan Tan <yuantan098@gmail.com> Reported-by: Yifan Wu <yifanwucs@gmail.com> Reported-by: Juefei Pu <tomapufckgml@gmail.com> Reported-by: Xin Liu <bird@lzu.edu.cn> Reviewed-by: Yuan Tan <yuantan098@gmail.com> Signed-off-by: Sven Eckelmann <sven@narfation.org>
Sven Eckelmann [Thu, 14 May 2026 14:33:12 +0000 (16:33 +0200)]
batman-adv: tvlv: abort OGM send on tvlv append failure
batadv_tvlv_container_ogm_append() could fail in two ways: a memory
allocation failure when resizing the packet buffer, or the tvlv data
exceeding U16_MAX bytes. In both cases the function previously returned the
old (now stale) tvlv_value_len rather than signalling an error, causing the
OGM/OGM2 send path to transmit a packet whose TVLV length field no longer
matched the actual buffer contents. And because it also didn't fill in the
new TVLV data, sending either uninitialized or corrupted data on the wire.
All errors in batadv_tvlv_container_ogm_append() must be forwarded to the
caller. And the caller must abort the send of the OGM2. For B.A.T.M.A.N.
IV, it is currently not allowed to abort the send. The non-TVLV part of the
OGM must be queued up instead.
Sven Eckelmann [Sat, 9 May 2026 20:44:12 +0000 (22:44 +0200)]
batman-adv: v: stop OGMv2 on disabled interface
When a batadv_hard_iface is disabled, its mesh_iface pointer is set to
NULL. However, batadv_v_ogm_send_meshif() may still dispatch OGMs via
batadv_v_ogm_queue_on_if() for interfaces that have since lost their
mesh_iface association. This results in a NULL pointer dereference when
batadv_v_ogm_queue_on_if() unconditionally calls netdev_priv() on the
now NULL hard_iface->mesh_iface to retrieve the batadv_priv.
It is necessary to ensure that the batadv_v_ogm_queue_on_if() checks that
it is using the same mesh_iface for which batadv_v_ogm_send_meshif() was
called.
Cc: stable@kernel.org Fixes: 0da0035942d4 ("batman-adv: OGMv2 - add basic infrastructure") Reported-by: Yuan Tan <yuantan098@gmail.com> Reported-by: Yifan Wu <yifanwucs@gmail.com> Reported-by: Juefei Pu <tomapufckgml@gmail.com> Reported-by: Xin Liu <bird@lzu.edu.cn> Reviewed-by: Yuan Tan <yuantan098@gmail.com> Signed-off-by: Sven Eckelmann <sven@narfation.org>
The US-428 pipe-4 output path submits at most one pending p4out
entry from the shared-memory ring per input interrupt. If userspace
queues more than one command before the interrupt handler runs, later
commands remain pending until later input interrupts, even when async
pipe-4 URBs are available.
Drain pending entries while idle async URBs are available. Copy each
command into the existing per-URB async buffer before submission, so the
submitted transfer does not depend on a userspace-mapped ring slot
remaining unchanged after p4out_sent is advanced.
Also update p4out_sent only after usb_submit_urb() succeeds, so a
failed submission is not reported as sent.
This keeps the shared-memory ABI unchanged and fixes only the local
queue-draining behavior.
Cássio Gabriel [Tue, 19 May 2026 03:32:15 +0000 (00:32 -0300)]
ALSA: ua101: Reject too-short USB descriptors
find_format_descriptor() walks the class-specific interface extras by
advancing with bLength. It rejects descriptors that extend past the
remaining buffer, but it does not reject descriptor lengths smaller than
a USB descriptor header.
Reject too-short descriptors before using bLength to advance the local
scan. This keeps the UA-101 parser robust against malformed descriptor
data and matches the usual USB descriptor walking rules.
Rosen Penev [Tue, 19 May 2026 00:48:34 +0000 (17:48 -0700)]
ALSA: usb-audio: Use flexible allocation for FCP packets
Allocate FCP request and response packets with kmalloc_flex() for
the trailing packet data instead of passing the computed struct size
directly to kmalloc().
Keep the computed packet sizes for the USB transfer length checks.
Maoyi Xie [Mon, 18 May 2026 19:40:23 +0000 (03:40 +0800)]
ALSA: seq: avoid past-the-end iterator in snd_seq_create_port()
snd_seq_create_port() walks client->ports_list_head looking for
the ordered insertion point and on loop fall-through passes
&p->list to list_add_tail():
When the loop walks all entries without break (e.g., the new
port sorts last), p is past-the-end. &p->list aliases
&client->ports_list_head (the list head) via container_of offset
cancellation, so the insert lands at the list tail. That is the
intended behaviour, but the access is undefined per C11 even
though it works in practice.
Track an explicit insert_before pointer initialised to the list
head and overwritten to &p->list only when the loop breaks
early. The observable behaviour is unchanged.
Maoyi Xie [Mon, 18 May 2026 19:40:22 +0000 (03:40 +0800)]
ALSA: timer: avoid past-the-end iterator in snd_timer_dev_register()
snd_timer_dev_register() walks snd_timer_list looking for the
ordered insertion point and on loop fall-through passes
&timer1->device_list to list_add_tail():
When the loop walks all entries without break, timer1 is
past-the-end. &timer1->device_list aliases &snd_timer_list (the
list head) via container_of offset cancellation, so the insert
lands at the list tail. That is the intended behaviour, but the
access is undefined per C11 even though it works in practice.
Track an explicit insert_before pointer initialised to the list
head and overwritten to &timer1->device_list only when the loop
breaks early. The observable behaviour is unchanged.
Cássio Gabriel [Mon, 18 May 2026 14:32:05 +0000 (11:32 -0300)]
ALSA: ice1724: Fix blocking open for independent surround PCMs
The independent surround playback open path rejects a substream when the
matching PDMA channel is reserved by the multi-channel PDMA0 stream. It
currently returns -EBUSY for that case, although the driver has carried a
FIXME noting that blocking mode is not handled properly.
ALSA PCM open waits and retries only when the low-level open callback
returns -EAGAIN. Returning -EBUSY therefore makes blocking opens fail
immediately, the same as nonblocking opens.
Return -EAGAIN for the temporary PDMA0 reservation conflict. The PCM core
continues to report -EBUSY for O_NONBLOCK callers, while blocking callers
sleep and retry.
Also wake the independent surround PCM wait queue when hw_free releases a
PDMA reservation. The reservation can be released by the pro PCM, while
waiters are sleeping on the independent surround PCM, so waking the current
substream PCM is not sufficient for this cross-PCM reservation.
Ezio Galeazzi [Sun, 17 May 2026 15:42:36 +0000 (17:42 +0200)]
ALSA: hda/ca0132: add QUIRK_GENERIC path for Gigabyte GA-Z170X-Gaming G1
Some CA0132 implementations (e.g. Gigabyte GA-Z170X-Gaming G1) produce
white noise when using the DSP firmware path. Add a QUIRK_GENERIC path
that uses the standard HDA generic parser instead, with custom pin
configs.
This patch applies against v6.18.24.
Ping-Ke Shih [Mon, 11 May 2026 07:01:47 +0000 (15:01 +0800)]
wifi: rtw89: phy: configure control options of BB wrapper by RFSI band
The settings of control options are predefined per RFSI band (2GHz band or
not 5/6GHz band) and used for fine-tuning transmit power. Calculate and set
the RFSI band once creating channel context, and use it by BB wrapper
configurations.
dt-bindings: arm: qcom,ids: Add SoC ID for Nord SA8797P
Nord is a SoC family from Qualcomm designed as the next generation of
Lemans series. SA8797P is the automotive variant of Nord, where platform
resources such as clocks, regulators, interconnects, etc. are managed
by firmware through SCMI.
Ping-Ke Shih [Mon, 11 May 2026 07:01:38 +0000 (15:01 +0800)]
wifi: rtw89: phy: define BB wrap data for RTL8922D variants
The BB wrap is a hardware block to control TX power. Since RTL8922D has
many variants with different CID and RFE types, prepare flow and dummy
struct adopt to configuration functions for coming patches.
Paul Chaignon [Mon, 18 May 2026 16:26:35 +0000 (18:26 +0200)]
selftests/bpf: Fix test for refinement of single-value tnum
This patch fixes the "bounds refinement with single-value tnum on umin"
verifier selftest. This selftest was introduced in commit e6ad477d1bf8
("selftests/bpf: Test refinement of single-value tnum") to cover the
logic from __update_reg64_bounds(), introduced in commit efc11a667878
("bpf: Improve bounds when tnum has a single possible value"). However,
the test still passes if that last commit is reverted.
The test is supposed to cover the case when the tnum and u64 range (or
cnum64 now) overlap in a single value. __update_reg64_bounds() detects
that case and refines the bounds to a known constant. However, the
constants for the test were poorly chosen and the bounds get refined to
a known constant even without __update_reg64_bounds(). The code is as
follows:
After instruction 3, we have u64=[0xe0; 0xef] and tnum=(0xe0; 0x10).
__reg_bound_offset() is able to deduce a new tnum from the u64,
tnum=(0xe0; 0x0f), which combined with the existing tnum gives us a
constant: 0xe0 or 224.
We can easily fix this by choosing different starting bounds. If we make
it u64=[0xe1; 0xf0], then __reg_bound_offset() doesn't have any impact.
selftests/bpf: Reject unsupported -k option in vmtest.sh
vmtest.sh does not document a -k option and does not handle it in the
getopts case statement. However, the getopts optstring includes k, which
causes the script to accept -k silently instead of reporting it as an
invalid option.
Remove k from the optstring so unsupported options are rejected through
the existing invalid-option path.
Fixes: c9709f52386d ("bpf: Helper script for running BPF presubmit tests") Signed-off-by: Roman Kvasnytskyi <roman@kvasnytskyi.net> Acked-by: Paul Chaignon <paul.chaignon@gmail.com> Link: https://lore.kernel.org/r/20260516120625.80839-1-roman@kvasnytskyi.net Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Paul Chaignon [Wed, 13 May 2026 11:24:37 +0000 (13:24 +0200)]
selftests/bpf: Override EXTRA_LDFLAGS for static builds
When running vmtest.sh with static linking, the bpftool_map_access
selftests fail. These selftests are calling the bpftool binary in
tools/sbin/ directly, which results in the following error:
error while loading shared libraries: libLLVM.so.21.1:
cannot open shared object file: No such file or directory
To fix this, we need to also build bpftool statically. That can be done
by setting EXTRA_LDFLAGS=-static.
For ice:
Jake fixes a mismatch in locking around wait queue usage.
Jose Ignacio Tornos Martinez adjusts allowed lower bound for VF data
buffer size to accommodate low MTU sizes.
Marcin adjusts for -EEXIST to not trigger error path when the promisc
filter already exists as part of adding VLAN Ids.
Grzegorz fixes a few issues related to PTP. He adds locking to
ice_start_phy_timer_eth56g() to protect proper register programming.
Fixes the PTP lock used in 2xNAC configuration to always be the primary
and restores PTP configuration on ethtool channel changes.
For ixgbevf:
Michael Bommarito sets freed skb pointer to NULL to prevent
use-after-free.
For igc:
Kohei Enju resolves a couple of issues reported by Sashiko; setting
buffer type for an SMD skb and freeing skb on error of
igc_fpe_init_tx_descriptor().
====================
Kohei Enju [Fri, 15 May 2026 18:24:16 +0000 (11:24 -0700)]
igc: fix potential skb leak in igc_fpe_xmit_smd_frame()
When igc_fpe_init_tx_descriptor() fails, no one takes care of an
allocated skb, leaking it. [1]
Use dev_kfree_skb_any() on failure.
Tested on an I226 adapter with the following command, while injecting
faults in igc_fpe_init_tx_descriptor() to trigger the error path.
# ethtool --set-mm $DEV verify-enabled on tx-enabled on pmac-enabled on
Kohei Enju [Fri, 15 May 2026 18:24:15 +0000 (11:24 -0700)]
igc: set tx buffer type for SMD frames
Sashiko pointed out that igc_fpe_init_smd_frame() initializes
igc_tx_buffer fields for an SMD skb, but does not set the buffer type:
https://sashiko.dev/#/patchset/20260415025226.114115-1-kohei%40enjuk.jp
Since igc_tx_buffer entries are reused, a stale XDP or XSK type can
remain and make TX completion use the wrong cleanup path.
Set the buffer type to IGC_TX_BUFFER_TYPE_SKB.
Fixes: 5422570c0010 ("igc: add support for frame preemption verification") Signed-off-by: Kohei Enju <kohei@enjuk.jp> Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Reviewed-by: Simon Horman <horms@kernel.org> Tested-by: Avigail Dahan <avigailx.dahan@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com> Link: https://patch.msgid.link/20260515182419.1597859-9-anthony.l.nguyen@intel.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
ixgbevf: fix use-after-free in VEPA multicast source pruning
ixgbevf_clean_rx_irq() prunes frames whose source MAC matches the VF's
own address (VEPA multicast workaround) by freeing the skb and
continuing to the next descriptor:
dev_kfree_skb_irq(skb);
continue;
The skb pointer is declared outside the while loop and persists across
iterations. Because the continue skips the "skb = NULL" reset at the
bottom of the loop, the next iteration enters the "else if (skb)" path
and calls ixgbevf_add_rx_frag() on the freed skb, dereferencing
skb_shinfo(skb)->nr_frags - a use-after-free in NAPI softirq context.
The sibling driver iavf already handles this correctly by nulling the
pointer before continuing. Apply the same pattern here.
I do not have ixgbevf hardware; the bug was found by static analysis
(scan_drop_continue_loops.py + semgrep drop_continue_in_loop, multi-tool
corroboration with the highest score in the scan). The UAF was confirmed
under KASAN by loading a test module that reproduces the exact code
pattern (alloc skb, kfree_skb, then read skb_shinfo(skb)->nr_frags):
QEMU emulates igb (82576) but not ixgbe (82599), and the igbvf VF
driver does not include the VEPA source pruning path, so a full
end-to-end reproduction with emulated hardware was not possible.
Fixes: bad17234ba70 ("ixgbevf: Change receive model to use double buffered page based receives") Cc: stable@vger.kernel.org Signed-off-by: Michael Bommarito <michael.bommarito@gmail.com> Reviewed-by: Simon Horman <horms@kernel.org> Tested-by: Rafal Romanowski <rafal.romanowski@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com> Link: https://patch.msgid.link/20260515182419.1597859-8-anthony.l.nguyen@intel.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Grzegorz Nitka [Fri, 15 May 2026 18:24:13 +0000 (11:24 -0700)]
ice: restore PTP Rx timestamp config after ethtool set-channels
When ethtool -L changes queue counts, ice_vsi_recfg_qs() closes and
rebuilds the VSI, reallocating Rx rings. The newly allocated rings have
ptp_rx cleared, so RX hardware timestamps are no longer attached to skb
until hwtstamp configuration is applied again.
Restore timestamp mode after ice_vsi_open() in the queue reconfiguration
path, matching reset/rebuild behavior and ensuring newly rebuilt Rx rings
have PTP RX timestamping re-enabled.
Testing hints:
- run ptp4l application in client synchronization mode:
ptp4l -i ethX -m -s
- run PTP traffic
- change queue number on ethX netdev interface:
ethtool -L ethX combined new_queue_size
- observe ptp4l output
- expected result: no "received DELAY_REQ without timestamp" messages
Fixes: 77a781155a65 ("ice: enable receive hardware timestamping") Cc: stable@vger.kernel.org Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Signed-off-by: Grzegorz Nitka <grzegorz.nitka@intel.com> Reviewed-by: Simon Horman <horms@kernel.org> Tested-by: Alexander Nowlin <alexander.nowlin@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com> Link: https://patch.msgid.link/20260515182419.1597859-7-anthony.l.nguyen@intel.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Grzegorz Nitka [Fri, 15 May 2026 18:24:12 +0000 (11:24 -0700)]
ice: ptp: use primary NAC semaphore on E825
For E825 2xNAC configurations, PTP semaphore operations must hit the
primary NAC register block so both sides coordinate on the same lock.
Commit e2193f9f9ec9 ("ice: enable timesync operation on 2xNAC E825
devices") updated other primary-only PTP register accesses to
use the primary NAC on non-primary functions, but left ice_ptp_lock()
and ice_ptp_unlock() operating on the local NAC. As a result, secondary
NAC PTP paths can take a different semaphore than the primary side.
Select the primary hardware in ice_ptp_lock() and ice_ptp_unlock() when
the current function is not primary, keeping semaphore operations
symmetric and consistent with the rest of the 2xNAC PTP register access
path.
Fixes: e2193f9f9ec9 ("ice: enable timesync operation on 2xNAC E825 devices") Reviewed-by: Arkadiusz Kubalewski <Arkadiusz.kubalewski@intel.com> Signed-off-by: Grzegorz Nitka <grzegorz.nitka@intel.com> Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Tested-by: Alexander Nowlin <alexander.nowlin@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com> Link: https://patch.msgid.link/20260515182419.1597859-6-anthony.l.nguyen@intel.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Grzegorz Nitka [Fri, 15 May 2026 18:24:11 +0000 (11:24 -0700)]
ice: ptp: serialize E825 PHY timer start with PTP lock
ice_start_phy_timer_eth56g() programs TIMETUS registers and issues
INIT_INCVAL without holding the global PTP semaphore.
This allows concurrent PTP command paths to interleave with PHY timer
start, which can make the sequence fail and leave timer initialization
inconsistent.
Take the PTP lock around TIMETUS registers programming and INIT_INCVAL
command execution, and make sure the lock is released on all error paths.
Keep the subsequent sync step outside of this critical section, since
ice_sync_phy_timer_eth56g() takes the same semaphore internally.
Fixes: 7cab44f1c35f ("ice: Introduce ETH56G PHY model for E825C products") Reviewed-by: Arkadiusz Kubalewski <Arkadiusz.kubalewski@intel.com> Signed-off-by: Grzegorz Nitka <grzegorz.nitka@intel.com> Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Tested-by: Alexander Nowlin <alexander.nowlin@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com> Link: https://patch.msgid.link/20260515182419.1597859-5-anthony.l.nguyen@intel.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Marcin Szycik [Fri, 15 May 2026 18:24:10 +0000 (11:24 -0700)]
ice: fix setting promisc mode while adding VID filter
There are at least two paths through which VSI promiscuous mode can be
independently configured via ice_fltr_set_vsi_promisc():
- ice_vlan_rx_add_vid() (netdev op)
- ice_service_task() -> ... -> ice_set_promisc()
Both paths may try to program promiscuous mode concurrently. One such
scenario is:
1. Add ice netdev to bond
2. Add the bond netdev to bridge
3. ice netdev enters allmulticast mode (IFF_ALLMULTI)
4. Service task programs promisc mode filter
5. Bridge -> bond calls ice_vlan_rx_add_vid()
Crucially, ice_vlan_rx_add_vid() fails if ice_fltr_set_vsi_promisc()
returns any error, including -EEXIST. This causes VLAN filtering setup
to fail on the bond interface. ice_set_promisc() already handles -EEXIST
correctly.
Fix by adding the same -EEXIST check to ice_vlan_rx_add_vid(): if the
promisc filter is already programmed, continue without returning error.
Fixes: 1273f89578f2 ("ice: Fix broken IFF_ALLMULTI handling") Cc: stable@vger.kernel.org Signed-off-by: Marcin Szycik <marcin.szycik@intel.com> Signed-off-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Reviewed-by: Simon Horman <horms@kernel.org> Tested-by: Rinitha S <sx.rinitha@intel.com> (A Contingent worker at Intel) Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com> Link: https://patch.msgid.link/20260515182419.1597859-4-anthony.l.nguyen@intel.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
ice: fix VF queue configuration with low MTU values
The ice driver's VF queue configuration validation rejects
databuffer_size values below 1024 bytes, which prevents VFs from
using MTU values below 871 bytes.
The iavf driver calculates databuffer_size based on the MTU using:
databuffer_size = ALIGN(MTU + LIBETH_RX_LL_LEN, 128)
where LIBETH_RX_LL_LEN = 26 (ETH_HLEN + 2*VLAN_HLEN + ETH_FCS_LEN).
For MTU values below 871:
MTU 870: 870 + 26 = 896, aligned to 128 = 896 (< 1024, rejected)
MTU 871: 871 + 26 = 897, aligned to 128 = 1024 (>= 1024, accepted)
The 1024-byte minimum seems unnecessarily restrictive, because the hardware
supports databuffer_size as low as 128 bytes (the alignment boundary),
which should allow MTU values down to the standard minimum of 68 bytes.
I haven't found the reason why the limit was configured in the commit 9c7dd7566d18 ("ice: add validation in OP_CONFIG_VSI_QUEUES VF message"), so
with no more information and since it is working, change the minimum
databuffer_size validation from 1024 to 128 bytes to allow standard low
MTU values while still preventing invalid configurations.
Fixes: 9c7dd7566d18 ("ice: add validation in OP_CONFIG_VSI_QUEUES VF message")
cc: stable@vger.kernel.org Signed-off-by: Jose Ignacio Tornos Martinez <jtornosm@redhat.com> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Reviewed-by: Michal Swiatkowski <michal.swiatkowski@linux.intel.com> Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de> Tested-by: Rafal Romanowski <rafal.romanowski@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com> Link: https://patch.msgid.link/20260515182419.1597859-3-anthony.l.nguyen@intel.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Jacob Keller [Fri, 15 May 2026 18:24:08 +0000 (11:24 -0700)]
ice: fix locking around wait_event_interruptible_locked_irq
Commit 50327223a8bb ("ice: add lock to protect low latency interface")
introduced a wait queue used to protect the low latency timer interface.
The queue is used with the wait_event_interruptible_locked_irq macro, which
unlocks the wait queue lock while sleeping. The irq variant uses
spin_lock_irq and spin_unlock_irq to manage this. The wait queue lock was
previously locked using spin_lock_irqsave. This difference in lock variants
could lead to issues, since wait_event would unlock the wait queue and
restore interrupts while sleeping.
The ice_read_phy_tstamp_ll_e810() function is ultimately called through
ice_read_phy_tstamp, which is called from ice_ptp_process_tx_tstamp or
ice_ptp_clear_unexpected_tx_ready. The former is called through the
miscellaneous IRQ thread function, while the latter is called from the
service task work queue thread. Neither of these functions has interrupts
disabled, so use spin_lock_irq instead of spin_lock_irqsave.
Fixes: 50327223a8bb ("ice: add lock to protect low latency interface") Cc: stable@vger.kernel.org Reported-by: Jakub Kicinski <kuba@kernel.org> Closes: https://lore.kernel.org/netdev/20250109181823.77f44c69@kernel.org/ Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Signed-off-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Reviewed-by: Simon Horman <horms@kernel.org> Tested-by: Rinitha S <sx.rinitha@intel.com> (A Contingent worker at Intel) Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com> Link: https://patch.msgid.link/20260515182419.1597859-2-anthony.l.nguyen@intel.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Rex Fu [Mon, 18 May 2026 10:00:40 +0000 (18:00 +0800)]
ARM: dts: aspeed: anacapa: Correct SGPIO names for monitoring
Update several Anacapa SGPIO line names to match the existing platform
hardware design and the signal names consumed by userspace monitoring.
The previous names did not match the actual Anacapa SGPIO usage. Some
lines were named as CPU or CPU power-good signals, but they are wired
and used on Anacapa for EDSFF presence, EDSFF power-good, boot EDSFF
presence, and thermal-trip assertion monitoring.
The left-side EDSFF slots are numbered as EDSFF0 and EDSFF1 to match
the platform slot numbering used by userspace. The thermtrip names are
also updated to describe the asserted condition monitored by userspace
instead of the raw active-low signal names.
This is a naming correction for the existing Anacapa hardware design.
There is no new board revision or underlying hardware change involved.
[arj: Tweak capitalisation in commit subject, rewrap paragraph]
====================
bpf: Follow-up fixes for BPF syscall common attributes
Address sashiko reviews for BPF syscall common attributes series.
1. The tailing padding bytes in struct bpf_common_attr should be
checked. [1]
2. There was a concurrent regression in syscall.c::map_create(). [2]
3. OPTS_VALID() was missing to validate the nested struct bpf_log_opts
in libbpf. [3]
4. The token_fd should be -1 to avoid a valid token fd in test. [4]
A test is added to verify the fix #1.
The fix #2 is hard to be verified by test. So, I decide not to add a test
for it to avoid over-engineering.
Decide not to add a test for fix #3 to avoid over-engineering, as the
fix looks really simple.
Leon Hwang [Mon, 18 May 2026 14:54:45 +0000 (22:54 +0800)]
selftests/bpf: Use -1 as token_fd in map create failure test
Because 0xFF can be an open BPF token fd in the test runner that will fail
test_invalid_token_fd(), change token_fd from 0xFF to -1 to avoid such
test failure.
Leon Hwang [Mon, 18 May 2026 14:54:44 +0000 (22:54 +0800)]
libbpf: Add OPTS_VALID() for log_opts in bpf_map_create
There should be an OPTS_VALID() check for log_opts before extracting its
fields.
If no such OPTS_VALID() check and an application compiled against a future
libbpf header passes a log_opts with new, non-zero fields to libbpf.so,
those fields will be ignored silently.
====================
net: devmem: support devmem with netkit devices
This series enables TCP devmem TX through netkit devices.
Netkit now supports queue leasing. A physical NIC's RX queue can be
leased to a netkit guest interface inside a container namespace. This
gives the container a devmem-capable data path on the RX side (bind-rx,
etc...). On the TX side, the container process binds to its netkit guest
interface and sends traffic that netkit redirects (via BPF or ip
forwarding) to the physical NIC for DMA.
Two things in the existing devmem TX path prevent this from working:
1. validate_xmit_unreadable_skb() requires dev->netmem_tx before it will
forward a dmabuf-backed (unreadable) skb. This protects skbs from
landing on devices that don't have the IOMMU mappings for the backing
dmabuf or that don't speak netmem. Netkit, however, does not support
DMA, doesn't attempt to read unreadable skb pages and so doesn't
break netmem (it is pure skb routing and redirection). It is
functionally capable of routing unreadable skbs, but there is no way
for the TX validation pathway to distinguish between a device that
will actually attempt DMA-ing the skb and another device
(like netkit) that does not DMA but also does not break
netmem.
2. bind_tx_doit uses the bound device as the DMA device. When the user
binds devmem TX to the netkit guest, the bind handler attempts to
create DMA mappings against netkit, which has no DMA capability and
no IOMMU mappings.
This series solves these problems as follows:
1. Extend netmem_tx to two bits, assigned to one of three values:
NETMEM_TX_NONE - netmem not supported
NETMEM_TX_DMA - netmem supported and performs DMA
NETMEM_TX_NO_DMA - netmem supported, but does not DMA
With these bits, phys devices can set NETMEM_TX_DMA and devices like
netkit set NETMEM_TX_NO_DMA. The validation TX path ensures that any
DMA-capable netdev exactly matches the bound device, guaranteeing the
correct mapping of the bound dmabuf. The validation TX path also
allows devices with NETMEM_TX_NO_DMA to pass, knowing these devices
will not misuse netmem or run into IOMMU faults. After redirection or
routing and the skb finally makes its way through the stack to a
physical device's TX path, the above NETMEM_TX_DMA check is performed
again to guarantee the device has the appropriate binding/mappings.
2. On TX bind, the bind handler recognizes NETMEM_TX_NO_DMA devices and
finds the phys TX device and binds to that instead. For the netkit
case, if it has been leased a queue from a DMA-capable device
already, then the bind action is performed on the DMA-capable device
instead and the dmabuf is mapped correctly.
====================
Bobby Eshleman [Thu, 14 May 2026 17:22:35 +0000 (10:22 -0700)]
selftests: drv-net: add netkit devmem tests
Add nk_devmem.py with four tests for TCP devmem through a netkit device.
These tests are just duplicates of the original devmem tests, with some
adjusted parameters such as telling ncdevmem to avoid device setup
(since it only has access to netkit, not a phys device).
Each test uses NetDrvContEnv with primary_rx_redirect=True to set up the
BPF redirect program on the primary netkit interface, then calls a
shared run_*() helper which probes for devmem support and configures
the NIC (HDS, RSS, queue lease) before driving the test. NIC state is
restored per-test via defer() callbacks registered inside the helper.
Bobby Eshleman [Thu, 14 May 2026 17:22:34 +0000 (10:22 -0700)]
selftests: drv-net: add primary_rx_redirect support to NetDrvContEnv
When sending from a namespace that has access to a netkit device with a
leased queue, the nk primary in the host namespace needs to redirect its
RX to the physical device. This patch adds that redirection bpf program
and teaches the harness to install it.
Add primary_rx_redirect=False parameter to NetDrvContEnv.__init__().
When enabled, _attach_primary_rx_redirect_bpf() attaches a new BPF TC
program (nk_primary_rx_redirect.bpf.c) to the primary (host-side) netkit
interface. The program redirects non-ICMPv6 IPv6 packets to the physical
NIC via bpf_redirect_neigh(), with the physical ifindex configured via
the .bss map. ICMPv6 is left on the host's netkit primary so IPv6
neighbor discovery still work locally.
Extract _find_bss_map_id() from _attach_bpf() into a reusable helper so
other BPF attachment methods can use it.
Bobby Eshleman [Thu, 14 May 2026 17:22:33 +0000 (10:22 -0700)]
selftests: drv-net: refactor devmem command builders into lib module
Adding netkit-based devmem tests is a straight-forward copy of devmem
test commands plus some args for the nk cases, so this patch breaks out
these command builders into helpers used by both.
Though we tried to avoid libraries to avoid increasing the barrier of
entry/complexity (see selftests/drivers/net/README.md, section "Avoid
libraries and frameworks"), factoring out these functions seemed like
the lesser of two evils in this case of using the same commands, just
with slightly different args per environment.
I experimented with just having all of the tests in the same file to
avoid having helpers in a library file, but because ksft_run() is
limited to a single call per file, and the new tests will require
different environments (NetDrvContEnv/NetDrvEpEnv), it would have been
necessary to have each test set up its own environment instead of
sharing one for the entire ksft_run() run. This came at the cost of
ballooning the test time (from under 5s to 30s on my test system), so to
strike a balance these tests were placed in separate files so they could
keep a shared environment across a single ksft_run() run shared across
all tests using the same env type (introduced in subsequent patches).
The helpers work transparently with both plain and netkit environments
by inspecting cfg for netkit-specific attributes (netns, nk_queue,
etc...).
Bobby Eshleman [Thu, 14 May 2026 17:22:32 +0000 (10:22 -0700)]
selftests: drv-net: make attr _nk_guest_ifname public
Subsequent patches will use the _nk_guest_ifname as a public attr for
setting up devmem. Rename to nk_guest_ifname to avoid angering the
linter about the '_' prefix being used for a non-private attr.
Bobby Eshleman [Thu, 14 May 2026 17:22:31 +0000 (10:22 -0700)]
selftests: drv-net: ncdevmem: add -n flag to skip NIC configuration
Add a -n (skip_config) flag that causes ncdevmem to skip NIC
configuration when operating as an RX server. When -n is passed,
ncdevmem skips configuring header split, RSS, and flow steering, as well
as their teardown on exit.
This allows ksft tests to pre-configure the NIC in the host namespace
before launching ncdevmem in the guest namespace. This is needed for
netkit devmem tests where the test harness namespace has direct access
to the NIC and the ncdevmem namespace does not.
Bobby Eshleman [Thu, 14 May 2026 17:22:30 +0000 (10:22 -0700)]
net: devmem: support TX over NETMEM_TX_NO_DMA devices
When a netkit virtual device leases queues from a physical NIC, devmem
TX bindings created on the netkit device must still result in the dmabuf
being mapped for dma by the physical device. This patch accomplishes
this by teaching the bind handler to search for the underlying
DMA-capable device by looking it up via leased rx queues. The function
netdev_find_netmem_tx_dev(), used for finding the underlying DMA-capable
device, can be extended to support other non-netkit NETMEM_TX_NO_DMA
devices in the future if needed.
Additionally, this patch extends validate_xmit_unreadable_skb() to
support the netkit case, where the skb is validated twice: once on the
netkit guest device and again on the physical NIC after BPF redirect or
ip forwarding.
Bobby Eshleman [Thu, 14 May 2026 17:22:29 +0000 (10:22 -0700)]
net: netkit: declare NETMEM_TX_NO_DMA mode
Some virtual devices like netkit (or ifb) never DMA and never touch frag
contents, they just forward the skb to another device. They are unable
to forward unreadable skbs, however, because they fail to pass TX
validation checks on dev->netmem_tx. The existing two-state
NETMEM_TX_NONE / NETMEM_TX_DMA doesn't give the TX validator enough
information to differentiate devices that will attempt DMA on the
unreadable skb from those that will simply route it untouched.
Add a third mode to the enum so drivers can indicate 1) if they have
netmem TX support, and 2) if they do, whether they are DMA-capable:
NETMEM_TX_NO_DMA - pass-through, device never DMAs
Widen dev->netmem_tx from a 1-bit field to 2 bits to fit the new value,
and declare netkit as NETMEM_TX_NO_DMA. Devmem TX support over these
devices comes in a follow-up patch.
Bobby Eshleman [Thu, 14 May 2026 17:22:28 +0000 (10:22 -0700)]
net: convert netmem_tx flag to enum
Devices that support netmem TX previously set dev->netmem_tx = true.
This was checked in validate_xmit_unreadable_skb() to drop unreadable
skbs (skbs with dmabuf-backed frags) before they reach drivers that
would mishandle them or devices that would not have the iommu mappings
for them.
A subsequent patch will introduce a third state for virtual devices
that forward unreadable skbs without ever performing DMA on them. To
prepare for that, convert the boolean dev->netmem_tx into an enum:
NETMEM_TX_NONE - no netmem TX support (drop unreadable skbs)
NETMEM_TX_DMA - full support, device does DMA
Update the existing NIC drivers (bnxt, gve, mlx5, fbnic) and the
validators in net/core to use the new enum. No functional change.
====================
net/mlx5e: simplify and optimize napi poll flow
This series simplifies the mlx5e napi poll flow and reduces branching in
hot paths by leveraging existing dependencies between channel features.
Patch 1 avoids passing the full channel object to kTLS RX code paths
when only the async ICOSQ is needed, and slightly optimizes the common
flow in the pending resync handling logic.
Patch 2 further reduces branches in napi poll by relying on established
feature dependencies between XDP, async ICOSQ, XSK, and kTLS RX state.
====================
Tariq Toukan [Thu, 14 May 2026 11:10:37 +0000 (14:10 +0300)]
net/mlx5e: Reduce branches in napi poll
Reduce the number of branches in napi poll, based on the following list
of dependencies:
1. xsk_open=t only if c->xdp and c->async_icosq.
2. c->xdpsq only if c->xdp.
3. c->xdp implies c->async_icosq.
4. ktls_rx_was_enabled implies c->async_icosq.
Linus Torvalds [Tue, 19 May 2026 00:55:42 +0000 (17:55 -0700)]
Merge tag 'perf-tools-fixes-for-v7.1-2026-05-18' of git://git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools
Pull perf-tools fixes
"An usual sync-up for the header files and related code:
- copy headers that are used for perf trace syscall beautifier
- update the beautifier scripts according to the changes
- don't show differences in the headers by default"
* tag 'perf-tools-fixes-for-v7.1-2026-05-18' of git://git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools:
perf trace: Update beautifier script for clone flags
perf trace: Add beautifier script for fsmount flags
perf build: Add make check-headers target
perf trace: Sync uapi/linux/sched.h with the kernel source
perf trace: Sync uapi/linux/mount.h with the kernel source
perf trace: Sync uapi/linux/fs.h with the kernel source
perf trace: Sync linux/socket.h with the kernel source
David Howells [Mon, 18 May 2026 21:13:09 +0000 (22:13 +0100)]
cifs: Fix undefined variables
Fix a couple of undefined variables introduced by the patch to fix tearing
on ->remote_i_size and ->zero_point. For some reason, make W=1 with gcc
doesn't give undefined variable warnings (but clang does).
Fixes: 2c8f4742bb76 ("netfs: Fix potential for tearing in ->remote_i_size and ->zero_point") Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202605031459.eX5UbO3K-lkp@intel.com/ Closes: https://lore.kernel.org/oe-kbuild-all/202605021450.ca5QGqLH-lkp@intel.com/
cc: Steve French <sfrench@samba.org>
cc: Paulo Alcantara <pc@manguebit.org>
cc: Matthew Wilcox <willy@infradead.org>
cc: Christian Brauner <brauner@kernel.org>
cc: linux-cifs@vger.kernel.org
cc: netfs@lists.linux.dev
cc: linux-fsdevel@vger.kernel.org Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Costa Shulyupin [Fri, 15 May 2026 18:45:25 +0000 (21:45 +0300)]
include: Remove unused ks8851_mll.h
The last user was removed in commit 72628da6d634 ("net: ks8851:
Remove ks8851_mll.c") which consolidated the driver into a
common implementation. No file includes this header.
Jakub Kicinski [Mon, 18 May 2026 23:59:29 +0000 (16:59 -0700)]
Merge tag 'nf-26-05-16' of git://git.kernel.org/pub/scm/linux/kernel/git/netfilter/nf
Pablo Neira Ayuso says:
====================
Netfilter/IPVS fixes for net
The following patchset contains Netfilter/IPVS fixes for net:
1) Fix small race windows in nf_ct_helper_log() when accessing helper,
from Florian Westphal.
2) Fix potential infinite loop and race conditions in IPVS caused by
frequent user-triggered service table changes, from Julia Anastasov.
3) Fix a race condition when dumping ipsets for restore,
from Jozsef Kadlecsik.
4) Fix inner transport offset in IPv6 in nft_inner when extension
headers come before the layer 4 transport header, from Yizhou Zhao.
5) Fix incorrect iteration over IPv4 ranges in several hash set types,
from Nan Li.
6) Fix incorrect order when restoring BH in nft_inner_restore_tun_ctx(),
from Florian Westphal.
7) Validate option array from ip6t_hbh checkpath() to fix an off-by-one
access, from Zhengchuan Liang.
8) Fix race condition between ipset list -terse and concurrent updates,
from Jozsef Kadlecisk.
9) Fix race condition when inserting elements into a hash bucket, also
from Jozsef.
10) Annotate access to first free slot in hashtable, from Jozsef Kadlecsik.
11) Ensure sufficient headroom in br_netfilter neigh transmission,
from Lorenzo Bianconi.
12) Hold reference on skb->dev in nfqueue exit path, bridge local input
is speciall since skb->dev != state->indev, allowing for net_device
to go away while packet is sitting in nfqueue. From Haoze Xie.
* tag 'nf-26-05-16' of git://git.kernel.org/pub/scm/linux/kernel/git/netfilter/nf:
netfilter: nf_queue: hold bridge skb->dev while queued
netfilter: br_netfilter: Reallocate headroom if necessary in neigh_hh_bridge()
netfilter: ipset: annotate "pos" for concurrent readers/writers
netfilter: ipset: Fix data race between add and dump in all hash types
netfilter: ipset: Fix data race between add and list header in all hash types
netfilter: ip6t_hbh: reject oversized option lists
netfilter: nft_inner: release local_lock before re-enabling softirqs
netfilter: ipset: stop hash:* range iteration at end
netfilter: nft_inner: Fix IPv6 inner_thoff desync
netfilter: ipset: fix a potential dump-destroy race
ipvs: avoid possible loop in ip_vs_dst_event on resizing
netfilter: nf_conntrack_helper: fix possible null deref during error log
====================
DIBS support (DIBS) [N/m/y/?]
intra-OS shortcut with dibs loopback (DIBS_LO) [N/y/?]
Clarify the DIBS prompt by expanding the acronym.
Capitalize the first character of the DIBS_LO prompt.
While at it, join the first two lines of the DIBS help text into a real
sentence.
arch/x86/include/asm/device.h is identical to
include/asm-generic/device.h, and therefore the x86-specific version
is unnecessary. Remove it.
[ dhansen: Minor note: It looks like if asm/foo.h does not exist that
the build system generates one that does a #include
<asm-generic/foo.h>. Thus, all that needs to be done is
remove the arch-specific one. ]
projects / thirdparty / kernel / linux.git / log
