John Garry [Wed, 15 Apr 2026 15:53:58 +0000 (15:53 +0000)]
nvme-multipath: put module reference when delayed removal work is canceled
The delayed disk removal work is canceled when a NS (re)appears. However,
we do not put the module reference grabbed in nvme_mpath_remove_disk(), so
fix that.
Reviewed-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Nilay Shroff <nilay@linux.ibm.com> Reviewed-by: Chaitanya Kulkarni <kch@nvidia.com> Signed-off-by: John Garry <john.g.garry@oracle.com> Signed-off-by: Keith Busch <kbusch@kernel.org>
Daniel Wagner [Wed, 8 Apr 2026 16:19:56 +0000 (18:19 +0200)]
nvme: expose TLS mode
It is not possible to determine the active TLS mode from the
presence or absence of sysfs attributes like tls_key,
tls_configured_key, or dhchap_secret.
With the introduction of the concat mode and optional DH-CHAP
authentication, different configurations can result in identical
sysfs state. This makes user space detection unreliable.
Expose the TLS mode explicitly to allow user space to
unambiguously identify the active configuration and avoid
fragile heuristics in nvme-cli.
Reviewed-by: Chris Leech <cleech@redhat.com> Reviewed-by: Hannes Reinecke <hare@suse.de> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Daniel Wagner <wagi@kernel.org> Signed-off-by: Keith Busch <kbusch@kernel.org>
nvme-apple: drop invalid put of admin queue reference count
Commit 03b3bcd319b3 ("nvme: fix admin request_queue lifetime") moved the
admin queue reference ->put call into nvme_free_ctrl() - a controller
device release callback performed for every nvme driver doing
nvme_init_ctrl().
nvme-apple sets refcount of the admin queue to 1 at allocation during the
probe function and then puts it twice now:
Note that there is a commit 941f7298c70c ("nvme-apple: remove an extra
queue reference") which intended to drop taking an extra admin queue
reference. Looks like at that moment it accidentally fixed a refcount
leak, which existed since the driver's introduction. There were two ->get
calls at driver's probe function and a single ->put inside
apple_nvme_free_ctrl().
However now after commit 03b3bcd319b3 ("nvme: fix admin request_queue
lifetime") the refcount is imbalanced again. Fix it by removing extra
->put call from apple_nvme_free_ctrl(). anv->dev and ctrl->dev point to
the same device, so use ctrl->dev directly for simplification. Compile
tested only.
Found by Linux Verification Center (linuxtesting.org).
In the declaration of the structure "core_quirks[]", in the comment
referred to the devices "Kioxia CD6-V Series / HPE PE8030", the
parameter "default_ps_max_latency_us" is reported in a wrong way:
nvme_core.default_ps_max_latency=0
The correct form is, instead:
nvme_core.default_ps_max_latency_us=0
Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Flavio Suligoi <f.suligoi@asem.it> Signed-off-by: Keith Busch <kbusch@kernel.org>
nvmet: avoid recursive nvmet-wq flush in nvmet_ctrl_free
nvmet_tcp_release_queue_work() runs on nvmet-wq and can drop the
final controller reference through nvmet_cq_put(). If that triggers
nvmet_ctrl_free(), the teardown path flushes ctrl->async_event_work on
the same nvmet-wq.
Previously Scheduled by :-
nvmet_add_async_event
queue_work(nvmet_wq, &ctrl->async_event_work);
This trips lockdep with a possible recursive locking warning.
[ 5223.015876] run blktests nvme/003 at 2026-04-07 20:53:55
[ 5223.061801] loop0: detected capacity change from 0 to 2097152
[ 5223.072206] nvmet: adding nsid 1 to subsystem blktests-subsystem-1
[ 5223.088368] nvmet_tcp: enabling port 0 (127.0.0.1:4420)
[ 5223.126086] nvmet: Created discovery controller 1 for subsystem nqn.2014-08.org.nvmexpress.discovery for NQN nqn.2014-08.org.nvmexpress:uuid:0f01fb42-9f7f-4856-b0b3-51e60b8de349.
[ 5223.128453] nvme nvme1: new ctrl: NQN "nqn.2014-08.org.nvmexpress.discovery", addr 127.0.0.1:4420, hostnqn: nqn.2014-08.org.nvmexpress:uuid:0f01fb42-9f7f-4856-b0b3-51e60b8de349
[ 5233.199447] nvme nvme1: Removing ctrl: NQN "nqn.2014-08.org.nvmexpress.discovery"
[ 5233.227718] ============================================
[ 5233.231283] WARNING: possible recursive locking detected
[ 5233.234696] 7.0.0-rc3nvme+ #20 Tainted: G O N
[ 5233.238434] --------------------------------------------
[ 5233.241852] kworker/u192:6/2413 is trying to acquire lock:
[ 5233.245429] ffff888111632548 ((wq_completion)nvmet-wq){+.+.}-{0:0}, at: touch_wq_lockdep_map+0x26/0x90
[ 5233.251438]
but task is already holding lock:
[ 5233.255254] ffff888111632548 ((wq_completion)nvmet-wq){+.+.}-{0:0}, at: process_one_work+0x5cc/0x6e0
[ 5233.261125]
other info that might help us debug this:
[ 5233.265333] Possible unsafe locking scenario:
There is also no need to flush async_event_work from controller
teardown. The admin queue teardown already fails outstanding AER
requests before the final controller put :-
The controller has already been removed from the subsystem list before
nvmet_ctrl_free() quiesces outstanding work.
Replace flush_work() with cancel_work_sync() so a pending
async_event_work item is canceled and a running instance is waited on
without recursing into the same workqueue.
Fixes: 06406d81a2d7 ("nvmet: cancel fatal error and flush async work before free controller") Cc: stable@vger.kernel.org Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Chaitanya Kulkarni <kch@nvidia.com> Signed-off-by: Keith Busch <kbusch@kernel.org>
extract-cert: Wrap key_pass with '#ifdef USE_PKCS11_ENGINE'
A recent strengthening of -Wunused-but-set-variable (enabled with -Wall)
in clang under a new subwarning, -Wunused-but-set-global, points out an
unused static global variable in certs/extract-cert.c:
certs/extract-cert.c:46:20: error: variable 'key_pass' set but not used [-Werror,-Wunused-but-set-global]
46 | static const char *key_pass;
| ^
After commit 558bdc45dfb2 ("sign-file,extract-cert: use pkcs11 provider
for OPENSSL MAJOR >= 3"), key_pass is only used with the OpenSSL engine
API, not the new provider API. Wrap key_pass's declaration and
assignment with '#ifdef USE_PKCS11_ENGINE' so that it is only included
with its use to clear up the warning. While this is a little uglier than
just marking key_pass with the unused attribute, this will make it
easier to clean up all code associated with the use of the engine API if
it were ever removed in the future. While in the area, use a tab for
the key_pass assignment line to match the rest of the file.
Mark Brown [Thu, 16 Apr 2026 19:03:59 +0000 (20:03 +0100)]
selftests: Fix runner.sh for non-bash shells
Commit 2964f6b816c2 ("selftests: Use ktap helpers for runner.sh") added a
number of bashisms and updated the interpreter specified for the script to
be /bin/bash to reflect this. Unfortunately this does not actually achieve
anything in production since the main way runner.sh is invoked is from the
top level run_kselftest.sh which sources it rather than running it as a
separate script and specifies the shell as /bin/sh. This means that on
systems where /bin/sh is not bash (such as Debian where /bin/sh defaults to
being dash) we see failures:
4. In runner.sh run_one(), get the return value and use ktap helpers for
all pass/fail reporting. This allows counting pass/fail numbers in the
main process.
which uses a bash array to track all the subtests being run. Convert this
to use a simple flat variable instead.
Mark Brown [Thu, 16 Apr 2026 19:03:58 +0000 (20:03 +0100)]
selftests: Fix runner.sh busybox support
Commit 2964f6b816c2 ("selftests: Use ktap helpers for runner.sh") added an
import of ktap_helper.sh to runner.sh in order to standardise on these for
output formatting. Rather than build on the existing requirement for the
user to supply BASE_DIR to find the helpers it uses some magic which
features a use of "readlink -e". Unfortunately the -e option is a GNU
extension and is not available in at least busybox, meaning that runner.sh
starts failing:
./run_kselftest.sh: 5: ./kselftest/runner.sh: Bad substitution
./run_kselftest.sh: 5: .: cannot open ./ktap_helpers.sh: No such file
Fix this by using the already required BASE_DIR to locate the helper
library.
Mark Brown [Thu, 16 Apr 2026 13:19:24 +0000 (14:19 +0100)]
selftests: Deescalate error reporting
Commit 7e47389142b8 ("selftests: Preserve subtarget failures in
all/install") updated the propagation of errors from indivdual kselftest
targets to be similar to that seen with FORCE_TARGETS. While it would
be really nice to be in a position to do this currently it is premature
to do this as the default behaviour.
At present we default to trying to build all selftests but a combination
of code quality issues and build dependencies mean that it is almost
certain that at least one of them will fail to build (for example,
several depend on clang so don't work in a GCC container) and a top
level failure in the kselftest build reported. Further, the resulting
failures mean that the install target does not run at all so any build
problem is escallated to a complete failure to produce a kselftest
tarball so CI systems that run into issues loose all selftests coverage.
This has been causing disruption to a range of CI systems including
KernelCI, mine and Arm's internal one.
Revert the commit, users who need this behaviour should be able to use
FORCE_TARGETS for the time being. At present users that do this (such
as linux-next) are most likely building a subset of targets known to
succeed in their environments.
Shuicheng Lin [Wed, 15 Apr 2026 22:54:28 +0000 (22:54 +0000)]
drm/xe/eustall: Fix drm_dev_put called before stream disable in close
In xe_eu_stall_stream_close(), drm_dev_put() is called before the
stream is disabled and its resources are freed. If this drops the
last reference, the device structures could be freed while the
subsequent cleanup code still accesses them, leading to a
use-after-free.
Fix this by moving drm_dev_put() after all device accesses are
complete. This matches the ordering in xe_oa_release().
Fixes: 9a0b11d4cf3b ("drm/xe/eustall: Add support to init, enable and disable EU stall sampling") Cc: Harish Chegondi <harish.chegondi@intel.com> Assisted-by: Claude:claude-opus-4.6 Signed-off-by: Shuicheng Lin <shuicheng.lin@intel.com> Reviewed-by: Harish Chegondi <harish.chegondi@intel.com> Link: https://patch.msgid.link/20260415225428.3399934-1-shuicheng.lin@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Philipp Stanner [Wed, 15 Apr 2026 14:49:56 +0000 (16:49 +0200)]
drm/sched: Make drm_sched_entity_kill() a public function
Some drivers do not care on teardown whether the last jobs pending in an
entity are actually executed before teardown completed. For such
scenarios, drm_sched_entity_flush() is not the ideal function since it's
intended to wait for jobs to complete.
Make drm_sched_entity_kill() public for that use-case and update the
documentation.
Thomas Gleixner [Tue, 14 Apr 2026 20:55:01 +0000 (22:55 +0200)]
clockevents: Add missing resets of the next_event_forced flag
The prevention mechanism against timer interrupt starvation missed to reset
the next_event_forced flag in a couple of places:
- When the clock event state changes. That can cause the flag to be
stale over a shutdown/startup sequence
- When a non-forced event is armed, which then prevents rearming before
that event. If that event is far out in the future this will cause
missed timer interrupts.
- In the suspend wakeup handler.
That led to stalls which have been reported by several people.
Add the missing resets, which fixes the problems for the reporters.
Jonathan Cavitt [Mon, 2 Feb 2026 21:47:10 +0000 (21:47 +0000)]
drm/colorop: Check if getting curve_1d_type default succeeds
Static analysis issue:
In all other uses of the function drm_object_property_get_default_value,
the return value of the function is checked before the output is saved to
the relevant object parameter. Though likely unnecessary given the
execution path involved, keep the behavior consistent across uses and only
set colorop_state->curve_1d_type in __drm_colorop_state_reset if
drm_object_property_get_default_value succeeds.
Jonathan Cavitt [Fri, 30 Jan 2026 19:19:54 +0000 (19:19 +0000)]
drm/gpuvm: Do not prepare NULL objects
Statis analysis issue:
drm_gpuvm_prepare_range issues an exec_object_prepare call to all
drm_gem_objects mapped between addr and addr + range. However, it is
possible (albeit very unlikely) that the objects found through
drm_gpuvm_for_each_va_range (as connected to va->gem) are NULL, as seen
in other functions such as drm_gpuva_link and drm_gpuva_unlink_defer.
Do not prepare NULL objects.
Fixes: 50c1a36f594b ("drm/gpuvm: track/lock/validate external/evicted objects") Signed-off-by: Jonathan Cavitt <jonathan.cavitt@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Krzysztof Karas <krzysztof.karas@intel.com> Link: https://patch.msgid.link/20260130191953.61718-2-jonathan.cavitt@intel.com
sched_ext: scx_qmap: replace FIFO queue maps with arena-backed lists
Arena simplifies verification and allows more natural programming.
Convert scx_qmap to arena as preparation for further sub-sched work.
Replace the five BPF_MAP_TYPE_QUEUE maps with doubly-linked lists in
arena, threaded through task_ctx. Each queue is a struct qmap_fifo with
head/tail pointers and its own per-queue bpf_res_spin_lock.
qmap_dequeue() now properly removes tasks from the queue instead of
leaving stale entries for dispatch to skip.
v2:
- Remove duplicate QMAP_TOUCH_ARENA() in qmap_dump_task (Andrea).
- Update file-level description for arena-backed lists (Andrea).
Signed-off-by: Tejun Heo <tj@kernel.org> Reviewed-by: Andrea Righi <arighi@nvidia.com> Reviewed-by: Emil Tsalapatis <emil@etsalapatis.com>
sched_ext: scx_qmap: move task_ctx into a BPF arena slab
Arena simplifies verification and allows more natural programming.
Convert scx_qmap to arena as preparation for further sub-sched work.
Allocate per-task context from an arena slab instead of storing it
directly in task_storage. task_ctx_stor now holds an arena pointer to
the task's slab entry. Free entries form a singly-linked list protected
by bpf_res_spin_lock; slab exhaustion triggers scx_bpf_error().
The slab size is configurable via the new -N option (default 16384).
Also add bpf_res_spin_lock/unlock declarations to common.bpf.h.
Scheduling logic unchanged.
v2: Add task_ctx_t typedef for struct task_ctx __arena (Emil).
Signed-off-by: Tejun Heo <tj@kernel.org> Reviewed-by: Andrea Righi <arighi@nvidia.com> Reviewed-by: Emil Tsalapatis <emil@etsalapatis.com>
sched_ext: scx_qmap: move globals and cpu_ctx into a BPF arena map
Arena simplifies verification and allows more natural programming.
Convert scx_qmap to arena as preparation for further sub-sched work.
Move scheduler state from BSS globals and a percpu array map
into a single BPF arena map. A shared struct qmap_arena is declared as
an __arena global so BPF accesses it directly and userspace reaches it
through skel->arena->qa.
Scheduling logic unchanged; only memory backing changes.
v2: Drop "mutable" from comments.
Signed-off-by: Tejun Heo <tj@kernel.org> Reviewed-by: Andrea Righi <arighi@nvidia.com> Reviewed-by: Emil Tsalapatis <emil@etsalapatis.com>
Ville Syrjälä [Wed, 15 Apr 2026 21:04:11 +0000 (00:04 +0300)]
drm/i915/reset: Disable execlist per-engine reset for display reset tests
The display reset only happens from the full reset path. We must
therefore force execlist submission to always take the full reset
path and not the per-engine reset path. Currently the display
reset tests are in fact not testing display resets at all on
platforms using execlist submission. Ring submission and GuC
submission always take the full path anyway.
Also disable the engine reset inside __intel_gt_set_wedged() so
that we simulate the intel_gt_gpu_reset_clobbers_display() behavior
as closely as possible also when taking the full wedge path.
The slight race between the separate intel_display_reset_test()
calls in the overall reset path is harmless. kms_busy will keep
the modparam fixed during the test, and even if someone were to
fiddle with the modparam manually nothing bad should happen if
the calls return different values.
Expose the number of display resets performed in a new
"display_reset_count" debugfs file. kms_busy can use this to
confirm that the kernel actually took the full display reset path.
v2: Give the file an "intel_" namespace (Jani)
Cc: Jouni Högander <jouni.hogander@intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Testcase: igt/kms_busy/*-with-reset Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260415210411.24750-7-ville.syrjala@linux.intel.com
Stephen Boyd [Thu, 16 Apr 2026 17:07:47 +0000 (10:07 -0700)]
Merge branches 'clk-fixes', 'clk-renesas', 'clk-rpi', 'clk-eswin' and 'clk-mediatek' into clk-next
- ESWIN eic700 SoC clk support
- Econet EN751221 SoC clock/reset support
* clk-fixes:
clk: spacemit: ccu_mix: fix inverted condition in ccu_mix_trigger_fc()
clk: microchip: mpfs-ccc: fix out of bounds access during output registration
clk: qcom: dispcc-sm8450: use RCG2 ops for DPTX1 AUX clock source
* clk-renesas:
clk: renesas: Add support for RZ/G3L SoC
dt-bindings: clock: renesas,rzg2l-cpg: Document RZ/G3L SoC
clk: renesas: rzg2l: Re-enable critical module clocks during resume
clk: renesas: rzg2l: Add rzg2l_mod_clock_init_mstop_helper()
clk: renesas: rzg2l: Add helper for mod clock enable/disable
clk: renesas: r9a0{7g04[34],8g045}: Add critical reset entries
clk: renesas: rzg2l: Add support for critical resets
clk: renesas: r9a09g056: Remove entries for WDT{0,2,3}
clk: renesas: r9a06g032: Enable watchdog reset sources
clk: renesas: cpg-mssr: Use struct_size() helper
clk: renesas: r9a09g047: Add PCIe clocks and reset
clk: renesas: r9a09g057: Add PCIe clocks and reset
clk: renesas: r9a09g056: Add PCIe clocks and reset
clk: renesas: r9a09g047: Add entries for the RSPIs
clk: renesas: r9a09g056: Add clock and reset entries for RTC
clk: renesas: r9a09g057: Remove entries for WDT{0,2,3}
clk: renesas: r9a09g056: Fix ordering of module clocks array
clk: renesas: r9a09g057: Fix ordering of module clocks array
Ville Syrjälä [Wed, 15 Apr 2026 21:04:09 +0000 (00:04 +0300)]
drm/xe/display: Add init_clock_gating.h stubs
Add static inline stubs for init_clock_gating.h functions
so that we don't need ifdefs in the actual code. We already
have one in intel_display_power.c, and now I need to bring
over intel_display_reset.c.
Ville Syrjälä [Wed, 15 Apr 2026 21:04:08 +0000 (00:04 +0300)]
drm/i915/reset: Move pending_fb_pin handling to i915
Only i915 uses the pending_fb_pin counter to potentially whack
the GPU harder if the display gets nuked during a GPU reset.
Move the atomic counter into the i915 specific bits of code, so
that we don't need to worry about on the display side.
For some reason the overlay code kept the pending_fb_pin counter
elevated for longer than just for the pin, but from now on it'll
just cover the actual pinning part.
Ville Syrjälä [Wed, 15 Apr 2026 21:04:07 +0000 (00:04 +0300)]
drm/i915/reset: Reorganize display reset code
Stop returning the "is there a display?" status from
intel_display_reset_prepare(). I plan to move the pending_fb_pin
into the i915 code, so I need to make that determination already
before intel_display_reset_prepare() is called. Add a new
intel_display_reset_supported() function for that.
Felix Gu [Thu, 16 Apr 2026 13:37:23 +0000 (21:37 +0800)]
accel/amdxdna: Fix memory leak in amdxdna_iommu_alloc()
In amdxdna_iommu_alloc(), if iommu_map() fails after successfully
allocating both iova and cpu_addr, the code jumps to free_iova
which only frees the iova, leaking the allocated pages.
Max Zhen [Wed, 15 Apr 2026 17:11:39 +0000 (10:11 -0700)]
accel/amdxdna: Add hardware scheduler time quantum support
Add support for configuring the hardware scheduler time quantum to
improve fairness across concurrent contexts.
The scheduler enforces a fixed time slice per context, preventing
long-running workloads from monopolizing the device and allowing
other contexts to make forward progress.
The default time quantum is 30ms and can be configured via the
time_quantum_ms module parameter.
Shuicheng Lin [Tue, 14 Apr 2026 22:54:33 +0000 (22:54 +0000)]
drm/xe: Fix type and parameter name mismatches in kernel-doc references
Fix kernel-doc references that point to wrong type or parameter names:
- xe_guc_capture_types.h: register_data_type ->
capture_register_data_type to match actual enum name
- xe_oa_types.h: enum @drm_xe_oa_format_type ->
enum drm_xe_oa_format_type (spurious '@' before type name)
- xe_pt_walk.h: @sizes -> @shifts to match actual struct member,
@start -> @addr to match actual parameter name,
page.table. -> page table. (typo)
Shuicheng Lin [Tue, 14 Apr 2026 22:54:32 +0000 (22:54 +0000)]
drm/xe: Fix kernel-doc comment syntax issues in header files
Fix doc comment formatting that does not conform to kernel-doc syntax
rules:
- xe_guc_relay_types.h: Add missing space after '/**' in member doc
comment (/**@lock -> /** @lock)
- xe_oa_types.h: Fix struct documentation to use proper kernel-doc
format (/** @xe_oa_buffer: -> /** struct xe_oa_buffer -)
- xe_pagefault_types.h: Use dash instead of colon as separator in
struct doc (struct xe_pagefault_queue: -> struct xe_pagefault_queue -)
- xe_pt_walk.h: Use dash instead of colon as separator in function
docs (xe_pt_num_entries: -> xe_pt_num_entries -,
xe_pt_offset: -> xe_pt_offset -)
Shuicheng Lin [Tue, 14 Apr 2026 22:54:31 +0000 (22:54 +0000)]
drm/xe: Add missing '@' prefix to kernel-doc member tags
Add the required '@' prefix to member documentation tags that were
missing it. Without the prefix, kernel-doc does not associate the
comment with the struct member.
Shuicheng Lin [Tue, 14 Apr 2026 22:54:30 +0000 (22:54 +0000)]
drm/xe: Fix stale and mismatched kernel-doc member tags in header files
Fix kernel-doc member tags that do not match the actual struct member
names, which would cause warnings with scripts/kernel-doc or produce
incorrect documentation:
Merge tag 'v7.1-rc-part1-smbdirect-fixes' of git://git.samba.org/ksmbd
Pull smbdirect updates from Steve French:
"Move smbdirect server and client code to common directory:
- temporary use of smbdirect_all_c_files.c to allow micro steps
- factor out common functions into a smbdirect.ko.
- convert cifs.ko to use smbdirect.ko
- convert ksmbd.ko to use smbdirect.ko
- let smbdirect.ko use global workqueues
- move ib_client logic from ksmbd.ko into smbdirect.ko
- remove smbdirect_all_c_files.c hack again
- some locking and teardown related fixes on top"
* tag 'v7.1-rc-part1-smbdirect-fixes' of git://git.samba.org/ksmbd: (145 commits)
smb: smbdirect: let smbdirect_connection_deregister_mr_io unlock while waiting
smb: smbdirect: fix the logic in smbdirect_socket_destroy_sync() without an error
smb: smbdirect: fix copyright header of smbdirect.h
smb: smbdirect: change smbdirect_socket_parameters.{initiator_depth,responder_resources} to __u16
smb: smbdirect: remove unused SMBDIRECT_USE_INLINE_C_FILES logic
smb: server: no longer use smbdirect_socket_set_custom_workqueue()
smb: client: no longer use smbdirect_socket_set_custom_workqueue()
smb: smbdirect: introduce global workqueues
smb: smbdirect: prepare use of dedicated workqueues for different steps
smb: smbdirect: remove unused smbdirect_connection_mr_io_recovery_work()
smb: smbdirect: wrap rdma_disconnect() in rdma_[un]lock_handler()
smb: server: make use of smbdirect_netdev_rdma_capable_mode_type()
smb: smbdirect: introduce smbdirect_netdev_rdma_capable_mode_type()
smb: server: make use of smbdirect.ko
smb: server: remove unused ksmbd_transport_ops.prepare()
smb: server: make use of smbdirect_socket_{listen,accept}()
smb: server: only use public smbdirect functions
smb: server: make use of smbdirect_socket_create_accepting()/smbdirect_socket_release()
smb: server: make use of smbdirect_{socket_init_accepting,connection_wait_for_connected}()
smb: server: make use of smbdirect_connection_send_iter() and related functions
...
Merge tag 'livepatching-for-7.1' of git://git.kernel.org/pub/scm/linux/kernel/git/livepatching/livepatching
Pull livepatching updates from Petr Mladek:
- Add two new selftests
* tag 'livepatching-for-7.1' of git://git.kernel.org/pub/scm/linux/kernel/git/livepatching/livepatching:
selftests/livepatch: add test for module function patching
selftests: livepatch: test-ftrace: livepatch a traced function
Merge tag 'efi-next-for-v7.1' of git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi
Pull EFI updates from Ard Biesheuvel:
"Again not a busy cycle for EFI, just some minor tweaks and bug fixes:
- Enable boot graphics resource table (BGRT) on Xen/x86
- Correct a misguided assumption in the memory attributes table
sanity check
- Start tagging efi_mem_reserve()'d regions as MEMBLOCK_RSRV_KERN
- Some other minor fixes and cleanups"
* tag 'efi-next-for-v7.1' of git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi:
efi/capsule-loader: fix incorrect sizeof in phys array reallocation
efi: Tag memblock reservations of boot services regions as RSRV_KERN
memblock: Permit existing reserved regions to be marked RSRV_KERN
efi/memattr: Fix thinko in table size sanity check
efi: libstub: fix type of fdt 32 and 64bit variables
efi: Drop unused efi_range_is_wc() function
efi: Enable BGRT loading under Xen
efi: make efi_mem_type() and efi_mem_attributes() work on Xen PV
- Conversions to const struct class in support of class_create()
deprecation (Jori Koolstra)
- Improve selftest compiler compatibility by avoiding initializer on
variable-length array (Manish Honap)
- Define new uAPI for drivers supporting migration to advise user-
space of new initial data for reducing target startup latency.
Implemented for mlx5 vfio-pci variant driver (Yishai Hadas)
- Enable vfio selftests on aarch64, not just cross-compiles reporting
arm64 (Ted Logan)
- Update vfio selftest driver support to include additional DSA devices
(Yi Lai)
- Unconditionally include debugfs root pointer in vfio device struct,
avoiding a build failure seen in hisi_acc variant driver without
debugfs otherwise (Arnd Bergmann)
- Add support for the s390 ISM (Internal Shared Memory) device via a
new variant driver. The device is unique in the size of its BAR space
(256TiB) and lack of mmap support (Julian Ruess)
- Enforce that vfio-pci drivers implement a name in their ops structure
for use in sequestering SR-IOV VFs (Alex Williamson)
- Prune leftover group notifier code (Paolo Bonzini)
- Fix Xe vfio-pci variant driver to avoid migration support as a
dependency in the reset path and missing release call (Michał
Winiarski)
* tag 'vfio-v7.1-rc1' of https://github.com/awilliam/linux-vfio: (23 commits)
vfio/xe: Add a missing vfio_pci_core_release_dev()
vfio/xe: Reorganize the init to decouple migration from reset
vfio: remove dead notifier code
vfio/pci: Require vfio_device_ops.name
MAINTAINERS: add VFIO ISM PCI DRIVER section
vfio/ism: Implement vfio_pci driver for ISM devices
vfio/pci: Rename vfio_config_do_rw() to vfio_pci_config_rw_single() and export it
vfio: unhide vdev->debug_root
vfio/qat: add support for Intel QAT 420xx VFs
vfio: selftests: Support DMR and GNR-D DSA devices
vfio: selftests: Build tests on aarch64
vfio/mlx5: Add REINIT support to VFIO_MIG_GET_PRECOPY_INFO
vfio/mlx5: consider inflight SAVE during PRE_COPY
net/mlx5: Add IFC bits for migration state
vfio: Adapt drivers to use the core helper vfio_check_precopy_ioctl
vfio: Add support for VFIO_DEVICE_FEATURE_MIG_PRECOPY_INFOv2
vfio: Define uAPI for re-init initial bytes during the PRE_COPY phase
vfio: selftests: Fix VLA initialisation in vfio_pci_irq_set()
vfio: uapi: fix comment typo
vfio: mdev: replace mtty_dev->vd_class with a const struct class
...
Melissa Wen [Wed, 18 Mar 2026 16:27:11 +0000 (13:27 -0300)]
drm/drm_atomic: duplicate colorop states if plane color pipeline in use
For suspend/resume to work correctly, do for colorop state the same we
do for plane/crtc/connector states: duplicate the state of colorops in a
color pipeline if it's in use by a given plane when suspending and
restore cached colorop states when resuming. While at it, prevent
unused-variable warning when using for_each_new_colorop_in_stage here.
Fixes: 2afc3184f3b3 ("drm/plane: Add COLOR PIPELINE property") Reviewed-by: Harry Wentland <harry.wentland@amd.com> Reviewed-by: Alex Hung <alex.hung@amd.com> Reviewed-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com> Signed-off-by: Melissa Wen <mwen@igalia.com> Link: https://patch.msgid.link/20260318163629.300627-1-mwen@igalia.com Signed-off-by: Melissa Wen <melissa.srw@gmail.com>
Ville Syrjälä [Wed, 15 Apr 2026 21:04:05 +0000 (00:04 +0300)]
drm/i915: Clear i915->display when no longer valid
Don't leave a stale i915->display pointer hanging around after
the display driver has been torn down. Apparently the gt code
calls into the reset codepaths after this, and if the display
pointer is still around we may try to access freed memory.
The whole teardown sequence here seems rather suspect. Why is
display done first and then everything else via the managed
release? Who the heck knows. Someone really needs to dig into
this stuff and figure out the proper init/cleanup sequence for
both i915 (real and mock) and xe...
Cc: Jani Nikula <jani.nikula@intel.com> Cc: Jouni Högander <jouni.hogander@intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260415210411.24750-2-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Tomas Glozar [Thu, 16 Apr 2026 11:59:42 +0000 (13:59 +0200)]
tracing/osnoise: Add option to align tlat threads
Add an option called TIMERLAT_ALIGN to osnoise/options, together with a
corresponding setting osnoise/timerlat_align_us.
This option sets the alignment of wakeup times between different
timerlat threads, similarly to cyclictest's -A/--aligned option. If
TIMERLAT_ALIGN is set, the first thread that reaches the first cycle
records its first wake-up time. Each following thread sets its first
wake-up time to a fixed offset from the recorded time, and increments
it by the same offset.
Example:
osnoise/timerlat_period is set to 1000, osnoise/timerlat_align_us is
set to 20. There are four threads, on CPUs 1 to 4.
- CPU 4 enters first cycle first. The current time is 20000us, so
the wake-up of the first cycle is set to 21000us. This time is recorded.
- CPU 2 enter first cycle next. It reads the recorded time, increments
it to 21020us, and uses this value as its own wake-up time for the first
cycle.
- CPU 3 enters first cycle next. It reads the recorded time, increments
it to 21040 us, and uses the value as its own wake-up time.
- CPU 1 proceeds analogically.
In each next cycle, the wake-up time (called "absolute period" in
timerlat code) is incremented by the (relative) period of 1000us. Thus,
the wake-ups in the following cycles (provided the times are reached and
not in the past) will be as follows:
CPU 1 CPU 2 CPU 3 CPU 4
21080us 21020us 21040us 21000us
22080us 22020us 22040us 22000us
... ... ... ...
Even if any cycle is skipped due to e.g. the first cycle calculation
happening later, the alignment stays in place.
Cc: Masami Hiramatsu <mhiramat@kernel.org> Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> Cc: John Kacur <jkacur@redhat.com> Cc: Luis Goncalves <lgoncalv@redhat.com> Cc: Costa Shulyupin <costa.shul@redhat.com> Link: https://patch.msgid.link/20260416115942.544032-1-tglozar@redhat.com Signed-off-by: Tomas Glozar <tglozar@redhat.com> Reviewed-by: Wander Lairson Costa <wander@redhat.com> Reviewed-by: Crystal Wood <crwood@redhat.com> Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
Daniel Borkmann [Thu, 16 Apr 2026 12:27:19 +0000 (14:27 +0200)]
bpf: Fix precedence bug in convert_bpf_ld_abs alignment check
Fix an operator precedence issue in convert_bpf_ld_abs() where the
expression offset + ip_align % size evaluates as offset + (ip_align % size)
due to % having higher precedence than +. That latter evaluation does
not make any sense. The intended check is (offset + ip_align) % size == 0
to verify that the packet load offset is properly aligned for direct
access.
With NET_IP_ALIGN == 2, the bug causes the inline fast-path for direct
packet loads to almost never be taken on !CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS
platforms. This forces nearly all cBPF BPF_LD_ABS packet loads through
the bpf_skb_load_helper slow path on the affected archs.
====================
emit ENDBR/BTI instructions for indirect
On architectures with CFI protection enabled that require landing pad
instructions at indirect jump targets, such as x86 with CET/IBT enabled
and arm64 with BTI enabled, kernel panics when an indirect jump lands on
a target without landing pad. Therefore, the JIT must emit landing pad
instructions for indirect jump targets.
The verifier already recognizes which instructions are indirect jump
targets during the verification phase. So we can store this information
in env->insn_aux_data and pass it to the JIT as new parameter, allowing
the JIT to consult env->insn_aux_data to determine which instructions are
indirect jump targets.
During JIT, constants blinding is performed. It rewrites the private copy
of instructions for the JITed program, but it does not adjust the global
env->insn_aux_data array. As a result, after constants blinding, the
instruction indexes used by JIT may no longer match the indexes in
env->insn_aux_data, so the JIT can not use env->insn_aux_data directly.
To avoid this mismatch, and given that all existing arch-specific JITs
already implement constants blinding with largely duplicated code, move
constants blinding from JIT to generic code.
v15:
- Rebase and target bpf tree
- Resotre subprog_start of the fake 'exit' subprog on failure
- Fix wrong function name used in comment
v14: https://lore.kernel.org/all/cover.1776062885.git.xukuohai@hotmail.com/
- Rebase
- Fix comment style
- Fix incorrect variable and function name used in commit message
v13: https://lore.kernel.org/bpf/20260411133847.1042658-1-xukuohai@huaweicloud.com
- Use vmalloc to allocate memory for insn_aux_data copies to match with vfree
- Do not free the copied memory of insn_aux_data when restoring from failure
- Code cleanup
v12: https://lore.kernel.org/bpf/20260403132811.753894-1-xukuohai@huaweicloud.com
- Restore env->insn_aux_data on JIT failure
- Fix incorrect error code sign (-EFAULT vs EFAULT)
- Fix incorrect prog used in the restore path
v11: https://lore.kernel.org/bpf/20260403090915.473493-1-xukuohai@huaweicloud.com
- Restore env->subprog_info after jit_subprogs() fails
- Clear prog->jit_requested and prog->blinding_requested on failure
- Use the actual env->insn_aux_data size in clear_insn_aux_data() on failure
v10: https://lore.kernel.org/bpf/20260324122052.342751-1-xukuohai@huaweicloud.com
- Fix the incorrect call_imm restore in jit_subprogs
- Define a dummy void version of bpf_jit_prog_release_other and
bpf_patch_insn_data when the corresponding config is not set
- Remove the unnecessary #ifdef in x86_64 JIT (Leon Hwang)
v9: https://lore.kernel.org/bpf/20260312170255.3427799-1-xukuohai@huaweicloud.com
- Make constant blinding available for classic bpf (Eduard)
- Clear prog->bpf_func, prog->jited ... on the error path of extra pass (Eduard)
- Fix spelling errors and remove unused parameter (Anton Protopopov)
v8: https://lore.kernel.org/bpf/20260309140044.2652538-1-xukuohai@huaweicloud.com
- Define void bpf_jit_blind_constants() function when CONFIG_BPF_JIT is not set
- Move indirect_target fixup for insn patching from bpf_jit_blind_constants()
to adjust_insn_aux_data()
v7: https://lore.kernel.org/bpf/20260307103949.2340104-1-xukuohai@huaweicloud.com
- Move constants blinding logic back to bpf/core.c
- Compute ip address before switch statement in x86 JIT
- Clear JIT state from error path on arm64 and loongarch
v6: https://lore.kernel.org/bpf/20260306102329.2056216-1-xukuohai@huaweicloud.com
- Move constants blinding from JIT to verifier
- Move call to bpf_prog_select_runtime from bpf_prog_load to verifier
v5: https://lore.kernel.org/bpf/20260302102726.1126019-1-xukuohai@huaweicloud.com
- Switch to pass env to JIT directly to get rid of copying private insn_aux_data for
each prog
v4: https://lore.kernel.org/all/20260114093914.2403982-1-xukuohai@huaweicloud.com
- Switch to the approach proposed by Eduard, using insn_aux_data to identify indirect
jump targets, and emit ENDBR on x86
v3: https://lore.kernel.org/bpf/20251227081033.240336-1-xukuohai@huaweicloud.com
- Get rid of unnecessary enum definition (Yonghong Song, Anton Protopopov)
v2: https://lore.kernel.org/bpf/20251223085447.139301-1-xukuohai@huaweicloud.com
- Exclude instruction arrays not used for indirect jumps (Anton Protopopov)
On CPUs that support CET/IBT, the indirect jump selftest triggers
a kernel panic because the indirect jump targets lack ENDBR
instructions.
To fix it, emit an ENDBR instruction to each indirect jump target. Since
the ENDBR instruction shifts the position of original jited instructions,
fix the instruction address calculation wherever the addresses are used.
For reference, below is a sample panic log.
Missing ENDBR: bpf_prog_2e5f1c71c13ac3e0_big_jump_table+0x97/0xe1
------------[ cut here ]------------
kernel BUG at arch/x86/kernel/cet.c:133!
Oops: invalid opcode: 0000 [#1] SMP NOPTI
Introduce helper bpf_insn_is_indirect_target to check whether a BPF
instruction is an indirect jump target.
Since the verifier knows which instructions are indirect jump targets,
add a new flag indirect_target to struct bpf_insn_aux_data to mark
them. The verifier sets this flag when verifying an indirect jump target
instruction, and the helper checks the flag to determine whether an
instruction is an indirect jump target.
Reviewed-by: Anton Protopopov <a.s.protopopov@gmail.com> #v8 Reviewed-by: Emil Tsalapatis <emil@etsalapatis.com> #v12 Signed-off-by: Xu Kuohai <xukuohai@huawei.com> Link: https://lore.kernel.org/r/20260416064341.151802-4-xukuohai@huaweicloud.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Pass bpf_verifier_env to bpf_int_jit_compile(). The follow-up patch will
use env->insn_aux_data in the JIT stage to detect indirect jump targets.
Since bpf_prog_select_runtime() can be called by cbpf and lib/test_bpf.c
code without verifier, introduce helper __bpf_prog_select_runtime()
to accept the env parameter.
Remove the call to bpf_prog_select_runtime() in bpf_prog_load(), and
switch to call __bpf_prog_select_runtime() in the verifier, with env
variable passed. The original bpf_prog_select_runtime() is preserved for
cbpf and lib/test_bpf.c, where env is NULL.
Now all constants blinding calls are moved into the verifier, except
the cbpf and lib/test_bpf.c cases. The instructions arrays are adjusted
by bpf_patch_insn_data() function for normal cases, so there is no need
to call adjust_insn_arrays() in bpf_jit_blind_constants(). Remove it.
bpf: Move constants blinding out of arch-specific JITs
During the JIT stage, constants blinding rewrites instructions but only
rewrites the private instruction copy of the JITed subprog, leaving the
global env->prog->insnsi and env->insn_aux_data untouched. This causes a
mismatch between subprog instructions and the global state, making it
difficult to use the global data in the JIT.
To avoid this mismatch, and given that all arch-specific JITs already
support constants blinding, move it to the generic verifier code, and
switch to rewrite the global env->prog->insnsi with the global states
adjusted, as other rewrites in the verifier do.
This removes the constants blinding calls in each JIT, which are largely
duplicated code across architectures.
Since constants blinding is only required for JIT, and there are two
JIT entry functions, jit_subprogs() for BPF programs with multiple
subprogs and bpf_prog_select_runtime() for programs with no subprogs,
move the constants blinding invocation into these two functions.
In the verifier path, bpf_patch_insn_data() is used to keep global
verifier auxiliary data in sync with patched instructions. A key
question is whether this global auxiliary data should be restored
on the failure path.
For prog->aux->poke_tab, it is only used by JIT or only meaningful after
JIT succeeds, so it does not need to be restored on the failure path.
For env->insn_array_maps, when JIT fails, programs using insn arrays
are rejected by bpf_insn_array_ready() due to missing JIT addresses.
Hence, env->insn_array_maps is only meaningful for JIT and does not need
to be restored.
For subprog_info, if jit_subprogs fails and CONFIG_BPF_JIT_ALWAYS_ON
is not enabled, kernel falls back to interpreter. In this case,
env->subprog_info is used to determine subprogram stack depth. So it
must be restored on failure.
For env->insn_aux_data, it is freed by clear_insn_aux_data() at the
end of bpf_check(). Before freeing, clear_insn_aux_data() loops over
env->insn_aux_data to release jump targets recorded in it. The loop
uses env->prog->len as the array length, but this length no longer
matches the actual size of the adjusted env->insn_aux_data array after
constants blinding.
To address it, a simple approach is to keep insn_aux_data as adjusted
after failure, since it will be freed shortly, and record its actual size
for the loop in clear_insn_aux_data(). But since clear_insn_aux_data()
uses the same index to loop over both env->prog->insnsi and env->insn_aux_data,
this approach results in incorrect index for the insnsi array. So an
alternative approach is adopted: clone the original env->insn_aux_data
before blinding and restore it after failure, similar to env->prog.
For classic BPF programs, constants blinding works as before since it
is still invoked from bpf_prog_select_runtime().
Dudu Lu [Mon, 13 Apr 2026 13:14:09 +0000 (21:14 +0800)]
vsock/virtio: fix accept queue count leak on transport mismatch
virtio_transport_recv_listen() calls sk_acceptq_added() before
vsock_assign_transport(). If vsock_assign_transport() fails or
selects a different transport, the error path returns without
calling sk_acceptq_removed(), permanently incrementing
sk_ack_backlog.
After approximately backlog+1 such failures, sk_acceptq_is_full()
returns true, causing the listener to reject all new connections.
Fix by moving sk_acceptq_added() to after the transport validation,
matching the pattern used by vmci_transport and hyperv_transport.
Fixes: c0cfa2d8a788 ("vsock: add multi-transports support") Signed-off-by: Dudu Lu <phx0fer@gmail.com> Reviewed-by: Bobby Eshleman <bobbyeshleman@meta.com> Reviewed-by: Luigi Leonardi <leonardi@redhat.com> Reviewed-by: Stefano Garzarella <sgarzare@redhat.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Link: https://patch.msgid.link/20260413131409.19022-1-phx0fer@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
ASoC: es8311: Fix clock leak and check update_bits in set_bias_level()
In es8311_set_bias_level(), the return value of
snd_soc_component_update_bits() was ignored. If this fails, not only
is the VMID selection not applied, but the previously enabled mclk
is left running, leading to an unbalanced clock reference count
(clock leak).
Check the return value and ensure clk_disable_unprepare() is called on
failure to maintain proper resource management.
ASoC: es8311: Check regcache_sync() error in resume
The es8311_resume() function currently ignores the return value of
regcache_sync(). If syncing the cache fails, the function still returns
0, leaving the codec in a potentially incorrect state.
Check the return value and propagate it to the ASoC core to ensure
resume failures are properly handled.
The AM62L DSS [1] support incorrectly used the same register and
clock constraints as AM65x, but AM62L has a single video port
Fix this by adding conditional constraints that properly define the
register regions and clocks for AM62L DSS (single video port) versus
other AM65x variants (dual video port).
[1]: Section 12.7 (Display Subsystem and Peripherals)
Link : https://www.ti.com/lit/pdf/sprujb4
Fixes: cb8d4323302c ("dt-bindings: display: ti,am65x-dss: Add support for AM62L DSS") Cc: stable@vger.kernel.org Signed-off-by: Swamil Jain <s-jain1@ti.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://patch.msgid.link/20260415110409.2577633-1-s-jain1@ti.com Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
Marek Vasut [Sat, 4 Apr 2026 03:42:50 +0000 (05:42 +0200)]
dt-bindings: display: simple: Move Innolux G156HCE-L01 panel to dual-link
The Innolux G156HCE-L01 15.6" 1920x1080 24bpp dual-link LVDS TFT panel
is exactly that, dual-link LVDS panel. Move it into the correct schema,
which is panel-simple-lvds-dual-ports.yaml.
Marek Vasut [Sat, 4 Apr 2026 03:42:49 +0000 (05:42 +0200)]
dt-bindings: display: simple: Move AUO 21.5" FHD to dual-link
AU Optronics Corporation 21.5" FHD (1920x1080) color TFT LCD panel
is a dual-link LVDS panel. Move it into the correct schema, which is
panel-simple-lvds-dual-ports.yaml.
dt-bindings: thermal: Fix false warning with 'phandle' in trips nodes
A pattern property matching essentially anything doesn't work if there
are implicit properties such as 'phandle' which can occur on any node.
One such example popped up recently:
arch/arm64/boot/dts/qcom/sm8650-hdk.dtb: thermal-zones: gpuss0-thermal:trips:phandle: 531 is not of type 'object'
from schema $id: http://devicetree.org/schemas/thermal/thermal-zones.yaml
Instead of a pattern property, use an "additionalProperties" schema
instead which is the fallback in case of no matching property.
of: unittest: fix use-after-free in testdrv_probe()
The function testdrv_probe() retrieves the device_node from the PCI
device, applies an overlay, and then immediately calls of_node_put(dn).
This releases the reference held by the PCI core, potentially freeing
the node if the reference count drops to zero. Later, the same freed
pointer 'dn' is passed to of_platform_default_populate(), leading to a
use-after-free.
The reference to pdev->dev.of_node is owned by the device model and
should not be released by the driver. Remove the erroneous of_node_put()
to prevent premature freeing.
of: unittest: fix use-after-free in of_unittest_changeset()
The variable 'parent' is assigned the value of 'nchangeset' earlier in the
function, meaning both point to the same struct device_node. The call to
of_node_put(nchangeset) can decrement the reference count to zero and
free the node if there are no other holders. After that, the code still
uses 'parent' to check for the presence of a property and to read a
string property, leading to a use-after-free.
Fix this by moving the of_node_put() call after the last access to
'parent', avoiding the UAF.
selftests: fib_nexthops: test stale has_v4 on nexthop replace
Add test cases that exercise the scenario where an IPv6 nexthop is
replaced with an IPv4 nexthop while being part of a group. The group's
has_v4 flag must be updated so that subsequent IPv6 route additions are
properly rejected.
Two cases are covered:
1. Gateway nexthop replaced across families with an existing IPv6
route on the group (rejected by fib6_check_nh_list).
2. Blackhole nexthop replaced across families with no existing IPv6
route on the group (fib6_check_nh_list returns early) — this is
the path that triggers a NULL ptr deref without the kernel fix.
When an IPv6 nexthop is replaced with an IPv4 nexthop, the has_v4 flag
of all groups containing this nexthop is not updated. This is because
nh_group_v4_update is only called when replacing AF_INET to AF_INET6,
but the reverse direction (AF_INET6 to AF_INET) is missed.
This allows a stale has_v4=false to bypass fib6_check_nexthop, causing
IPv6 routes to be attached to groups that effectively contain only AF_INET
members. Subsequent route lookups then call nexthop_fib6_nh() which
returns NULL for the AF_INET member, leading to a NULL pointer
dereference.
Fix by calling nh_group_v4_update whenever the family changes, not just
AF_INET to AF_INET6.
Reproducer:
# AF_INET6 blackhole
ip -6 nexthop add id 1 blackhole
# group with has_v4=false
ip nexthop add id 100 group 1
# replace with AF_INET (no -6), has_v4 stays false
ip nexthop replace id 1 blackhole
# pass stale has_v4 check
ip -6 route add 2001:db8::/64 nhid 100
# panic
ping -6 2001:db8::1
fsnotify_get_mark_safe() may return false for a mark on an unrelated group,
which results in bypassing the permission check.
Fix by skipping over detached marks that are not in the current group.
CC: stable@vger.kernel.org Fixes: abc77577a669 ("fsnotify: Provide framework for dropping SRCU lock in ->handle_event") Signed-off-by: Miklos Szeredi <mszeredi@redhat.com> Link: https://patch.msgid.link/20260410144950.156160-1-mszeredi@redhat.com Signed-off-by: Jan Kara <jack@suse.cz>
Dudu Lu [Mon, 13 Apr 2026 11:00:41 +0000 (19:00 +0800)]
net/sched: sch_cake: fix NAT destination port not being updated in cake_update_flowkeys
cake_update_flowkeys() is supposed to update the flow dissector keys
with the NAT-translated addresses and ports from conntrack, so that
CAKE's per-flow fairness correctly identifies post-NAT flows as
belonging to the same connection.
For the source port, this works correctly:
keys->ports.src = port;
But for the destination port, the assignment is reversed:
port = keys->ports.dst;
This means the NAT destination port is never updated in the flow keys.
As a result, when multiple connections are NATed to the same destination,
CAKE treats them as separate flows because the original (pre-NAT)
destination ports differ. This breaks CAKE's NAT-aware flow isolation
when using the "nat" mode.
The bug was introduced in commit b0c19ed6088a ("sch_cake: Take advantage
of skb->hash where appropriate") which refactored the original direct
assignment into a compare-and-conditionally-update pattern, but wrote
the destination port update backwards.
Fix by reversing the assignment direction to match the source port
pattern.
Fixes: b0c19ed6088a ("sch_cake: Take advantage of skb->hash where appropriate") Signed-off-by: Dudu Lu <phx0fer@gmail.com> Acked-by: Toke Høiland-Jørgensen <toke@toke.dk> Link: https://patch.msgid.link/20260413110041.44704-1-phx0fer@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
net: bridge: use a stable FDB dst snapshot in RCU readers
Local FDB entries can be rewritten in place by `fdb_delete_local()`, which
updates `f->dst` to another port or to `NULL` while keeping the entry
alive. Several bridge RCU readers inspect `f->dst`, including
`br_fdb_fillbuf()` through the `brforward_read()` sysfs path.
These readers currently load `f->dst` multiple times and can therefore
observe inconsistent values across the check and later dereference.
In `br_fdb_fillbuf()`, this means a concurrent local-FDB update can change
`f->dst` after the NULL check and before the `port_no` dereference,
leading to a NULL-ptr-deref.
Fix this by taking a single `READ_ONCE()` snapshot of `f->dst` in each
affected RCU reader and using that snapshot for the rest of the access
sequence. Also publish the in-place `f->dst` updates in `fdb_delete_local()`
with `WRITE_ONCE()` so the readers and writer use matching access patterns.
Fixes: 960b589f86c7 ("bridge: Properly check if local fdb entry can be deleted in br_fdb_change_mac_address") Cc: stable@kernel.org Reported-by: Yifan Wu <yifanwucs@gmail.com> Reported-by: Juefei Pu <tomapufckgml@gmail.com> Co-developed-by: Yuan Tan <yuantan098@gmail.com> Signed-off-by: Yuan Tan <yuantan098@gmail.com> Suggested-by: Xin Liu <bird@lzu.edu.cn> Tested-by: Ren Wei <enjou1224z@gmail.com> Signed-off-by: Zhengchuan Liang <zcliangcn@gmail.com> Signed-off-by: Ren Wei <n05ec@lzu.edu.cn> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Acked-by: Nikolay Aleksandrov <razor@blackwall.org> Link: https://patch.msgid.link/6570fabb85ecadb8baaf019efe856f407711c7b9.1776043229.git.zcliangcn@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Jason Gunthorpe [Sun, 1 Mar 2026 18:57:54 +0000 (14:57 -0400)]
dma-buf: Change st-dma-fence.c to use kunit
Modernize the open coded test framework by using kunit.
Add a num_online_cpus() check to test_race_signal_callback() as the
default kunit.py runs the VM with a single CPU and this test depends on
two truly parallel kthreads. Skip it instead of hanging.
Jason Gunthorpe [Sun, 1 Mar 2026 18:57:53 +0000 (14:57 -0400)]
dma-buf: Change st-dma-resv.c to use kunit
Modernize the open coded test framework by using kunit.
The kunit tool can be used to build a kernel and run it in a VM with:
$ tools/testing/kunit/kunit.py run --build_dir build_kunit_x86_64 --arch x86_64 --kunitconfig ./drivers/dma-buf/.kunitconfig
Along with the other ways to run kunits.
To make the kunit tool work like this the DMABUF_KUNIT_TEST kconfig must
select DMA_SHARED_BUFFER to get it turned on without building a driver
using it.
Dudu Lu [Mon, 13 Apr 2026 08:53:49 +0000 (16:53 +0800)]
macvlan: fix macvlan_get_size() not reserving space for IFLA_MACVLAN_BC_CUTOFF
macvlan_get_size() does not account for IFLA_MACVLAN_BC_CUTOFF, but
macvlan_fill_info() conditionally includes it when port->bc_cutoff != 1.
This causes nla_put_s32() to fail with -EMSGSIZE when the netlink skb
runs out of space, triggering a WARN_ON in rtnetlink and preventing the
interface from being dumped.
The bug can be reproduced with:
ip link add macvlan0 link eth0 type macvlan mode bridge
ip link set macvlan0 type macvlan bc_cutoff 0
ip -d link show macvlan0 # fails with -EMSGSIZE
The bc_cutoff feature was added in commit 954d1fa1ac93 ("macvlan: Add
netlink attribute for broadcast cutoff"), which added the nla_put_s32()
call in macvlan_fill_info() but missed adding the corresponding
nla_total_size(4) in macvlan_get_size(). A follow-up commit 55cef78c244d ("macvlan: add forgotten nla_policy for
IFLA_MACVLAN_BC_CUTOFF") fixed the missing nla_policy entry but still
did not fix the size calculation.
Fixes: 954d1fa1ac93 ("macvlan: Add netlink attribute for broadcast cutoff") Signed-off-by: Dudu Lu <phx0fer@gmail.com> Reviewed-by: Vadim Fedorenko <vadim.fedorenko@linux.dev> Reviewed-by: Eric Dumazet <edumazet@google.com> Link: https://patch.msgid.link/20260413085349.73977-1-phx0fer@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Paul Moses [Wed, 1 Apr 2026 08:07:49 +0000 (03:07 -0500)]
crypto: ccp - copy IV using skcipher ivsize
AF_ALG rfc3686-ctr-aes-ccp requests pass an 8-byte IV to the driver.
ccp_aes_complete() restores AES_BLOCK_SIZE bytes into the caller's IV
buffer while RFC3686 skciphers expose an 8-byte IV, so the restore
overruns the provided buffer.
Use crypto_skcipher_ivsize() to copy only the algorithm's IV length.
Fixes: 2b789435d7f3 ("crypto: ccp - CCP AES crypto API support") Signed-off-by: Paul Moses <p@1g4.org> Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
crypto: ccp: Don't attempt to copy ID to userspace if PSP command failed
When retrieving the ID for the CPU, don't attempt to copy the ID blob to
userspace if the firmware command failed. If the failure was due to an
invalid length, i.e. the userspace buffer+length was too small, copying
the number of bytes _firmware_ requires will overflow the kernel-allocated
buffer and leak data to userspace.
BUG: KASAN: slab-out-of-bounds in instrument_copy_to_user ../include/linux/instrumented.h:129 [inline]
BUG: KASAN: slab-out-of-bounds in _inline_copy_to_user ../include/linux/uaccess.h:205 [inline]
BUG: KASAN: slab-out-of-bounds in _copy_to_user+0x66/0xa0 ../lib/usercopy.c:26
Read of size 64 at addr ffff8881867f5960 by task syz.0.906/24388
WARN if the driver says the command succeeded, but the firmware error code
says otherwise, as __sev_do_cmd_locked() is expected to return -EIO on any
firwmware error.
Reported-by: Alexander Potapenko <glider@google.com> Reported-by: Sebastian Alba Vives <sebasjosue84@gmail.com> Fixes: d6112ea0cb34 ("crypto: ccp - introduce SEV_GET_ID2 command") Cc: stable@vger.kernel.org Signed-off-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
crypto: ccp: Don't attempt to copy PDH cert to userspace if PSP command failed
When retrieving the PDH cert, don't attempt to copy the blobs to userspace
if the firmware command failed. If the failure was due to an invalid
length, i.e. the userspace buffer+length was too small, copying the number
of bytes _firmware_ requires will overflow the kernel-allocated buffer and
leak data to userspace.
BUG: KASAN: slab-out-of-bounds in instrument_copy_to_user ../include/linux/instrumented.h:129 [inline]
BUG: KASAN: slab-out-of-bounds in _inline_copy_to_user ../include/linux/uaccess.h:205 [inline]
BUG: KASAN: slab-out-of-bounds in _copy_to_user+0x66/0xa0 ../lib/usercopy.c:26
Read of size 2084 at addr ffff8885c4ab8aa0 by task syz.0.186/21033
WARN if the driver says the command succeeded, but the firmware error code
says otherwise, as __sev_do_cmd_locked() is expected to return -EIO on any
firwmware error.
Reported-by: Alexander Potapenko <glider@google.com> Reported-by: Sebastian Alba Vives <sebasjosue84@gmail.com> Fixes: 76a2b524a4b1 ("crypto: ccp: Implement SEV_PDH_CERT_EXPORT ioctl command") Cc: stable@vger.kernel.org Signed-off-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
crypto: ccp: Don't attempt to copy CSR to userspace if PSP command failed
When retrieving the PEK CSR, don't attempt to copy the blob to userspace
if the firmware command failed. If the failure was due to an invalid
length, i.e. the userspace buffer+length was too small, copying the number
of bytes _firmware_ requires will overflow the kernel-allocated buffer and
leak data to userspace.
BUG: KASAN: slab-out-of-bounds in instrument_copy_to_user ../include/linux/instrumented.h:129 [inline]
BUG: KASAN: slab-out-of-bounds in _inline_copy_to_user ../include/linux/uaccess.h:205 [inline]
BUG: KASAN: slab-out-of-bounds in _copy_to_user+0x66/0xa0 ../lib/usercopy.c:26
Read of size 2084 at addr ffff898144612e20 by task syz.9.219/21405
WARN if the driver says the command succeeded, but the firmware error code
says otherwise, as __sev_do_cmd_locked() is expected to return -EIO on any
firwmware error.
Reported-by: Alexander Potapenko <glider@google.com> Reported-by: Sebastian Alba Vives <sebasjosue84@gmail.com> Fixes: e799035609e1 ("crypto: ccp: Implement SEV_PEK_CSR ioctl command") Cc: stable@vger.kernel.org Signed-off-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Herbert Xu [Thu, 16 Apr 2026 09:00:50 +0000 (17:00 +0800)]
crypto: pcrypt - Fix handling of MAY_BACKLOG requests
MAY_BACKLOG requests can return EBUSY. Handle them by checking
for that value and filtering out EINPROGRESS notifications.
Reported-by: Yiming Qian <yimingqian591@gmail.com> Fixes: 5a1436beec57 ("crypto: pcrypt - call the complete function on error") Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
T Pratham [Wed, 15 Apr 2026 14:36:58 +0000 (20:06 +0530)]
crypto: sa2ul - Fix AEAD fallback algorithm names
For authenc AEAD algorithms, sa2ul is trying to register very specific
-ce version as a fallback. This causes registration failure on SoCs
which do not have ARMv8-CE enabled/available. Change the fallback
algorithm from the specific driver name to generic algorithm name so
that the kernel can allocate any available fallback.
Herbert Xu [Tue, 14 Apr 2026 23:39:06 +0000 (07:39 +0800)]
crypto: authencesn - Fix src offset when decrypting in-place
The src SG list offset wasn't set properly when decrypting in-place,
fix it.
Reported-by: Wolfgang Walter <linux@stwm.de> Fixes: e02494114ebf ("crypto: authencesn - Do not place hiseq at end of dst for out-of-place decryption") Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
eip93_hmac_setkey() allocates a temporary ahash transform for
computing HMAC ipad/opad key material. The allocation uses the
driver-specific cra_driver_name (e.g. "sha256-eip93") but passes
CRYPTO_ALG_ASYNC as the mask, which excludes async algorithms.
Since the EIP93 hash algorithms are the only ones registered
under those driver names and they are inherently async, the
lookup is self-contradictory and always fails with -ENOENT.
When called from the AEAD setkey path, this failure leaves the
SA record partially initialized with zeroed digest fields. A
subsequent crypto operation then dereferences a NULL pointer in
the request context, resulting in a kernel panic:
The reported symbol eip93_aead_handle_result+0xc8c is a
resolution artifact from static functions being merged under
the nearest exported symbol. Decoding the faulting sequence:
The faulting LDR at [X26, #0x8] is loading ctx->flags
(offset 8 in eip93_hash_ctx), where ctx has been resolved
to NULL from a partially initialized or unreachable
transform context following the failed setkey.
Fix this by dropping the CRYPTO_ALG_ASYNC mask from the
crypto_alloc_ahash() call. The code already handles async
completion correctly via crypto_wait_req(), so there is no
requirement to restrict the lookup to synchronous algorithms.
Note that hashing a single 64-byte block through the hardware
is likely slower than doing it in software due to the DMA
round-trip overhead, but offloading it may still spare CPU
cycles on the slower embedded cores where this IP is found.
Fixes: 9739f5f93b78 ("crypto: eip93 - Add Inside Secure SafeXcel EIP-93 crypto engine support") Signed-off-by: Aleksander Jan Bajkowski <olek2@wp.pl>
[Detailed investigation report of this bug] Signed-off-by: Kenneth Kasilag <kenneth@kasilag.me> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Dudu Lu [Mon, 13 Apr 2026 08:49:27 +0000 (16:49 +0800)]
net/sched: act_mirred: fix wrong device for mac_header_xmit check in tcf_blockcast_redir
In tcf_blockcast_redir(), when iterating block ports to redirect
packets to multiple devices, the mac_header_xmit flag is queried
from the wrong device. The loop sends to dev_prev but queries
dev_is_mac_header_xmit(dev) — which is the NEXT device in the
iteration, not the one being sent to.
This causes tcf_mirred_to_dev() to make incorrect decisions about
whether to push or pull the MAC header. When the block contains
mixed device types (e.g., an ethernet veth and a tunnel device),
intermediate devices get the wrong mac_header_xmit flag, leading to
skb header corruption. In the worst case, skb_push_rcsum with an
incorrect mac_len can exhaust headroom and panic.
The last device in the loop is handled correctly (line 365-366 uses
dev_is_mac_header_xmit(dev_prev)), confirming this is a copy-paste
oversight for the intermediate devices.
Fix by using dev_prev instead of dev for the mac_header_xmit query,
consistent with the device actually being sent to.
Fixes: 42f39036cda8 ("net/sched: act_mirred: Allow mirred to block") Signed-off-by: Dudu Lu <phx0fer@gmail.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20260413084927.71353-1-phx0fer@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Cássio Gabriel [Wed, 15 Apr 2026 15:04:53 +0000 (12:04 -0300)]
ALSA: usb-audio: stop parsing UAC2 rates at MAX_NR_RATES
parse_uac2_sample_rate_range() caps the number of enumerated
rates at MAX_NR_RATES, but it only breaks out of the current
rate loop. A malformed UAC2 RANGE response with additional
triplets continues parsing the remaining triplets and repeatedly
prints "invalid uac2 rates" while probe still holds
register_mutex.
Stop the whole parse once the cap is reached and return the
number of rates collected so far.
Fixes: 4fa0e81b8350 ("ALSA: usb-audio: fix possible hang and overflow in parse_uac2_sample_rate_range()") Cc: stable@vger.kernel.org Reported-by: syzbot+d56178c27a4710960820@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=d56178c27a4710960820 Signed-off-by: Cássio Gabriel <cassiogabrielcontato@gmail.com> Link: https://patch.msgid.link/20260415-usb-audio-uac2-rate-cap-v1-1-5ecbafc120d8@gmail.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
ALSA: hda/intel: Move firmware loading into the probe work
The hda-intel driver uses request_firmware_nowait() for loading its
patch, and tries to continue the probe directly from the fw loader
callback. This works in principle, but it has a few drawbacks:
- The driver may be released before the firmware callback completes
- Having two ways of async probe makes the code flow unnecessarily
complex
The former issue is more severe, as it may potentially lead to a UAF,
and there is no explicit way to cancel the pending firmware worker
for now.
This patch changes the firmware loading to be performed rather in the
common probe work without *_nowait(). Then the pending work can be
easily canceled, and the code becomes more straightforward.
A nice bonus is that, by moving into the probe work, the firmware
doesn't need any longer to be cached, hence we can get rid of struct
azx.fw field, and release the firmware immediately after parsing it,
too.
fs/ntfs3: validate rec->used in journal-replay file record check
check_file_record() validates rec->total against the record size but
never validates rec->used. The do_action() journal-replay handlers read
rec->used from disk and use it to compute memmove lengths:
DeleteAttribute: memmove(attr, ..., used - asize - roff)
CreateAttribute: memmove(..., attr, used - roff)
change_attr_size: memmove(..., used - PtrOffset(rec, next))
When rec->used is smaller than the offset of a validated attribute, or
larger than the record size, these subtractions can underflow allowing
us to copy huge amounts of memory in to a 4kb buffer, generally
considered a bad idea overall.
This requires a corrupted filesystem, which isn't a threat model the
kernel really needs to worry about, but checking for such an obvious
out-of-bounds value is good to keep things robust, especially on journal
replay
Fix this up by bounding rec->used correctly.
This is much like commit b2bc7c44ed17 ("fs/ntfs3: Fix slab-out-of-bounds
read in DeleteIndexEntryRoot") which checked different values in this
same switch statement.
Changes have been introduced in Bspec regarding the Tx Swing level,
Tx pre/post coefficients. Update the Tx Swing Level and the Tx
pre/post-cursor co-effecients to incorporate these changes
drm: rcar-du: encoder: convert to of_drm_find_and_get_bridge()
of_drm_find_bridge() is deprecated. Move to its replacement
of_drm_find_and_get_bridge() which gets a bridge reference, and ensure it
is put when done.
We need to handle the two cases: when a panel_bridge is added and when it
isn't. So:
* in the 'else' case a panel_bridge is not added and bridge is found: use
of_drm_find_and_get_bridge() to get a reference to the found bridge
* in the 'then' case a panel_bridge is found using a devm function which
already takes a refcount and will put it on removal, but we need to take
another so the following code in this function always get exactly one
reference that it needs to put
In order to put the reference, add the needed drm_bridge_put() calls in the
existing cleanup function.
projects / thirdparty / linux.git / log
