* [PATCH v2] docs/mm/slab: document cache isolation with SLAB_NO_MERGE
From: Mohammed EL Kadiri @ 2026-06-07 7:06 UTC (permalink / raw)
To: Jonathan Corbet, Andrew Morton
Cc: Vlastimil Babka, Matthew Wilcox, David Hildenbrand,
Lorenzo Stoakes, Kees Cook, linux-mm, linux-doc, linux-hardening,
linux-kernel, Mohammed EL Kadiri
In-Reply-To: <20260606155856.15548-1-med08elkadiri@gmail.com>
Add documentation to slab.rst explaining when and how to use
SLAB_NO_MERGE to protect security-critical slab caches from
cross-cache heap exploitation.
The document covers:
- When to use SLAB_NO_MERGE and what it communicates
- How to verify merge status on a running system
- Tradeoffs (memory cost vs performance)
- Relationship to CONFIG_RANDOM_KMALLOC_CACHES, SLAB_TYPESAFE_BY_RCU,
and the slab_nomerge boot parameter
Assisted-by: Claude:claude-opus-4.6
Signed-off-by: Mohammed EL Kadiri <med08elkadiri@gmail.com>
---
Changes in v2 (per Jonathan Corbet and Matthew Wilcox feedback):
- Add content to existing slab.rst instead of creating new file
- Fix markup: use plain function() without additional formatting
- Use slab terminology consistently, not SLUB
- Remove How merging works section (implementation internals)
- Remove cross-cache attack class section (redundant)
- Remove Bounded allocation volume criteria
- Rephrase unmergeability guidance per Matthew Wilcox suggestion
- Add Assisted-by tag per coding-assistants.rst
Documentation/mm/slab.rst | 60 +++++++++++++++++++++++++++++++++++++++
1 file changed, 60 insertions(+)
diff --git a/Documentation/mm/slab.rst b/Documentation/mm/slab.rst
index 2bcc58ada302..c485bd257c44 100644
--- a/Documentation/mm/slab.rst
+++ b/Documentation/mm/slab.rst
@@ -4,6 +4,66 @@
Slab Allocation
===============
+Cache isolation with SLAB_NO_MERGE
+===================================
+
+The slab allocator merges caches with compatible size, alignment, and flags
+to reduce memory fragmentation. While this improves memory efficiency, it
+allows objects of different types to share the same slab. This enables
+cross-cache heap exploitation, where a use-after-free in one object type can
+be leveraged to corrupt an unrelated type.
+
+SLAB_NO_MERGE prevents a cache from being merged, ensuring it receives a
+dedicated slab. A freed slot in an isolated cache can only be reallocated as
+the same object type.
+
+When to use SLAB_NO_MERGE
+--------------------------
+
+SLAB_NO_MERGE should be considered for caches holding security-critical
+objects whose corruption leads directly to privilege escalation, such as
+credentials, cryptographic keys, or capability sets.
+
+It is harmless to specify SLAB_NO_MERGE even if the cache is already
+unmergeable for other reasons (e.g., it has a constructor or a non-zero
+usersize). The flag communicates intent and ensures the cache remains
+isolated if those other properties change in the future.
+
+Verifying merge status
+-----------------------
+
+To check whether a cache is merged on a running system::
+
+ # Check how many other caches share its slab
+ cat /sys/kernel/slab/<cache_name>/aliases
+
+ # aliases > 0 means other types share this cache's slab
+
+Tradeoffs
+----------
+
+**Memory**: Isolated caches may have partially-filled slabs that cannot be
+used by other types. The overhead is typically a few extra pages.
+
+**Performance**: Zero impact on kmem_cache_alloc() and kmem_cache_free().
+The only effect is at boot when the cache is created.
+
+Relationship to other mitigations
+----------------------------------
+
+CONFIG_RANDOM_KMALLOC_CACHES creates multiple copies of each kmalloc size
+class and randomly assigns allocations among them. It only affects kmalloc()
+users and does not affect named caches created with kmem_cache_create().
+
+SLAB_TYPESAFE_BY_RCU delays freeing the slab by an RCU grace period. It
+does not delay object slot reuse and does not prevent cross-cache merging.
+It solves a different problem: safe lockless access to freed-and-reallocated
+objects of the same type.
+
+The slab_nomerge boot parameter disables merging for all caches globally.
+SLAB_NO_MERGE provides the same protection selectively for individual caches
+without the global memory cost.
+
Functions and structures
========================
--
2.43.0
^ permalink raw reply related
* [PATCH v2 0/1] add ROG STRIX B650E-E GAMING WIFI
From: Eugene Shalygin @ 2026-06-07 11:06 UTC (permalink / raw)
To: eugene.shalygin
Cc: Guenter Roeck, Jonathan Corbet, Shuah Khan,
open list:HARDWARE MONITORING, open list:DOCUMENTATION, open list
Version 1 of the patch contained a mistake, where the board definition
referred to a sensor, unavailable for its family. Veronika, the original
submitter, has not responded to clarification request. Another owner of
this board model took over and corrected the board definition, and the
result of that is submitted as version 2.
Veronika Kossmann (1):
hwmon: (asus-ec-sensors) add ROG STRIX B650E-E GAMING WIFI
Documentation/hwmon/asus_ec_sensors.rst | 1 +
drivers/hwmon/asus-ec-sensors.c | 12 +++++++++++-
2 files changed, 12 insertions(+), 1 deletion(-)
--
2.54.0
^ permalink raw reply
* [PATCH v2 1/1] hwmon: (asus-ec-sensors) add ROG STRIX B650E-E GAMING WIFI
From: Eugene Shalygin @ 2026-06-07 11:06 UTC (permalink / raw)
To: eugene.shalygin
Cc: Veronika Kossmann, Oleg Tsvetkov, Guenter Roeck, Jonathan Corbet,
Shuah Khan, open list:HARDWARE MONITORING,
open list:DOCUMENTATION, open list
In-Reply-To: <20260607110702.84599-1-eugene.shalygin@gmail.com>
From: Veronika Kossmann <nanodesuu@gmail.com>
Add support for ROG STRIX B650E-E GAMING WIFI
Signed-off-by: Veronika Kossmann <nanodesuu@gmail.com>
Co-developed-by: Oleg Tsvetkov <oleg-tsv@yandex.ru>
Signed-off-by: Oleg Tsvetkov <oleg-tsv@yandex.ru>
Signed-off-by: Eugene Shalygin <eugene.shalygin@gmail.com>
---
Documentation/hwmon/asus_ec_sensors.rst | 1 +
drivers/hwmon/asus-ec-sensors.c | 12 +++++++++++-
2 files changed, 12 insertions(+), 1 deletion(-)
diff --git a/Documentation/hwmon/asus_ec_sensors.rst b/Documentation/hwmon/asus_ec_sensors.rst
index 9ad3f0a57f55..e14419811aac 100644
--- a/Documentation/hwmon/asus_ec_sensors.rst
+++ b/Documentation/hwmon/asus_ec_sensors.rst
@@ -31,6 +31,7 @@ Supported boards:
* ROG MAXIMUS Z690 FORMULA
* ROG STRIX B550-E GAMING
* ROG STRIX B550-I GAMING
+ * ROG STRIX B650E-E GAMING WIFI
* ROG STRIX B650E-I GAMING WIFI
* ROG STRIX B850-I GAMING WIFI
* ROG STRIX X470-F GAMING
diff --git a/drivers/hwmon/asus-ec-sensors.c b/drivers/hwmon/asus-ec-sensors.c
index 070bb368f2b7..f351bcfc5679 100644
--- a/drivers/hwmon/asus-ec-sensors.c
+++ b/drivers/hwmon/asus-ec-sensors.c
@@ -274,7 +274,7 @@ static const struct ec_sensor_info sensors_family_amd_600[] = {
[ec_sensor_temp_cpu_package] =
EC_SENSOR("CPU Package", hwmon_temp, 1, 0x00, 0x31),
[ec_sensor_temp_mb] =
- EC_SENSOR("Motherboard", hwmon_temp, 1, 0x00, 0x32),
+ EC_SENSOR("Motherboard", hwmon_temp, 1, 0x00, 0x32),
[ec_sensor_temp_vrm] =
EC_SENSOR("VRM", hwmon_temp, 1, 0x00, 0x33),
[ec_sensor_temp_t_sensor] =
@@ -616,6 +616,14 @@ static const struct ec_board_info board_info_strix_b550_i_gaming = {
.family = family_amd_500_series,
};
+static const struct ec_board_info board_info_strix_b650e_e_gaming = {
+ .sensors = SENSOR_TEMP_CPU | SENSOR_TEMP_CPU_PACKAGE |
+ SENSOR_TEMP_MB | SENSOR_TEMP_VRM |
+ SENSOR_FAN_CPU_OPT,
+ .mutex_path = ASUS_HW_ACCESS_MUTEX_SB_PCI0_SBRG_SIO1_MUT0,
+ .family = family_amd_600_series,
+};
+
static const struct ec_board_info board_info_strix_b650e_i_gaming = {
.sensors = SENSOR_TEMP_VRM | SENSOR_TEMP_T_SENSOR |
SENSOR_SET_TEMP_CHIPSET_CPU_MB | SENSOR_IN_CPU_CORE,
@@ -861,6 +869,8 @@ static const struct dmi_system_id dmi_table[] = {
&board_info_strix_b550_e_gaming),
DMI_EXACT_MATCH_ASUS_BOARD_NAME("ROG STRIX B550-I GAMING",
&board_info_strix_b550_i_gaming),
+ DMI_EXACT_MATCH_ASUS_BOARD_NAME("ROG STRIX B650E-E GAMING WIFI",
+ &board_info_strix_b650e_e_gaming),
DMI_EXACT_MATCH_ASUS_BOARD_NAME("ROG STRIX B650E-I GAMING WIFI",
&board_info_strix_b650e_i_gaming),
DMI_EXACT_MATCH_ASUS_BOARD_NAME("ROG STRIX B850-I GAMING WIFI",
--
2.54.0
^ permalink raw reply related
* Re: [RFC v1 0/9] kho: granular compatibility and header decoupling
From: Mike Rapoport @ 2026-06-07 11:58 UTC (permalink / raw)
To: Pasha Tatashin
Cc: linux-kselftest, rppt, shuah, akpm, linux-mm, skhan, linux-doc,
jasonmiu, linux-kernel, corbet, ran.xiaokai, kexec, pratyush,
graf
In-Reply-To: <20260605033235.717351-1-pasha.tatashin@soleen.com>
On Fri, 05 Jun 2026 03:32:26 +0000, Pasha Tatashin <pasha.tatashin@soleen.com> wrote:
Hi,
> [...]
> data structure. Keeping all of this within the same `kexec_handover.c`
> file, and also under the same global version, is no longer sustainable.
>
> To address this, this series:
> 1. Refactors and reorganizes the code by splitting out radix tree
> and vmalloc into separate files.
I'd keep vmalloc where it is, it's more of a memory preservation primitive
rather than a data structure of it's own. The data structure it uses is an
implementation detail.
Let's minimize the churn where possible for the sake of git blame and
backports.
> 2. Moves and organizes internal and ABI headers into structured
> directories under include/linux/kho/ and include/linux/kho/abi/.
> Instead of cluttering include/linux/ with prefix-styled headers like
> kho_block.h or kho_radix_tree.h, we use the already existing
> include/linux/kho/ directory (e.g., kho/block.h and
> kho/radix_tree.h).
This looks to me like unnecessary churn.
These all are bundled with KHO anyway, there is no header dependencies
that justify small headers for each two functions and netiher
linux/kexec_handover.h nor linux/kho/abi/kexec_handover.h are that long
to start splitting them.
> 3. Introduces a standard set of compatibility helpers in
> kho/abi/compat.h.
> 4. Decouples the compatibility strings of individual KHO subsystems
> (radix tree, vmalloc, and block) from the global KHO version.
> This enables independent, granular compatibility versioning.
I agree that we should decouple versioning of these components from the
global KHO versioning.
Can't say I agree with the way you propose to do it.
I don't like that each user of a KHO component should include that
component version in its own version string (or whatever it may become
later).
It requires ABI headers update each time a user decides to add a new
data structure and worse when there is a change to that data structure.
It creates coupling of the data structure user with its particular
version and just looks ugly IMHO.
Suppose we added new fields to vmalloc, but made the implementation of
restore to be able to cope with both old and new versions.
How this would be reflected in memfd versioning?
We'll add both versions of vmalloc to memfd version? And all other vmalloc
users?
Or, say, we add support to kmalloc() and use it in kho_block.
Then we'd have to add kmalloc() versioning to all kho_block users, right?
I think the versioning of each component should be handled by ->restore()
of that component. If it sees an incompatible version in the preserved
data, it returns an error. The versions can be stored e.g. in the base KHO
fdt.
> 5. Adds a KUnit test suite to verify that the composite compatibility
> strings of different subsystems remain unique and sorted in
> alphabetical order, guaranteeing a consistent and predictable
> representation across configurations.
Without "composite compatibility strings" we don't need to care about
them "remaining unique and sorted in alphabetical order".
The need for this test alone is already a red flag ;-)
--
Sincerely yours,
Mike.
^ permalink raw reply
* Re: [RFC v1 1/9] kho: split out radix tree tracker into kho_radix.c
From: Mike Rapoport @ 2026-06-07 11:58 UTC (permalink / raw)
To: Pasha Tatashin
Cc: linux-kselftest, rppt, shuah, akpm, linux-mm, skhan, linux-doc,
jasonmiu, linux-kernel, corbet, ran.xiaokai, kexec, pratyush,
graf
In-Reply-To: <20260605033235.717351-2-pasha.tatashin@soleen.com>
On Fri, 05 Jun 2026 03:32:27 +0000, Pasha Tatashin <pasha.tatashin@soleen.com> wrote:
> Move the radix tree tracker implementation from the core KHO code
It's radix tree data structure implementation, kho memory tracker is it's
user. Please rephrase to keep the semantics clear.
>
>
> diff --git a/kernel/liveupdate/Makefile b/kernel/liveupdate/Makefile
> index eec9d3ae07eb..a3ee8a5c27a2 100644
> --- a/kernel/liveupdate/Makefile
> +++ b/kernel/liveupdate/Makefile
> @@ -7,7 +7,11 @@ luo-y := \
> luo_flb.o \
> luo_session.o
>
> -obj-$(CONFIG_KEXEC_HANDOVER) += kexec_handover.o
> +kho-y := \
> + kexec_handover.o \
I don't see much value in moving kexec_handover.o to a separate line,
btw, the same is true for luo_core.o, but it's not important enough to
change.
--
Sincerely yours,
Mike.
^ permalink raw reply
* [PATCH] hwmon: (asus-ec-sensors) add ROG STRIX B850-E GAMING WIFI
From: Eugene Shalygin @ 2026-06-07 12:36 UTC (permalink / raw)
To: eugene.shalygin
Cc: Guenter Roeck, Jonathan Corbet, Shuah Khan,
open list:HARDWARE MONITORING, open list:DOCUMENTATION, open list
The board has a similar sensor configuration to the
ROG STRIX B850-I GAMING WIFI, but includes an additional
T-Sensor header. The patch was provided via GitHub [1].
Signed-off-by: Eugene Shalygin <eugene.shalygin@gmail.com>
[1] https://github.com/zeule/asus-ec-sensors/pull/105
---
Documentation/hwmon/asus_ec_sensors.rst | 1 +
drivers/hwmon/asus-ec-sensors.c | 10 ++++++++++
2 files changed, 11 insertions(+)
diff --git a/Documentation/hwmon/asus_ec_sensors.rst b/Documentation/hwmon/asus_ec_sensors.rst
index 9ad3f0a57f55..9669e729bb8b 100644
--- a/Documentation/hwmon/asus_ec_sensors.rst
+++ b/Documentation/hwmon/asus_ec_sensors.rst
@@ -32,6 +32,7 @@ Supported boards:
* ROG STRIX B550-E GAMING
* ROG STRIX B550-I GAMING
* ROG STRIX B650E-I GAMING WIFI
+ * ROG STRIX B850-E GAMING WIFI
* ROG STRIX B850-I GAMING WIFI
* ROG STRIX X470-F GAMING
* ROG STRIX X470-I GAMING
diff --git a/drivers/hwmon/asus-ec-sensors.c b/drivers/hwmon/asus-ec-sensors.c
index b5d97a27f80d..27e39138011e 100644
--- a/drivers/hwmon/asus-ec-sensors.c
+++ b/drivers/hwmon/asus-ec-sensors.c
@@ -628,6 +628,14 @@ static const struct ec_board_info board_info_strix_b650e_i_gaming = {
.family = family_amd_600_series,
};
+static const struct ec_board_info board_info_strix_b850_e_gaming_wifi = {
+ .sensors = SENSOR_TEMP_CPU | SENSOR_TEMP_CPU_PACKAGE |
+ SENSOR_TEMP_MB | SENSOR_TEMP_VRM |
+ SENSOR_TEMP_T_SENSOR | SENSOR_FAN_CPU_OPT,
+ .mutex_path = ASUS_HW_ACCESS_MUTEX_SB_PCI0_SBRG_SIO1_MUT0,
+ .family = family_amd_800_series,
+};
+
static const struct ec_board_info board_info_strix_b850_i_gaming_wifi = {
.sensors = SENSOR_TEMP_CPU | SENSOR_TEMP_CPU_PACKAGE |
SENSOR_TEMP_MB | SENSOR_TEMP_VRM,
@@ -868,6 +876,8 @@ static const struct dmi_system_id dmi_table[] = {
&board_info_strix_b550_i_gaming),
DMI_EXACT_MATCH_ASUS_BOARD_NAME("ROG STRIX B650E-I GAMING WIFI",
&board_info_strix_b650e_i_gaming),
+ DMI_EXACT_MATCH_ASUS_BOARD_NAME("ROG STRIX B850-E GAMING WIFI",
+ &board_info_strix_b850_e_gaming_wifi),
DMI_EXACT_MATCH_ASUS_BOARD_NAME("ROG STRIX B850-I GAMING WIFI",
&board_info_strix_b850_i_gaming_wifi),
DMI_EXACT_MATCH_ASUS_BOARD_NAME("ROG STRIX X470-F GAMING",
--
2.54.0
^ permalink raw reply related
* Re: [RFC PATCH v1 00/13] exec: add spawn templates for repeated executable startup
From: Li Chen @ 2026-06-07 13:22 UTC (permalink / raw)
To: Gabriel Krisman Bertazi
Cc: Christian Brauner, Kees Cook, Alexander Viro, linux-fsdevel,
linux-api, linux-kernel, linux-mm, linux-arch, linux-doc,
linux-kselftest, x86, Arnd Bergmann, Andy Lutomirski,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
H. Peter Anvin, Jan Kara, Jonathan Corbet, Shuah Khan
In-Reply-To: <87fr31xdz3.fsf@mailhost.krisman.be>
Hi Gabriel,
Yes, I looked at Josh's slides and your RFC a few days ago.
I agree that io_uring is a very interesting direction, and I can see why it
fits the "ordered setup operations before exec" model.
My current preference is still to first explore a pidfd/pidfs-based builder,
modeled roughly like fsconfig(). Process creation feels like a core process
lifecycle API, and I think a normal fd-based syscall interface may be easier
for libc, language runtimes, shells,and sandboxing tools to adopt.
My hesitation is practical rather than conceptual.Some important
deployments still disable io_uring entirely; Docker's default seccomp
profile blocks the io_uring syscalls, and Google has disabled or restricted
io_uring in ChromeOS, Android app processes, and production servers.
I will study your io_uring work more carefully and compare the two directions.
One possible outcome is that io_uring can drive/share the same builder object later;
I do not know that yet.
Thanks for pointing this out.
---- On Fri, 05 Jun 2026 22:24:00 +0800 Gabriel Krisman Bertazi <krisman@suse.de> wrote ---
> Li Chen <me@linux.beauty> writes:
>
> > Hi,
> >
> > This is an early RFC for an idea that is probably still rough in both the
> > UAPI and implementation details. Sorry for the rough edges; I am sending
> > it now to check whether this direction is worth pursuing and to get
> > feedback on the kernel/userspace boundary.
> >
> > The series is based on linux-next version 20260518.
> >
> > This RFC adds spawn_template, a userspace-controlled exec acceleration
> > mechanism for runtimes that repeatedly start the same executable with
> > different argv, envp, and per-spawn file descriptor setup.
>
> Have you looked at Josh's proposal to do this over io_uring [1] and my
> implementation of it at [2]? I think io_uring is a very natural
> interface for something like this, it will avoid adding a larger API,
> since you could, in theory, set up the entire new task context using
> regular io_uring operations in an io workqueue and then starting it would
> be a matter of forking the pre-configured io thread with a new io_uring
> operation.
>
> [1]
> https://lpc.events/event/16/contributions/1213/attachments/1012/1945/io-uring-spawn.pdf
> [2] https://lwn.net/Articles/1001622/
>
> >
> > The main target is agent runtimes. Modern coding agents repeatedly start
> > short-lived helper tools such as rg, git, sed, awk, python, node, and
> > shell wrappers while they inspect and edit a workspace. Those runtimes
> > already know which tools are hot, and they are also the right place to
> > decide policy. The kernel does not choose names such as rg, git, or sed.
> > Userspace opts in by creating a template fd for one executable, then uses
> > that fd for later spawns. Launchers, shells, and build systems have a
> > similar repeated-startup shape and could use the same primitive, but the
> > agent runtime case is the main motivation for this RFC.
> >
> > The mechanism applies to the executable that userspace asks the kernel to
> > start. If an agent runtime directly starts /usr/bin/rg, the rg executable
> > is the template target. If the runtime starts /usr/bin/bash -c "rg ... |
> > head", the shell is the template target unless the shell itself opts in
> > when it starts rg and head. The kernel does not parse the shell command
> > string or rewrite inner commands into template spawns. Userspace has to
> > call spawn_template for those inner commands explicitly:
> >
> > direct exec shell wrapper
> > ----------- -------------
> > agent agent
> > template("/usr/bin/rg") template("/usr/bin/bash")
> > spawn rg argv spawn bash -c "rg ... | head"
> >
> > kernel target: rg kernel target: bash
> > rg startup benefits rg/head need shell opt-in
> >
> > Several agent runtime discussions are moving toward direct argv-style
> > exec tools for both security and policy clarity. For example, opencode
> > issue #2206 proposes an exec tool as a safer alternative to a shell-only
> > bash tool:
> >
> > https://github.com/anomalyco/opencode/issues/2206
> >
> > spawn_template is meant to support both models. Direct exec users can
> > cache the actual hot tool. Shell-wrapper users can cache the shell and
> > still reduce shell startup cost. If a shell or an agent runtime later
> > uses the same API for commands started inside a shell command, those
> > inner tools can benefit too.
> >
> > Each spawn still goes through the normal exec path. The template reuses
> > only metadata that can be revalidated before use. Credential preparation,
> > permission checks, binary handler checks, secure-exec handling, and LSM
> > hooks remain on the normal execve path.
> >
> > The UAPI has two operations. spawn_template_create() creates an
> > anonymous-inode template fd from either an executable fd or an absolute
> > executable path. spawn_template_spawn() starts one child from that
> > template, applies per-spawn fd, cwd, and signal actions, and returns both
> > pid and pidfd.
> >
> > fd inheritance is deliberately conservative. By default, after the
> > requested per-spawn actions have run, the child closes fds above stderr.
> > An agent runtime can still request traditional inheritance explicitly,
> > but helper tools do not inherit unrelated secret files or sockets by
> > accident. The create-time actions fields are reserved and rejected in
> > this RFC because fd numbers are per-process state, not stable reusable
> > objects. The caller supplies fd actions for each spawn instead.
> >
> > A typical agent runtime would keep one template per hot executable and
> > still build argv, envp, cwd, and pipe wiring for each tool call:
> >
> > rg_tmpl = spawn_template_create("/usr/bin/rg");
> >
> > for each search request:
> > out_r, out_w = pipe_cloexec();
> > err_r, err_w = pipe_cloexec();
> > actions = [
> > FCHDIR(worktree_fd),
> > DUP2(out_w, STDOUT_FILENO),
> > DUP2(err_w, STDERR_FILENO),
> > ];
> > child = spawn_template_spawn(rg_tmpl, rg_argv, envp, actions);
> > close(out_w);
> > close(err_w);
> > read out_r and err_r;
> > waitid(P_PIDFD, child.pidfd, ...);
> >
> > A shell-wrapper runtime would use the same shape with a template for
> > /usr/bin/bash and argv such as ["/usr/bin/bash", "-c", command]. That
> > reduces shell startup cost, but it does not cache rg or head inside that
> > command unless the shell also opts into spawn_template for commands it
> > starts internally.
> >
> > The template pins the executable and denies writes to that file while the
> > template fd is alive, so cached executable metadata cannot race with a
> > writer changing the same inode. This means direct in-place writes to the
> > executable can fail while a runtime keeps a template open. It does not
> > block the common package-manager update pattern where a new inode is
> > written and then atomically renamed over the old path. In that case the
> > old path-created template becomes stale, spawn_template_spawn() rejects
> > it with ESTALE, and the runtime should close and recreate the template
> > for the new executable.
> >
> > in-place write package-manager update
> > -------------- ----------------------
> > template pins old inode write new inode
> > write(old inode) denied rename(new, "/usr/bin/rg")
> >
> > cached metadata safe old template sees path mismatch
> > spawn_template_spawn() = -ESTALE
> > recreate template for new inode
> >
> > Each spawn revalidates executable identity before cached metadata is
> > used. Path-created templates only accept absolute paths: a relative path
> > such as ./tool depends on cwd, and the same string can name a different
> > file after chdir. For an absolute path template, each spawn reopens the
> > path and checks that it still resolves to the executable recorded when
> > the template was created. If the path now names a replaced file, the
> > template is stale and userspace should close and recreate it.
> >
> > A template fd can be passed over SCM_RIGHTS like any other fd, but this
> > RFC does not treat that as delegation. spawn_template_spawn() only works
> > while the caller still has the same struct cred object that created the
> > template. If another task, or the same task after a credential change,
> > receives the fd, spawn fails instead of running the executable using the
> > creator's launch authority:
> >
> > ordinary fd spawn_template fd
> > ----------- -----------------
> > A: open log A: create rg template
> > A -> B: SCM_RIGHTS(fd) A -> B: SCM_RIGHTS(tfd)
> >
> > B: read(fd) = ok B: spawn(tfd) = -EACCES
> > B: create own rg template
> > B: spawn(own_tfd) = ok
> >
> > open-file use is delegated spawn authority is not delegated
> >
> > The cached state is intentionally small. The template fd keeps the opened
> > main executable file, an optional absolute path string, the creator
> > credential pointer, and the deny-write state. The executable identity key
> > records device, inode, size, mode, owner, ctime, and mtime, and is
> > rechecked before cached metadata is used. The ELF cache keeps only the
> > main executable's ELF header, program header table, and program header
> > count.
> >
> > cached in this RFC not cached in this RFC
> > ------------------ ----------------------
> > opened main executable PT_INTERP metadata
> > executable identity key shared-library graph
> > main ELF header VMA layout metadata
> > main ELF program headers cross-process metadata sharing
> > creator cred pointer
> > deny-write state
> >
> > This RFC does not cache ELF interpreter metadata, shared-library
> > dependency state, or derived mapping-layout state. Shared-library
> > resolution is dynamic linker policy and depends on LD_LIBRARY_PATH,
> > RPATH, RUNPATH, /etc/ld.so.cache, mount namespaces, and secure-exec
> > state. It also does not share cached executable metadata between template
> > fds created by different processes. Each template owns its small cached
> > metadata object in this RFC.
> >
> > Performance
> > ===========
> >
> > The numbers below come from my separate local autogen-bench project.
> > autogen-bench uses AutoGen [1] Core as the agent harness: RoutedAgent
> > instances run under SingleThreadedAgentRuntime, and RPC-style dispatch
> > fans out concurrent tool-call requests to worker agents. The workload
> > definitions, generated test files, and subprocess/spawn_template backends
> > are local to autogen-bench.
> >
> > The agent-tools preset includes direct tool calls and shell-wrapper forms
> > for:
> >
> > rg, grep, sed, awk, cat, head, tail, find, stat, ls, git-status, git-diff,
> > python-small, node-small, sh-c, and bash-c.
> >
> > The benchmark is launch-heavy but not no-op: it searches generated
> > Python-like source files, reads sample files, runs small Python and
> > Node.js programs, and runs git status and git diff in a small repository.
> > It does not include model inference or long-running tool work, so the
> > numbers mainly describe the short-tool regime.
> >
> > The subprocess column starts each tool call through the existing
> > userspace launch path. The spawn_template column creates templates for
> > hot executables and uses spawn_template_spawn() for later calls.
> >
> > Total in-flight tool calls stay at 16; only the worker-process split
> > changes. For example, 4x4 means 4 worker processes with 4 in-flight tool
> > calls each. The two time_s values are subprocess/spawn_template wall
> > times.
> >
> > Workload Calls subprocess spawn_template time_s Delta
> > (workers) calls calls/s calls/s seconds
> > 1x16 6144 411.04 420.32 14.95/14.62 +2.26%
> > 2x8 6144 666.78 690.08 9.21/8.90 +3.49%
> > 4x4 6144 955.61 1003.25 6.43/6.12 +4.99%
> > 8x2 6144 1048.25 1069.18 5.86/5.75 +2.00%
> >
> > The table measures the whole mixed workload, including both process
> > startup and the short tool work done after exec. Since this workload is
> > launch-heavy, the possible launch-side savings include:
> >
> > - the template fd keeps an opened executable, avoiding repeated ordinary
> > open/path setup for that executable;
> > - the kernel can reuse cached main-executable ELF header and program
> > header metadata after revalidation;
> > - the fork-and-exec-style launch is submitted as one
> > spawn_template_spawn() operation;
> > - fd, cwd, and signal actions run in the child kernel path instead of
> > being driven one syscall at a time by userspace child glue;
> > - pid and pidfd are returned by the same operation, reducing some
> > runtime-side bookkeeping.
> >
> > In local experiments before this RFC, I also tried caching ELF
> > interpreter metadata and derived ELF mapping-layout metadata. A focused
> > repeated-exec benchmark did not show a stable standalone throughput gain
> > for those two optimizations, so this RFC leaves them out and keeps only
> > the main executable metadata cache.
> >
> > I also tried sharing main-executable ELF metadata across template fds
> > created by different processes for the same executable identity. That can
> > reduce duplicated metadata memory when many agent worker processes create
> > their own templates for /usr/bin/rg, /usr/bin/git, and similar tools, but
> > it did not show a stable throughput win in local multi-agent tests. It
> > also adds cache keying, lifetime, invalidation, credential, and namespace
> > questions to the RFC. This version therefore keeps per-template metadata
> > ownership and leaves cross-process sharing out.
> >
> > Sorry again for the rough edges in this RFC. I would appreciate feedback
> > on whether this direction is useful and what the right API boundary
> > should be.
> >
> > Thanks,
> > Li
> >
> > [1]: https://github.com/microsoft/autogen
> >
> > Li Chen (13):
> > exec: factor argument setup out of do_execveat_common()
> > exec: add an internal helper for opened executables
> > file: expose helpers for in-kernel fd actions
> > exec: add spawn template UAPI definitions
> > exec: add spawn template file descriptors
> > exec: add spawn_template_spawn()
> > exec: validate spawn template executable identity
> > binfmt_elf: cache ELF metadata for spawn templates
> > Documentation: describe spawn templates
> > exec: require absolute paths for path-created templates
> > exec: let close-range actions target the max fd
> > syscalls: add generic spawn template entries
> > selftests/exec: cover spawn template basics
> >
> > Documentation/userspace-api/index.rst | 1 +
> > .../userspace-api/spawn_template.rst | 153 +++
> > MAINTAINERS | 6 +
> > arch/x86/entry/syscalls/syscall_64.tbl | 3 +-
> > fs/Makefile | 2 +-
> > fs/binfmt_elf.c | 104 +-
> > fs/exec.c | 162 ++-
> > fs/file.c | 11 +-
> > fs/spawn_template.c | 619 +++++++++++
> > include/linux/binfmts.h | 10 +
> > include/linux/fdtable.h | 2 +
> > include/linux/spawn_template.h | 72 ++
> > include/linux/syscalls.h | 7 +
> > include/uapi/asm-generic/unistd.h | 7 +-
> > include/uapi/linux/spawn_template.h | 62 ++
> > scripts/syscall.tbl | 2 +
> > tools/testing/selftests/exec/Makefile | 1 +
> > tools/testing/selftests/exec/spawn_template.c | 997 ++++++++++++++++++
> > 18 files changed, 2179 insertions(+), 42 deletions(-)
> > create mode 100644 Documentation/userspace-api/spawn_template.rst
> > create mode 100644 fs/spawn_template.c
> > create mode 100644 include/linux/spawn_template.h
> > create mode 100644 include/uapi/linux/spawn_template.h
> > create mode 100644 tools/testing/selftests/exec/spawn_template.c
>
> --
> Gabriel Krisman Bertazi
>
Regards,
Li
^ permalink raw reply
* Re: [RFC v1 0/9] kho: granular compatibility and header decoupling
From: Pasha Tatashin @ 2026-06-07 13:43 UTC (permalink / raw)
To: Mike Rapoport
Cc: Pasha Tatashin, linux-kselftest, shuah, akpm, linux-mm, skhan,
linux-doc, jasonmiu, linux-kernel, corbet, ran.xiaokai, kexec,
pratyush, graf
In-Reply-To: <178083348872.1648214.17778188633648887952.b4-review@b4>
On 06-07 14:58, Mike Rapoport wrote:
> On Fri, 05 Jun 2026 03:32:26 +0000, Pasha Tatashin <pasha.tatashin@soleen.com> wrote:
>
> Hi,
>
> > [...]
> > data structure. Keeping all of this within the same `kexec_handover.c`
> > file, and also under the same global version, is no longer sustainable.
> >
> > To address this, this series:
> > 1. Refactors and reorganizes the code by splitting out radix tree
> > and vmalloc into separate files.
>
> I'd keep vmalloc where it is, it's more of a memory preservation primitive
> rather than a data structure of it's own. The data structure it uses is an
> implementation detail.
kho vmalloc is absolutely a data structure. KHO core only provides the
basic handover mechanism (FDT nodes, physical memory ranges). vmalloc
is a structured representation on top of KHO, and should provide its own
versioned ABI.
If we change any of the vmalloc serialized structures (like kho_vmalloc,
kho_vmalloc_chunk, or kho_vmalloc_hdr), then vmalloc won't work and
compatibility will break.
Core KHO does not need vmalloc; nothing in kexec_handover.c uses it.
Instead, vmalloc has external customers:
- memfd (uses it to preserve serialized folio metadata)
- KHO test suite in lib/test_kho.c (uses it to preserve physical address arrays)
> Let's minimize the churn where possible for the sake of git blame and
> backports.
It is much better to do the right cleanups now while KHO is young. Once more
subsystems are added, this refactoring will be twice as hard. Modularizing the
code now guarantees a simpler, safer, and scalable design. Placing each data
structure in its own file gives us code that is easier to maintain, review, and
less prone to bugs.
> > 2. Moves and organizes internal and ABI headers into structured
> > directories under include/linux/kho/ and include/linux/kho/abi/.
> > Instead of cluttering include/linux/ with prefix-styled headers like
> > kho_block.h or kho_radix_tree.h, we use the already existing
> > include/linux/kho/ directory (e.g., kho/block.h and
> > kho/radix_tree.h).
>
> This looks to me like unnecessary churn.
> These all are bundled with KHO anyway, there is no header dependencies
> that justify small headers for each two functions and netiher
> linux/kexec_handover.h nor linux/kho/abi/kexec_handover.h are that long
> to start splitting them.
External users only need to include the headers they actually use. For
example, LUO shouldn't have to pull vmalloc or radix tree KHO
declarations, and memfd does not need block.
From a maintenance point of view, it is much easier to catch ABI
changes when the file with the appropriate version has been changed,
and most likely the version of that file should be updated. If a single
header contains compatibility versions for several different data
structures, it is easier to miss the correct version update.
Since we are splitting the source files (like kho_radix.c and
kho_vmalloc.c), the headers should logically follow the same
modularity.
>
> > 3. Introduces a standard set of compatibility helpers in
> > kho/abi/compat.h.
> > 4. Decouples the compatibility strings of individual KHO subsystems
> > (radix tree, vmalloc, and block) from the global KHO version.
> > This enables independent, granular compatibility versioning.
>
> I agree that we should decouple versioning of these components from the
> global KHO versioning.
> Can't say I agree with the way you propose to do it.
>
> I don't like that each user of a KHO component should include that
> component version in its own version string (or whatever it may become
> later).
>
> It requires ABI headers update each time a user decides to add a new
> data structure and worse when there is a change to that data structure.
> It creates coupling of the data structure user with its particular
> version and just looks ugly IMHO.
It is actually the opposite.
If a user adds a new data structure, that new data structure will have
its own compatibility version. Instead of the current approach where
the global version string needs to be updated, only the new version
string would be added.
Also, if someone updates their code to use the new data structure, their
compatibility string is going to be updated anyway, as part of using
the data structure requires including the dependency in their
compatibility.
> Suppose we added new fields to vmalloc, but made the implementation of
> restore to be able to cope with both old and new versions.
> How this would be reflected in memfd versioning?
> We'll add both versions of vmalloc to memfd version? And all other vmalloc
> users?
Backward compatibility is not in scope at the moment, but we can make
the version parsing more granular in the future.
Instead of a simple strncmp(), we can introduce a standard callback
interface for data structures. Each data structure implementation would
implement this interface, and we would pass the parsed version string
to the data-structure-specific version check.
> Or, say, we add support to kmalloc() and use it in kho_block.
> Then we'd have to add kmalloc() versioning to all kho_block users, right?
I was thinking about this. Since we don't have examples of data
structures depending on each other right now, I simply made sure
there are no duplicates in the compatibility strings.
If data structures have interdependencies in the future, we can easily
remove this uniqueness restriction. The users of block will still
include the block compatibility string (which automatically includes
kmalloc), and if user also depends on kmalloc, they will include it
as well.
> I think the versioning of each component should be handled by ->restore()
> of that component. If it sees an incompatible version in the preserved
> data, it returns an error. The versions can be stored e.g. in the base KHO
> fdt.
Hm, I think, checking compatibility inside ->restore() of each component may be
too late in the boot sequence.
By checking the composite compatibility strings upfront (before invoking
the actual restore/retrieve callbacks), we can guarantee that the entire
state configuration is fully compatible. If any mismatch is found, we
can cleanly abort the live update.
Additionally, keeping the versioning managed via composite strings on the
serialized data and registered handlers keeps the KHO core completely
decoupled from individual component ABIs, avoiding the need to bloat the
base KHO FDT with subsystem-specific versions.
> > 5. Adds a KUnit test suite to verify that the composite compatibility
> > strings of different subsystems remain unique and sorted in
> > alphabetical order, guaranteeing a consistent and predictable
> > representation across configurations.
>
> Without "composite compatibility strings" we don't need to care about
> them "remaining unique and sorted in alphabetical order".
These are not strict runtime requirements; they are simply there to enforce
code cleanliness and prevent human errors like accidental duplicates or
mismatched orders.
Even with a simple strncmp(), it works perfectly fine as long as the
strings match exactly. If the uniqueness or sorting constraints are too
strict, they can easily be removed.
In the future, we can transition to a more sophisticated version checker
that parses the composite string into individual subsystem version tokens
and verifies them one-by-one, rather than relying on a strict literal
strcmp() string comparison.
> The need for this test alone is already a red flag ;-)
I will remove test ;-)
^ permalink raw reply
* Re: [PATCH v2 5/7] seg6: add End.M.GTP6.D.Di behavior
From: Andrea Mayer @ 2026-06-07 14:01 UTC (permalink / raw)
To: Yuya Kusakabe
Cc: David S. Miller, Eric Dumazet, David Ahern, Jakub Kicinski,
Paolo Abeni, Simon Horman, Justin Iurman, Shuah Khan,
Jonathan Corbet, Shuah Khan, linux-kernel, netdev,
linux-kselftest, linux-doc, stefano.salsano, ahabdels,
Andrea Mayer, andrea
In-Reply-To: <20260505-seg6-mobile-v2-5-9e8022bdfdb6@gmail.com>
On Tue, 05 May 2026 01:30:15 +0900
Yuya Kusakabe <yuya.kusakabe@gmail.com> wrote:
Hi Yuya,
I do not repeat below the points from the cover letter thread and patch
1-4 replies (drop reasons, OIF/VRF removal, C helper, coding style, etc.).
The patch 4 review applies here, except for the parts where Section 6.4 is
implemented instead of Section 6.3 (which is incorrectly implemented in
patch 4).
> Add the End.M.GTP6.D.Di drop-in mode variant of End.M.GTP6.D
> (RFC 9433 Section 6.4). Unlike End.M.GTP6.D, the drop-in variant
> does NOT fold the GTP-U identifiers into Args.Mob.Session: the
> original outer IPv6 destination is preserved at SRH[0] of the new
> SRH, so the destination side can keep the original address
> untouched while still benefiting from SR Policy steering.
>
> The augmented SRH builder/destroyer is shared with End.M.GTP6.D.
> The TEID and QFI parsed out of the inbound GTP-U header are
> intentionally discarded for this variant (matching RFC 9433
> Section 6.4).
>
> When net.netfilter.nf_hooks_lwtunnel=1, the inner T-PDU traverses
> NF_INET_PRE_ROUTING between the GTP-U strip and the SRv6 push,
> mirroring End.DX4 / End.DX6.
>
> Non-T-PDU GTP-U messages are forwarded the same way as in
> End.M.GTP6.D: passed through via the lwtunnel's saved orig_input
> to a downstream peer that owns the GTP-U control plane.
>
> Configuration:
>
> ip -6 route add 2001:db8:f::/64 \
> encap seg6local action End.M.GTP6.D.Di \
> srh segs 2001:db8:2::e,2001:db8:3::e \
> src 2001:db8:2::1 \
> dev <dev>
>
> Link: https://www.rfc-editor.org/rfc/rfc9433.html#section-6.4
> Signed-off-by: Yuya Kusakabe <yuya.kusakabe@gmail.com>
> ---
> include/uapi/linux/seg6_local.h | 2 +
> net/ipv6/seg6_local.c | 222 +++++++++++
> tools/testing/selftests/net/Makefile | 1 +
> .../selftests/net/srv6_end_m_gtp6_d_di_test.sh | 427 +++++++++++++++++++++
> 4 files changed, 652 insertions(+)
>
> diff --git a/include/uapi/linux/seg6_local.h b/include/uapi/linux/seg6_local.h
> index 7d3d3d245b47..326da65ad5aa 100644
> --- a/include/uapi/linux/seg6_local.h
> +++ b/include/uapi/linux/seg6_local.h
> @@ -80,6 +80,8 @@ enum {
> SEG6_LOCAL_ACTION_END_M_GTP6_E = 19,
> /* IPv6/GTP-U decap into SRv6 (RFC 9433 Section 6.3) */
> SEG6_LOCAL_ACTION_END_M_GTP6_D = 20,
> + /* IPv6/GTP-U decap into SRv6, drop-in mode (RFC 9433 Section 6.4) */
> + SEG6_LOCAL_ACTION_END_M_GTP6_D_DI = 21,
>
> __SEG6_LOCAL_ACTION_MAX,
> };
> diff --git a/net/ipv6/seg6_local.c b/net/ipv6/seg6_local.c
> index 09e912e17df8..a6cd57ebcbde 100644
> --- a/net/ipv6/seg6_local.c
> +++ b/net/ipv6/seg6_local.c
> + [snip]
input_action_end_m_gtp6_d_di() and its finish callback are largely
identical to the patch 4 functions (input_action_end_m_gtp6_d() and its
finish): the SRH check, GTP-U dispatch, outer strip, inner protocol
detection, and NF_HOOK invocation are identical. The duplication should be
reduced via shared helpers.
> +static int input_action_end_m_gtp6_d_di(struct sk_buff *skb,
> + struct seg6_local_lwt *slwt)
> +{
> + [snip]
> + gtp_hdrlen = seg6_mobile_parse_gtpu(skb,
> + upper_off + sizeof(*uh),
> + &teid, &qfi);
> + if (gtp_hdrlen == -EOPNOTSUPP)
> + return seg6_mobile_passthrough_non_tpdu(skb);
> + if (gtp_hdrlen < 0) {
> + reason = SKB_DROP_REASON_SEG6_MOBILE_BAD_GTPU;
> + goto drop;
> + }
> + (void)teid;
> + (void)qfi;
D.Di does not use teid or qfi, so these variables and the (void) casts are
dead code and should be avoided. For example, seg6_mobile_parse_gtpu() could
accept NULL for teid and qfi so callers that do not need them can pass NULL
directly.
Thanks,
Ciao,
Andrea
P.S. I am temporarily writing from another address due to a mail
delivery issue at my @uniroma2.it address. Please always Cc my default
andrea.mayer@uniroma2.it address on replies.
^ permalink raw reply
* [PATCH] hwmon: (asus-ec-sensors) add ROG MAXIMUS Z790 EXTREME
From: Eugene Shalygin @ 2026-06-07 14:42 UTC (permalink / raw)
To: eugene.shalygin
Cc: Brian Downey, Guenter Roeck, Jonathan Corbet, Shuah Khan,
open list:HARDWARE MONITORING, open list:DOCUMENTATION, open list
From: Brian Downey <bdowne01@gmail.com>
Add support for ROG MAXIMUS Z790 EXTREME
Signed-off-by: Brian Downey <bdowne01@gmail.com>
Signed-off-by: Eugene Shalygin <eugene.shalygin@gmail.com>
---
Documentation/hwmon/asus_ec_sensors.rst | 1 +
drivers/hwmon/asus-ec-sensors.c | 9 +++++++++
2 files changed, 10 insertions(+)
diff --git a/Documentation/hwmon/asus_ec_sensors.rst b/Documentation/hwmon/asus_ec_sensors.rst
index 9ad3f0a57f55..60f1a6036538 100644
--- a/Documentation/hwmon/asus_ec_sensors.rst
+++ b/Documentation/hwmon/asus_ec_sensors.rst
@@ -29,6 +29,7 @@ Supported boards:
* ROG MAXIMUS XI HERO
* ROG MAXIMUS XI HERO (WI-FI)
* ROG MAXIMUS Z690 FORMULA
+ * ROG MAXIMUS Z790 EXTREME
* ROG STRIX B550-E GAMING
* ROG STRIX B550-I GAMING
* ROG STRIX B650E-I GAMING WIFI
diff --git a/drivers/hwmon/asus-ec-sensors.c b/drivers/hwmon/asus-ec-sensors.c
index 070bb368f2b7..171f06a4f120 100644
--- a/drivers/hwmon/asus-ec-sensors.c
+++ b/drivers/hwmon/asus-ec-sensors.c
@@ -509,6 +509,13 @@ static const struct ec_board_info board_info_maximus_z690_formula = {
.family = family_intel_600_series,
};
+static const struct ec_board_info board_info_maximus_z790_extreme = {
+ .sensors = SENSOR_TEMP_T_SENSOR | SENSOR_TEMP_VRM |
+ SENSOR_SET_TEMP_WATER | SENSOR_FAN_WATER_FLOW,
+ .mutex_path = ASUS_HW_ACCESS_MUTEX_RMTW_ASMX,
+ .family = family_intel_700_series,
+};
+
static const struct ec_board_info board_info_prime_x470_pro = {
.sensors = SENSOR_SET_TEMP_CHIPSET_CPU_MB |
SENSOR_TEMP_T_SENSOR | SENSOR_TEMP_VRM |
@@ -857,6 +864,8 @@ static const struct dmi_system_id dmi_table[] = {
&board_info_maximus_x_hero),
DMI_EXACT_MATCH_ASUS_BOARD_NAME("ROG MAXIMUS Z690 FORMULA",
&board_info_maximus_z690_formula),
+ DMI_EXACT_MATCH_ASUS_BOARD_NAME("ROG MAXIMUS Z790 EXTREME",
+ &board_info_maximus_z790_extreme),
DMI_EXACT_MATCH_ASUS_BOARD_NAME("ROG STRIX B550-E GAMING",
&board_info_strix_b550_e_gaming),
DMI_EXACT_MATCH_ASUS_BOARD_NAME("ROG STRIX B550-I GAMING",
--
2.54.0
^ permalink raw reply related
* Re: [PATCH v1] docs: omap/dss: Fix stale modedb.c path
From: Helge Deller @ 2026-06-07 15:10 UTC (permalink / raw)
To: Costa Shulyupin, Jonathan Corbet, Shuah Khan, Randy Dunlap,
linux-omap, linux-fbdev, linux-doc, linux-kernel
In-Reply-To: <20260531140325.4115024-1-costa.shul@redhat.com>
On 5/31/26 16:03, Costa Shulyupin wrote:
> The modedb.c file was moved from drivers/video/ to
> drivers/video/fbdev/core/. Update the reference.
>
> Assisted-by: Claude:claude-opus-4-6
> Signed-off-by: Costa Shulyupin <costa.shul@redhat.com>
> ---
> Documentation/arch/arm/omap/dss.rst | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
applied.
Thanks!
Helge
^ permalink raw reply
* [PATCH 1/3] x86/vdso: use kstrtouint() to validate vdso= boot parameter
From: Thorsten Blum @ 2026-06-07 15:16 UTC (permalink / raw)
To: Andy Lutomirski, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, H. Peter Anvin, Andrew Morton, Jonathan Corbet,
Shuah Khan, Randy Dunlap
Cc: x86, linux-doc, linux-kernel, Thorsten Blum
In-Reply-To: <20260607151614.79567-5-thorsten.blum@linux.dev>
Replace the deprecated simple_strtoul() with kstrtouint() when parsing
the vdso= boot parameter.
simple_strtoul() accepts partial input and silently converts invalid
input to 0. Use kstrtouint() for strict input validation instead and
reject malformed input. Accept only 0 and 1; warn and disable vDSO
support otherwise.
kstrtouint() converts the input string directly to an unsigned int,
avoiding an implicit conversion when assigning to vdso64_enabled.
Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
---
arch/x86/entry/vdso/vma.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/x86/entry/vdso/vma.c b/arch/x86/entry/vdso/vma.c
index d903bce24f15..b45549cd7acf 100644
--- a/arch/x86/entry/vdso/vma.c
+++ b/arch/x86/entry/vdso/vma.c
@@ -270,7 +270,11 @@ bool arch_syscall_is_vdso_sigreturn(struct pt_regs *regs)
#ifdef CONFIG_X86_64
static __init int vdso_setup(char *s)
{
- vdso64_enabled = simple_strtoul(s, NULL, 0);
+ if (kstrtouint(s, 0, &vdso64_enabled) || vdso64_enabled > 1) {
+ pr_warn("vdso= values other than 0 and 1 are invalid; vdso disabled\n");
+ vdso64_enabled = 0;
+ }
+
return 1;
}
__setup("vdso=", vdso_setup);
^ permalink raw reply related
* [PATCH 2/3] x86/vdso: use kstrtouint() to validate vdso32= boot parameter
From: Thorsten Blum @ 2026-06-07 15:16 UTC (permalink / raw)
To: Andy Lutomirski, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, H. Peter Anvin, Andrew Morton, Jonathan Corbet,
Shuah Khan, Randy Dunlap
Cc: x86, linux-doc, linux-kernel, Thorsten Blum
In-Reply-To: <20260607151614.79567-5-thorsten.blum@linux.dev>
Replace the deprecated simple_strtoul() with kstrtouint() when parsing
the vdso32= boot parameter and its X86_32 vdso= alias.
simple_strtoul() accepts partial input and silently converts invalid
input to 0. Use kstrtouint() for strict input validation instead and
reject malformed input. Accept only 0 and 1; warn and disable vDSO
support otherwise.
kstrtouint() converts the input string directly to an unsigned int,
avoiding an implicit conversion when assigning to vdso32_enabled.
Update the vdso32= handler comment to reflect the supported values.
Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
---
arch/x86/entry/vdso/vdso32-setup.c | 10 ++++------
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/arch/x86/entry/vdso/vdso32-setup.c b/arch/x86/entry/vdso/vdso32-setup.c
index 8894013eea1d..5f3e548ebf19 100644
--- a/arch/x86/entry/vdso/vdso32-setup.c
+++ b/arch/x86/entry/vdso/vdso32-setup.c
@@ -30,10 +30,8 @@ unsigned int __read_mostly vdso32_enabled = VDSO_DEFAULT;
static int __init vdso32_setup(char *s)
{
- vdso32_enabled = simple_strtoul(s, NULL, 0);
-
- if (vdso32_enabled > 1) {
- pr_warn("vdso32 values other than 0 and 1 are no longer allowed; vdso disabled\n");
+ if (kstrtouint(s, 0, &vdso32_enabled) || vdso32_enabled > 1) {
+ pr_warn("vdso32= values other than 0 and 1 are invalid; vdso disabled\n");
vdso32_enabled = 0;
}
@@ -41,9 +39,9 @@ static int __init vdso32_setup(char *s)
}
/*
- * For consistency, the argument vdso32=[012] affects the 32-bit vDSO
+ * For consistency, the argument vdso32=[01] affects the 32-bit vDSO
* behavior on both 64-bit and 32-bit kernels.
- * On 32-bit kernels, vdso=[012] means the same thing.
+ * On 32-bit kernels, vdso=[01] means the same thing.
*/
__setup("vdso32=", vdso32_setup);
^ permalink raw reply related
* [PATCH 3/3] Documentation/arch/x86: remove obsolete vdso32=2 compatibility note
From: Thorsten Blum @ 2026-06-07 15:16 UTC (permalink / raw)
To: Andy Lutomirski, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, H. Peter Anvin, Andrew Morton, Jonathan Corbet,
Shuah Khan, Randy Dunlap
Cc: x86, linux-doc, linux-kernel, Thorsten Blum
In-Reply-To: <20260607151614.79567-5-thorsten.blum@linux.dev>
Commit b0b49f2673f0 ("x86, vdso: Remove compat vdso support") removed
compat vDSO support and documented vdso32=2 as an alias for vdso32=0.
However, since commit c06989da39cd ("x86/vdso: Ensure vdso32_enabled
gets set to valid values only"), vdso32_setup() accepts only 0 and 1.
Remove the obsolete vdso32=2 compatibility note and document only the
supported values.
Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
---
Documentation/admin-guide/kernel-parameters.txt | 5 +----
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index 97007f4f69d4..ce1c630d6859 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -8249,15 +8249,12 @@ Kernel parameters
vdso32= [X86] Control the 32-bit vDSO
vdso32=1: enable 32-bit VDSO
- vdso32=0 or vdso32=2: disable 32-bit VDSO
+ vdso32=0: disable 32-bit VDSO
See the help text for CONFIG_COMPAT_VDSO for more
details. If CONFIG_COMPAT_VDSO is set, the default is
vdso32=0; otherwise, the default is vdso32=1.
- For compatibility with older kernels, vdso32=2 is an
- alias for vdso32=0.
-
Try vdso32=0 if you encounter an error that says:
dl_main: Assertion `(void *) ph->p_vaddr == _rtld_local._dl_sysinfo_dso' failed!
^ permalink raw reply related
* [PATCH 0/3] x86/vdso: improve vdso=/vdso32= boot parameter validation
From: Thorsten Blum @ 2026-06-07 15:16 UTC (permalink / raw)
To: Andy Lutomirski, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, H. Peter Anvin, Andrew Morton, Jonathan Corbet,
Shuah Khan, Randy Dunlap
Cc: x86, linux-doc, linux-kernel, Thorsten Blum
Replace the deprecated simple_strtoul() [1] with kstrtouint() when
parsing the vDSO boot parameters. This provides strict input validation,
rejects partial input, and warns when disabling vDSO for invalid values.
Adjust both warnings for consistency and update the documentation.
[1] https://www.kernel.org/doc/html/latest/process/deprecated.html#simple-strtol-simple-strtoll-simple-strtoul-simple-strtoull
Thorsten Blum (3):
x86/vdso: use kstrtouint() to validate vdso= boot parameter
x86/vdso: use kstrtouint() to validate vdso32= boot parameter
Documentation/arch/x86: remove obsolete vdso32=2 compatibility note
Documentation/admin-guide/kernel-parameters.txt | 5 +----
arch/x86/entry/vdso/vdso32-setup.c | 10 ++++------
arch/x86/entry/vdso/vma.c | 6 +++++-
3 files changed, 10 insertions(+), 11 deletions(-)
base-commit: 979c294509f9248fe1e7c358d582fb37dd5ca12d
^ permalink raw reply
* Re: [PATCH v2] docs/mm/slab: document cache isolation with SLAB_NO_MERGE
From: Vishal Moola @ 2026-06-07 16:04 UTC (permalink / raw)
To: Mohammed EL Kadiri
Cc: Jonathan Corbet, Andrew Morton, Vlastimil Babka, Matthew Wilcox,
David Hildenbrand, Lorenzo Stoakes, Kees Cook, linux-mm,
linux-doc, linux-hardening, linux-kernel
In-Reply-To: <20260607070645.9559-1-med08elkadiri@gmail.com>
On Sun, Jun 07, 2026 at 08:06:45AM +0100, Mohammed EL Kadiri wrote:
> Add documentation to slab.rst explaining when and how to use
> SLAB_NO_MERGE to protect security-critical slab caches from
> cross-cache heap exploitation.
Thanks for helping improve the documentation. I haven't looked at the
patch, but have some comments in regards to the process.
We prefer to send new iterations of patches as separate threads,
with the exception being small fixes/cleanups.
Also, I'd recommend waiting a bit longer between versions to let the
maintainers comment since getting documentation is pretty particular.
^ permalink raw reply
* Re: [RFC v1 1/9] kho: split out radix tree tracker into kho_radix.c
From: Pasha Tatashin @ 2026-06-07 16:20 UTC (permalink / raw)
To: Mike Rapoport
Cc: Pasha Tatashin, linux-kselftest, shuah, akpm, linux-mm, skhan,
linux-doc, jasonmiu, linux-kernel, corbet, ran.xiaokai, kexec,
pratyush, graf
In-Reply-To: <178083348873.1648214.11020626647820932506.b4-review@b4>
On 06-07 14:58, Mike Rapoport wrote:
> On Fri, 05 Jun 2026 03:32:27 +0000, Pasha Tatashin <pasha.tatashin@soleen.com> wrote:
> > Move the radix tree tracker implementation from the core KHO code
>
> It's radix tree data structure implementation, kho memory tracker is it's
> user. Please rephrase to keep the semantics clear.
Yeap, I will update it.
>
> >
> >
> > diff --git a/kernel/liveupdate/Makefile b/kernel/liveupdate/Makefile
> > index eec9d3ae07eb..a3ee8a5c27a2 100644
> > --- a/kernel/liveupdate/Makefile
> > +++ b/kernel/liveupdate/Makefile
> > @@ -7,7 +7,11 @@ luo-y := \
> > luo_flb.o \
> > luo_session.o
> >
> > -obj-$(CONFIG_KEXEC_HANDOVER) += kexec_handover.o
> > +kho-y := \
> > + kexec_handover.o \
>
> I don't see much value in moving kexec_handover.o to a separate line,
> btw, the same is true for luo_core.o, but it's not important enough to
> change.
This is purely for consistency. I wanted to use the exact same style in
the Makefile instead of having two different ways of declaring the
object lists.
This:
luo-y := \
luo_core.o \
luo_file.o \
luo_flb.o \
luo_session.o
kho-y := \
kexec_handover.o \
kho_radix.o \
kho_block.o \
kho_vmalloc.o
Or this:
obj-$(CONFIG_LIVEUPDATE) += luo_core.o
obj-$(CONFIG_LIVEUPDATE) += luo_file.o
obj-$(CONFIG_LIVEUPDATE) += luo_flb.o
obj-$(CONFIG_LIVEUPDATE) += luo_session.o
obj-$(CONFIG_KEXEC_HANDOVER) += kexec_handover.o
obj-$(CONFIG_KEXEC_HANDOVER) += kho_radix.o
obj-$(CONFIG_KEXEC_HANDOVER) += kho_vmalloc.o
obj-$(CONFIG_KEXEC_HANDOVER) += kho_block.o
I do not care which way is chosen as long as it is consistent. Since
this series adds new separate files for KHO, and does not touch LUO, I
used LUO as template, but we can do the other way around.
^ permalink raw reply
* [netfilter-nf-next:for-netdev-nf-next-26-06-07 1/15] htmldocs: Documentation/networking/ipvs-sysctl.rst:76: WARNING: Block quote ends without a blank line; unexpected unindent. [docutils]
From: kernel test robot @ 2026-06-07 17:02 UTC (permalink / raw)
To: Julian Anastasov; +Cc: oe-kbuild-all, Pablo Neira Ayuso, linux-doc
tree: https://git.kernel.org/pub/scm/linux/kernel/git/netfilter/nf-next.git for-netdev-nf-next-26-06-07
head: d3bf9eae486490832bd08fd62ab0ac601f346bd4
commit: 4a15044a2b06748c99a8c8c3c6b3ee0a01f8004d [1/15] ipvs: add conn_max sysctl to limit connections
compiler: clang version 22.0.0git (https://github.com/llvm/llvm-project f43d6834093b19baf79beda8c0337ab020ac5f17)
docutils: docutils (Docutils 0.21.2, Python 3.13.5, on linux)
reproduce: (https://download.01.org/0day-ci/archive/20260607/202606071851.Dc1H7hOO-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202606071851.Dc1H7hOO-lkp@intel.com/
All warnings (new ones prefixed by >>):
Checksumming on output with GSO
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ [docutils]
>> Documentation/networking/ipvs-sysctl.rst:76: WARNING: Block quote ends without a blank line; unexpected unindent. [docutils]
Documentation/networking/ipvs-sysctl.rst:76: ERROR: Unexpected section title or transition.
vim +76 Documentation/networking/ipvs-sysctl.rst
9
10 am_droprate - INTEGER
11 default 10
12
13 It sets the always mode drop rate, which is used in the mode 3
14 of the drop_rate defense.
15
16 amemthresh - INTEGER
17 default 1024
18
19 It sets the available memory threshold (in pages), which is
20 used in the automatic modes of defense. When there is no
21 enough available memory, the respective strategy will be
22 enabled and the variable is automatically set to 2, otherwise
23 the strategy is disabled and the variable is set to 1.
24
25 backup_only - BOOLEAN
26 - 0 - disabled (default)
27 - not 0 - enabled
28
29 If set, disable the director function while the server is
30 in backup mode to avoid packet loops for DR/TUN methods.
31
32 conn_lfactor - INTEGER
33 Possible values: -8 (larger table) .. 8 (smaller table)
34
35 Default: -4
36
37 Controls the sizing of the connection hash table based on the
38 load factor (number of connections per table buckets):
39
40 2^conn_lfactor = nodes / buckets
41
42 As result, the table grows if load increases and shrinks when
43 load decreases in the range of 2^8 - 2^conn_tab_bits (module
44 parameter).
45 The value is a shift count where negative values select
46 buckets = (connection hash nodes << -value) while positive
47 values select buckets = (connection hash nodes >> value). The
48 negative values reduce the collisions and reduce the time for
49 lookups but increase the table size. Positive values will
50 tolerate load above 100% when using smaller table is
51 preferred with the cost of more collisions. If using NAT
52 connections consider decreasing the value with one because
53 they add two nodes in the hash table.
54
55 Example:
56 -4: grow if load goes above 6% (buckets = nodes * 16)
57 2: grow if load goes above 400% (buckets = nodes / 4)
58
59 conn_max - INTEGER
60 Limit for number of connections, per netns.
61
62 Controls the soft and hard limit for number of connections.
63 Initially, the platform specific limit is assigned for init_net.
64 The value can be changed and later the soft limit propagated
65 to other networking namespaces.
66
67 Privileged admin can change both limits up to the value of the
68 platform limit while the unprivileged admin can change only the
69 soft limit up to the value of the hard limit.
70
71 For setups using conntrack=1 (CONFIG_IP_VS_NFCT for
72 Netfilter connection tracking) the connections can be
73 limited also by nf_conntrack_max.
74
75 soft limit hard limit
> 76 =====================================================
77 init_net:
78 create netns platform platform
79 priv admin 0 .. platform 0 .. platform
80 =====================================================
81 new netns:
82 create netns init_net:soft init_net:soft
83 priv admin 0 .. platform 0 .. platform
84 unpriv admin 0 .. hard N/A
85
86 Limits per platform:
87 1,073,741,824 (2^30 for 64-bit)
88 16,777,216 (2^24 for 32-bit)
89
90 Possible values: 0 .. platform limit
91
92 Default: platform limit
93
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH] ata: pata_legacy: remove documentation for removed module parameters
From: Randy Dunlap @ 2026-06-07 17:13 UTC (permalink / raw)
To: Ethan Nelson-Moore, linux-doc
Cc: stable, Jonathan Corbet, Shuah Khan, Damien Le Moal
In-Reply-To: <20260607064053.195166-1-enelsonmoore@gmail.com>
On 6/6/26 11:40 PM, Ethan Nelson-Moore wrote:
> Commit 3c4d783f6922 ("ata: pata_legacy: remove VLB support") removed
> several module parameters from the pata_legacy driver, but neglected to
> remove their documentation. Remove it.
>
> Fixes: 3c4d783f6922 ("ata: pata_legacy: remove VLB support")
> Cc: stable@vger.kernel.org # 7.0+
> Signed-off-by: Ethan Nelson-Moore <enelsonmoore@gmail.com>
Reviewed-by: Randy Dunlap <rdunlap@infradead.org>
Thanks.
> ---
> .../admin-guide/kernel-parameters.txt | 37 -------------------
> 1 file changed, 37 deletions(-)
>
> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
> index 97007f4f69d4..47bccc148a54 100644
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt
> @@ -4935,18 +4935,6 @@ Kernel parameters
> Set to non-zero if a chip is present that snoops speed
> changes. Disabled by default.
>
> - pata_legacy.ht6560a= [HW,LIBATA]
> - Format: <int>
> - Set to 1, 2, or 3 for HT 6560A on the primary channel,
> - the secondary channel, or both channels respectively.
> - Disabled by default.
> -
> - pata_legacy.ht6560b= [HW,LIBATA]
> - Format: <int>
> - Set to 1, 2, or 3 for HT 6560B on the primary channel,
> - the secondary channel, or both channels respectively.
> - Disabled by default.
> -
> pata_legacy.iordy_mask= [HW,LIBATA]
> Format: <int>
> IORDY enable mask. Set individual bits to allow IORDY
> @@ -4959,18 +4947,6 @@ Kernel parameters
> with the sequence. By default IORDY is allowed across
> all channels.
>
> - pata_legacy.opti82c46x= [HW,LIBATA]
> - Format: <int>
> - Set to 1, 2, or 3 for Opti 82c611A on the primary
> - channel, the secondary channel, or both channels
> - respectively. Disabled by default.
> -
> - pata_legacy.opti82c611a= [HW,LIBATA]
> - Format: <int>
> - Set to 1, 2, or 3 for Opti 82c465MV on the primary
> - channel, the secondary channel, or both channels
> - respectively. Disabled by default.
> -
> pata_legacy.pio_mask= [HW,LIBATA]
> Format: <int>
> PIO mode mask for autospeed devices. Set individual
> @@ -4994,19 +4970,6 @@ Kernel parameters
> the first port in the list above (0x1f0), and so on.
> By default all supported ports are probed.
>
> - pata_legacy.qdi= [HW,LIBATA]
> - Format: <int>
> - Set to non-zero to probe QDI controllers. By default
> - set to 1 if CONFIG_PATA_QDI_MODULE, 0 otherwise.
> -
> - pata_legacy.winbond= [HW,LIBATA]
> - Format: <int>
> - Set to non-zero to probe Winbond controllers. Use
> - the standard I/O port (0x130) if 1, otherwise the
> - value given is the I/O port to use (typically 0x1b0).
> - By default set to 1 if CONFIG_PATA_WINBOND_VLB_MODULE,
> - 0 otherwise.
> -
> pata_platform.pio_mask= [HW,LIBATA]
> Format: <int>
> Supported PIO mode mask. Set individual bits to allow
--
~Randy
^ permalink raw reply
* Re: [RFC v1 1/9] kho: split out radix tree tracker into kho_radix.c
From: Mike Rapoport @ 2026-06-07 17:59 UTC (permalink / raw)
To: Pasha Tatashin
Cc: Mike Rapoport, linux-kselftest, shuah, akpm, linux-mm, skhan,
linux-doc, jasonmiu, linux-kernel, corbet, ran.xiaokai, kexec,
pratyush, graf
In-Reply-To: <aiWYZhoSOAruIIM3@plex>
On 2026-06-07 16:20:50+00:00, Pasha Tatashin wrote:
> On 06-07 14:58, Mike Rapoport wrote:
>
> > On Fri, 05 Jun 2026 03:32:27 +0000, Pasha Tatashin <pasha.tatashin@soleen.com> wrote:
> >
> > It's radix tree data structure implementation, kho memory tracker is it's
> > user. Please rephrase to keep the semantics clear.
>
> Yeap, I will update it.
>
> > I don't see much value in moving kexec_handover.o to a separate line,
> > btw, the same is true for luo_core.o, but it's not important enough to
> > change.
>
> This is purely for consistency. I wanted to use the exact same style in
> the Makefile instead of having two different ways of declaring the
> object lists.
>
> This:
> luo-y := \
> luo_core.o \
> luo_file.o \
> luo_flb.o \
> luo_session.o
>
> kho-y := \
> kexec_handover.o \
> kho_radix.o \
> kho_block.o \
> kho_vmalloc.o
I mean this:
luo-y := luo_core.o \
luo_file.o \
luo_flb.o \
luo_session.o
kho-y := kexec_handover.o \
kho_radix.o \
kho_block.o \
kho_vmalloc.o
^ permalink raw reply
* Re: [PATCH v6 07/12] PCI: Refactor matching logic for pci_dev_acs_ops
From: Pranjal Shrivastava @ 2026-06-07 19:01 UTC (permalink / raw)
To: David Matlack
Cc: kexec, linux-doc, linux-kernel, linux-mm, linux-pci,
Adithya Jayachandran, Alexander Graf, Alex Williamson,
Bjorn Helgaas, Chris Li, David Rientjes, Jacob Pan,
Jason Gunthorpe, Jonathan Corbet, Josh Hilke, Leon Romanovsky,
Lukas Wunner, Mike Rapoport, Parav Pandit, Pasha Tatashin,
Pratyush Yadav, Saeed Mahameed, Samiullah Khawaja, Shuah Khan,
Vipin Sharma, William Tu, Yi Liu
In-Reply-To: <20260522202410.3104264-8-dmatlack@google.com>
On Fri, May 22, 2026 at 08:24:05PM +0000, David Matlack wrote:
> Refactor the logic to match devices to pci_dev_acs_ops by factoring out
> the loop and device matching into its own routine. This eliminates some
> duplicate code between pci_dev_specific_enable_acs() and
> pci_dev_specific_disable_acs_redir(), and will also be used in a
> subsequent commit to check if a device requires device-specific
> enable_acs() during a Live Update.
>
> No functional change intended.
>
> Signed-off-by: David Matlack <dmatlack@google.com>
> ---
> drivers/pci/quirks.c | 50 ++++++++++++++++++--------------------------
> 1 file changed, 20 insertions(+), 30 deletions(-)
>
[...]
> } pci_dev_acs_ops[] = {
> { PCI_VENDOR_ID_INTEL, PCI_ANY_ID,
> + .match = pci_quirk_intel_pch_acs_match,
> .enable_acs = pci_quirk_enable_intel_pch_acs,
> },
> { PCI_VENDOR_ID_INTEL, PCI_ANY_ID,
> + .match = pci_quirk_intel_spt_pch_acs_match,
> .enable_acs = pci_quirk_enable_intel_spt_pch_acs,
> .disable_acs_redir = pci_quirk_disable_intel_spt_pch_acs_redir,
> },
> };
>
> -int pci_dev_specific_enable_acs(struct pci_dev *dev)
> +static const struct pci_dev_acs_ops *pci_dev_acs_ops_get(struct pci_dev *dev)
> {
> const struct pci_dev_acs_ops *p;
> - int i, ret;
> + int i;
>
> for (i = 0; i < ARRAY_SIZE(pci_dev_acs_ops); i++) {
> p = &pci_dev_acs_ops[i];
> @@ -5481,33 +5475,29 @@ int pci_dev_specific_enable_acs(struct pci_dev *dev)
> p->vendor == (u16)PCI_ANY_ID) &&
> (p->device == dev->device ||
> p->device == (u16)PCI_ANY_ID) &&
> - p->enable_acs) {
> - ret = p->enable_acs(dev);
> - if (ret >= 0)
> - return ret;
> - }
> + p->match(dev))
> + return p;
Nit:
Should we check if (p->match != NULL) like we check for p->enable_acs &
p->disable_acs_redir().
Otherwise, it seems like we're mandating the existence of a match op in
the pci_dev_acs_ops here? Today, we just have two Intel entries in that
array, both of which need the match op. However, AFAICT, it shouldn't be
mandatory for future SoCs that might only need a simple vid + devid match
[...]
with that nit:
Reviewed-by: Pranjal Shrivastava <praan@google.com>
Thanks,
Praan
^ permalink raw reply
* RE: [PATCH net-next v4 13/16] onsemi: s2500: Add driver support for TS2500 MAC-PHY
From: Selvamani Rajagopal @ 2026-06-07 19:25 UTC (permalink / raw)
To: Randy Dunlap, Andrew Lunn, Piergiorgio Beruto, Heiner Kallweit,
Russell King, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Andrew Lunn, Parthiban Veerasooran, Richard Cochran,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Simon Horman,
Jonathan Corbet, Shuah Khan
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
devicetree@vger.kernel.org, linux-doc@vger.kernel.org, Jerry Ray
In-Reply-To: <7b100b6a-40c5-407d-8de0-7b1edb82a16c@infradead.org>
> Subject: Re: [PATCH net-next v4 13/16] onsemi: s2500: Add driver support for TS2500
> MAC-PHY
>
> > + the questions about onsemi ethernet devices. If you say Y, you
> > + will be asked for your specific card in the following questions.
>
> Above line should be indented with one tab + spaces.
Sorry about that. Will fix the formatting issue in both Kconfig files,
one under onsemi and one under onsemi/s2500.
> > + /**
>
> Use /*
> since this is not a kernel-doc comment.
>
Yes. will fix it.
> > + * Convert unsigned scaled_ppm to atto-seconds per clock cycles.
> > + * The scaled_ppm format is Qx.16 --> 1 lsb = 1/65536 ppm.
> > + * The clock period of the S2500 is 8ns (125 MHz), so 1 lsb of
^ permalink raw reply
* Re: [PATCH v6 08/12] PCI: liveupdate: Inherit ACS flags in incoming preserved devices
From: Pranjal Shrivastava @ 2026-06-07 20:37 UTC (permalink / raw)
To: David Matlack
Cc: kexec, linux-doc, linux-kernel, linux-mm, linux-pci,
Adithya Jayachandran, Alexander Graf, Alex Williamson,
Bjorn Helgaas, Chris Li, David Rientjes, Jacob Pan,
Jason Gunthorpe, Jonathan Corbet, Josh Hilke, Leon Romanovsky,
Lukas Wunner, Mike Rapoport, Parav Pandit, Pasha Tatashin,
Pratyush Yadav, Saeed Mahameed, Samiullah Khawaja, Shuah Khan,
Vipin Sharma, William Tu, Yi Liu
In-Reply-To: <20260522202410.3104264-9-dmatlack@google.com>
On Fri, May 22, 2026 at 08:24:06PM +0000, David Matlack wrote:
> Inherit Access Control Services (ACS) flags on all incoming preserved
> devices (endpoints and upstream bridges) during a Live Update.
>
> Inheriting ACS flags avoids changing routing rules while memory
> transactions are in flight from preserved devices. This is also strictly
> necessary to ensure that IOMMU group assignments do not change across
> a Live Update for preserved devices, as changing ACS configurations can
> split or merge IOMMU groups.
>
> Cache the inherited ACS controls established by the previous kernel in
> struct pci_dev so that ACS controls do not change after a reset
> (pci_restore_state() calls pci_enable_acs()).
>
> To simplify ACS inheritance, reject preserving any devices that require
> quirks to enable ACS as those quirks would also have to take Live Update
> into account.
>
> Signed-off-by: David Matlack <dmatlack@google.com>
> ---
> drivers/pci/liveupdate.c | 68 ++++++++++++++++++++++++++++++++++
> drivers/pci/liveupdate.h | 11 ++++++
> drivers/pci/pci.c | 5 +++
> drivers/pci/pci.h | 5 +++
> drivers/pci/quirks.c | 7 ++++
> include/linux/pci_liveupdate.h | 6 +++
> 6 files changed, 102 insertions(+)
>
[...]
>
> +void pci_liveupdate_init_acs(struct pci_dev *dev)
> +{
> + guard(rwsem_read)(&pci_liveupdate.rwsem);
> +
> + if (!dev->acs_cap || !dev->liveupdate.incoming)
> + return;
> +
> + pci_read_config_word(dev, dev->acs_cap + PCI_ACS_CTRL, &dev->liveupdate.acs_ctrl);
I might be thinking out loud here, but as an attacker, this motivates me
to somehow hack the EP FW to mis-report the PCI_ACS_CTRL register across
a liveupdate to fool the incoming kernel. If the FW feeds a 0, it silently
strips ACS protections.
Should we also serialize ACS state in ser somehow to ensure we aren't
fooled by something like this?
> +}
> +
> +int pci_liveupdate_enable_acs(struct pci_dev *dev)
> +{
> + u16 acs_ctrl = dev->liveupdate.acs_ctrl;
> + u16 acs_cap = dev->acs_cap;
> +
> + /*
> + * Use liveupdate.was_preserved instead of liveupdate.incoming since the
> + * device's ACS controls should not change even after the device is
> + * finished participating in the Live Update.
> + */
> + if (!dev->liveupdate.was_preserved)
> + return -EINVAL;
> +
> + /*
> + * The previous kernel should not have preserved any devices that
> + * require device-specific quirks to enable ACS, but if such a device is
> + * detected, log a big warning and fall back to the normal enable ACS
> + * path.
> + */
Nit: It might be worth adding a note here that this can also happen if a
new device-specific ACS quirk is introduced in the incoming kernel for a
device that was preserved by the old kernel (which didn't have the quirk).
In such cases, the two kernels are essentially non-LUO-compatible..
> + if (pci_need_dev_specific_enable_acs(dev)) {
> + pci_warn(dev, "Device-specific quirk required to enable ACS!\n");
> + WARN_ON_ONCE(true);
> + return -EINVAL;
> + }
> +
> + if (acs_cap)
> + pci_write_config_word(dev, acs_cap + PCI_ACS_CTRL, acs_ctrl);
> +
> + return 0;
> +}
> +
> /**
> * pci_liveupdate_is_incoming() - Check if a device is incoming-preserved
> * @dev: The PCI device to check
[...]
Thanks,
Praan
^ permalink raw reply
* Re: [PATCH RESEND] riscv: enable HAVE_CMPXCHG_{DOUBLE,LOCAL}
From: Miquel Sabaté Solà @ 2026-06-07 20:38 UTC (permalink / raw)
To: Paul Walmsley
Cc: linux-riscv, corbet, skhan, palmer, alex, linux-doc, linux-kernel
In-Reply-To: <f63eefc9-769d-409c-4099-274254432129@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 3054 bytes --]
Hi,
Paul Walmsley @ 2026-06-06 18:50 -06:
> Hi,
>
> On Fri, 5 Jun 2026, Miquel Sabaté Solà wrote:
>
>> Support for atomic Compare-And-Swap instructions has been in the RISC-V
>> port of the Linux kernel for a long time. That being said, we apparently
>> never bothered to set HAVE_CMPXCHG_DOUBLE and HAVE_CMPXCHG_LOCAL in the
>> Kconfig, despite having all the framework to support them.
>>
>> Signed-off-by: Miquel Sabaté Solà <mssola@mssola.com>
>> ---
>> This is a resend of [1], rebased on top of the latest commit from the
>> for-next branch.
>>
>> I have built this patch with multiple configurations and ran it with KVM
>> (the VisionFive2 board that I have lacks the needed extensions). All seems
>> to work, but I do wonder if we did not enable these for a reason or this
>> just slipped through. So far in the code I believe everything is in place,
>> and I haven't seen any commit in the git log stating otherwise.
>>
>> [1] https://lore.kernel.org/all/20260220074449.8526-1-mssola@mssola.com/
>
> Thanks for the patch. Your comments above are why I've been hesitant to
> merge it. I'm not aware of any publicly available hardware that supports
> Zacas/Zabha. No one has stepped forward to provide any Tested-by:s on
> hardware that hasn't been released yet. You mention that you tested on
> your VisionFive2 board, but it would not have exercised those code paths.
No, I mention that I ran it _only_ on KVM, as my VisionFive2 board lacks
these extensions and hence I couldn't possible have tested this there :)
>
> Of course, we already have Zacas/Zabha support, merged back in 2024, in
> cmpxchg.h. I assume (?) that it was tested in QEMU, but I don't see any
> comments about that in the patch series. No one sent any Tested-by:s
> then, either.
>
> It would be good if you (and ideally others) could put this patch through
> some testing on QEMU with Zacas and Zabha enabled, before we merge it.
> The affected code paths for HAVE_CMPXCHG_LOCAL seem to primarily involve
> per-CPU counters and MM zone counters, so those would be the areas to
> focus. HAVE_CMPXCHG_DOUBLE seems to do nothing useful other than
> preventing the AMD IOMMU driver from being selected if it's not present,
> so that part of the patch seems fairly useless. In fact I'd suggest
> dropping that from the patch and just sending a separate patch to remove
> HAVE_CMPXCHG_DOUBLE from the kernel completely.
To be fair, on QEMU I only "tested" it by booting it, running a few
things for some time and ensuring that nothing got totally broken in the
process while taking a look at the kernel logs.
In any case, let me double check with QEMU with these extensions enabled
and I'll try to be more thorough about it. I'll do just that whenever I
have some spare time during the following week :)
As for HAVE_CMPXCHG_DOUBLE, removing it makes sense. Let me just take
another look and I will send a separate patch whenever I'm ready for it.
>
>
> - Paul
Thanks for your input!
Miquel
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 897 bytes --]
^ permalink raw reply
* RE: [PATCH net-next v4 16/16] Documentation: networking: Add timestamp related APIs to OA TC6 framework
From: Selvamani Rajagopal @ 2026-06-07 21:10 UTC (permalink / raw)
To: Randy Dunlap, Andrew Lunn, Piergiorgio Beruto, Heiner Kallweit,
Russell King, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Andrew Lunn, Parthiban Veerasooran, Richard Cochran,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Simon Horman,
Jonathan Corbet, Shuah Khan
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
devicetree@vger.kernel.org, linux-doc@vger.kernel.org, Jerry Ray
In-Reply-To: <cf3d6937-1ffa-4d81-8e19-b3f607a7e1d1@infradead.org>
>
> Hi,
> These needs a few additional blank lines to avoid docs build warnings:
Will do. My bad that I didn't verify with make htmldocs after editing the file.
>
> Documentation/networking/oa-tc6-framework.rst:554: WARNING: Explicit markup ends
> without a blank line; unexpected unindent. [docutils]
> Documentation/networking/oa-tc6-framework.rst:561: WARNING: Explicit markup ends
> without a blank line; unexpected unindent. [docutils]
> Documentation/networking/oa-tc6-framework.rst:566: WARNING: Explicit markup ends
> without a blank line; unexpected unindent. [docutils]
> Documentation/networking/oa-tc6-framework.rst:573: WARNING: Explicit markup ends
> without a blank line; unexpected unindent. [docutils]
>
> See below.
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox