]> git.ipfire.org Git - thirdparty/linux.git/log
thirdparty/linux.git
11 days agobpf: Add struct bpf_tramp_node object
Jiri Olsa [Sat, 6 Jun 2026 12:39:33 +0000 (14:39 +0200)] 
bpf: Add struct bpf_tramp_node object

Adding struct bpf_tramp_node to decouple the link out of the trampoline
attachment info.

At the moment the object for attaching bpf program to the trampoline is
'struct bpf_tramp_link':

  struct bpf_tramp_link {
       struct bpf_link link;
       struct hlist_node tramp_hlist;
       u64 cookie;
  }

The link holds the bpf_prog pointer and forces one link - one program
binding logic. In following changes we want to attach program to multiple
trampolines but we want to keep just one bpf_link object.

Splitting struct bpf_tramp_link into:

  struct bpf_tramp_link {
       struct bpf_link link;
       struct bpf_tramp_node node;
  };

  struct bpf_tramp_node {
       struct bpf_link *link;
       struct hlist_node tramp_hlist;
       u64 cookie;
  };

The 'struct bpf_tramp_link' defines standard single trampoline link
and 'struct bpf_tramp_node' is the attachment trampoline object with
pointer to the bpf_link object.

This will allow us to define link for multiple trampolines, like:

  struct bpf_tracing_multi_link {
       struct bpf_link link;
       ...
       int nodes_cnt;
       struct bpf_tracing_multi_node nodes[] __counted_by(nodes_cnt);
  };

Cc: Hengqi Chen <hengqi.chen@gmail.com>
Signed-off-by: Jiri Olsa <jolsa@kernel.org>
Link: https://lore.kernel.org/r/20260606123955.345967-9-jolsa@kernel.org
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
11 days agobpf: Add bpf_trampoline_add/remove_prog functions
Jiri Olsa [Sat, 6 Jun 2026 12:39:32 +0000 (14:39 +0200)] 
bpf: Add bpf_trampoline_add/remove_prog functions

Separate bpf_trampoline_add/remove_prog functions from
__bpf_trampoline_link/unlink functions to be able to add/remove
trampoline programs without the image being updated in following
changes. No functional change is intended.

Signed-off-by: Jiri Olsa <jolsa@kernel.org>
Link: https://lore.kernel.org/r/20260606123955.345967-8-jolsa@kernel.org
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
11 days agobpf: Move trampoline image setup into bpf_trampoline_ops callbacks
Jiri Olsa [Sat, 6 Jun 2026 12:39:31 +0000 (14:39 +0200)] 
bpf: Move trampoline image setup into bpf_trampoline_ops callbacks

Moving trampoline image setup into bpf_trampoline_ops callbacks,
so we can have different image handling for multi attachment which
is coming in following changes.

Signed-off-by: Jiri Olsa <jolsa@kernel.org>
Link: https://lore.kernel.org/r/20260606123955.345967-7-jolsa@kernel.org
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
11 days agobpf: Add struct bpf_trampoline_ops object
Jiri Olsa [Sat, 6 Jun 2026 12:39:30 +0000 (14:39 +0200)] 
bpf: Add struct bpf_trampoline_ops object

In following changes we will need to override ftrace direct attachment
behaviour. In order to do that we are adding struct bpf_trampoline_ops
object that defines callbacks for ftrace direct attachment:

   register_fentry
   unregister_fentry
   modify_fentry

The new struct bpf_trampoline_ops object is passed as an argument to
__bpf_trampoline_link/unlink_prog functions.

At the moment the default trampoline_ops is set to the current ftrace
direct attachment functions, so there's no functional change for the
current code.

Signed-off-by: Jiri Olsa <jolsa@kernel.org>
Link: https://lore.kernel.org/r/20260606123955.345967-6-jolsa@kernel.org
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
11 days agobpf: Use mutex lock pool for bpf trampolines
Jiri Olsa [Sat, 6 Jun 2026 12:39:29 +0000 (14:39 +0200)] 
bpf: Use mutex lock pool for bpf trampolines

Adding mutex lock pool that replaces bpf trampolines mutex.

For tracing_multi link coming in following changes we need to lock all
the involved trampolines during the attachment. This could mean thousands
of mutex locks, which is not convenient.

As suggested by Andrii we can replace bpf trampolines mutex with mutex
pool, where each trampoline is hash-ed to one of the locks from the pool.

It's better to lock all the pool mutexes (32 at the moment) than
thousands of them.

There is 48 (MAX_LOCK_DEPTH) lock limit allowed to be simultaneously
held by task, so we need to keep 32 mutexes (5 bits) in the pool, so
when we lock them all in following changes the lockdep won't scream.

Removing the mutex_is_locked in bpf_trampoline_put, because we removed
the mutex from bpf_trampoline.

Suggested-by: Andrii Nakryiko <andrii@kernel.org>
Signed-off-by: Jiri Olsa <jolsa@kernel.org>
Link: https://lore.kernel.org/r/20260606123955.345967-5-jolsa@kernel.org
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
11 days agoftrace: Add add_ftrace_hash_entry function
Jiri Olsa [Sat, 6 Jun 2026 12:39:28 +0000 (14:39 +0200)] 
ftrace: Add add_ftrace_hash_entry function

Renaming __add_hash_entry to add_ftrace_hash_entry and making it global,
it will be used in following changes outside ftrace.c object.

Signed-off-by: Jiri Olsa <jolsa@kernel.org>
Link: https://lore.kernel.org/r/20260606123955.345967-4-jolsa@kernel.org
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
11 days agoftrace: Add ftrace_hash_remove function
Jiri Olsa [Sat, 6 Jun 2026 12:39:27 +0000 (14:39 +0200)] 
ftrace: Add ftrace_hash_remove function

Adding ftrace_hash_remove function that removes all entries
from struct ftrace_hash object without freeing them.

It will be used in following changes where entries are allocated
as part of another structure and are free-ed separately.

Signed-off-by: Jiri Olsa <jolsa@kernel.org>
Link: https://lore.kernel.org/r/20260606123955.345967-3-jolsa@kernel.org
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
11 days agoftrace: Add ftrace_hash_count function
Jiri Olsa [Sat, 6 Jun 2026 12:39:26 +0000 (14:39 +0200)] 
ftrace: Add ftrace_hash_count function

Adding external ftrace_hash_count function so we could get hash
count outside of ftrace object.

Signed-off-by: Jiri Olsa <jolsa@kernel.org>
Link: https://lore.kernel.org/r/20260606123955.345967-2-jolsa@kernel.org
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
11 days agofbdev: vesafb: fix memory leak in vesafb_probe()
Abdun Nihaal [Thu, 14 May 2026 08:24:42 +0000 (13:54 +0530)] 
fbdev: vesafb: fix memory leak in vesafb_probe()

Since commit 73ce73c30ba9 ("fbdev: Transfer video= option strings to
caller; clarify ownership") the string returned from fb_get_options()
is expected to be freed by the caller. But the string is not freed in
vesafb_probe(). Fix that by freeing the option string after setup.

Fixes: 73ce73c30ba9 ("fbdev: Transfer video= option strings to caller; clarify ownership")
Cc: stable@vger.kernel.org
Signed-off-by: Abdun Nihaal <nihaal@cse.iitm.ac.in>
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: Helge Deller <deller@gmx.de>
11 days agofbdev: efifb: fix memory leak in efifb_probe()
Abdun Nihaal [Thu, 14 May 2026 08:24:41 +0000 (13:54 +0530)] 
fbdev: efifb: fix memory leak in efifb_probe()

Since commit 73ce73c30ba9 ("fbdev: Transfer video= option strings to
caller; clarify ownership") the string returned from fb_get_options()
is expected to be freed by the caller, but the string is not freed in
efifb_probe(). Fix that by freeing the option string after setup.

Fixes: 73ce73c30ba9 ("fbdev: Transfer video= option strings to caller; clarify ownership")
Cc: stable@vger.kernel.org
Signed-off-by: Abdun Nihaal <nihaal@cse.iitm.ac.in>
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: Helge Deller <deller@gmx.de>
11 days agofbdev: uvesafb: fix potential memory leak in uvesafb_probe()
Abdun Nihaal [Thu, 14 May 2026 08:24:40 +0000 (13:54 +0530)] 
fbdev: uvesafb: fix potential memory leak in uvesafb_probe()

Due to an incorrect goto label, memory allocated for modedb and modelist
in uvesafb_vbe_init() is not freed in some error paths. Fix this by
updating the goto label.

Fixes: 8bdb3a2d7df4 ("uvesafb: the driver core")
Cc: stable@vger.kernel.org
Signed-off-by: Abdun Nihaal <nihaal@cse.iitm.ac.in>
Signed-off-by: Helge Deller <deller@gmx.de>
11 days agofbdev: tridentfb: fix potential memory leak in trident_pci_probe()
Abdun Nihaal [Thu, 14 May 2026 08:24:39 +0000 (13:54 +0530)] 
fbdev: tridentfb: fix potential memory leak in trident_pci_probe()

In trident_pci_probe(), the memory allocated for modelist using
fb_videomode_to_modelist() is not freed in subsequent error paths.
Fix that by calling fb_destroy_modelist().

Fixes: 6a5e3bd0c8bc ("tridentfb: Add DDC support")
Cc: stable@vger.kernel.org
Signed-off-by: Abdun Nihaal <nihaal@cse.iitm.ac.in>
Signed-off-by: Helge Deller <deller@gmx.de>
11 days agofbdev: tdfxfb: fix potential memory leak in tdfxfb_probe()
Abdun Nihaal [Thu, 14 May 2026 08:24:38 +0000 (13:54 +0530)] 
fbdev: tdfxfb: fix potential memory leak in tdfxfb_probe()

In tdfxfb_probe(), the memory allocated for modelist using
fb_videomode_to_modelist() when CONFIG_FB_3DFX_I2C is defined, is not
freed in the subsequent error paths.
Fix that by calling fb_destroy_modelist().

Fixes: 215059d2421f ("tdfxfb: make use of DDC information about connected monitor")
Cc: stable@vger.kernel.org
Signed-off-by: Abdun Nihaal <nihaal@cse.iitm.ac.in>
Signed-off-by: Helge Deller <deller@gmx.de>
11 days agofbdev: s3fb: fix potential memory leak in s3_pci_probe()
Abdun Nihaal [Thu, 14 May 2026 08:24:37 +0000 (13:54 +0530)] 
fbdev: s3fb: fix potential memory leak in s3_pci_probe()

In s3_pci_probe(), the memory allocated for modelist using
fb_videomode_to_modelist() is not freed in subsequent error paths.
Fix that by calling fb_destroy_modelist()

Fixes: 86c0f043a737 ("s3fb: add DDC support")
Cc: stable@vger.kernel.org
Signed-off-by: Abdun Nihaal <nihaal@cse.iitm.ac.in>
Signed-off-by: Helge Deller <deller@gmx.de>
11 days agofbdev: nvidia: fix potential memory leak in nvidiafb_probe()
Abdun Nihaal [Thu, 14 May 2026 08:24:36 +0000 (13:54 +0530)] 
fbdev: nvidia: fix potential memory leak in nvidiafb_probe()

In nvidiafb_probe(), the memory allocated for modelist in
nvidia_set_fbinfo() is not freed in the subsequent error paths.
Fix that by calling fb_destroy_modelist().

Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Cc: stable@vger.kernel.org
Signed-off-by: Abdun Nihaal <nihaal@cse.iitm.ac.in>
Signed-off-by: Helge Deller <deller@gmx.de>
11 days agofbdev: i740fb: fix potential memory leak in i740fb_probe()
Abdun Nihaal [Thu, 14 May 2026 08:24:35 +0000 (13:54 +0530)] 
fbdev: i740fb: fix potential memory leak in i740fb_probe()

In i740fb_probe(), the memory allocated in fb_videomode_to_modelist()
for modelist is not freed in the error paths. Fix that by calling
fb_destroy_modelist().

Fixes: 5350c65f4f15 ("Resurrect Intel740 driver: i740fb")
Cc: stable@vger.kernel.org
Signed-off-by: Abdun Nihaal <nihaal@cse.iitm.ac.in>
Signed-off-by: Helge Deller <deller@gmx.de>
11 days agofbdev: carminefb: fix potential memory leak in alloc_carmine_fb()
Abdun Nihaal [Thu, 14 May 2026 08:24:34 +0000 (13:54 +0530)] 
fbdev: carminefb: fix potential memory leak in alloc_carmine_fb()

The memory allocated for modelist in fb_videomode_to_modelist() is not
freed in the subsequent error path.
Fix that by calling fb_destroy_modelist()

Fixes: 2ece5f43b041 ("fbdev: add the carmine FB driver")
Cc: stable@vger.kernel.org
Signed-off-by: Abdun Nihaal <nihaal@cse.iitm.ac.in>
Signed-off-by: Helge Deller <deller@gmx.de>
11 days agofbdev: radeon: fix potential memory leak in radeonfb_pci_register()
Abdun Nihaal [Thu, 14 May 2026 08:24:33 +0000 (13:54 +0530)] 
fbdev: radeon: fix potential memory leak in radeonfb_pci_register()

The function radeonfb_pci_register() allocates memory for modelist
(by calling radeon_check_modes() which calls fb_add_videomode()).
The memory is appended to info->modelist, but is not freed in subsequent
error paths. Fix this by calling fb_destroy_modelist().

Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Cc: stable@vger.kernel.org
Signed-off-by: Abdun Nihaal <nihaal@cse.iitm.ac.in>
Signed-off-by: Helge Deller <deller@gmx.de>
11 days agofbdev: metronomefb: fix potential memory leak in metronomefb_probe()
Abdun Nihaal [Thu, 14 May 2026 08:24:32 +0000 (13:54 +0530)] 
fbdev: metronomefb: fix potential memory leak in metronomefb_probe()

The memory allocated for pagerefs in fb_deferred_io_init() is not freed
on the error path. Fix it by calling fb_deferred_io_cleanup().

Fixes: 56c134f7f1b5 ("fbdev: Track deferred-I/O pages in pageref struct")
Cc: stable@vger.kernel.org
Signed-off-by: Abdun Nihaal <nihaal@cse.iitm.ac.in>
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: Helge Deller <deller@gmx.de>
11 days agofbdev: broadsheetfb: fix potential memory leak in broadsheetfb_probe()
Abdun Nihaal [Thu, 14 May 2026 08:24:31 +0000 (13:54 +0530)] 
fbdev: broadsheetfb: fix potential memory leak in broadsheetfb_probe()

The memory allocated for pagerefs in fb_deferred_io_init() is not freed
on the error path. Fix it by calling fb_deferred_io_cleanup().

Fixes: 56c134f7f1b5 ("fbdev: Track deferred-I/O pages in pageref struct")
Cc: stable@vger.kernel.org
Signed-off-by: Abdun Nihaal <nihaal@cse.iitm.ac.in>
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: Helge Deller <deller@gmx.de>
11 days agofbdev: hecubafb: fix potential memory leak in hecubafb_probe()
Abdun Nihaal [Thu, 14 May 2026 08:24:30 +0000 (13:54 +0530)] 
fbdev: hecubafb: fix potential memory leak in hecubafb_probe()

The memory allocated for pagerefs in fb_deferred_io_init() is not freed
on the error path. Fix it by calling fb_deferred_io_cleanup().

Fixes: 56c134f7f1b5 ("fbdev: Track deferred-I/O pages in pageref struct")
Cc: stable@vger.kernel.org
Signed-off-by: Abdun Nihaal <nihaal@cse.iitm.ac.in>
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: Helge Deller <deller@gmx.de>
11 days agofbdev: atmel_lcdfb: Use of_device_get_match_data()
Rosen Penev [Tue, 19 May 2026 00:36:13 +0000 (17:36 -0700)] 
fbdev: atmel_lcdfb: Use of_device_get_match_data()

Use of_device_get_match_data() to retrieve the driver match data instead
of open-coding the OF match lookup and dereferencing match->data.

This also removes the deprecated of_device.h include from the driver.

No need for NULL check as every compatible has a corresponding data
component.

Assisted-by: Codex:GPT-5.5
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Signed-off-by: Helge Deller <deller@gmx.de>
11 days agofbdev: imxfb: Use of_device_get_match_data()
Rosen Penev [Mon, 18 May 2026 21:13:03 +0000 (14:13 -0700)] 
fbdev: imxfb: Use of_device_get_match_data()

Use of_device_get_match_data() to fetch the platform ID entry directly
instead of open-coding an of_match_device() lookup. No NULL check is
needed as every compatible string has a corresponding data section.

This also lets the driver drop the of_device.h include.

Assisted-by: Codex:GPT-5.5
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Signed-off-by: Helge Deller <deller@gmx.de>
11 days agofbcon: Use correct type for vc_resize() return value
Jiacheng Yu [Thu, 14 May 2026 09:19:18 +0000 (17:19 +0800)] 
fbcon: Use correct type for vc_resize() return value

The return value of vc_resize() is int, but fbcon_set_disp() stores it
in an unsigned long variable. While the !ret check happens to work
correctly by coincidence (negative values become large positive values),
the types should match. Use int instead.

Eliminates the following W=3 warning:

  drivers/video/fbdev/core/fbcon.c: In function 'fbcon_set_disp':
  drivers/video/fbdev/core/fbcon.c:1494:14: warning: implicit conversion from 'int' to 'unsigned long' [-Wconversion]

Fixes: af0db3c1f898 ("fbdev: Fix vmalloc out-of-bounds write in fast_imageblit")
Cc: stable@vger.kernel.org # v6.17+
Signed-off-by: Jiacheng Yu <yujiacheng3@huawei.com>
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: Helge Deller <deller@gmx.de>
11 days agofbdev: Consistently define pci_device_ids using named initializers
Uwe Kleine-König [Thu, 30 Apr 2026 11:16:36 +0000 (13:16 +0200)] 
fbdev: Consistently define pci_device_ids using named initializers

... and PCI device helpers.

The various struct pci_device_id arrays were initialized mostly by list
expressions. This isn't easily readable if you're not into PCI. Using
named initializers is more explicit and thus easier to parse. Also use
PCI_DEVICE* helper macros to assign .vendor, .device, .subvendor and
.subdevice where appropriate and skip explicit assignments of 0 (which
the compiler takes care of).

The secret plan is to make struct pci_device_id::driver_data an
anonymous union (similar to
https://lore.kernel.org/all/cover.1776579304.git.u.kleine-koenig@baylibre.com/)
and that requires named initializers. But it's also a nice cleanup on
its own.

While touching all these arrays, unify usage of whitespace and comma
in a few drivers.

This change doesn't introduce changes to the compiled pci_device_id
array. Tested on x86 and arm64.

Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>
Signed-off-by: Helge Deller <deller@gmx.de>
11 days agofbdev: matroxfb/ssd1307fb: Use named initializers for struct i2c_device_id
Uwe Kleine-König [Mon, 18 May 2026 16:08:08 +0000 (18:08 +0200)] 
fbdev: matroxfb/ssd1307fb: Use named initializers for struct i2c_device_id

While being less compact, using named initializers allows to more easily
see which members of the structs are assigned which value without having
to lookup the declaration of the struct. And it's also more robust
against changes to the struct definition.

While touching all these arrays, unify usage of whitespace in the list
terminator.

This patch doesn't modify the compiled arrays, only their representation
in source form benefits. The former was confirmed with x86 and arm64
builds.

Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>
Signed-off-by: Helge Deller <deller@gmx.de>
11 days agoMerge tag 'input-for-v7.1-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor...
Linus Torvalds [Sun, 7 Jun 2026 15:40:53 +0000 (08:40 -0700)] 
Merge tag 'input-for-v7.1-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input

Pull input fixes from Dmitry Torokhov:

 - two quirks for atkbd to deal with laptops that can not handle
   "deactivate" command on the keyboard PS/2 port

* tag 'input-for-v7.1-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input:
  Input: atkbd - skip deactivate for HONOR BCC-N's internal keyboard
  Input: atkbd - add DMI quirk for Lenovo Yoga Air 14 (83QK)

11 days agonet/mlx5: Add sd_group_size bits for SD management
Shay Drory [Fri, 29 May 2026 05:23:59 +0000 (08:23 +0300)] 
net/mlx5: Add sd_group_size bits for SD management

Currently, mlx5 is querying the MPIR register to get the number of PFs
that should comprise the SD group.
However, this register does not reflect the correct number in complex
deployments. Hence, add an sd_group_size field to nic_vport_context to
determine the correct number of PFs, and add an sd_group_size capability
bit to indicate whether FW supports it.

Signed-off-by: Shay Drory <shayd@nvidia.com>
Reviewed-by: Moshe Shemesh <moshe@nvidia.com>
Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
Link: https://patch.msgid.link/20260529052359.389413-3-tariqt@nvidia.com
Signed-off-by: Leon Romanovsky <leon@kernel.org>
11 days agonet/mlx5: Update IFC allowed_list_size field bits
Dragos Tatulea [Fri, 29 May 2026 05:23:58 +0000 (08:23 +0300)] 
net/mlx5: Update IFC allowed_list_size field bits

The vport context allowed_list_size was increased from 12 to 16 bits.

Writing to this field is protected by the log_max_current_uc/mc_list
capabilities. On older FW versions these capabilities are limited
to < 2K and only the high bits of the field are extended. This means
that the change is backward compatible with older FW versions.

Signed-off-by: Dragos Tatulea <dtatulea@nvidia.com>
Reviewed-by: Cosmin Ratiu <cratiu@nvidia.com>
Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
Link: https://patch.msgid.link/20260529052359.389413-2-tariqt@nvidia.com
Signed-off-by: Leon Romanovsky <leon@kernel.org>
11 days agoALSA: es18xx: check control allocation before private data setup
Ruoyu Wang [Sun, 7 Jun 2026 07:42:19 +0000 (15:42 +0800)] 
ALSA: es18xx: check control allocation before private data setup

snd_es18xx_mixer() creates controls with snd_ctl_new1() and then stores
bookkeeping pointers or sets private_free before calling snd_ctl_add().
snd_ctl_new1() can return NULL on allocation failure, so those writes
can dereference a NULL control pointer.

Check the returned control pointers before using them and return -ENOMEM
on allocation failure.

Signed-off-by: Ruoyu Wang <ruoyuw560@gmail.com>
Link: https://patch.msgid.link/20260607074219.3-1-ruoyuw560@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
11 days agofilelock: fix break_lease() stub signature for CONFIG_FILE_LOCKING=n
Christian Brauner [Sun, 7 Jun 2026 09:40:28 +0000 (11:40 +0200)] 
filelock: fix break_lease() stub signature for CONFIG_FILE_LOCKING=n

The CONFIG_FILE_LOCKING=n stub for break_lease() takes a 'bool wait'
argument, whereas the CONFIG_FILE_LOCKING=y version and every caller pass
an openmode as an 'unsigned int mode'. The mismatch was introduced when
__break_lease() was reworked to use flags: only the stub was switched to
'bool wait', a stray leftover from the neighbouring break_layout()
helper. The real prototype kept 'unsigned int mode'.

This was harmless until O_WRONLY changed from the octal literal 00000001
to (1 << 0). clang's -Wtautological-constant-compare then fires on the
implicit shift-to-bool conversion at the first FILE_LOCKING=n caller:

  fs/open.c:112:29: warning: converting the result of '<<' to a boolean
                    always evaluates to true [-Wtautological-constant-compare]
    112 | error = break_lease(inode, O_WRONLY);

Restore the stub's parameter to 'unsigned int mode' so it matches the
real prototype and every caller. The stub still just returns 0, so there
is no functional change; it removes the type inconsistency and silences
the warning.

Root cause diagnosed by Nathan Chancellor.

Fixes: 4be9f3cc582a ("filelock: rework the __break_lease API to use flags")
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202606071029.DKCs8WOs-lkp@intel.com/
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
11 days agonetfilter: nf_conntrack: use get_unaligned_be32() in tcp_sack()
Rosen Penev [Mon, 25 May 2026 21:58:40 +0000 (14:58 -0700)] 
netfilter: nf_conntrack: use get_unaligned_be32() in tcp_sack()

The timestamp-only fast path dereferences the option stream as
*(__be32 *)ptr, which assumes 4-byte alignment that the TCP option
stream does not guarantee. Use get_unaligned_be32() instead, which
reads the value safely and already returns host byte order, so the
htonl() on the comparison constant can be dropped.

This matches the existing get_unaligned_be32() use later in the same
function.

Assisted-by: Claude:Opus-4.7
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Reviewed-by: Fernando Fernandez Mancera <fmancera@suse.de>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
11 days agonetfilter: flowtable: avoid num_encaps underflow on bridge VLAN untag
David Carlier [Sat, 23 May 2026 15:26:21 +0000 (16:26 +0100)] 
netfilter: flowtable: avoid num_encaps underflow on bridge VLAN untag

The DEV_PATH_BR_VLAN_UNTAG case post-decrements info->num_encaps
inside WARN_ON_ONCE(). num_encaps is u8, so if it's already 0 the
decrement still happens and wraps it to 255. The break only leaves
the inner switch -- a later path entry can set info->indev back to
a real device, and we end up returning with num_encaps == 255.

nft_dev_forward_path() then walks info.encap[] (size 2) up to
num_encaps, which means an OOB stack read and a bogus count copied
into the route descriptor.

Should only happen on a malformed bridge path stack, hence the WARN,
but worth handling sanely. Move the decrement out of the WARN.

[ While at this, remove the WARN_ON_ONCE since this can only happen
  with a buggy bridge path stack --pablo ].

Fixes: e990cef6516d ("netfilter: flowtable: add bridge vlan filtering support")
Signed-off-by: David Carlier <devnexen@gmail.com>
Reviewed-by: Fernando Fernandez Mancera <fmancera@suse.de>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
12 days agobpf: Reject sleepable BPF_LSM_CGROUP programs at load time
David Windsor [Fri, 5 Jun 2026 14:57:07 +0000 (10:57 -0400)] 
bpf: Reject sleepable BPF_LSM_CGROUP programs at load time

The cgroup shim runs under rcu_read_lock_dont_migrate(), so we should
not attach any sleepable BPF programs there. Add support to the verifier
to explicitly reject attempts to load sleepable BPF programs destined
for LSM cgroup attachment.

Without this, we get the following splat from a BPF_LSM_CGROUP
program marked BPF_F_SLEEPABLE attached to file_open when it calls
bpf_get_dentry_xattr():

  BUG: sleeping function called from invalid context at kernel/locking/rwsem.c:1567
  in_atomic(): 0, irqs_disabled(): 0, non_block: 0, pid: 34317, name: load
  preempt_count: 0, expected: 0
  RCU nest depth: 2, expected: 0
  Call Trace:
   down_read+0x76/0x480
   ext4_xattr_get+0x11f/0x700
   __vfs_getxattr+0xf0/0x150
   bpf_get_dentry_xattr+0xbb/0xf0
   bpf_prog_e76a298dac9218c6_test_open+0x6a/0x85
   __cgroup_bpf_run_lsm_current+0x326/0x840
   bpf_trampoline_6442534646+0x62/0x14d
   security_file_open+0x34/0x60
   do_dentry_open+0x340/0x1260
   vfs_open+0x7a/0x440
   path_openat+0x1bac/0x30a0

libbpf provides a .s named section variant for every sleepable
program type except lsm_cgroup, reflecting that per-cgroup LSM programs
are intended to only run in a non-sleepable context.

The above splat was obtained by bypassing libbpf by using bpf(2)
directly.

Fixes: 69fd337a975c ("bpf: per-cgroup lsm flavor")
Signed-off-by: David Windsor <dwindsor@gmail.com>
Acked-by: Yonghong Song <yonghong.song@linux.dev>
Acked-by: Song Liu <song@kernel.org>
Link: https://lore.kernel.org/bpf/20260605145707.608579-1-dwindsor@gmail.com
Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
12 days agoMerge branch 'for-linus' into for-next
Takashi Iwai [Sun, 7 Jun 2026 07:26:48 +0000 (09:26 +0200)] 
Merge branch 'for-linus' into for-next

Signed-off-by: Takashi Iwai <tiwai@suse.de>
12 days agoALSA: seq: Clear variable event pointer on read
Kyle Zeng [Sun, 7 Jun 2026 00:41:29 +0000 (17:41 -0700)] 
ALSA: seq: Clear variable event pointer on read

snd_seq_read() copies a queued variable-length event header to userspace
before expanding the payload. Queued variable-length events use
SNDRV_SEQ_EXT_CHAINED internally, and data.ext.ptr points at the first
extension cell.

The read side strips SNDRV_SEQ_EXT_* bits from data.ext.len before the
copy, but it leaves data.ext.ptr untouched. A userspace sequencer client
can therefore write a direct variable event to itself and read back the
extension-cell kernel address from the returned header.

Clear the temporary header pointer before copy_to_user(). The original
queued event remains unchanged and is still passed to
snd_seq_expand_var_event(), so payload expansion keeps using the
internal chain.

Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Kyle Zeng <kylebot@openai.com>
Link: https://patch.msgid.link/20260607004129.61345-1-kylebot@openai.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
12 days agoALSA: timer: Fix UAF at snd_timer_user_params()
Takashi Iwai [Sat, 6 Jun 2026 16:11:41 +0000 (18:11 +0200)] 
ALSA: timer: Fix UAF at snd_timer_user_params()

At releasing a timer object, e.g. when a userspace timer
(CONFIG_SND_UTIMER) gets closed and snd_timer_free() is called, it
tries to detach the timer instances and release the resources.
However, it's still possible that other in-flight tasks are holding
the timer instance where the to-be-deleted timer object is associated,
and this may lead to racy accesses.

Fortunately, most of ioctls dealing with the timer instance list
already have the protection with register_mutex, and this also avoids
such races.  But, SNDRV_TIMER_IOCTL_PARAMS isn't protected, hence the
concurrent ioctl may lead to use-after-free.

This patch just adds the guard with register_mutex to protect
snd_timer_user_params() for covering the code path as a quick
workaround.  It's no hot-path but rather a rarely issued ioctl, so the
performance penalty doesn't matter.

Reported-by: Kyle Zeng <kylebot@openai.com>
Tested-by: Kyle Zeng <kylebot@openai.com>
Cc: <stable@vger.kernel.org>
Link: https://patch.msgid.link/20260606161145.1933447-2-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
12 days agoALSA: timer: Forcibly close timer instances at closing
Takashi Iwai [Sat, 6 Jun 2026 16:11:40 +0000 (18:11 +0200)] 
ALSA: timer: Forcibly close timer instances at closing

When snd_timer object is freed via snd_timer_free() and still pending
snd_timer_instance objects are assigned to the timer object, it tries
to unlink all instances and just set NULL to each ti->timer, then
releases the resources immediately.  The problem is, however, when
there are slave timer instances that are associated with a master
instance linked to this timer: namely, those slave instances still
point to the freed timer object although the master instance is
unlinked, which may lead to user-after-free.  The bug can be easily
triggered particularly when a new userspace-driven timers
(CONFIG_SND_UTIMER) is involved, since it can create and delete the
timer object via a simple file open/close, while the other
applications may keep accessing to that timer.

This patch is an attempt to paper over the problem above: now instead
of just unlinking, call snd_timer_close[_locked]() forcibly for each
pending timer instance, so that all assigned slave timer instances are
properly detached, too.  Since snd_timer_close() might be called later
by the driver that created that instance, the check of
SNDRV_TIMER_IFLG_DEAD is added at the beginning, too.

Reported-by: Kyle Zeng <kylebot@openai.com>
Tested-by: Kyle Zeng <kylebot@openai.com>
Fixes: 37745918e0e7 ("ALSA: timer: Introduce virtual userspace-driven timers")
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20260606161145.1933447-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
12 days agoriscv: cfi: reject unknown flags in PR_SET_CFI
Richard Patel [Mon, 18 May 2026 18:39:18 +0000 (18:39 +0000)] 
riscv: cfi: reject unknown flags in PR_SET_CFI

prctl(PR_SET_CFI,PR_CFI_BRANCH_LANDING_PADS) silently ignored
unknown control values. Only PR_CFI_{ENABLE,DISABLE,LOCK} should
be permitted.

This changes the behavior of the uABI (fails previously accepted bits
with EINVAL).

Fixes: 08ee1559052b ("prctl: cfi: change the branch landing pad prctl()s to be more descriptive")
Signed-off-by: Richard Patel <ripatel@wii.dev>
Link: https://patch.msgid.link/20260518183918.322545-1-ripatel@wii.dev
[pjw@kernel.org: change the patch description to note that although this is a uABI change, it does not break the uABI]
Signed-off-by: Paul Walmsley <pjw@kernel.org>
12 days agoriscv: Fix fast_unaligned_access_speed_key not getting initialized
Nam Cao [Tue, 7 Apr 2026 12:06:39 +0000 (14:06 +0200)] 
riscv: Fix fast_unaligned_access_speed_key not getting initialized

The static key fast_unaligned_access_speed_key is supposed to be
initialized after check_unaligned_access_all_cpus() has been completed.

However, check_unaligned_access_all_cpus() has been moved to late_initcall
while setting fast_unaligned_access_speed_key still happens at
arch_initcall_sync, thus the static key does not get properly initialized.

fast_unaligned_access_speed_key can still be initialized in CPU hotplug
events, but that cannot be relied on.

Move fast_unaligned_access_speed_key's initialization into
check_unaligned_access_all_cpus() to fix this issue. This also prevent
someone from moving one initcall while forgetting the other in the future.

Fixes: 6455c6c11827 ("riscv: Clean up & optimize unaligned scalar access probe")
Reported-by: Michael Neuling <mikey@neuling.org>
Closes: https://lore.kernel.org/linux-riscv/CAEjGV6y0=bSLp_wrS0uHFj1S2TCRtz4GKzaU5O-L1VV-EL7Nnw@mail.gmail.com/
Signed-off-by: Nam Cao <namcao@linutronix.de>
Link: https://patch.msgid.link/20260407120639.4006031-1-namcao@linutronix.de
Signed-off-by: Paul Walmsley <pjw@kernel.org>
12 days agoriscv/ptrace: Use USER_REGSET_NOTE_TYPE for REGSET_CFI
Andreas Schwab [Thu, 21 May 2026 22:34:30 +0000 (00:34 +0200)] 
riscv/ptrace: Use USER_REGSET_NOTE_TYPE for REGSET_CFI

Fixes a warning while dumping core:

[54983.546369][    C7] WARNING: [!note_name] fs/binfmt_elf.c:1771 at elf_core_dump+0x910/0xf68, CPU#7: abort01/31982

Fixes: 2af7c9cf021c ("riscv/ptrace: expose riscv CFI status and state via ptrace and in core files")
Signed-off-by: Andreas Schwab <schwab@suse.de>
Link: https://patch.msgid.link/87y0hcxuh5.fsf@igel.home
Signed-off-by: Paul Walmsley <pjw@kernel.org>
12 days agoMerge branch 'bpf-verifier-fix-ptr_to_flow_keys-constant-offset-oob'
Alexei Starovoitov [Sat, 6 Jun 2026 23:44:47 +0000 (16:44 -0700)] 
Merge branch 'bpf-verifier-fix-ptr_to_flow_keys-constant-offset-oob'

Nuoqi Gui says:

====================
bpf, verifier: fix PTR_TO_FLOW_KEYS constant-offset OOB

A constant offset added to a PTR_TO_FLOW_KEYS register lands in
reg->var_off, but check_flow_keys_access() bounds-checks only insn->off
and never folds reg->var_off.value.  A BPF_PROG_TYPE_FLOW_DISSECTOR
program can therefore do "flow_keys += 0x1000; *(flow_keys + 0)" and have
it accepted, then read/write kernel stack past struct bpf_flow_keys at
runtime.  Patch 1 folds reg->var_off.value into the offset (and rejects
non-constant offsets), mirroring check_ctx_access(); patch 2 adds verifier
selftests.

This is a regression introduced in the 7.1 development cycle by commit
022ac0750883 ("bpf: use reg->var_off instead of reg->off for pointers"),
which moved the constant offset from reg->off (folded generically before
022ac0750883) into reg->var_off without updating the flow_keys path.  No
released kernel is affected: v7.0.x rejects the program above, and the bug
reproduces only on v7.1-rc1..rc5, so no stable backport is needed.

It was first reported privately to security@kernel.org; per their guidance
it is handled in the open as a normal regression fix.  Found by manual
verifier audit and confirmed dynamically in a disposable QEMU/KVM guest:
the load above is accepted, a runtime read leaked a kernel-stack pointer
0x1000 past bpf_flow_keys, and a runtime write of a marker faulted the
guest in net_rx_action.

An alternative -- forbidding pointer arithmetic on PTR_TO_FLOW_KEYS
outright by dropping "if (known) break;" in adjust_ptr_min_max_vals() --
was rejected because v7.0.x accepted (and correctly bounds-checked)
constant arithmetic on the keys pointer; restoring the fold preserves that
behaviour while closing the divergence.

Signed-off-by: Nuoqi Gui <gnq25@mails.tsinghua.edu.cn>
---
v2 -> v3:
 - Pass existing reg/argno context into check_flow_keys_access(), avoiding
   a stale regno reference in check_mem_access().
 - Add a variable-offset selftest using bpf_get_prandom_u32().

v1 -> v2:
 - Target bpf-next instead of bpf (per reviewer feedback).
 - Base-commit updated to bpf-next/master.

v2: https://lore.kernel.org/bpf/20260604180730.2518088-1-gnq25@mails.tsinghua.edu.cn/
v1: https://lore.kernel.org/bpf/20260604150755.2487555-1-gnq25@mails.tsinghua.edu.cn/
====================

Link: https://patch.msgid.link/20260606-c3-01-v3-v3-0-97c51f592f15@mails.tsinghua.edu.cn
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
12 days agoselftests/bpf: add tests for PTR_TO_FLOW_KEYS offset bounds
Nuoqi Gui [Sat, 6 Jun 2026 10:50:38 +0000 (18:50 +0800)] 
selftests/bpf: add tests for PTR_TO_FLOW_KEYS offset bounds

Add verifier tests covering pointer arithmetic on a PTR_TO_FLOW_KEYS
register. This covers the bpf-next regression where an out-of-bounds
constant offset introduced as flow_keys += K and then dereferenced at
insn->off 0 was accepted, while the equivalent flow_keys + K direct offset
was rejected.

The tests check that in-bounds constant arithmetic on the keys pointer is
still accepted, out-of-bounds constant arithmetic is rejected for both read
and write, and a truly varying offset from bpf_get_prandom_u32() remains
rejected by the existing PTR_TO_FLOW_KEYS pointer arithmetic rules.

Signed-off-by: Nuoqi Gui <gnq25@mails.tsinghua.edu.cn>
Acked-by: Eduard Zingerman <eddyz87@gmail.com>
Link: https://lore.kernel.org/r/20260606-c3-01-v3-v3-2-97c51f592f15@mails.tsinghua.edu.cn
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
12 days agobpf: Fold reg->var_off into PTR_TO_FLOW_KEYS bounds check
Nuoqi Gui [Sat, 6 Jun 2026 10:50:37 +0000 (18:50 +0800)] 
bpf: Fold reg->var_off into PTR_TO_FLOW_KEYS bounds check

Constant pointer arithmetic on a PTR_TO_FLOW_KEYS register lands the
constant in reg->var_off (e.g. flow_keys(imm=4096)), but the
PTR_TO_FLOW_KEYS path in check_mem_access() passes only insn->off to
check_flow_keys_access() and never folds reg->var_off.value.  The
verifier therefore accepts an access that, at runtime, dereferences past
struct bpf_flow_keys -- a verifier/runtime divergence that yields an
out-of-bounds read and write of kernel stack memory.

Commit 022ac0750883 ("bpf: use reg->var_off instead of reg->off for
pointers") removed the generic "off += reg->off" that check_mem_access()
applied before the per-type dispatch and replaced it with per-path
folding of reg->var_off.value (for example the ctx path now folds the
register offset via check_ctx_access()).  The PTR_TO_FLOW_KEYS path was
not given the equivalent fold, so a constant offset that used to be
folded and rejected is now silently accepted:

  before 022ac0750883: the offset stays in reg->off and is folded
    generically, so the access is checked with off=4096 and rejected.
  after  022ac0750883: the offset lands in reg->var_off, the flow_keys
    path checks off=0 and accepts; at runtime the access dereferences
    base + 0x1000.

For a BPF_PROG_TYPE_FLOW_DISSECTOR program the following is accepted:

  r2 = *(u64 *)(r1 + 144)   ; R2=flow_keys (PTR_TO_FLOW_KEYS)
  r2 += 0x1000              ; R2=flow_keys(imm=4096), accepted
  r0 = *(u64 *)(r2 + 0)     ; accepted, var_off.value=0x1000 ignored

while the equivalent insn->off form

  r0 = *(u64 *)(r2 + 0x1000)

has the same effective offset but is correctly rejected with
"invalid access to flow keys off=4096 size=8", which isolates the defect
to the missing var_off fold.  Once attached as a flow dissector, the
accepted program reads kernel stack past struct bpf_flow_keys (a
kernel-stack / KASLR information leak) and can likewise write past it,
corrupting kernel memory.

Fix it by folding reg->var_off.value into the offset before the bounds
check and rejecting non-constant offsets, mirroring the other pointer
types (e.g. check_ctx_access()).

Fixes: 022ac0750883 ("bpf: use reg->var_off instead of reg->off for pointers")
Signed-off-by: Nuoqi Gui <gnq25@mails.tsinghua.edu.cn>
Acked-by: Eduard Zingerman <eddyz87@gmail.com>
Link: https://lore.kernel.org/r/20260606-c3-01-v3-v3-1-97c51f592f15@mails.tsinghua.edu.cn
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
12 days agocfi: Include uaccess.h for get_kernel_nofault()
Nathan Chancellor [Fri, 5 Jun 2026 00:33:21 +0000 (17:33 -0700)] 
cfi: Include uaccess.h for get_kernel_nofault()

After commit 0652a3daa787 ("tracing: Fix CFI violation in probestub
being called by tprobes"), there are many build errors when building
ARCH=arm multi_v7_defconfig + CONFIG_CFI=y like:

  In file included from drivers/base/devres.c:17:
  In file included from drivers/base/trace.h:16:
  In file included from include/linux/tracepoint.h:23:
  include/linux/cfi.h:44:6: error: call to undeclared function 'get_kernel_nofault'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
     44 |         if (get_kernel_nofault(hash, func - cfi_get_offset()))
        |             ^
  1 error generated.

get_kernel_nofault() is called in the generic version of
cfi_get_func_hash() but nothing ensures uaccess.h is always included for
a proper expansion and prototype.  Include uaccess.h in cfi.h to clear
up the errors.

Cc: stable@vger.kernel.org
Fixes: 0652a3daa787 ("tracing: Fix CFI violation in probestub being called by tprobes")
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Acked-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
Reviewed-by: Sami Tolvanen <samitolvanen@google.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
12 days agogfs2: use d_splice_alias() for ->lookup() return value
Al Viro [Sat, 9 May 2026 16:31:57 +0000 (12:31 -0400)] 
gfs2: use d_splice_alias() for ->lookup() return value

Reviewed-by: Andreas Gruenbacher <agruenba@redhat.com>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
12 days agontfs: use d_splice_alias() for ->lookup() return value
Al Viro [Sat, 9 May 2026 16:30:19 +0000 (12:30 -0400)] 
ntfs: use d_splice_alias() for ->lookup() return value

Reviewed-by: Namjae Jeon <linkinjeon@kernel.org>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
12 days agoInput: atkbd - skip deactivate for HONOR BCC-N's internal keyboard
Cryolitia PukNgae [Fri, 5 Jun 2026 07:27:21 +0000 (15:27 +0800)] 
Input: atkbd - skip deactivate for HONOR BCC-N's internal keyboard

After commit 9cf6e24c9fbf17e52de9fff07f12be7565ea6d61 ("Input: atkbd -
do not skip atkbd_deactivate() when skipping ATKBD_CMD_GETID"), HONOR
BCC-N, aka HONOR MagicBook 14 2026's internal keyboard stops
working. Adding the atkbd_deactivate_fixup quirk fixes it.

DMI: HONOR BCC-N/BCC-N-PCB, BIOS 1.04 04/07/2026

Fixes: 9cf6e24c9fbf17e52de9fff07f12be7565ea6d61 ("Input: atkbd - do not skip atkbd_deactivate() when skipping ATKBD_CMD_GETID")
Reported-by: Hongfei Ren <lcrhf@outlook.com>
Link: https://github.com/colorcube/Linux-on-Honor-Magicbook-14-Pro/issues/1#issuecomment-4562679891
Tested-by: Hongfei Ren <lcrhf@outlook.com>
Cc: stable@kernel.org
Signed-off-by: Cryolitia PukNgae <cryolitia.pukngae@linux.dev>
Link: https://patch.msgid.link/20260605-honor-v1-1-78e05e491193@linux.dev
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
12 days agoMerge tag 'sound-7.1-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai...
Linus Torvalds [Sat, 6 Jun 2026 16:49:16 +0000 (09:49 -0700)] 
Merge tag 'sound-7.1-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound

Pull sound fixes from Takashi Iwai:
 "It's getting calmer, but we still came up with a handful of small
  fixes, including two core fixes. All look sane and safe.

  Core:
   - Fix wait queue list corruption in snd_pcm_drain() on linked streams
   - Fix UMP event stack overread in seq dummy driver

  USB-audio:
   - Add quirk for AB13X USB Audio
   - Fix the regression with sticky mixer volumes in 7.1-rc

  ASoC:
   - Fix 32-slot TDM breakage on Freescale SAI
   - Varioud DMI quirks for AMD ACP"

* tag 'sound-7.1-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound:
  ALSA: seq: dummy: fix UMP event stack overread
  ALSA: usb-audio: Add iface reset and delay quirk for AB13X USB Audio
  ALSA: PCM: Fix wait queue list corruption in snd_pcm_drain() on linked streams
  ASoC: amd: acp70: add standalone RT721 SoundWire machine
  ASoC: amd: yc: Add MSI Raider A18 HX A9WJG to quirk table
  ASoC: fsl_sai: Fix 32 slots TDM broken by integer shift UB in xMR write
  ASoC: amd: yc: Enable internal mic on MSI Bravo 17 C7VF
  ASoC: amd: acp: Add DMI quirk for Lenovo Yoga Pro 7 15ASH11
  ALSA: usb-audio: Set the value of potential sticky mixers to maximum

12 days agoMerge tag 'rust-fixes-7.1-2' of git://git.kernel.org/pub/scm/linux/kernel/git/ojeda...
Linus Torvalds [Sat, 6 Jun 2026 16:44:42 +0000 (09:44 -0700)] 
Merge tag 'rust-fixes-7.1-2' of git://git.kernel.org/pub/scm/linux/kernel/git/ojeda/linux

Pull Rust fixes from Miguel Ojeda:
 "Toolchain and infrastructure:

   - Fix 'rustc-option' (the Makefile one) when cross-compiling that
     leads to build or boot failures in certain configs

   - Work around a Rust compiler bug (already fixed for Rust 1.98.0)
     thats lead to boot failures in certain configs due to missing
     'uwtable' LLVM module flags

   - Support a Rust compiler change (starting with Rust 1.98.0) in the
     unstable target specification JSON files

   - Forbid Rust + arm + KASAN configs, which do not build

  'kernel' crate:

   - Fix NOMMU build by adding a missing helper"

* tag 'rust-fixes-7.1-2' of git://git.kernel.org/pub/scm/linux/kernel/git/ojeda/linux:
  rust: x86: support Rust >= 1.98.0 target spec
  rust: arm64: set uwtable llvm module flag for CONFIG_UNWIND_TABLES
  rust: helpers: add is_vmalloc_addr wrapper for NOMMU builds
  rust: kasan/kbuild: fix rustc-option when cross-compiling
  ARM: Do not select HAVE_RUST when KASAN is enabled

12 days agoALSA: pcm: Fix unlocked runtime state reads in xfer ioctls
Cássio Gabriel [Fri, 5 Jun 2026 15:48:27 +0000 (12:48 -0300)] 
ALSA: pcm: Fix unlocked runtime state reads in xfer ioctls

The recent runtime state locking cleanup converted several PCM ioctl state
checks to snd_pcm_get_state(), including snd_pcm_pre_prepare(),
snd_pcm_drain() and snd_pcm_kernel_ioctl(). The native and compat xfer
ioctl paths still sample runtime->state directly before dispatching to the
PCM transfer helpers, and snd_pcm_common_ioctl() still samples the
DISCONNECTED state directly in its common precheck.

Use snd_pcm_get_state() for those ioctl-side prechecks as well. This keeps
the externally visible ioctl entry checks consistent with the stream-locked
state access used by the recent PCM state-read cleanup.

Fixes: 032322b44c02 ("ALSA: pcm: oss: use proper stream lock for runtime->state access")
Signed-off-by: Cássio Gabriel <cassiogabrielcontato@gmail.com>
Link: https://patch.msgid.link/20260605-alsa-pcm-xfer-state-helper-v1-1-eba97cecf820@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
12 days agoALSA: seq: Fix partial userptr event expansion
HyeongJun An [Sat, 6 Jun 2026 04:09:13 +0000 (13:09 +0900)] 
ALSA: seq: Fix partial userptr event expansion

snd_seq_expand_var_event_at() clamps the number of bytes to copy to the
remaining variable-event length, but passes the original buffer size to
expand_var_event().

For SNDRV_SEQ_EXT_USRPTR events, expand_var_event() copies exactly the
size argument from userspace.  On the final chunk, when the remaining
event data is shorter than the caller's buffer, this can read past the
declared event data and can spuriously fail with -EFAULT if the extra
bytes cross an unmapped page.

Pass the clamped length instead.  The chained and kernel-backed paths
already reclamp in dump_var_event(), but the user-pointer path handles
the size directly.

Fixes: ea46f79709b6 ("ALSA: seq: Add snd_seq_expand_var_event_at() helper")
Signed-off-by: HyeongJun An <sammiee5311@gmail.com>
Link: https://patch.msgid.link/20260606040913.230213-1-sammiee5311@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
12 days agowifi: ath9k_htc: allocate tx_buf and buf together
Rosen Penev [Thu, 21 May 2026 23:20:20 +0000 (16:20 -0700)] 
wifi: ath9k_htc: allocate tx_buf and buf together

Use a flexible array member to combine allocations. No need to have them
separate as they are always together.

Signed-off-by: Rosen Penev <rosenp@gmail.com>
Acked-by: Toke Høiland-Jørgensen <toke@toke.dk>
Link: https://patch.msgid.link/20260521232020.261405-1-rosenp@gmail.com
Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
12 days agowifi: ath9k: remove disabling of bands
Rosen Penev [Thu, 21 May 2026 23:18:06 +0000 (16:18 -0700)] 
wifi: ath9k: remove disabling of bands

The old platform data code that used this is gone and this serves no
purpose.

The modern way to disable bands is ieee80211-freq-limit, which is
already implemented.

Signed-off-by: Rosen Penev <rosenp@gmail.com>
Acked-by: Toke Høiland-Jørgensen <toke@toke.dk>
Link: https://patch.msgid.link/20260521231806.261220-1-rosenp@gmail.com
Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
12 days agowifi: ath9k: remove TX99 power array zero init
Rosen Penev [Sun, 17 May 2026 22:21:36 +0000 (15:21 -0700)] 
wifi: ath9k: remove TX99 power array zero init

This array is fully initialized in the loop itself. No need to zero
initialize and then overwrite.

Remove static from the array. This was a holdover from when the array
was a static global variable. It no longer confers any benefit.

Also add a min() call to avoid the manual if/ternary operation.

Assisted-by: Codex:GPT-5.5
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Acked-by: Toke Høiland-Jørgensen <toke@toke.dk>
Link: https://patch.msgid.link/20260517222136.1660347-1-rosenp@gmail.com
Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
12 days agowifi: ath9k: Clear DMA descriptors without memset
Rosen Penev [Sun, 17 May 2026 04:27:16 +0000 (21:27 -0700)] 
wifi: ath9k: Clear DMA descriptors without memset

Clear ath9k DMA descriptors with explicit status word stores instead of
memset(). The descriptor rings are coherent DMA memory, which may be
mapped uncached on 32-bit powerpc. The optimized memset() path can use
dcbz there and trigger an alignment warning.

Use WRITE_ONCE() for the descriptor status words so the compiler keeps
the clears as ordinary stores instead of folding them back into bulk
memset(). This covers AR9003 TX status descriptors as well as the RX
status area cleared when setting up RX descriptors.

Assisted-by: Codex:GPT-5.5
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Acked-by: Toke Høiland-Jørgensen <toke@toke.dk>
Link: https://patch.msgid.link/20260517042716.2218386-1-rosenp@gmail.com
Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
12 days agowifi: ath9k_htc: use module_usb_driver
Rosen Penev [Wed, 6 May 2026 23:48:48 +0000 (16:48 -0700)] 
wifi: ath9k_htc: use module_usb_driver

This follows the pattern with other USB Wifi drivers. There is nothing
special being done in the _init and _exit functions here. Simplifies and
saves some lines of code.

Signed-off-by: Rosen Penev <rosenp@gmail.com>
Acked-by: Toke Høiland-Jørgensen <toke@toke.dk>
Link: https://patch.msgid.link/20260506234848.189840-1-rosenp@gmail.com
Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
12 days agowifi: wcn36xx: allocate chan_surveys with main struct
Rosen Penev [Tue, 19 May 2026 02:03:17 +0000 (19:03 -0700)] 
wifi: wcn36xx: allocate chan_surveys with main struct

Avoid allocating separately with a flexible array member. Simplifies
allocation slightly.

Signed-off-by: Rosen Penev <rosenp@gmail.com>
Reviewed-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
Link: https://patch.msgid.link/20260519020317.635011-1-rosenp@gmail.com
Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
12 days agowifi: wcn36xx: fix spelling mistakes in dxe header comment
Stepan Ionichev [Sun, 3 May 2026 16:58:32 +0000 (21:58 +0500)] 
wifi: wcn36xx: fix spelling mistakes in dxe header comment

Fix three spelling mistakes in the DMA Transfer Engine (DXE)
description comment at the top of dxe.c.

No functional change.

Signed-off-by: Stepan Ionichev <sozdayvek@gmail.com>
Link: https://patch.msgid.link/20260503165832.1675-1-sozdayvek@gmail.com
Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
12 days agowifi: wcn36xx: fix OOB read from short trigger BA firmware response
Tristan Madani [Tue, 21 Apr 2026 13:50:18 +0000 (13:50 +0000)] 
wifi: wcn36xx: fix OOB read from short trigger BA firmware response

The firmware response length is only checked against sizeof(*rsp) (20
bytes), but when candidate_cnt >= 1, a 22-byte candidate struct is read
at buf + 20 without verifying the response contains it. This causes an
out-of-bounds read of stale heap data, corrupting the BA session state.

Add validation that the response includes the candidate data.

Fixes: 16be1ac55944 ("wcn36xx: Parse trigger_ba response properly")
Signed-off-by: Tristan Madani <tristan@talencesecurity.com>
Reviewed-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
Link: https://patch.msgid.link/20260421135018.352774-4-tristmd@gmail.com
Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
12 days agowifi: wcn36xx: fix OOB read from firmware count in PRINT_REG_INFO indication
Tristan Madani [Tue, 21 Apr 2026 13:50:17 +0000 (13:50 +0000)] 
wifi: wcn36xx: fix OOB read from firmware count in PRINT_REG_INFO indication

The firmware-controlled rsp->count field is used as the loop bound for
indexing into the flexible rsp->regs[] array without validation against
the message length. A count exceeding the actual data causes out-of-
bounds reads from the heap-allocated message buffer.

Add a check that count fits within the received message.

Fixes: 43efa3c0f241 ("wcn36xx: Implement print_reg indication")
Signed-off-by: Tristan Madani <tristan@talencesecurity.com>
Reviewed-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
Link: https://patch.msgid.link/20260421135018.352774-3-tristmd@gmail.com
Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
12 days agowifi: wcn36xx: fix heap overflow from oversized firmware HAL response
Tristan Madani [Tue, 21 Apr 2026 13:50:16 +0000 (13:50 +0000)] 
wifi: wcn36xx: fix heap overflow from oversized firmware HAL response

The firmware response dispatcher copies all synchronous HAL responses
into the 4096-byte hal_buf without validating the response length. A
response exceeding WCN36XX_HAL_BUF_SIZE causes a heap buffer overflow
with firmware-controlled content.

Add a bounds check on the response length.

Fixes: 8e84c2582169 ("wcn36xx: mac80211 driver for Qualcomm WCN3660/WCN3680 hardware")
Signed-off-by: Tristan Madani <tristan@talencesecurity.com>
Reviewed-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
Link: https://patch.msgid.link/20260421135018.352774-2-tristmd@gmail.com
Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
12 days agoMerge tag 'vfs-7.1-rc7.fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs
Linus Torvalds [Sat, 6 Jun 2026 14:28:59 +0000 (07:28 -0700)] 
Merge tag 'vfs-7.1-rc7.fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs

Pull vfs fixes from Christian Brauner:

 - Fix error handling in ovl_cache_get()

 - Tighten access checks for exited tasks in pidfd_getfd()

 - Fix selftests leak in __wait_for_test()

 - Limit FUSE_NOTIFY_RETRIEVE to uptodate folios

 - Reject fuse_notify() pagecache ops on directories

 - Clear JOBCTL_PENDING_MASK for caller in zap_other_threads()

 - Fix failure to unlock in nfsd4_create_file()

 - Fix pointer arithmetic in qnx6 directory iteration

 - Fix UAF due to unlocked ->mnt_ns read in may_decode_fh()

 - Avoid potential null folio->mapping deref during iomap error
   reporting

* tag 'vfs-7.1-rc7.fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs:
  iomap: avoid potential null folio->mapping deref during error reporting
  fhandle: fix UAF due to unlocked ->mnt_ns read in may_decode_fh()
  fs/qnx6: fix pointer arithmetic in directory iteration
  VFS: fix possible failure to unlock in nfsd4_create_file()
  signal: clear JOBCTL_PENDING_MASK for caller in zap_other_threads()
  fuse: reject fuse_notify() pagecache ops on directories
  fuse: limit FUSE_NOTIFY_RETRIEVE to uptodate folios
  selftests: harness: fix pidfd leak in __wait_for_test
  pidfd: refuse access to tasks that have started exiting harder
  ovl: keep err zero after successful ovl_cache_get()

12 days agorust: i2c: fix I2cAdapter refcounts double increment
Nicolás Antinori [Sun, 31 May 2026 18:23:07 +0000 (15:23 -0300)] 
rust: i2c: fix I2cAdapter refcounts double increment

When `I2cAdapter::get` executes, it first calls
`bindings::i2c_get_adapter()` which increments the device and module
reference counts. It then takes a reference to the raw pointer and
converts it to an `ARef` via `.into()`.

The implementation of `From<&T> for ARef<T>` where `T: AlwaysRefCounted`
unconditionally calls `T::inc_ref()`. This leads to a second increment
to the reference counts.

Since the returned `ARef` will only release a single reference when
dropped via `dec_ref()`, this leaks one device and module reference count
on every call.

This fix was suggested by sashiko.dev.

Link: https://sashiko.dev/#/patchset/20260521190937.248904-1-nico.antinori.7@gmail.com
Signed-off-by: Nicolás Antinori <nico.antinori.7@gmail.com>
Reviewed-by: Igor Korotin <igor.korotin@linux.dev>
Signed-off-by: Igor Korotin <igor.korotin@linux.dev>
12 days agovfs: uapi: retire octal and hex numbers in favor of (1 << n) for O_ flags
Jori Koolstra [Thu, 4 Jun 2026 22:24:05 +0000 (00:24 +0200)] 
vfs: uapi: retire octal and hex numbers in favor of (1 << n) for O_ flags

A recent build failure[1] exposed the diffculty of working with the
current octal and hex definitions of O_ flags when trying to find a gap
for a new flag. This difficulty is compounded by the fact that O_ flags
may have architectural specific values.

Replace the hex/octal #defines, which are hard to parse when looking for
free bits, with explicit bit shifts like (1 << 11). Also, add comments
that identify which architectures redefine some of the seemingly free
("cursed") bits in uapi/asm-generic/fcntl.h. These should not be used to
define new O_ flags (for now, at least).

The translastion was done with Claude Opus 4.8, and verified with a
(non-AI) gawk script. The accounting of which architectures claim
which bit-gaps in uapi/asm-generic/fcntl.h is also done by hand.

[1]: https://lore.kernel.org/all/agruPPybCx8q2XcJ@sirena.org.uk/

Assisted-by: Claude:Opus 4.8
Signed-off-by: Jori Koolstra <jkoolstra@xs4all.nl>
Link: https://patch.msgid.link/20260604222405.5382-1-jkoolstra@xs4all.nl
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
12 days agobpf: add bpf_real_inode() kfunc
Christian Brauner [Tue, 26 May 2026 12:02:22 +0000 (14:02 +0200)] 
bpf: add bpf_real_inode() kfunc

Add a sleepable BPF kfunc that resolves the real inode backing a dentry
via d_real_inode(). On overlay/union filesystems the inode attached to
the dentry is the overlay inode which does not carry the underlying
device information. d_real_inode() resolves through the overlay and
returns the inode from the lower, real filesystem.

This is used in the RestrictFilesytemAccess bpf program that has been
merged into systemd a little while ago.

Link: https://github.com/systemd/systemd/pull/41340
Link: https://patch.msgid.link/20260526-work-bpf-verity-v2-1-cd0b1850d31b@kernel.org
Reviewed-by: Amir Goldstein <amir73il@gmail.com>
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
12 days agobpf: Add simple xattr support to bpffs
Daniel Borkmann [Tue, 2 Jun 2026 07:40:12 +0000 (09:40 +0200)] 
bpf: Add simple xattr support to bpffs

Add support for extended attributes on bpffs inodes so that user space
and BPF LSM programs can attach metadata, for example, a content hash
or a security label - to a pinned object or directory. BPF LSM or user
space tooling can then uniformly look at this (e.g. security.bpf.*) in
similar way to other fs'es. The store is in-memory and non-persistent:
it lives only for the lifetime of the mount, like everything else in
bpffs. The modelling is similar to tmpfs.

bpffs serves the trusted.* and security.* namespaces; user.* is left
unsupported. As bpffs is FS_USERNS_MOUNT, security.* is reachable by
the unprivileged mounter in a user namespace, and thus we are using
the simple_xattr_set_limited infra there (trusted.* needs global
CAP_SYS_ADMIN).

bpf_fill_super() is open-coded instead of using simple_fill_super(),
because the root inode must now be allocated through bpf_fs_alloc_inode()
i.e. carry the bpf_fs_inode wrapper and come from the right cache -
which requires s_op (and s_xattr) to be installed before the first
inode is created. While at it, also harden s_iflags with SB_I_NOEXEC
and SB_I_NODEV.

bpf_fs_listxattr() is only reachable through the filesystem via
i_op->listxattr, so the BPF token inode is left untouched. Name-based
fsetxattr()/fgetxattr() on a token fd still work since the get/set
handlers are installed at the superblock.

For security.* namespace, we use simple_xattr_set_limited() but
there was no simple_xattr_add_limited() API yet which was needed
in bpf_fs_initxattrs() to avoid underflows in the accounting. The
symlink target is freed in bpf_free_inode() rather than in
bpf_destroy_inode() so that it is released only after an RCU grace
period, as an RCU path walk following the symlink may still
dereference inode->i_link in security_inode_follow_link(). Lastly,
the bpf_symlink() allocated the symlink target is switched to
GFP_KERNEL_ACCOUNT, so the string is charged to the caller's memcg.

Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Link: https://patch.msgid.link/20260602074012.416289-1-daniel@iogearbox.net
Cc: Christian Brauner <brauner@kernel.org>
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
12 days agokernfs: link kn to its parent before the LSM init hook
Christian Brauner [Tue, 26 May 2026 08:57:06 +0000 (10:57 +0200)] 
kernfs: link kn to its parent before the LSM init hook

After commit 12e9e3cd03b5 ("simpe_xattr: use per-sb cache"),
kernfs_xattr_set() and kernfs_xattr_get() compute the cache via
kernfs_root(kn) before any other check.  kernfs_root(kn) walks
kn->__parent first and falls back to kn->dir.root, both of which are
NULL on a freshly kmem_cache_zalloc()'d kn. kn->__parent was being set
in kernfs_new_node() after __kernfs_new_node() returned, and kn->dir.root
is set even later by kernfs_create_dir_ns() / kernfs_create_empty_dir().

The LSM kernfs_init_security hook is invoked from inside
__kernfs_new_node(), before either field has been initialized.
selinux_kernfs_init_security() ends with kernfs_xattr_set(kn,
XATTR_NAME_SELINUX, ...).  kernfs_root(kn) then returns NULL, and
&((struct kernfs_root *)NULL)->xa_cache evaluates to
offsetof(struct kernfs_root, xa_cache) which faults:

  BUG: kernel NULL pointer dereference, address: 00000000000000e0
  RIP: 0010:simple_xattr_set+0x27/0x8b0
  Call Trace:
   kernfs_xattr_set+0x63/0xb0
   selinux_kernfs_init_security+0x13b/0x270
   security_kernfs_init_security+0x36/0xc0
   __kernfs_new_node+0x182/0x290
   kernfs_new_node+0x80/0xc0
   kernfs_create_dir_ns+0x2b/0xa0
   cgroup_create+0x116/0x380
   cgroup_mkdir+0x7c/0x1a0

Reproduces deterministically at PID 1 (systemd) on an SELinux-enabled
distro. The first cgroup mkdir under /sys/fs/cgroup with a labelled
parent panics the kernel.

The LSM hook's contract is that the kn_dir argument is the parent of
the new kn, so kn->__parent should already point at kn_dir when the
hook runs.  Move kernfs_get(parent) and rcu_assign_pointer of
kn->__parent from kernfs_new_node() into __kernfs_new_node() right
before the security hook, and unwind the parent reference on the
err_out4 path.  kernfs_root(kn) then takes its parent branch during
the hook and returns parent->dir.root, which is the correct root.

This also closes the same-shape latent bug in kernfs_xattr_get() (which
today is hidden only by kernfs_iattrs_noalloc() returning NULL on a
fresh kn).

Fixes: 12e9e3cd03b5 ("simpe_xattr: use per-sb cache")
Reported-by: Calum Mackay <calum.mackay@oracle.com>
Closes: https://lore.kernel.org/all/5386153f-9112-4971-98fc-de90d7aae2c6@oracle.com/
Link: https://patch.msgid.link/20260526-ablief-demut-wehen-aef8446ef5c9@brauner
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
12 days agoMerge patch series "Rework simple xattrs"
Christian Brauner [Sat, 6 Jun 2026 13:21:46 +0000 (15:21 +0200)] 
Merge patch series "Rework simple xattrs"

Christian Brauner (Amutable) <brauner@kernel.org> says:

Rework the simple xattrs api to make it more efficient and easier to
use for all consumers.

* patches from https://patch.msgid.link/20260605135322.2632068-1-mszeredi@redhat.com:
  simpe_xattr: use per-sb cache
  simple_xattr: change interface to pass struct simple_xattrs **
  tmpfs: simplify constructing "security.foo" xattr names
  kernfs: fix xattr race condition with multiple superblocks

Link: https://patch.msgid.link/20260605135322.2632068-1-mszeredi@redhat.com
Signed-off-by: Christian Brauner <brauner@kernel.org>
12 days agosimpe_xattr: use per-sb cache
Miklos Szeredi [Fri, 5 Jun 2026 13:53:19 +0000 (15:53 +0200)] 
simpe_xattr: use per-sb cache

Move the hash table to the super block to remove excessive overhead in case
of small number of xattrs per inode.

Add linked list to the inode, used for listxattr and eviction.  Listxattr
uses rcu protection to iterate the list of xattrs.

Before being made per-sb, lazy allocation was protected by inode lock.  Now
inode lock no longer provides sufficient exclusion, so use cmpxchg() to
ensure atomicity.

Though I haven't found a description of this pattern, after some research
it seems that cmpxchg_release() and READ_ONCE() should provide the
necessary memory barriers.

Use simple_xattr_free_rcu() in simple_xattrs_free(). This is needed because
the hash table is now shared between inodes and lookup on a different inode
might be running the compare function on the just freed element within the
RCU grace period.

Following stats are based on slabinfo diff, after creating 100k empty
files, then adding a "user.test=foo" xattr to each:

v7.0 (no rhashtable):
  File creation: 993.40 bytes/file
  Xattr addition: 79.99 bytes/file

v7.1-rc2 (per-inode rhashtable):
  File creation: 939.73 bytes/file
  Xattr addition: 1296.08 bytes/file

v7.1-rc2 + this patch (per-sb rhashtable)
  File creation: 946.84 bytes/file
  Xattr addition: 111.86 bytes/file

The overhead of a single xattr is reduced to nearly v7.0 levels.  The per
xattr overhead is slightly larger due to the addition of three pointers to
struct simple_xattr.

Fixes: b32c4a213698 ("xattr: add rhashtable-based simple_xattr infrastructure")
Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
Link: https://patch.msgid.link/20260605135322.2632068-5-mszeredi@redhat.com
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
12 days agosimple_xattr: change interface to pass struct simple_xattrs **
Miklos Szeredi [Fri, 5 Jun 2026 13:53:18 +0000 (15:53 +0200)] 
simple_xattr: change interface to pass struct simple_xattrs **

Change the simple_xattr API to accept pointer-to-pointer (struct
simple_xattrs **) instead of pointer.  This allows the functions to handle
lazy allocation internally without requiring callers to use
simple_xattrs_lazy_alloc().

The simple_xattr_set(), simple_xattr_set_limited() and simple_xattr_add()
functions now handle allocation when xattrs is NULL.  simple_xattrs_free()
now also frees the xattrs structure itself and sets the pointer to NULL.

This simplifies callers and removes the need for most callers to explicitly
manage xattrs allocation and lifetime.

In shmem_initxattrs(), the total required space for all initial xattrs
(ispace) is pre-calculated and deducted from sbinfo->free_ispace.

Since this patch modifies the function to add new xattrs directly to the
inode's &info->xattrs list rather than using a local temporary variable, a
failure means that the partially populated info->xattrs list remains
attached to the inode.

When the VFS caller handles the -ENOMEM error, it drops the newly created
inode via iput(), shmem_free_inode() adds freed to sbinfo->free_ispace a
second time, permanently inflating the tmpfs free space quota.

Fix by substracting already added xattrs from ispace.

Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
Link: https://patch.msgid.link/20260605135322.2632068-4-mszeredi@redhat.com
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
12 days agotmpfs: simplify constructing "security.foo" xattr names
Miklos Szeredi [Fri, 5 Jun 2026 13:53:17 +0000 (15:53 +0200)] 
tmpfs: simplify constructing "security.foo" xattr names

Use kasprintf() instead of doing it with kmalloc() + 2 x memcpy().

Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
Link: https://patch.msgid.link/20260605135322.2632068-3-mszeredi@redhat.com
Tested-by: Calum Mackay <calum.mackay@oracle.com>
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
12 days agokernfs: fix xattr race condition with multiple superblocks
Miklos Szeredi [Fri, 5 Jun 2026 13:53:16 +0000 (15:53 +0200)] 
kernfs: fix xattr race condition with multiple superblocks

Multiple superblocks with different namespaces can share the same
kernfs_node when kernfs_test_super() finds a matching root but
different namespace. This means multiple inodes from different
superblocks can reference the same kernfs_node->iattr->xattrs
structure.

The VFS layer only holds per-inode locks during xattr operations,
which is insufficient to serialize concurrent xattr modifications on
the shared kernfs_node. This can lead to race conditions in
simple_xattr_set() where the lookup->replace/remove sequence is not
atomic with respect to operations from other superblocks.

Fix this by protecting xattr operations with the existing hashed
kernfs_locks->open_file_mutex[] array, which is already used to
protect per-node open file data. The hashed mutex array provides
scalable per-node serialization (scaled by CPU count, up to 1024 locks
on 32+ CPU systems) with zero memory overhead.

Changes:
- Rename open_file_mutex[] to node_mutex[] to reflect dual purpose
- Add kernfs_node_lock_ptr() and kernfs_node_lock() helpers
- Protect simple_xattr_set() calls in kernfs_xattr_set() and
  kernfs_vfs_user_xattr_set() with the hashed mutex
- Update file.c to use new helpers via compatibility wrappers
- Update documentation to explain the extended lock usage

Fixes: b32c4a213698 ("xattr: add rhashtable-based simple_xattr infrastructure")
Reported-by: Sashiko <sashiko-bot@kernel.org>
Closes: https://sashiko.dev/#/patchset/20260601162454.2116375-1-mszeredi%40redhat.com
Assisted-by: Claude:claude-sonnet-4-5
Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
Link: https://patch.msgid.link/20260605135322.2632068-2-mszeredi@redhat.com
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
12 days agodebugobjects: Don't call fill_pool() in early boot hardirq context
Waiman Long [Fri, 5 Jun 2026 17:30:38 +0000 (13:30 -0400)] 
debugobjects: Don't call fill_pool() in early boot hardirq context

When booting a debug PREEMPT_RT kernel on an ARM64 system, a "inconsistent
{HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage" lockdep warning message was
reported to the console.

During early boot, interrupts are enabled before the scheduler is
enabled. In this window (before SYSTEM_SCHEDULING is set) interrupts can
fire and in the hard interrupt context handler attempt to fill the pool

This can lead to a deadlock when the interrupt occurred when the interrupt
hits a region which holds a lock that is required to be taken in the
allocation path.

Add a new can_fill_pool() helper and reorder the exception rule and forbid
this scenario by excluding allocations from hard interrupt context.

Fixes: 06e0ae988f6e ("debugobjects: Allow to refill the pool before SYSTEM_SCHEDULING")
Suggested-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Suggested-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Waiman Long <longman@redhat.com>
Signed-off-by: Thomas Gleixner <tglx@kernel.org>
Reviewed-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20260605173038.495075-1-longman@redhat.com
12 days agoMerge tag 'pin-init-v7.2' of https://github.com/Rust-for-Linux/linux into rust-next
Miguel Ojeda [Sat, 6 Jun 2026 12:01:29 +0000 (14:01 +0200)] 
Merge tag 'pin-init-v7.2' of https://github.com/Rust-for-Linux/linux into rust-next

Pull pin-init updates from Gary Guo:
 "User visible changes:

   - Do not generate 'non_snake_case' warnings for identifiers that are
     syntactically just users of a field name. This would allow all
     '#[allow(non_snake_case)]' in nova-core to be removed, which I will
     send to the nova tree next cycle.

   - Filter non-cfg attributes out properly in derived structs. This
     improves pin-init compatibility with other derive macros.

   - Insert projection types' where clause properly.

  Other changes:

   - Bump MSRV to 1.82, plus associated cleanups.

   - Overhaul how init slots are projected. The new approach is easier
     to justify with safety comments.

   - Mark more functions as inline, which should help mitigate the
     super-long symbol name issue due to lack of inlining.

   - Various small code quality cleanups."

* tag 'pin-init-v7.2' of https://github.com/Rust-for-Linux/linux: (27 commits)
  rust: pin_init: internal: use `loop {}` to produce never value
  rust: pin-init: remove `E` from `InitClosure`
  rust: pin-init: move `InitClosure` out from `__internal`
  rust: pin-init: docs: fix typos in MaybeZeroable documentation
  rust: pin-init: internal: suppress `non_snake_case` lint in `[pin_]init!`
  rust: pin-init: internal: suppress `non_snake_case` lint in `#[pin_data]`
  rust: pin-init: internal: pin_data: filter non-`#[cfg]` attr in generated code
  rust: pin-init: internal: project using full slot
  rust: pin-init: internal: project slots instead of references
  rust: pin-init: internal: make `make_closure` inherent methods
  rust: pin-init: internal: use marker on drop guard type for pinned fields
  rust: pin-init: internal: init: handle code blocks early
  rust: pin-init: internal: add `PhantomInvariant` and `PhantomInvariantLifetime`
  rust: pin-init: internal: pin_data: add struct to record field info
  rust: pin-init: internal: pin_data: use closure for `handle_field`
  rust: pin-init: examples: fix `useless_borrows_in_formatting` clippy warning
  rust: pin-init: internal: remove `collect_tuple` polyfill after MSRV bump
  rust: pin-init: internal: turn `PhantomPinned` error into warnings
  rust: pin-init: cleanup workaround for old Rust compiler
  rust: pin-init: fix badge URL in README
  ...

13 days agokconfig: Remove the architecture specific config for Propeller
Rong Xu [Thu, 4 Jun 2026 19:56:08 +0000 (12:56 -0700)] 
kconfig: Remove the architecture specific config for Propeller

The CONFIG_PROPELLER_CLANG option currently depends on
ARCH_SUPPORTS_PROPELLER_CLANG, but this dependency seems unnecessary.

Remove ARCH_SUPPORTS_PROPELLER_CLANG and allow users to control
Propeller builds solely through CONFIG_PROPELLER_CLANG. This simplifies
the kconfig and avoids potential confusion.

Move the .llvm_bb_addr_map sections grouping to
include/asm-generic/vmlinux.lds.h.

The Propeller documentation has been updated to reflect the most
recent tool location and now includes instructions for arm64.

Contributor Acknowledgments:
  * SPE instructions: Daniel Hoekwater <hoekwater@google.com>

Signed-off-by: Rong Xu <xur@google.com>
Suggested-by: Will Deacon <will@kernel.org>
Suggested-by: Nathan Chancellor <nathan@kernel.org>
Tested-by: Yabin Cui <yabinc@google.com>
Reviewed-by: Kees Cook <kees@kernel.org>
Link: https://patch.msgid.link/20260604195612.3757860-3-xur@google.com
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
13 days agokconfig: Remove the architecture specific config for AutoFDO
Rong Xu [Thu, 4 Jun 2026 19:56:07 +0000 (12:56 -0700)] 
kconfig: Remove the architecture specific config for AutoFDO

The CONFIG_AUTOFDO_CLANG option currently depends on
ARCH_SUPPORTS_AUTOFDO_CLANG, but this dependency seems unnecessary.

Remove ARCH_SUPPORTS_AUTOFDO_CLANG and allow users to control AutoFDO
builds solely through CONFIG_AUTOFDO_CLANG. This simplifies the kconfig
and avoids potential confusion.

Expand the AutoFDO documentation to include instructions for arm64.

Contributor acknowledgments:
  * SPE instructions: Daniel Hoekwater <hoekwater@google.com>
  * ETM instructions: Yabin Cui <yabinc@google.com>

Signed-off-by: Rong Xu <xur@google.com>
Suggested-by: Will Deacon <will@kernel.org>
Tested-by: Yabin Cui <yabinc@google.com>
Reviewed-by: Kees Cook <kees@kernel.org>
Link: https://patch.msgid.link/20260604195612.3757860-2-xur@google.com
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
13 days agomodpost: Add __llvm_covfun and __llvm_covmap to section_white_list
James Lee [Thu, 4 Jun 2026 06:03:00 +0000 (14:03 +0800)] 
modpost: Add __llvm_covfun and __llvm_covmap to section_white_list

Modpost emits hundreds of warnings when using Clang to build for ARCH=um
and CONFIG_GCOV=y. e.g.:
    vmlinux (__llvm_covfun): unexpected non-allocatable section.
    Did you forget to use "ax"/"aw" in a .S file?
    Note that for example <linux/init.h> contains
    section definitions for use in .S files.

For example, when we use LLVM for a kunit user mode build with coverage:
    python3 tools/testing/kunit/kunit.py build --make_options LLVM=1 \
        --kunitconfig=tools/testing/kunit/configs/default.config \
        --kunitconfig=tools/testing/kunit/configs/coverage_uml.config

The behaviour occurs when building the kernel for ARCH=um with code
coverage enabled. The warnings come from modpost's check_sec_ref
function, which ensures no sections reference others that will be
discarded. covfun and covmap sections must reference __init and __exit
sections to collect coverage data, triggering the modpost warning.

To suppress these warnings, these section names have been added to
modpost's whitelist. This is unlikely to suppress legitimate warnings as
Clang will only insert these sections when building with coverage, and
can be assumed to manage these references safely.

Signed-off-by: James Lee <james@codeconstruct.com.au>
Link: https://patch.msgid.link/20260604-dev-coverage-patch-v1-1-9f9368253cb4@codeconstruct.com.au
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
13 days agoselftests/bpf: Inspect the signature verdict exposed to BPF LSM
Daniel Borkmann [Fri, 5 Jun 2026 21:35:18 +0000 (23:35 +0200)] 
selftests/bpf: Inspect the signature verdict exposed to BPF LSM

Add a minimal BPF LSM program on lsm/bpf_prog_load that, for loads on
the monitored thread, reads back prog->aux->sig.{verdict,keyring_type,
keyring_serial}, and a signed_loader subtest that drives the same
gen_loader loader through the hook twice: i) /unsigned/ where the LSM
must observe UNSIGNED, no keyring and serial 0; ii) /signed/ where the
very same insns signed against the session keyring must be observed as
VERIFIED with a user keyring, and the recorded keyring_serial must be
equal to the resolved session keyring serial. Loading (not running) the
loader is sufficient since the verdict is attached at load time.

  # LDLIBS=-static PKG_CONFIG='pkg-config --static' ./vmtest.sh -- ./test_progs -t signed_loader
  [    1.970530] clocksource: Switched to clocksource tsc
  #405/1   signed_loader/metadata_check_shape:OK
  #405/2   signed_loader/metadata_match:OK
  #405/3   signed_loader/metadata_sha_mismatch:OK
  #405/4   signed_loader/metadata_not_exclusive:OK
  #405/5   signed_loader/metadata_hash_not_computed:OK
  #405/6   signed_loader/signature_enforced:OK
  #405/7   signed_loader/signature_too_large:OK
  #405/8   signed_loader/signature_bad_keyring:OK
  #405/9   signed_loader/metadata_ctx_max_entries_ignored:OK
  #405/10  signed_loader/metadata_ctx_initial_value_ignored:OK
  #405/11  signed_loader/signature_authenticates_insns:OK
  #405/12  signed_loader/hash_requires_frozen:OK
  #405/13  signed_loader/no_update_after_freeze:OK
  #405/14  signed_loader/freeze_writable_mmap:OK
  #405/15  signed_loader/no_writable_mmap_frozen:OK
  #405/16  signed_loader/map_hash_matches_libbpf:OK
  #405/17  signed_loader/map_hash_multi_element:OK
  #405/18  signed_loader/map_hash_bad_size:OK
  #405/19  signed_loader/map_hash_unsupported_type:OK
  #405/20  signed_loader/lsm_signature_verdict:OK
  #405     signed_loader:OK
  Summary: 1/20 PASSED, 0 SKIPPED, 0 FAILED

Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Link: https://lore.kernel.org/r/20260605213518.544262-2-daniel@iogearbox.net
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
13 days agobpf: Expose signature verdict via bpf_prog_aux
KP Singh [Fri, 5 Jun 2026 21:35:17 +0000 (23:35 +0200)] 
bpf: Expose signature verdict via bpf_prog_aux

BPF_PROG_LOAD verifies the loader signature but does not record the
outcome on the BPF program. [BPF] LSMs and audit can read attr->signature
and attr->keyring_id to infer "was this signed, and if so, against which
keyring".

Add prog->aux->sig (verdict + keyring_{type,serial}), populated by
bpf_prog_load before the LSM hook. keyring_type classifies the keyring
the load referenced (builtin, secondary, platform or user), while
keyring_serial records the serial of the keyring the signature was
actually validated against. System keyrings carry a pseudo key pointer
with no user-visible serial and are reported as 0, as are unsigned loads.
Failed verifications reject the load before the hook runs, so it observes
only either UNSIGNED or VERIFIED.

Signed-off-by: KP Singh <kpsingh@kernel.org>
Co-developed-by: Daniel Borkmann <daniel@iogearbox.net>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Link: https://lore.kernel.org/r/20260605213518.544262-1-daniel@iogearbox.net
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
13 days agoMerge branch 'selftests-bpf-libarena-add-initial-data-structures'
Alexei Starovoitov [Sat, 6 Jun 2026 03:32:21 +0000 (20:32 -0700)] 
Merge branch 'selftests-bpf-libarena-add-initial-data-structures'

Emil Tsalapatis says:

====================
selftests/bpf: libarena: Add initial data structures

Add two new data structures to libarena. These data structures initially
resided in the sched-ext repo (https://github.com/sched-ext/scx) and
have been adapted to the internal libarena build system. The data
structures are:

- Red black tree: Fundamental tree data structure that can also serve
  as a base for more domain-specific data structures.

- Lev-Chase deque: Queue data structure that allows efficient work
  stealing, useful in scheduling scenarios.

The data structures are accompanied by selftests that are automatically
discovered by the existing libarena test_progs selftest and incorporated
in the CI.

CHANGELOG
=========

v3 -> v4 (https://lore.kernel.org/bpf/20260604235016.20856-1-emil@etsalapatis.com/)
- Turn off load_acquire/store_relesase - dependent selftests for s390 (CI)
- Various style/non-functional nits (AI)

v2 -> v3 (https://lore.kernel.org/bpf/20260603182727.3922-1-emil@etsalapatis.com/)

- Add workaround to handle LLVM 21 and GCC 15 assignment-to-memset promotions
  that are causing verification failures for arena programs (CI)
- Incorporate Sashiko feedback for cleanup edge cases (Sashiko)
- Simplify some of the ordering semantics in spmc

v1 -> v2 (https://lore.kernel.org/bpf/20260511214100.9487-1-emil@etsalapatis.com/):

- Rename tests from st_ to test_ (Alexei)
- Removed the freelist caches from the rbtrees, previously used to defer freeing (Alexei)
- Moved the type and function definitions to use the __arena identifier
- Removed the typecasts during function return and directly return __arena
  pointers (Alexei)
- Renamed queues to spmc queues to abstract away the algorithm (Alexei)
- Adjusted the memory barriers in the spmc queue
- Added multithreaded testing harness for libarena programs (Alexei)
- Added parallel selftest for queues (Alexei)
- Split least upper bound and exact find operations back into separate
  functions to prevent RB_DUPLICATE-related bug (AI)
====================

Link: https://patch.msgid.link/20260605222020.5231-1-emil@etsalapatis.com
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
13 days agoselftests/bpf: libarena: parallel test harness and spmc parallel selftest
Emil Tsalapatis [Fri, 5 Jun 2026 22:20:20 +0000 (18:20 -0400)] 
selftests/bpf: libarena: parallel test harness and spmc parallel selftest

Add a parallel test for the SPMC Lev-Chase workstealing queue. The queue
is built to be wait-free even when there are multiple consumers, and
the parallel selftest provides a signal on whether the queue behaves
correctly when stress tested.

To support the test, this patch includes a test harness for parallel
selftests. The spmc selftest acts as an example of the naming and other
conventions expected by the harness.

Signed-off-by: Emil Tsalapatis <emil@etsalapatis.com>
Link: https://lore.kernel.org/r/20260605222020.5231-4-emil@etsalapatis.com
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
13 days agoselftests/bpf: libarena: Add spmc queue data structure
Emil Tsalapatis [Fri, 5 Jun 2026 22:20:19 +0000 (18:20 -0400)] 
selftests/bpf: libarena: Add spmc queue data structure

Expand libarena with a single producer multiple consumer deque data
structure. This is a single producer, multiple consumer lockless structure
that permits efficient work stealing. The structure is a Lev-Chase queue,
so it is lock-free and wait-free.

The data structure exposes three main calls. two of them are available to
the thread owning the queue and one available to all threads in the program:

spmc_owner_push(): Push an item to the top of the queue.
spmc_owner_pop(): Pop an item from the top of the queue.
spmc_steal(): Steal a thread from the bottom of the queue from
any thread.

Note that the queue is not really FIFO for all consumers, since
non-owners of the queue can only work steal from the bottom.

Signed-off-by: Emil Tsalapatis <emil@etsalapatis.com>
Link: https://lore.kernel.org/r/20260605222020.5231-3-emil@etsalapatis.com
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
13 days agoselftests/bpf: libarena: Add rbtree data structure
Emil Tsalapatis [Fri, 5 Jun 2026 22:20:18 +0000 (18:20 -0400)] 
selftests/bpf: libarena: Add rbtree data structure

Add a native red-black tree data structure to libarena.
The data structure supports multiple APIs (key-value based,
node based) with which users can query and modify it. The
tree uses the libarena memory allocator to manage its data.

Signed-off-by: Emil Tsalapatis <emil@etsalapatis.com>
Link: https://lore.kernel.org/r/20260605222020.5231-2-emil@etsalapatis.com
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
13 days agonet: stmmac: xgmac: report L3/L4 filter match count in ethtool stats
Nazim Amirul [Thu, 4 Jun 2026 08:30:37 +0000 (01:30 -0700)] 
net: stmmac: xgmac: report L3/L4 filter match count in ethtool stats

Read the L3FM and L4FM bits from the RX descriptor status word (RDES2)
and increment the corresponding ethtool statistics counters. This allows
users to observe L3/L4 filter hit rates via ethtool -S.

Signed-off-by: Rohan G Thomas <rohan.g.thomas@altera.com>
Signed-off-by: Nazim Amirul <muhammad.nazim.amirul.nazle.asmade@altera.com>
Reviewed-by: Jacob Keller <jacob.e.keller@intel.com>
Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Link: https://patch.msgid.link/20260604083037.24407-1-muhammad.nazim.amirul.nazle.asmade@altera.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
13 days agonet: microchip: sparx5: clean up PSFP resources on flower setup failure
Haoxiang Li [Wed, 3 Jun 2026 06:17:16 +0000 (14:17 +0800)] 
net: microchip: sparx5: clean up PSFP resources on flower setup failure

sparx5_tc_flower_psfp_setup() allocates PSFP stream gate, flow meter and
stream filter resources before adding VCAP actions. If a later step
fails, the resources allocated earlier in the function are not unwound.

Add error paths to release the stream filter, flow meter and stream gate
when setup fails after they have been acquired.

Also make sparx5_psfp_fm_add() return the acquired flow-meter id before
the existing-flow-meter early return. When an existing flow meter is
reused, sparx5_psfp_fm_get() increments its pool reference count, but the
caller previously kept psfp_fmid as 0. If a later setup step failed, the
error path could try to delete flow-meter id 0 instead of the reused flow
meter, leaving the incremented reference behind.

Signed-off-by: Haoxiang Li <lihaoxiang@isrc.iscas.ac.cn>
Link: https://patch.msgid.link/20260603061716.747282-1-lihaoxiang@isrc.iscas.ac.cn
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
13 days agonetlabel: validate unlabeled address and mask attribute lengths
Chenguang Zhao [Wed, 3 Jun 2026 01:13:53 +0000 (09:13 +0800)] 
netlabel: validate unlabeled address and mask attribute lengths

netlbl_unlabel_addrinfo_get() used the address attribute length to
determine whether the attribute data could be read as an IPv4 or IPv6
address, but did not independently validate the corresponding mask
attribute length.  A crafted Generic Netlink request could therefore
provide a valid IPv4/IPv6 address attribute with a shorter mask
attribute, which would later be read as a full struct in_addr or
struct in6_addr.

NLA_BINARY policy lengths are maximum lengths by default, so use
NLA_POLICY_EXACT_LEN() for the unlabeled IPv4/IPv6 address and mask
attributes.  This rejects short attributes during policy validation and
also exposes the exact length requirements through policy introspection.

Fixes: 8cc44579d1bd ("NetLabel: Introduce static network labels for unlabeled connections")
Signed-off-by: Chenguang Zhao <zhaochenguang@kylinos.cn>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
13 days agoMerge branch 'net-airoha-support-multiple-net_devices-connected-to-the-same-gdm-port'
Jakub Kicinski [Sat, 6 Jun 2026 01:46:55 +0000 (18:46 -0700)] 
Merge branch 'net-airoha-support-multiple-net_devices-connected-to-the-same-gdm-port'

Lorenzo Bianconi says:

====================
net: airoha: Support multiple net_devices connected to the same GDM port

EN7581 or AN7583 SoCs support connecting multiple external SerDes (e.g.
Ethernet or USB SerDes) to GDM3 or GDM4 ports via a hw arbiter that
manages the traffic in a TDM manner. As a result multiple net_devices can
connect to the same GDM{3,4} port and there is a theoretical "1:n"
relation between GDM ports and net_devices.

           ┌─────────────────────────────────┐
           │                                 │    ┌──────┐
           │                         P1 GDM1 ├────►MT7530│
           │                                 │    └──────┘
           │                                 │      ETH0 (DSA conduit)
           │                                 │
           │              PSE/FE             │
           │                                 │
           │                                 │
           │                                 │    ┌─────┐
           │                         P0 CDM1 ├────►QDMA0│
           │  P4                     P9 GDM4 │    └─────┘
           └──┬─────────────────────────┬────┘
              │                         │
           ┌──▼──┐                 ┌────▼────┐
           │ PPE │                 │   ARB   │
           └─────┘                 └─┬─────┬─┘
                                     │     │
                                  ┌──▼──┐┌─▼───┐
                                  │ ETH ││ USB │
                                  └─────┘└─────┘
                                   ETH1   ETH2

This series introduces support for multiple net_devices connected to the
same Frame Engine (FE) GDM port (GDM3 or GDM4) via an external hw
arbiter. Please note GDM1 or GDM2 does not support the connection with
the external arbiter.
====================

Link: https://patch.msgid.link/20260603-airoha-eth-multi-serdes-v9-0-5d476bc2f426@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
13 days agonet: airoha: Support multiple LAN/WAN interfaces for hw MAC address configuration
Lorenzo Bianconi [Wed, 3 Jun 2026 06:00:20 +0000 (08:00 +0200)] 
net: airoha: Support multiple LAN/WAN interfaces for hw MAC address configuration

The EN7581 and AN7583 SoCs provide registers to configure hardware LAN/WAN
MAC addresses. These registers are used during FE hw acceleration to
determine whether received traffic is destined to this host (L3 traffic)
or should be switched to another device (L2 traffic).
The SoC hardware design assumes all interfaces configured as LAN (or WAN)
share the MAC address MSBs, which are programmed into the
REG_FE_{LAN,WAN}_MAC_H register. The LSBs of 'local' mac addresses can be
expressed as a range via the REG_FE_MAC_LMIN and REG_FE_MAC_LMAX
registers. In order to properly accelerate the traffic, FE module requires
the user to configure the REG_FE_{LAN,WAN}_MAC_H register respecting this
limitation. Please note a misconfiguration in REG_FE_{LAN,WAN}_MAC_H
will still allow the user to log into the device for debugging.
Previously, only a single interface was considered when programming these
registers. Extend the logic to derive the correct minimum and maximum
values for REG_FE_MAC_LMIN/REG_FE_MAC_LMAX when two or more interfaces are
configured as LAN or WAN. Since this functionality was not available
before this series, no regression is introduced.

Tested-by: Madhur Agrawal <madhur.agrawal@airoha.com>
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Link: https://patch.msgid.link/20260603-airoha-eth-multi-serdes-v9-6-5d476bc2f426@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
13 days agonet: airoha: Introduce WAN device flag
Lorenzo Bianconi [Wed, 3 Jun 2026 06:00:19 +0000 (08:00 +0200)] 
net: airoha: Introduce WAN device flag

Introduce WAN flag to specify if a given device is used to transmit/receive
WAN or LAN traffic. Current codebase supports specifying LAN/WAN device
configuration in ndo_init() callback during device bootstrap.
In order to consider setups where LAN configuration is used even for
GDM3/GDM4 devices, check airoha_is_lan_gdm_dev() to select pse_port in
airoha_ppe_foe_entry_prepare().
Please note after this patch, it will be possible to specify multiple LAN
devices but just a single WAN one. Please note this change is not visible
to the user since airoha_eth driver currently supports just the internal
phy available via the MT7530 DSA switch and there are no WAN interfaces
officially supported since PCS/external phy is not merged mainline yet
(it will be posted with following patches).

Tested-by: Xuegang Lu <xuegang.lu@airoha.com>
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Link: https://patch.msgid.link/20260603-airoha-eth-multi-serdes-v9-5-5d476bc2f426@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
13 days agonet: airoha: Do not stop GDM port if it is shared
Lorenzo Bianconi [Wed, 3 Jun 2026 06:00:18 +0000 (08:00 +0200)] 
net: airoha: Do not stop GDM port if it is shared

Theoretically, in the current codebase, two independent net_devices can
be connected to the same GDM port so we need to check the GDM port is not
used by any other running net_device before setting the forward
configuration to FE_PSE_PORT_DROP.
Moreover, always set in GDM_LONG_LEN_MASK field of REG_GDM_LEN_CFG
register the maximum MTU of all running net_devices connected to the same
GDM port.

Tested-by: Xuegang Lu <xuegang.lu@airoha.com>
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Link: https://patch.msgid.link/20260603-airoha-eth-multi-serdes-v9-4-5d476bc2f426@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
13 days agonet: airoha: Support multiple net_devices for a single FE GDM port
Lorenzo Bianconi [Wed, 3 Jun 2026 06:00:17 +0000 (08:00 +0200)] 
net: airoha: Support multiple net_devices for a single FE GDM port

EN7581 or AN7583 SoCs support connecting multiple external SerDes (e.g.
Ethernet or USB SerDes) to GDM3 or GDM4 ports via a hw arbiter that
manages the traffic in a TDM manner. As a result multiple net_devices can
connect to the same GDM{3,4} port and there is a theoretical "1:n"
relation between GDM ports and net_devices.

           ┌─────────────────────────────────┐
           │                                 │    ┌──────┐
           │                         P1 GDM1 ├────►MT7530│
           │                                 │    └──────┘
           │                                 │      ETH0 (DSA conduit)
           │                                 │
           │              PSE/FE             │
           │                                 │
           │                                 │
           │                                 │    ┌─────┐
           │                         P0 CDM1 ├────►QDMA0│
           │  P4                     P9 GDM4 │    └─────┘
           └──┬─────────────────────────┬────┘
              │                         │
           ┌──▼──┐                 ┌────▼────┐
           │ PPE │                 │   ARB   │
           └─────┘                 └─┬─────┬─┘
                                     │     │
                                  ┌──▼──┐┌─▼───┐
                                  │ ETH ││ USB │
                                  └─────┘└─────┘
                                   ETH1   ETH2

Introduce support for multiple net_devices connected to the same Frame
Engine (FE) GDM port (GDM3 or GDM4) via an external hw arbiter.
Please note GDM1 or GDM2 does not support the connection with the external
arbiter.
Add get_dev_from_sport callback since EN7581 and AN7583 have different
logics for the net_device type connected to GDM3 or GDM4.

Tested-by: Xuegang Lu <xuegang.lu@airoha.com>
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Link: https://patch.msgid.link/20260603-airoha-eth-multi-serdes-v9-3-5d476bc2f426@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
13 days agonet: airoha: Remove private net_device pointer in airoha_gdm_dev struct
Lorenzo Bianconi [Wed, 3 Jun 2026 06:00:16 +0000 (08:00 +0200)] 
net: airoha: Remove private net_device pointer in airoha_gdm_dev struct

Remove redundant net_device pointer inside airoha_gdm_dev struct and
rely on netdev_from_priv routine instead. Please note this patch does
not introduce any logical change, just code refactoring.

Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Link: https://patch.msgid.link/20260603-airoha-eth-multi-serdes-v9-2-5d476bc2f426@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
13 days agodt-bindings: net: airoha: Add GDM port ethernet child node
Lorenzo Bianconi [Wed, 3 Jun 2026 06:00:15 +0000 (08:00 +0200)] 
dt-bindings: net: airoha: Add GDM port ethernet child node

EN7581 and AN7583 SoCs support connecting multiple external SerDes to GDM3
or GDM4 ports via a hw arbiter that manages the traffic in a TDM manner.
As a result multiple net_devices can connect to the same GDM{3,4} port
and there is a theoretical "1:n" relation between GDM ports and
net_devices.
Introduce the ethernet node child of a specific GDM port in order to model
a given net_device that is connected via the external arbiter to the
GDM{3,4} port. This new ethernet node is defined by the "airoha,eth-port"
compatible string. Please note GDM1 and GDM2 does not support the
connection with the external arbiter and they are represented by an
ethernet node defined by the "airoha,eth-mac" compatible string.

Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Link: https://patch.msgid.link/20260603-airoha-eth-multi-serdes-v9-1-5d476bc2f426@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
13 days agoMerge branch 'net-mdio-realtek-rtl9300-refactor-initialization-and-port-lookup'
Jakub Kicinski [Sat, 6 Jun 2026 01:38:59 +0000 (18:38 -0700)] 
Merge branch 'net-mdio-realtek-rtl9300-refactor-initialization-and-port-lookup'

Markus Stockhausen says:

====================
net: mdio: realtek-rtl9300: Refactor initialization and port lookup

The Realtek Otto switch platform consists of four different series

- RTL838x aka maple   : 28 port 1G Switches
- RTL839x aka cypress : 52 port 1G Switches
- RTL930x aka longan  : 28 port 1G/2.5G/10G Switches
- RTL931x aka mango   : 56 port 1G/2.5G/10G Switches

A lot has been done to enhance the ethernet MDIO driver for simple
integration of more SoCs. Now it is time to solve inconveniences
that were discovered during daily operation. That includes

- Consistent "of" API usage
- Tightening error handling and improving overall robustness.
- Adding support for PHY packages.
- Fixing setup order issues. These currently hinder the driver from
  properly enabling the hardware on devices where U-Boot skips the
  setup and leaves the controller registers untouched.
====================

Link: https://patch.msgid.link/20260603175924.123019-1-markus.stockhausen@gmx.de
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
13 days agonet: mdio: realtek-rtl9300: Correctly handle ethernet-phy-package
Manuel Stocker [Wed, 3 Jun 2026 17:59:24 +0000 (19:59 +0200)] 
net: mdio: realtek-rtl9300: Correctly handle ethernet-phy-package

Realtek Otto switches usually make use of multiport PHYs (e.g. 8 port
1G RTL8218D or 4 port 2.5G RTL8224). The device tree can describe this
fact via an "ethernet-phy-package" node that resides between the bus
and the PHY node.

When looking up the device tree bus node via the chain port->phy->parent
the driver totally ignores the existence of a PHY package. Enhance the
lookup to take care of this feature.

Link: https://github.com/openwrt/openwrt/pull/23591
Signed-off-by: Manuel Stocker <mensi@mensi.ch>
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://patch.msgid.link/20260603175924.123019-8-markus.stockhausen@gmx.de
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
13 days agonet: mdio: realtek-rtl9300: reorder controller setup
Markus Stockhausen [Wed, 3 Jun 2026 17:59:23 +0000 (19:59 +0200)] 
net: mdio: realtek-rtl9300: reorder controller setup

After the former refactoring the existing otto_emdio_9300_mdiobus_init()
contains only the c22/c45 bus mode setup. Like the topology setup this
must run before bus registration. Otherwise the bus does not "speak" the
right protocol for PHY setup.

This setup is device-specific and other SoCs will need to set up other
register bits in the controller in the future. Therefore

- Relocate c22/c45 device tree readout to the very beginning of the probing
- Add a new device-specific setup_controller() into the info structure.
- Relocate otto_emdio_priv to satisfy the new info structure dependency.
- Rename otto_emdio_9300_mdiobus_init accordingly and add it to the
  RTL9300 info structure. At the same time, adapt register naming
  for the function to make it clear that it only applies to this SoC.
- Call setup_controller() prior to bus registration.

Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://patch.msgid.link/20260603175924.123019-7-markus.stockhausen@gmx.de
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
13 days agonet: mdio: realtek-rtl9300: relocate c22/c45 device tree readout
Markus Stockhausen [Wed, 3 Jun 2026 17:59:22 +0000 (19:59 +0200)] 
net: mdio: realtek-rtl9300: relocate c22/c45 device tree readout

otto_emdio_map_ports() is the central place to lookup the topology and the
properties of the Realtek ethernet MDIO controller from the device tree.
Deviating from this the c22/c45 detection via "ethernet-phy-ieee802.3-c45"
is running separately in otto_emdio_probe_one(). It loops over the same
nodes, just at a later point in time.

There is no benefit to divide this setup and to have a time window where
the data structure is only filled partially. Additionally it uses the
"fwnode" API. Consolidate the setup and convert it to the "of" API.

Remark. This is a subtle change for dangling PHY nodes (not referenced
by ethernet-ports). Before this commit all PHY nodes were evaluated for
c45 setup, now only the referenced ones.

Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://patch.msgid.link/20260603175924.123019-6-markus.stockhausen@gmx.de
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
13 days agonet: mdio: realtek-rtl9300: relocate topology setup
Markus Stockhausen [Wed, 3 Jun 2026 17:59:21 +0000 (19:59 +0200)] 
net: mdio: realtek-rtl9300: relocate topology setup

Until now the driver sets up the port to bus/address topology of the
controller after all buses are set up via otto_emdio_probe_one(). This
does not work for devices where U-Boot skips this setup. It is not
only needed for the hardware internal background PHY polling engine
but it is essential for access to the PHYs during probing.

Depending on the SoC type there exist two different register arrays

- Bus mapping registers (RTL930x, RTL931x) define to which bus the port
  is attached. E.g. [1]
- Address mapping registers (RTL838x, RTL930x, RTL931x) define to which
  address of the bus the port is attached. E.g. [2]

Relocate the topology setup and make it generic. For this

- Define device-specific bus_base/addr_base attributes that give the
  register base address where the mapping lives. In case one or both are
  not given the SoC does not support this specific type of mapping.
- Create a helper otto_emdio_setup_topology() that writes the detected
  topology to the registers.
- Call this helper prior to otto_emdio_probe_one().
- Remove unneeded code from otto_emdio_9300_mdiobus_init().
- Due to the added prefixes, increase define indentation

Subtle change: The old coding used regmap_bulk_write and silently wrote
bus=0/address=0 to mapping registers for ports that are out of scope.
The new coding leaves those untouched.

[1] https://svanheule.net/realtek/longan/register/smi_port0_15_polling_sel
[2] https://svanheule.net/realtek/longan/register/smi_port0_5_addr_ctrl

Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://patch.msgid.link/20260603175924.123019-5-markus.stockhausen@gmx.de
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
13 days agonet: mdio: realtek-rtl9300: harden otto_emdio_probe_one()
Markus Stockhausen [Wed, 3 Jun 2026 17:59:20 +0000 (19:59 +0200)] 
net: mdio: realtek-rtl9300: harden otto_emdio_probe_one()

The bus probing of the MDIO driver uses a two stage approach.

1. The device tree "ethernet-ports" node is scanned to build a mapping
   between ports and PHYs.

2. The children of the device tree "controller" are scanned to create
   the individual MDIO buses.

The first step already checks the consistency of the PHY and bus nodes
that are linked via the ports. But it might miss a dangling bus child
node that is not linked. Step two simply iterates over all bus child
nodes and might read malformed data from nodes not checked in step one.

Harden this and return a meaningful error message.

Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://patch.msgid.link/20260603175924.123019-4-markus.stockhausen@gmx.de
Signed-off-by: Jakub Kicinski <kuba@kernel.org>