* 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] 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 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
* 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: [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
* [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 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
* 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
* [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
* [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] 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] ata: pata_legacy: remove documentation for removed module parameters
From: Ethan Nelson-Moore @ 2026-06-07 6:40 UTC (permalink / raw)
To: linux-doc
Cc: Ethan Nelson-Moore, stable, Jonathan Corbet, Shuah Khan,
Damien Le Moal
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>
---
.../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
--
2.43.0
^ permalink raw reply related
* Re: [PATCH net-next v4 13/16] onsemi: s2500: Add driver support for TS2500 MAC-PHY
From: Randy Dunlap @ 2026-06-07 5:56 UTC (permalink / raw)
To: Selvamani.Rajagopal, 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, linux-kernel, devicetree, linux-doc, Jerry Ray
In-Reply-To: <20260605-s2500-mac-phy-support-v4-13-de0fbc13c6d8@onsemi.com>
On 6/5/26 10:42 PM, Selvamani Rajagopal via B4 Relay wrote:
> From: Selvamani Rajagopal <Selvamani.Rajagopal@onsemi.com>
>
> Support for onsemi's S2500, 802.3 cg compliant Ethernet
> transceiver with integrated MAC-PHY. Works with
> Open Alliance TC6 framework.
>
> adjtime callback is implemented using adjfine. If time
> delta is too big, bigger than 1 second, using adjtime
> would take long to reduce the delta. In those cases,
> settime callback is used to reduce the delta. Once delta
> becomes less than a second, it uses adjfine to reduce
> the drift further.
>
> Signed-off-by: Selvamani Rajagopal <Selvamani.Rajagopal@onsemi.com>
> ---
> MAINTAINERS | 7 +
> drivers/net/ethernet/oa_tc6/oa_tc6_std_def.h | 2 +-
> drivers/net/ethernet/onsemi/Kconfig | 21 +
> drivers/net/ethernet/onsemi/Makefile | 7 +
> drivers/net/ethernet/onsemi/s2500/Kconfig | 21 +
> drivers/net/ethernet/onsemi/s2500/Makefile | 7 +
> drivers/net/ethernet/onsemi/s2500/s2500_ethtool.c | 347 ++++++++++++
> drivers/net/ethernet/onsemi/s2500/s2500_hw_def.h | 225 ++++++++
> drivers/net/ethernet/onsemi/s2500/s2500_main.c | 632 ++++++++++++++++++++++
> drivers/net/ethernet/onsemi/s2500/s2500_ptp.c | 233 ++++++++
> 10 files changed, 1501 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/onsemi/Kconfig b/drivers/net/ethernet/onsemi/Kconfig
> new file mode 100644
> index 000000000000..8dd3a3f074a2
> --- /dev/null
> +++ b/drivers/net/ethernet/onsemi/Kconfig
> @@ -0,0 +1,21 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> +#
> +# onsemi network device configuration
> +#
> +
> +config NET_VENDOR_ONSEMI
> + bool "onsemi network devices"
> + help
> + If you have a network card belonging to this class, say Y.
> +
> + Note that the answer to this question doesn't directly affect the
> + kernel: saying N will just cause the configurator to skip all
> + 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.
> +
> +if NET_VENDOR_ONSEMI
> +
> +source "drivers/net/ethernet/onsemi/s2500/Kconfig"
> +
> +endif # NET_VENDOR_ONSEMI
> +
> diff --git a/drivers/net/ethernet/onsemi/s2500/Kconfig b/drivers/net/ethernet/onsemi/s2500/Kconfig
> new file mode 100644
> index 000000000000..22b0afad7a21
> --- /dev/null
> +++ b/drivers/net/ethernet/onsemi/s2500/Kconfig
> @@ -0,0 +1,21 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> +#
> +# onsemi S2500 Driver Support
> +#
> +
> +if NET_VENDOR_ONSEMI
> +
> +config S2500_MACPHY
> + help
> + tristate "S2500 support"
> + depends on SPI
> + select NCN26000_PHY
> + select OA_TC6
> + Support for the onsemi TS2500 MACPHY Ethernet chip.
> + It works under the framework that conform to OPEN Alliance
> + 10BASE-T1x Serial Interface specification.
> +
> + To compile this driver as a module, choose M here. The module will be
> + called s2500.
Kconfig help text should be indented with one tab + 2 spaces (applies to
all lines following the "Support for the ..." line).
> +
> +endif # NET_VENDOR_ONSEMI
> diff --git a/drivers/net/ethernet/onsemi/s2500/s2500_ptp.c b/drivers/net/ethernet/onsemi/s2500/s2500_ptp.c
> new file mode 100644
> index 000000000000..fd6617c7ac79
> --- /dev/null
> +++ b/drivers/net/ethernet/onsemi/s2500/s2500_ptp.c
> +static int s2500_ptp_adjfine(struct ptp_clock_info *ptp, long scaled_ppm)
> +{
> + struct s2500_info *priv = container_of(ptp, struct s2500_info,
> + ptp_clock_info);
> + u32 sign_bit = 0;
> + long adj;
> + u32 val;
> + u64 ppm;
> +
> + if (scaled_ppm < 0) {
> + /* split sign / mod */
> + sign_bit = 1U << 31;
> + scaled_ppm = ~scaled_ppm + 1;
> + }
> +
> + /**
Use /*
since this is not a kernel-doc comment.
> + * 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
> + * adj register LSB is 1 atto-sec / 8ns = 0.000125 ppm.
> + * Represented in Qx.16 format, this is 0.000125 * 2^16 = 8(.192)
> + * To convert scaled_ppm into a register value we need to divide
> + * it by the LSB value, hence adj = (scaled_ppm * 1000) / 8192 to
> + * minimize the precision loss due to the integer arithmetic.
> + * That further reduces to (scaled_ppm * 125) / 1024.
> + */
> + ppm = (u64)scaled_ppm * 125;
> + do_div(ppm, 1024);
> + adj = (long)ppm;
> +
> + /* check overflow */
> + if (adj >= (1L << 28))
> + return -ERANGE;
> +
> + val = (u32)adj | sign_bit;
> + return oa_tc6_write_register_mms(priv->tc6, S2500_REG_VS_PTP_ADJ,
> + OA_TC6_PHY_C45_VS_MMS12, val);
> +}
--
~Randy
^ permalink raw reply
* Re: [PATCH net-next v4 16/16] Documentation: networking: Add timestamp related APIs to OA TC6 framework
From: Randy Dunlap @ 2026-06-07 5:49 UTC (permalink / raw)
To: Selvamani.Rajagopal, 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, linux-kernel, devicetree, linux-doc, Jerry Ray
In-Reply-To: <20260605-s2500-mac-phy-support-v4-16-de0fbc13c6d8@onsemi.com>
Hi,
These needs a few additional blank lines to avoid docs build warnings:
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.
On 6/5/26 10:42 PM, Selvamani Rajagopal via B4 Relay wrote:
> From: Selvamani Rajagopal <Selvamani.Rajagopal@onsemi.com>
>
> Added new APIs to support hardware timestamp feature as defined in
> OPEN Alliance 10BASE-T1x MAC-PHY serial interface specification.
>
> Signed-off-by: Selvamani Rajagopal <Selvamani.Rajagopal@onsemi.com>
> ---
> Documentation/networking/oa-tc6-framework.rst | 76 +++++++++++++++++++++++++++
> 1 file changed, 76 insertions(+)
>
> diff --git a/Documentation/networking/oa-tc6-framework.rst b/Documentation/networking/oa-tc6-framework.rst
> index fe2aabde923a..694d9485b1c5 100644
> --- a/Documentation/networking/oa-tc6-framework.rst
> +++ b/Documentation/networking/oa-tc6-framework.rst
> @@ -153,6 +153,10 @@ OPEN Alliance TC6 Framework
> - Forwards the received Ethernet frame from 10Base-T1x MAC-PHY to n/w
> subsystem.
>
> +- If supported by the hardware and enabled, updates hardware timestamp
> + in skb, when indicated by one of the three timestamp capture registers
> + through TSC fields of the header.
> +
> Data Transaction
> ~~~~~~~~~~~~~~~~
>
> @@ -495,3 +499,75 @@ the MAC-PHY.
> Zero align receive frame feature can be enabled to align all receive ethernet
> frames data to start at the beginning of any receive data chunk payload with a
> start word offset (SWO) of zero.
> +
> +.. c:function:: int oa_tc6_ptp_register(struct oa_tc6 *tc6, \
> + struct ptp_clock_info *info);
> +
> +Registers the PTP hardware clock related functions with the kernel.
> +This API simply registers. Initialization of the fields in the
> +ptp_clock_info structure are left to the vendor as programming hardware
> +timer is expected to be vendor dependent. The fields max_adj, owner,
> +and all the functions for the clock operations, like adjfine, gettimex64,
> +settime64, adjtime are expected to be initialized in the structure before
> +calling the registering the hardware clock.
> +
> +.. c:function:: void oa_tc6_ptp_unregister(struct oa_tc6 *tc6);
> +
> +Unregisters the PTP hardware clock related callbacks.
> +
> +.. c:function:: int oa_tc6_ioctl(struct oa_tc6 *tc6, struct ifreq *rq, \
> + int cmd);
> +
> +ioctl interface to handle hardware timestamp and PHY related commands.
> +
> +.. c:function:: int oa_tc6_get_ts_info(struct oa_tc6 *tc6, \
> + struct kernel_ethtool_ts_info *info);
> +
> +Provides timestamp related settings that are supported to ethtool.
> +
> +.. c:function:: void oa_tc6_hwtstamp_get(struct oa_tc6 *tc6, \
> + struct kernel_hwtstamp_config *cfg);
> +
> +Returns hardware timestamp configuration. Part of net_device_ops callbacks.
> +
> +.. c:function:: void oa_tc6_get_ts_stats(struct oa_tc6 *tc6, \
> + struct ethtool_ts_stats *ts_stats);
> +
> +Provides hardware timestamp related traffic statistics for ethtool.
> +
> +.. c:function:: int oa_tc6_hwtstamp_set(struct oa_tc6 *tc6, \
> + struct kernel_hwtstamp_config *cfg);
> +
> +Helper to set hardware timestamp configuration. Part of net_device_ops
> +callbacks.
> +
> +.. c:function:: void oa_tc6_set_vend1_mms(struct oa_tc6 *tc6, int mms);
> +
> +Helper to map MDIO_MMD_VEND1 command to vendor specific Memory Map Select
> +(MMS) value. This function offers flexibility for vendors that may have
> +used any MMS value between 10 and 15 as allowed by the specification.
> +MDIO_MMD_VEND2 is already mapped to MMS4 in the OA TC6 frame work code.
> +
> +.. c:function:: int oa_tc6_write_registers_mms(struct oa_tc6 *tc6, \
> + u16 address, u16 mms, \
> + u32 value[], u8 length);
Insert blank line here.
> +Writing multiple consecutive registers starting from @address for the
> +given @mms memory map selector in the MAC-PHY. Maximum of 128 consecutive
> +registers can be written starting at @address.
> +
> +.. c:function:: int oa_tc6_write_register_mms(struct oa_tc6 *tc6, \
> + u16 address, u16 mms, \
> + u32 value);
and here.
> +Write a single register addressed by @address and @mms in the MAC-PHY.
> +
> +.. c:function:: int oa_tc6_read_registers_mms(struct oa_tc6 *tc6, \
> + u16 address, u16 mms, \
> + u32 value[], u8 length);
and here.
> +Reading multiple consecutive registers starting from @address for the
> +given @mms memory map selector value, in the MAC-PHY. Maximum of 128
> +consecutive registers can be read starting at @address.
> +
> +.. c:function:: int oa_tc6_read_register_mms(struct oa_tc6 *tc6, \
> + u16 address, u16 mms, \
> + u32 *value);
and here.
> +Read a single register addressed by @address and @mms in the MAC-PHY.
>
--
~Randy
^ permalink raw reply
* Re: [PATCH] docs: memfd_preservation: fix rendering of ABI documentation
From: Mike Rapoport @ 2026-06-07 5:40 UTC (permalink / raw)
To: Pasha Tatashin, Andrew Morton, David Hildenbrand, Jonathan Corbet,
Shuah Khan, Pratyush Yadav
Cc: kexec, linux-kernel, linux-mm, linux-doc
In-Reply-To: <20260605160645.3650271-1-pratyush@kernel.org>
On Fri, 05 Jun 2026 18:06:44 +0200, Pratyush Yadav wrote:
> docs: memfd_preservation: fix rendering of ABI documentation
Applied to next branch of liveupdate/linux.git tree, thanks!
[1/1] docs: memfd_preservation: fix rendering of ABI documentation
commit: 3a358c78093f98a70d84c934b7054f636bc846f2
tree: https://git.kernel.org/pub/scm/linux/kernel/git/liveupdate/linux
branch: next
--
Sincerely yours,
Mike.
^ permalink raw reply
* Re: [PATCH RESEND] riscv: enable HAVE_CMPXCHG_{DOUBLE,LOCAL}
From: Paul Walmsley @ 2026-06-07 0:50 UTC (permalink / raw)
To: Miquel Sabaté Solà
Cc: linux-riscv, corbet, skhan, pjw, palmer, alex, linux-doc,
linux-kernel
In-Reply-To: <20260605141247.253315-1-mssola@mssola.com>
[-- Attachment #1: Type: text/plain, Size: 2180 bytes --]
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.
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.
- Paul
^ permalink raw reply
* Re: [RFC PATCH v2 01/10] liveupdate: luo_file: Add internal APIs for file preservation
From: tarunsahu @ 2026-06-07 0:35 UTC (permalink / raw)
To: Jonathan Corbet, vannapurve, fvdl, Pasha Tatashin, Shuah Khan,
sagis, aneesh.kumar, skhawaja, vipinsh, ackerleytng,
Pratyush Yadav, david, dmatlack, mark.rutland, Paolo Bonzini,
Mike Rapoport, Alexander Graf, seanjc, axelrasmussen
Cc: linux-kselftest, kexec, linux-kernel, linux-doc, kvm, linux-mm
In-Reply-To: <c054ba0fb2639932bbe354420d3f4f84cce84905.1780676742.git.tarunsahu@google.com>
Hi,
I am sorry for incorrect layout of this series. After copy-pasting
I forgot to change the message id in header and the cover letter is not
attached to the same thread.
Please find the V2 cover letter here:
https://lore.kernel.org/all/cover.1780667929.git.tarunsahu@google.com/
Also for latest discussion related to scope:
https://lore.kernel.org/all/9huzldcrxkch.fsf@tarunix.c.googlers.com/
Thankyou
Tarun Sahu <tarunsahu@google.com> writes:
> From: Pasha Tatashin <pasha.tatashin@soleen.com>
>
> The core liveupdate mechanism allows userspace to preserve file
> descriptors. However, kernel subsystems often manage struct file
> objects directly and need to participate in the preservation process
> programmatically without relying solely on userspace interaction.
>
> Signed-off-by: Pasha Tatashin <pasha.tatashin@soleen.com>
> Signed-off-by: Samiullah Khawaja <skhawaja@google.com>
> Signed-off-by: Tarun Sahu <tarunsahu@google.com>
> ---
> include/linux/liveupdate.h | 21 ++++++++++
> kernel/liveupdate/luo_file.c | 69 ++++++++++++++++++++++++++++++++
> kernel/liveupdate/luo_internal.h | 17 ++++++++
> 3 files changed, 107 insertions(+)
>
> diff --git a/include/linux/liveupdate.h b/include/linux/liveupdate.h
> index 30c5a39ff9e9..de052438eaac 100644
> --- a/include/linux/liveupdate.h
> +++ b/include/linux/liveupdate.h
> @@ -24,6 +24,7 @@ struct file;
> /**
> * struct liveupdate_file_op_args - Arguments for file operation callbacks.
> * @handler: The file handler being called.
> + * @session: The session this file belongs to.
> * @retrieve_status: The retrieve status for the 'can_finish / finish'
> * operation. A value of 0 means the retrieve has not been
> * attempted, a positive value means the retrieve was
> @@ -44,6 +45,7 @@ struct file;
> */
> struct liveupdate_file_op_args {
> struct liveupdate_file_handler *handler;
> + struct liveupdate_session *session;
> int retrieve_status;
> struct file *file;
> u64 serialized_data;
> @@ -240,6 +242,13 @@ void liveupdate_unregister_flb(struct liveupdate_file_handler *fh,
>
> int liveupdate_flb_get_incoming(struct liveupdate_flb *flb, void **objp);
> int liveupdate_flb_get_outgoing(struct liveupdate_flb *flb, void **objp);
> +/* kernel can internally retrieve files */
> +int liveupdate_get_file_incoming(struct liveupdate_session *s, u64 token,
> + struct file **filep);
> +
> +/* Get a token for an outgoing file, or -ENOENT if file is not preserved */
> +int liveupdate_get_token_outgoing(struct liveupdate_session *s,
> + struct file *file, u64 *tokenp);
>
> #else /* CONFIG_LIVEUPDATE */
>
> @@ -285,5 +294,17 @@ static inline int liveupdate_flb_get_outgoing(struct liveupdate_flb *flb,
> return -EOPNOTSUPP;
> }
>
> +static inline int liveupdate_get_file_incoming(struct liveupdate_session *s,
> + u64 token, struct file **filep)
> +{
> + return -EOPNOTSUPP;
> +}
> +
> +static inline int liveupdate_get_token_outgoing(struct liveupdate_session *s,
> + struct file *file, u64 *tokenp)
> +{
> + return -EOPNOTSUPP;
> +}
> +
> #endif /* CONFIG_LIVEUPDATE */
> #endif /* _LINUX_LIVEUPDATE_H */
> diff --git a/kernel/liveupdate/luo_file.c b/kernel/liveupdate/luo_file.c
> index a0a419085e28..0aa0b4e5339f 100644
> --- a/kernel/liveupdate/luo_file.c
> +++ b/kernel/liveupdate/luo_file.c
> @@ -323,6 +323,7 @@ int luo_preserve_file(struct luo_file_set *file_set, u64 token, int fd)
> mutex_init(&luo_file->mutex);
>
> args.handler = fh;
> + args.session = luo_session_from_file_set(file_set);
> args.file = file;
> err = fh->ops->preserve(&args);
> if (err)
> @@ -380,6 +381,7 @@ void luo_file_unpreserve_files(struct luo_file_set *file_set)
> struct luo_file, list);
>
> args.handler = luo_file->fh;
> + args.session = luo_session_from_file_set(file_set);
> args.file = luo_file->file;
> args.serialized_data = luo_file->serialized_data;
> args.private_data = luo_file->private_data;
> @@ -411,6 +413,7 @@ static int luo_file_freeze_one(struct luo_file_set *file_set,
> struct liveupdate_file_op_args args = {0};
>
> args.handler = luo_file->fh;
> + args.session = luo_session_from_file_set(file_set);
> args.file = luo_file->file;
> args.serialized_data = luo_file->serialized_data;
> args.private_data = luo_file->private_data;
> @@ -432,6 +435,7 @@ static void luo_file_unfreeze_one(struct luo_file_set *file_set,
> struct liveupdate_file_op_args args = {0};
>
> args.handler = luo_file->fh;
> + args.session = luo_session_from_file_set(file_set);
> args.file = luo_file->file;
> args.serialized_data = luo_file->serialized_data;
> args.private_data = luo_file->private_data;
> @@ -621,6 +625,7 @@ int luo_retrieve_file(struct luo_file_set *file_set, u64 token,
> }
>
> args.handler = luo_file->fh;
> + args.session = luo_session_from_file_set(file_set);
> args.serialized_data = luo_file->serialized_data;
> err = luo_file->fh->ops->retrieve(&args);
> if (err) {
> @@ -654,6 +659,7 @@ static int luo_file_can_finish_one(struct luo_file_set *file_set,
> struct liveupdate_file_op_args args = {0};
>
> args.handler = luo_file->fh;
> + args.session = luo_session_from_file_set(file_set);
> args.file = luo_file->file;
> args.serialized_data = luo_file->serialized_data;
> args.retrieve_status = luo_file->retrieve_status;
> @@ -671,6 +677,7 @@ static void luo_file_finish_one(struct luo_file_set *file_set,
> guard(mutex)(&luo_file->mutex);
>
> args.handler = luo_file->fh;
> + args.session = luo_session_from_file_set(file_set);
> args.file = luo_file->file;
> args.serialized_data = luo_file->serialized_data;
> args.retrieve_status = luo_file->retrieve_status;
> @@ -924,3 +931,65 @@ void liveupdate_unregister_file_handler(struct liveupdate_file_handler *fh)
> luo_flb_unregister_all(fh);
> list_del(&ACCESS_PRIVATE(fh, list));
> }
> +EXPORT_SYMBOL_GPL(liveupdate_unregister_file_handler);
> +
> +/**
> + * liveupdate_get_token_outgoing - Get the token for a preserved file.
> + * @s: The outgoing liveupdate session.
> + * @file: The file object to search for.
> + * @tokenp: Output parameter for the found token.
> + *
> + * Searches the list of preserved files in an outgoing session for a matching
> + * file object. If found, the corresponding user-provided token is returned.
> + *
> + * This function is intended for in-kernel callers that need to correlate a
> + * file with its liveupdate token.
> + *
> + * Context: It must be called with session mutex acquired.
> + * Return: 0 on success, -ENOENT if the file is not preserved in this session.
> + */
> +int liveupdate_get_token_outgoing(struct liveupdate_session *s,
> + struct file *file, u64 *tokenp)
> +{
> + struct luo_file_set *file_set = luo_file_set_from_session_locked(s);
> + struct luo_file *luo_file;
> + int err = -ENOENT;
> +
> + list_for_each_entry(luo_file, &file_set->files_list, list) {
> + if (luo_file->file == file) {
> + if (tokenp)
> + *tokenp = luo_file->token;
> + err = 0;
> + break;
> + }
> + }
> +
> + return err;
> +}
> +
> +/**
> + * liveupdate_get_file_incoming - Retrieves a preserved file for in-kernel use.
> + * @s: The incoming liveupdate session (restored from the previous kernel).
> + * @token: The unique token identifying the file to retrieve.
> + * @filep: On success, this will be populated with a pointer to the retrieved
> + * 'struct file'.
> + *
> + * Provides a kernel-internal API for other subsystems to retrieve their
> + * preserved files after a live update. This function is a simple wrapper
> + * around luo_retrieve_file(), allowing callers to find a file by its token.
> + *
> + * The caller receives a new reference to the file and must call fput() when it
> + * is no longer needed. The file's lifetime is managed by LUO and any userspace
> + * file descriptors. If the caller needs to hold a reference to the file beyond
> + * the immediate scope, it must call get_file() itself.
> + *
> + * Context: It must be called with session mutex acquired of a restored session.
> + * Return: 0 on success. Returns -ENOENT if no file with the matching token is
> + * found, or any other negative errno on failure.
> + */
> +int liveupdate_get_file_incoming(struct liveupdate_session *s, u64 token,
> + struct file **filep)
> +{
> + return luo_retrieve_file(luo_file_set_from_session_locked(s),
> + token, filep);
> +}
> diff --git a/kernel/liveupdate/luo_internal.h b/kernel/liveupdate/luo_internal.h
> index 875844d7a41d..08b198802e7f 100644
> --- a/kernel/liveupdate/luo_internal.h
> +++ b/kernel/liveupdate/luo_internal.h
> @@ -79,6 +79,23 @@ struct luo_session {
>
> extern struct rw_semaphore luo_register_rwlock;
>
> +static inline struct liveupdate_session *luo_session_from_file_set(struct luo_file_set *file_set)
> +{
> + struct luo_session *session;
> +
> + session = container_of(file_set, struct luo_session, file_set);
> +
> + return (struct liveupdate_session *)session;
> +}
> +
> +static inline struct luo_file_set *luo_file_set_from_session_locked(struct liveupdate_session *s)
> +{
> + struct luo_session *session = (struct luo_session *)s;
> +
> + lockdep_assert_held(&session->mutex);
> + return &session->file_set;
> +}
> +
> int luo_session_create(const char *name, struct file **filep);
> int luo_session_retrieve(const char *name, struct file **filep);
> int __init luo_session_setup_outgoing(void *fdt);
> --
> 2.54.0.1032.g2f8565e1d1-goog
^ permalink raw reply
* Re: [PATCH v2 4/7] seg6: add End.M.GTP6.D behavior
From: Andrea Mayer @ 2026-06-07 0:05 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-4-9e8022bdfdb6@gmail.com>
On Tue, 05 May 2026 01:30:14 +0900
Yuya Kusakabe <yuya.kusakabe@gmail.com> wrote:
Hi Yuya,
I do not repeat below the points from my cover letter and patch 1-3 replies
(drop reasons, OIF/VRF removal, C helper, coding style, etc.).
> Add the End.M.GTP6.D headend behavior (RFC 9433 Section 6.3), which
> receives an IPv6/UDP/GTP-U packet matching a locally instantiated
> End.M.GTP6.D SID and re-encapsulates the inner T-PDU in SRv6 using
> the configured SR Policy. TEID and QFI are folded into the 40-bit
> Args.Mob.Session field defined by RFC 9433 Section 6.1.
>
> RFC 9433 Section 6.3 Step S08 specifies "Write in the SRH[0] the
> Args.Mob.Session" for a single-SID SR Policy. When the SR Policy
> contains more segments, the augmented SRH must reserve a leading
> slot for the original outer destination D so that the downstream
> End.M.GTP6.E (which Section 6.5 requires to sit at the penultimate
> SID and Step S01 instructs to "Copy SRH[0] and D to buffer memory")
> can rebuild the GTP-U tunnel. Args.Mob.Session is therefore stamped
> into segments[1] (the End.M.GTP6.E SID's locator-relative tail).
>
> The augmented SRH (slwt->srh + one extra leading slot) is built
> once at build_state time and reused on every packet.
>
> The new SEG6_LOCAL_MOBILE_SR_PREFIX_LEN attribute carries the
> locator length used by the remote End.M.GTP6.E SID; it is required
> because the SR Gateway has no way to discover the remote SID's
> prefix length from the FIB on its own.
>
> 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.
>
> Inbound GTP-U packets are classified by message type (3GPP TS
> 29.281 Section 5.1). Only T-PDU (type 255) is encapsulated into
> SRv6. Any other GTP-U message (Echo Request/Response, Error
> Indication, ...) is forwarded unchanged via the lwtunnel's saved
> orig_input so that a downstream peer that owns the GTP-U control
> plane can process it.
>
> Configuration:
>
> ip -6 route add 2001:db8:f::/64 \
> encap seg6local action End.M.GTP6.D \
> srh segs 2001:db8:2::e \
> src 2001:db8:2::1 \
The "src" attribute is used verbatim here as the outer IPv6 source address,
same as patch 3. The src dual-semantics overload flagged in the patch 3
reply applies here too.
> sr_prefix_len 64 \
> dev <dev>
>
Thank you for the follow-up in the cover letter thread. The finish callback
writes orig_dst into SRH[0] and Args.Mob.Session into SRH[1]. As far as I
can see, this matches neither Section 6.3 (Args.Mob.Session in SRH[0], no
D) nor Section 6.4 (D in SRH[0], no Args.Mob).
The comments below apply regardless of which section the behavior
ends up implementing.
> Link: https://www.rfc-editor.org/rfc/rfc9433.html#section-6.3
> Signed-off-by: Yuya Kusakabe <yuya.kusakabe@gmail.com>
> ---
> include/uapi/linux/seg6_local.h | 3 +
> net/ipv6/seg6_local.c | 512 +++++++++++++++++++++
> tools/testing/selftests/net/Makefile | 1 +
> .../selftests/net/srv6_end_m_gtp6_d_test.sh | 497 ++++++++++++++++++++
> 4 files changed, 1013 insertions(+)
>
> diff --git a/include/uapi/linux/seg6_local.h b/include/uapi/linux/seg6_local.h
> index 8e46ede2980d..7d3d3d245b47 100644
> --- a/include/uapi/linux/seg6_local.h
> +++ b/include/uapi/linux/seg6_local.h
> @@ -33,6 +33,7 @@ enum {
> SEG6_LOCAL_MOBILE_V4_MASK_LEN,
> SEG6_LOCAL_MOBILE_PDU_TYPE,
> SEG6_LOCAL_MOBILE_V6_SRC_PREFIX_LEN,
> + SEG6_LOCAL_MOBILE_SR_PREFIX_LEN,
> __SEG6_LOCAL_MAX,
> };
> #define SEG6_LOCAL_MAX (__SEG6_LOCAL_MAX - 1)
> @@ -77,6 +78,8 @@ enum {
> SEG6_LOCAL_ACTION_END_M_GTP4_E = 18,
> /* SRv6 to IPv6/GTP-U encap (RFC 9433 Section 6.5) */
> 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,
>
> __SEG6_LOCAL_ACTION_MAX,
> };
> diff --git a/net/ipv6/seg6_local.c b/net/ipv6/seg6_local.c
> index 4e5d138c3657..09e912e17df8 100644
> --- a/net/ipv6/seg6_local.c
> +++ b/net/ipv6/seg6_local.c
> + [snip]
>
> +/* Parse the GTP-U header at @skb offset @gtp_off. Pulls each
> + * additional region (long header, extension chain) into the linear
> + * area as it walks; on success returns the total header length to
> + * consume (mandatory + optional + extension headers), or a negative
> + * errno on failure.
> + *
> + * Returns -EOPNOTSUPP if the packet is a well-formed GTPv1-U header
> + * that this code path does not consume itself (any non-T-PDU message
> + * such as Echo Request / Error Indication). Callers pass such packets
> + * through to the configured forwarding path via
> + * seg6_mobile_passthrough_non_tpdu().
> + *
> + * Returns -EINVAL when the GTP-U header is structurally malformed
> + * (truncated extension chain, ext_units == 0, etc.). Callers should
> + * drop those.
> + *
> + * On success, *@teid is set to the GTP-U TEID and *@qfi is set to the
> + * QFI found in a PDU Session extension header, or 0 if none is present.
> + *
> + * Callers must re-derive any pointers into @skb->data after this
> + * function returns: pskb_may_pull() may have reallocated skb->head.
> + */
> +static int seg6_mobile_parse_gtpu(struct sk_buff *skb, unsigned int gtp_off,
> + u32 *teid, u8 *qfi)
> +{
> + const struct gtp1_header *gtph;
> + const struct gtp1_header_long *gtphl;
> + const u8 *gtp;
> + unsigned int hdrlen;
> + u8 flags, next;
Same reverse Christmas tree as patch 2; same issue in the other functions
introduced by this patch.
gtp is only used as a cast intermediary. Could it be inlined?
> +
> + if (!pskb_may_pull(skb, gtp_off + sizeof(*gtph)))
> + return -EINVAL;
> + gtp = skb->data + gtp_off;
> + gtph = (const struct gtp1_header *)gtp;
> + flags = gtph->flags;
> +
> + /* Accept only GTPv1-U T-PDU (3GPP TS 29.281 Section 5.1). Other
> + * GTPv1-U message types (Echo Request/Response, Error Indication,
> + * ...) are dispatched separately by the caller.
> + */
> + if ((flags & ~GTP1_F_MASK) != SEG6_MOBILE_GTP1U_FLAGS_BASE)
> + return -EOPNOTSUPP;
> + if (gtph->type != GTP_TPDU)
> + return -EOPNOTSUPP;
> +
> + *teid = ntohl(gtph->tid);
> + *qfi = 0;
> +
> + if (!(flags & (GTP1_F_EXTHDR | GTP1_F_SEQ | GTP1_F_NPDU)))
> + return sizeof(*gtph);
> +
> + if (!pskb_may_pull(skb, gtp_off + sizeof(*gtphl)))
> + return -EINVAL;
> + gtp = skb->data + gtp_off;
> + gtphl = (const struct gtp1_header_long *)gtp;
> + hdrlen = sizeof(*gtphl);
> +
> + if (!(flags & GTP1_F_EXTHDR))
> + return hdrlen;
Nit: gtphl and hdrlen are assigned before the GTP1_F_EXTHDR check. On the
path where the E flag is not set, gtphl is unused. Moving the gtphl
assignment after the check would make the flow clearer.
> +
> + next = gtphl->next;
> + while (next != 0) {
> + unsigned int ext_units, ext_bytes;
> + const u8 *ext;
Maybe ext could be renamed to ext_hdr? It would be easier to distinguish
from ext_units and ext_bytes.
> +
> + if (!pskb_may_pull(skb, gtp_off + hdrlen + 1))
> + return -EINVAL;
> + ext = skb->data + gtp_off + hdrlen;
> + ext_units = ext[0];
> + if (ext_units == 0)
> + return -EINVAL;
> +
> + ext_bytes = ext_units * 4;
> + if (!pskb_may_pull(skb, gtp_off + hdrlen + ext_bytes))
> + return -EINVAL;
> + ext = skb->data + gtp_off + hdrlen;
ext_units is only used to derive ext_bytes. A single ext_len would
remove the intermediate variable.
> +
> + if (next == SEG6_MOBILE_PDU_SESSION_NH) {
> + /* 3GPP TS 38.415: the PDU Session extension header
> + * is exactly 4 bytes long.
> + */
> + if (ext_bytes != 4)
> + return -EINVAL;
> + *qfi = ext[2] & SEG6_MOBILE_PDU_SESSION_QFI_MASK;
> + }
If the extension chain contains more than one PDU Session Container, *qfi
is silently overwritten. Is that intentional, or should the function reject
a duplicate?
> +
> + next = ext[ext_bytes - 1];
ext[ext_bytes - 1] reads the Next Extension Header Type field from the last
byte of the current extension. Would a short comment help the reader?
> + hdrlen += ext_bytes;
> + }
> +
> + return hdrlen;
> +}
> + [snip]
> +static int seg6_mobile_passthrough_non_tpdu(struct sk_buff *skb)
> +{
> + struct dst_entry *dst = skb_dst(skb);
> +
> + if (dst && dst->lwtstate && dst->lwtstate->orig_input)
> + return dst->lwtstate->orig_input(skb);
> +
> + kfree_skb_reason(skb, SKB_DROP_REASON_SEG6_MOBILE_BAD_GTPU);
input_action_end_m_gtp6_d() does not change skb_dst(skb) before this call,
so dst and lwtstate are the same ones the caller already dereferenced. When
can this NULL check trigger?
> + return -EINVAL;
> +}
> + [snip]
> +static int input_action_end_m_gtp6_d_finish(struct net *net,
> + struct sock *sk,
> + struct sk_buff *skb)
> +{
> + struct seg6_mobile_gtp6_d_cb cb = *SEG6_MOBILE_GTP6_D_CB(skb);
> + struct dst_entry *orig_dst = skb_dst(skb);
> + enum skb_drop_reason reason;
> + const struct seg6_mobile_info *minfo;
> + struct seg6_local_lwt *slwt;
> + struct ipv6_sr_hdr *new_srh;
> + int inner_proto;
> + int err;
> +
> + slwt = seg6_local_lwtunnel(orig_dst->lwtstate);
> + minfo = &slwt->mobile_info;
Same dst/lwtstate issue as patch 2. Not introduced by this patch.
> +
> + inner_proto = (skb->protocol == htons(ETH_P_IP)) ? IPPROTO_IPIP
> + : IPPROTO_IPV6;
> +
> + err = seg6_do_srh_encap(skb, minfo->aug_srh, inner_proto);
Same missing iptunnel_handle_offloads() as patch 2.
> + if (err) {
> + reason = (err == -ENOMEM) ? SKB_DROP_REASON_SEG6_MOBILE_NOMEM
> + : SKB_DROP_REASON_SEG6_MOBILE_BAD_INNER;
Same BAD_INNER misuse as patch 2. seg6_do_srh_encap() can also fail from
seg6_push_hmac(), which is an HMAC error on the new SRH, not an inner-T-PDU
problem.
> + goto drop;
> + }
> +
> + skb->protocol = htons(ETH_P_IPV6);
> +
> + new_srh = (struct ipv6_sr_hdr *)(skb_network_header(skb) +
> + sizeof(struct ipv6hdr));
> + new_srh->segments[0] = cb.orig_dst;
> + if (seg6_mobile_write_args_mob(&new_srh->segments[1],
> + minfo->sr_prefix_len, cb.args_mob)) {
> + reason = SKB_DROP_REASON_SEG6_MOBILE_BAD_SID;
> + goto drop;
> + }
> +
> + ipv6_hdr(skb)->saddr = minfo->src_addr;
> +
> + /* seg6_do_srh_encap() copied segments[first_segment] to the outer
> + * DA before Args.Mob.Session was stamped; refresh it.
> + */
> + ipv6_hdr(skb)->daddr = new_srh->segments[new_srh->first_segment];
As noted at the top of this reply, segments[0] = orig_dst and
segments[1] = Args.Mob.Session matches neither Section 6.3 nor Section 6.4.
segments[0], segments[1], saddr, and daddr are written after
seg6_do_srh_encap() already called skb_postpush_rcsum(). skb->csum can
be stale. Same for any later change to the outer header or SRH.
HMAC, if configured, is computed on non-final SRH and saddr, hence invalid.
> +
> + skb_set_transport_header(skb, sizeof(struct ipv6hdr));
> + nf_reset_ct(skb);
> + skb_dst_drop(skb);
> +
> + seg6_lookup_any_nexthop(skb, NULL, 0, false, slwt->oif);
> + return dst_input(skb);
> +
> +drop:
> + kfree_skb_reason(skb, reason);
> + return -EINVAL;
> +}
Same redundant skb_dst_drop() as patch 3.
> +
> +/* RFC 9433 Section 6.3 -- End.M.GTP6.D
> + * Receives an IPv6/UDP/GTP-U packet matching a locally instantiated
> + * End.M.GTP6.D SID and re-encapsulates the inner T-PDU in SRv6 using
> + * the configured SR Policy. TEID and QFI are folded into
> + * Args.Mob.Session. Per RFC 9433 Section 6.5 ("End.M.GTP6.E SID MUST
> + * always be the penultimate SID"), Args.Mob.Session is encoded into
> + * segments[1] of the new SRH (the penultimate SID at the egress UPF)
> + * while segments[0] holds the original outer DA so that the egress
> + * has a real GTP-U destination after End.M.GTP6.E decap.
> + *
> + * When net.netfilter.nf_hooks_lwtunnel=1 the inner T-PDU is exposed
> + * to NF_INET_PRE_ROUTING after the GTP-U strip and before the SRv6
> + * push, mirroring End.DX4 / End.DX6. This lets nftables / conntrack
> + * apply policy on the inner 5-tuple at the SR Gateway.
> + */
> +static int input_action_end_m_gtp6_d(struct sk_buff *skb,
> + struct seg6_local_lwt *slwt)
> +{
> + unsigned int outer_len, inner_off;
> + int gtp_hdrlen, inner_proto, inner_nfproto;
> + struct in6_addr orig_dst;
> + u8 inner_first, qfi;
> + struct ipv6_sr_hdr *srh;
> + struct ipv6hdr *ip6h;
> + struct udphdr *uh;
> + u64 args_mob;
> + u32 teid;
> + enum skb_drop_reason reason = SKB_DROP_REASON_SEG6_MOBILE_BAD_GTPU;
The initializer on reason is dead. Every goto drop path sets reason
explicitly before the jump. The variable can be left uninitialized here.
> +
> + BUILD_BUG_ON(sizeof(struct seg6_mobile_gtp6_d_cb) >
> + sizeof_field(struct sk_buff, cb));
> +
> + /* RFC 9433 Section 6.3 SRH-S01: drop if outer SRH carries
> + * SegmentsLeft != 0
> + */
> + srh = seg6_get_srh(skb, 0);
> + if (srh && srh->segments_left != 0) {
> + reason = SKB_DROP_REASON_SEG6_MOBILE_INVALID_SRH_SL;
> + goto drop;
> + }
Same SRH validation concerns as patch 1. HMAC is not validated here.
> +
> + if (!pskb_may_pull(skb, sizeof(struct ipv6hdr))) {
> + reason = SKB_DROP_REASON_SEG6_MOBILE_BAD_INNER;
> + goto drop;
> + }
Same BAD_INNER misuse as patch 2: this is pulling the outer IPv6 header,
not the inner T-PDU.
> +
> + ip6h = ipv6_hdr(skb);
> + orig_dst = ip6h->daddr;
> +
> + /* RFC 9433 Section 6.3 upper-layer S01-S11: dispatch on
> + * (NH == UDP && UDP dport == GTP-U); otherwise delegate to the
> + * regular End behaviour (S10-S11).
> + */
> + {
The anonymous { } block scopes three variables that should be declared at
function top. Splitting into smaller helpers would make this easier to
follow.
> + __be16 frag_off;
> + u8 nh = ip6h->nexthdr;
> + int upper_off;
> +
> + upper_off = ipv6_skip_exthdr(skb, sizeof(*ip6h), &nh,
> + &frag_off);
> + if (upper_off < 0) {
> + /* Outer IPv6 ext-header walk failed; the GTP-U
> + * envelope below it is unreachable.
> + */
> + reason = SKB_DROP_REASON_SEG6_MOBILE_BAD_GTPU;
> + goto drop;
> + }
Same missing frag_off check as patch 2.
> +
> + if (nh != IPPROTO_UDP)
> + return input_action_end(skb, slwt);
> +
> + if (!pskb_may_pull(skb, upper_off + sizeof(*uh))) {
> + reason = SKB_DROP_REASON_SEG6_MOBILE_BAD_GTPU;
> + goto drop;
> + }
> +
> + ip6h = ipv6_hdr(skb);
> + uh = (struct udphdr *)((u8 *)ip6h + upper_off);
> + if (uh->dest != htons(GTP1U_PORT))
> + return input_action_end(skb, slwt);
Limitation note for both input_action_end() calls above: correct per RFC
9433 Section 6.3 S10-S11, but the SRH is absent or SL == 0 here, so
input_action_end() will always drop without signaling non-GTP-U traffic.
Perhaps you meant to drop directly with BAD_GTPU?
> +
> + 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;
> + }
> +
> + outer_len = upper_off + sizeof(*uh) + gtp_hdrlen;
> + }
> +
> + args_mob = seg6_mobile_args_from_teid_qfi(teid, qfi);
> +
> + if (!pskb_may_pull(skb, outer_len + 1)) {
> + reason = SKB_DROP_REASON_SEG6_MOBILE_BAD_INNER;
> + goto drop;
> + }
> +
> + inner_off = outer_len;
> + inner_first = *((u8 *)skb->data + inner_off);
> + switch (inner_first >> 4) {
Nit: inner_first could be an inner_ver with the shift done at assignment.
The name would say what the variable holds.
> + case 4:
> + inner_proto = IPPROTO_IPIP;
> + inner_nfproto = NFPROTO_IPV4;
> + break;
> + case 6:
> + inner_proto = IPPROTO_IPV6;
> + inner_nfproto = NFPROTO_IPV6;
> + break;
> + default:
> + reason = SKB_DROP_REASON_SEG6_MOBILE_BAD_INNER;
> + goto drop;
> + }
> +
> + if (!pskb_may_pull(skb, outer_len +
> + ((inner_proto == IPPROTO_IPIP) ?
> + sizeof(struct iphdr) : sizeof(struct ipv6hdr)))) {
> + reason = SKB_DROP_REASON_SEG6_MOBILE_BAD_INNER;
> + goto drop;
> + }
> +
> + skb_pull_rcsum(skb, outer_len);
> + skb_reset_network_header(skb);
> +
> + /* Set skb->protocol to match the inner header so that the
> + * NF_INET_PRE_ROUTING hook (and seg6_do_srh_encap() inside
> + * the finish half) see a coherent IPv4/IPv6 packet.
> + */
> + skb->protocol = (inner_proto == IPPROTO_IPIP) ? htons(ETH_P_IP)
> + : htons(ETH_P_IPV6);
> +
> + skb_set_transport_header(skb,
> + (inner_proto == IPPROTO_IPIP) ?
> + sizeof(struct iphdr) :
> + sizeof(struct ipv6hdr));
Same repeated size-selection ternary as patch 2.
> + nf_reset_ct(skb);
> +
> + SEG6_MOBILE_GTP6_D_CB(skb)->args_mob = args_mob;
> + SEG6_MOBILE_GTP6_D_CB(skb)->orig_dst = orig_dst;
> +
> + if (static_branch_unlikely(&nf_hooks_lwtunnel_enabled))
> + return NF_HOOK(inner_nfproto, NF_INET_PRE_ROUTING,
> + dev_net(skb->dev), NULL, skb, skb->dev,
> + NULL, input_action_end_m_gtp6_d_finish);
> +
> + return input_action_end_m_gtp6_d_finish(dev_net(skb->dev), NULL, skb);
> +
> +drop:
> + kfree_skb_reason(skb, reason);
> + return -EINVAL;
> +}
> +
> +/* Shared between End.M.GTP6.D and End.M.GTP6.D.Di -- both
> + * prepend a single leading slot to the user-configured SRH to leave
> + * room for the original outer DA at SRH[0]. End.M.GTP6.D writes
> + * Args.Mob.Session into segments[1] at runtime; End.M.GTP6.D.Di
> + * leaves segments[1+] as the user provided them.
> + */
> +static int seg6_end_m_gtp6_d_aug_build(struct seg6_local_lwt *slwt,
> + const void *cfg,
> + struct netlink_ext_ack *extack)
> +{
> + struct ipv6_sr_hdr *aug;
> + int orig_len, aug_len;
> +
> + if (!slwt->srh) {
> + NL_SET_ERR_MSG_MOD(extack,
> + "End.M.GTP6.D{,.Di} requires srh segs");
> + return -EINVAL;
> + }
The "{,.Di}" shell brace notation is unusual. Emitting the actual
behavior name (End.M.GTP6.D or End.M.GTP6.D.Di) would be clearer.
Same applies wherever this notation appears in the patchset.
> +
> + /* The augmented SRH adds one extra leading slot, so its hdrlen
> + * field (u8) must still fit the +2-segment-equivalent encoding.
> + * Reject pathological srh inputs at setup time so that no
> + * silent overflow can produce an undersized aug->hdrlen and a
> + * subsequent OOB read in seg6_do_srh_encap().
> + */
> + if (slwt->srh->hdrlen > 253) {
> + NL_SET_ERR_MSG_MOD(extack,
> + "End.M.GTP6.D{,.Di} srh too large to augment (max 126 segments)");
> + return -EINVAL;
> + }
> +
> + orig_len = (slwt->srh->hdrlen + 1) << 3;
> + aug_len = orig_len + sizeof(struct in6_addr);
> +
> + aug = kzalloc(aug_len, GFP_KERNEL);
> + if (!aug)
> + return -ENOMEM;
> +
> + memcpy(aug, slwt->srh, sizeof(*aug));
> + aug->hdrlen = (aug_len >> 3) - 1;
> + aug->segments_left = slwt->srh->segments_left + 1;
> + aug->first_segment = slwt->srh->first_segment + 1;
> + /* segments[0] left zero; data path stamps the original outer
> + * DA into the in-skb copy after seg6_do_srh_encap().
> + */
> + memcpy(&aug->segments[1], &slwt->srh->segments[0],
> + orig_len - sizeof(*aug));
> +
> + slwt->mobile_info.aug_srh = aug;
> + return 0;
> +}
> + [snip]
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
* Re: [PATCH v6 06/12] PCI: liveupdate: Auto-preserve upstream bridges across Live Update
From: Pranjal Shrivastava @ 2026-06-06 22:15 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-7-dmatlack@google.com>
On Fri, May 22, 2026 at 08:24:04PM +0000, David Matlack wrote:
> When a PCI device is preserved across a Live Update, all of its upstream
> bridges up to the root port must also be preserved. This enables the PCI
> core and any drivers bound to the bridges to manage bridges correctly
> across a Live Update.
>
> Notably, this will be used in subsequent commits to ensure that
> preserved devices can continue performing memory transactions without a
> disruption or change in routing.
>
> To preserve bridges, the PCI core tracks the number of downstream
> devices preserved under each bridge using a reference count in struct
> pci_dev_ser. This allows a bridge to remain preserved until all its
> downstream preserved devices are unpreserved or finish their
> participation in the Live Update.
>
> Signed-off-by: David Matlack <dmatlack@google.com>
> ---
> drivers/pci/liveupdate.c | 136 +++++++++++++++++++++++++++++++-----
> include/linux/kho/abi/pci.h | 5 +-
> 2 files changed, 122 insertions(+), 19 deletions(-)
>
[...]
> +
> +#define for_each_pci_dev_in_path(_d, _start, _end) \
> + for ((_d) = (_start); (_d) != (_end); (_d) = (_d)->bus->self)
> +
> +static void __pci_liveupdate_unpreserve_path(struct pci_ser *ser,
> + struct pci_dev *start,
> + struct pci_dev *end)
> +{
> + struct pci_dev *dev;
> +
> + for_each_pci_dev_in_path(dev, start, end) {
> + if (pci_liveupdate_unpreserve_device(ser, dev))
I might be reading this wrong but are we leaking some upstream devs if
an intermediate node fails?
EP0
/
Assume we have: RC -> B1 -> B2
\
EP1
and EP0 & EP1 were preserved successfully.
And then we try unpreserving EP1, we follow:
unpreserve EP1 -> unpreserve B2 failed due to a corruption.
This aborts the loop, skipping B1 and RC completely?
Their refcounts remain elevated, effectively leaking them as preserved
state permanently? (i.e. if we unpreserve EP0 after this, B1 & RC will
still get preserved).
> + return;
> + }
> +}
> +
> +static void pci_liveupdate_unpreserve_path(struct pci_ser *ser,
> + struct pci_dev *start)
> +{
> + __pci_liveupdate_unpreserve_path(ser, start, /*end=*/NULL);
> +}
> +
> +static int pci_liveupdate_preserve_path(struct pci_ser *ser,
> + struct pci_dev *start)
> +{
> + struct pci_dev *dev;
> + int ret;
> +
> + for_each_pci_dev_in_path(dev, start, NULL) {
> + ret = pci_liveupdate_preserve_device(ser, dev);
> + if (ret) {
> + __pci_liveupdate_unpreserve_path(ser, start, dev);
> + return ret;
> + }
> + }
> +
> + return 0;
> +}
> +
> /**
> * pci_liveupdate_preserve() - Preserve a PCI device across Live Update
> * @dev: The PCI device to preserve.
> @@ -321,6 +403,9 @@ static int pci_liveupdate_preserve_device(struct pci_ser *ser, struct pci_dev *d
> * pci_liveupdate_preserve() from their struct liveupdate_file_handler
> * preserve() callback to ensure the outgoing struct pci_ser is already set up.
> *
> + * pci_liveupdate_preserve() automatically preserves all bridges upstream of
> + * @dev.
> + *
> * Returns: 0 on success, <0 on failure.
> */
> int pci_liveupdate_preserve(struct pci_dev *dev)
> @@ -336,7 +421,7 @@ int pci_liveupdate_preserve(struct pci_dev *dev)
> if (IS_ERR(ser))
> return PTR_ERR(ser);
>
> - return pci_liveupdate_preserve_device(ser, dev);
> + return pci_liveupdate_preserve_path(ser, dev);
Minor nit: I might be too nitpicky here (and it's NOT a strong opinion)
but naming it pci_liveupdate_preserve_path_for_dev() reads better to me.
> }
> EXPORT_SYMBOL_GPL(pci_liveupdate_preserve);
>
[...]
Thanks,
Praan
^ permalink raw reply
* Re: [PATCH v2 4/4] dt-bindings: input: remove obsolete matrix-keymap.txt
From: Dmitry Torokhov @ 2026-06-06 21:03 UTC (permalink / raw)
To: Rob Herring (Arm), Lee Jones
Cc: Akash Sukhavasi, Conor Dooley, David S. Miller, Andrew Lunn,
linux-tegra, linux-input, Mauro Carvalho Chehab, Heiner Kallweit,
Thierry Reding, linux-media, Krzysztof Kozlowski, Jakub Kicinski,
Vladimir Oltean, linux-doc, linux-kernel, Eric Dumazet,
Jonathan Hunter, Simon Horman, devicetree, Paolo Abeni, netdev,
Shuah Khan, Russell King, Jonathan Corbet
In-Reply-To: <178052559618.2296868.8781332297681333925.robh@kernel.org>
On Wed, Jun 03, 2026 at 05:26:38PM -0500, Rob Herring (Arm) wrote:
>
> On Wed, 03 Jun 2026 15:42:21 -0500, Akash Sukhavasi wrote:
> > matrix-keymap.txt has been a single-line redirect to
> > matrix-keymap.yaml since commit 639d6eda3b80 ("dt-bindings: input:
> > Convert matrix-keymap to json-schema"), which introduced the .yaml
> > schema and reduced the .txt to a stub in the same change. The .yaml
> > has the same filename in the same directory, making this redirect
> > unnecessary for discoverability.
> >
> > Eight instances across six files still reference matrix-keymap.txt,
> > forcing readers through an extra hop to reach the .yaml. The stub has
> > not been touched since June 2020. Update all references across input
> > and mfd binding documentation to point directly to matrix-keymap.yaml
> > and remove the stub.
> >
> > Signed-off-by: Akash Sukhavasi <akash.sukhavasi@gmail.com>
> > ---
> > v2:
> > - Patch 4/4: corrected commit message (eight references in six files,
> > not eight files), Sashiko review.
> > https://sashiko.dev/#/patchset/20260529052246.4934-1-akash.sukhavasi@gmail.com?part=4
> >
> > v1: https://lore.kernel.org/all/20260529052246.4934-5-akash.sukhavasi@gmail.com/
> > ---
> > Documentation/devicetree/bindings/input/brcm,bcm-keypad.txt | 2 +-
> > Documentation/devicetree/bindings/input/clps711x-keypad.txt | 2 +-
> > Documentation/devicetree/bindings/input/matrix-keymap.txt | 1 -
> > Documentation/devicetree/bindings/input/nvidia,tegra20-kbc.txt | 2 +-
> > Documentation/devicetree/bindings/input/pxa27x-keypad.txt | 2 +-
> > Documentation/devicetree/bindings/input/st-keyscan.txt | 2 +-
> > Documentation/devicetree/bindings/mfd/tc3589x.txt | 6 +++---
> > 7 files changed, 8 insertions(+), 9 deletions(-)
> >
>
> Acked-by: Rob Herring (Arm) <robh@kernel.org>
>
Lee, could you please ack for MFD piece and I can take it through input?
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH] docs/mm: document slab cache isolation with SLAB_NO_MERGE
From: Matthew Wilcox @ 2026-06-06 20:19 UTC (permalink / raw)
To: Mohammed EL Kadiri
Cc: Andrew Morton, Vlastimil Babka, David Hildenbrand,
Lorenzo Stoakes, Jonathan Corbet, Kees Cook, linux-mm, linux-doc,
linux-hardening, linux-kernel
In-Reply-To: <20260606155856.15548-1-med08elkadiri@gmail.com>
On Sat, Jun 06, 2026 at 04:58:55PM +0100, Mohammed EL Kadiri wrote:
> +The SLUB allocator merges slab caches with compatible size, alignment, and
More of a question for Vlastimil ... do we want to continue to
distinguish between slab (the API) and SLUB (the implementation)?
I don't think we ever want to go back to a situation where we have
multiple competing implementations of the slab API in the kernel.
So shouldn't we deprecate uses of SLUB, particularly in the
documentation?
> +flags to reduce memory fragmentation. While this improves memory efficiency,
> +it allows objects of different types to share the same slab pages. This
s/ pages//
> +enables cross-cache heap exploitation, where a use-after-free in one object
> +type can be leveraged to corrupt an unrelated type.
> +
> +The `SLAB_NO_MERGE` flag prevents a cache from being merged, ensuring it
> +receives dedicated slab pages.
s/slab pages/a dedicated slab/
> +2. *Actually mergeable*: The cache must not already be unmergeable.
> + A cache is already unmergeable if any of the following is true:
> +
> + - It has a constructor (`ctor` argument is non-NULL).
> + - It has a non-zero `usersize` (with `CONFIG_HARDENED_USERCOPY`).
> + - It already has `SLAB_NO_MERGE` or another `SLAB_NEVER_MERGE` flag.
I don't know if this is good advice for users of the API. It's true
that the slab will already be unmergable for these other reasons, but
it's harmless to specify SLAB_NO_MERGE in that case. And it
communicates intent. And in case somebody removes the ctor in the
future, or we decide to change which flags are in SLAB_NEVER_MERGE,
the slab will still be unmergable.
> +3. *Bounded allocation volume*: The cache has a predictable number of
> + active objects, so the memory cost of dedicated slab pages is
> + acceptable.
I don't understand why this is a criteria.
> +How merging works
> +=================
> +
> +When `kmem_cache_create()` is called:
> +
> +1. If `usersize` is non-zero, the merge path is skipped entirely.
> +
> +2. Otherwise, `find_mergeable()` in `mm/slab_common.c` searches for a
> + compatible existing cache. A merge is prevented if:
> +
> + - The `slab_nomerge` boot parameter is set
> + - The new cache has a constructor
> + - The new cache's flags include `SLAB_NO_MERGE`
> + - No existing cache has compatible size and flags
> +
> +3. If a compatible cache is found, the new cache becomes an alias. Both
> + share the same slab pages.
This feels like documenting internals rather than documenting how to use
the flag. I'd drop it entirely.
> +The cross-cache attack class
> +=============================
> +
> +Cross-cache attacks exploit slab merging to achieve type confusion:
> +
> +1. Attacker triggers a use-after-free in object type A.
> +2. Type A's cache is merged with type B (they share slab pages).
> +3. The freed type A slot is reallocated as type B.
> +4. Attacker uses the dangling pointer to corrupt type B.
> +5. Privilege escalation.
> +
> +CVE-2022-29582 demonstrates this technique: an io_uring use-after-free is
> +exploited via cross-cache page-level reallocation to achieve root.
> +
> +`SLAB_NO_MERGE` prevents step 2: dedicated pages mean a freed slot of
> +one type cannot be reallocated as a different type.
Not sure this section adds anything to what was already described.
> +Tradeoffs
> +=========
> +
> +*Memory*: Isolated caches may have partially-filled slab pages that
> +cannot be used by other types. For caches with bounded allocation counts,
> +this 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 16 copies of each `kmalloc` size class and randomly assigns
> + allocations among them. Only affects `kmalloc()` users. Does not
> + affect named caches created with `kmem_cache_create()`.
> +
> +`SLAB_TYPESAFE_BY_RCU`
> + Delays freeing the slab page by an RCU grace period. Does not delay
> + object slot reuse. Does not prevent cross-cache merging. Solves a
> + different problem: safe lockless access to freed-and-reallocated
> + objects of the same type.
> +
> +`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.
These two sections also feel unnecessary.
^ permalink raw reply
* Re: [PATCH] docs: memfd_preservation: fix rendering of ABI documentation
From: Randy Dunlap @ 2026-06-06 19:36 UTC (permalink / raw)
To: Pratyush Yadav, Pasha Tatashin, Mike Rapoport, Andrew Morton,
David Hildenbrand, Jonathan Corbet, Shuah Khan
Cc: kexec, linux-kernel, linux-mm, linux-doc
In-Reply-To: <20260605160645.3650271-1-pratyush@kernel.org>
On 6/5/26 9:06 AM, Pratyush Yadav wrote:
> From: "Pratyush Yadav (Google)" <pratyush@kernel.org>
>
> The "memfd Live Update ABI" section in include/linux/kho/abi/memfd.h
> currently does not render in the exported documentation. This is because
> it should not include the "DOC:" in its reference. Drop it to ensure
> correct rendering. Tested by running make htmldocs.
>
> Fixes: 15fc11bb2cb6 ("docs: add documentation for memfd preservation via LUO")
> Signed-off-by: Pratyush Yadav (Google) <pratyush@kernel.org>
Tested-by: Randy Dunlap <rdunlap@infradead.org>
Acked-by: Randy Dunlap <rdunlap@infradead.org>
Thanks.
> ---
>
> Notes:
> Mike/Pasha, I reckon this can still go in liveupdate/next. But if you
> think it is too late, we can probably take it via -rc1 fixes as well.
>
> Documentation/mm/memfd_preservation.rst | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/mm/memfd_preservation.rst b/Documentation/mm/memfd_preservation.rst
> index a8a5b476afd3..c908a12dffa7 100644
> --- a/Documentation/mm/memfd_preservation.rst
> +++ b/Documentation/mm/memfd_preservation.rst
> @@ -11,7 +11,7 @@ Memfd Preservation ABI
> ======================
>
> .. kernel-doc:: include/linux/kho/abi/memfd.h
> - :doc: DOC: memfd Live Update ABI
> + :doc: memfd Live Update ABI
>
> .. kernel-doc:: include/linux/kho/abi/memfd.h
> :internal:
>
> base-commit: 2935777b418d2bfcbfe96705bb2c0fa6c0d94e18
--
~Randy
^ permalink raw reply
* Re: [PATCH] docs/mm: document slab cache isolation with SLAB_NO_MERGE
From: Jonathan Corbet @ 2026-06-06 19:36 UTC (permalink / raw)
To: Mohammed EL Kadiri
Cc: Andrew Morton, Vlastimil Babka, David Hildenbrand,
Lorenzo Stoakes, Kees Cook, linux-mm, linux-doc, linux-hardening,
linux-kernel
In-Reply-To: <20260606174412.4843-1-med08elkadiri@gmail.com>
Mohammed EL Kadiri <med08elkadiri@gmail.com> writes:
> Hi Jonathan,
>
> Thank you for the review.
>
> Yes, I used AI assistance in writing this document.
Please see Documentation/process/coding-assistants.rst for information
on how to document that use.
I would also consider starting to fill out Documentation/mm/slab.rst
rather than creating a new standalone file.
Thanks,
jon
^ permalink raw reply
* Re: [PATCH 1/1] docs: Fix minor grammatical error
From: Randy Dunlap @ 2026-06-06 19:10 UTC (permalink / raw)
To: Brigham Campbell, Thorsten Leemhuis, Jonathan Corbet, Shuah Khan,
open list:DOCUMENTATION REPORTING ISSUES, open list
In-Reply-To: <20260605053826.7836-1-me@brighamcampbell.com>
On 6/4/26 10:38 PM, Brigham Campbell wrote:
> Fix minor grammatical error in the admin guide docs.
>
> Signed-off-by: Brigham Campbell <me@brighamcampbell.com>
> ---
>
> I happened across this minor mistake while investigating techniques to
> use a partial kernel config to generate a complete config. If
> maintainers that I don't send out minor fixes like this, please let me
> know and I'll remember that for the future.
>
> Documentation/admin-guide/quickly-build-trimmed-linux.rst | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/admin-guide/quickly-build-trimmed-linux.rst b/Documentation/admin-guide/quickly-build-trimmed-linux.rst
> index cb178e0a6208..194d22f56449 100644
> --- a/Documentation/admin-guide/quickly-build-trimmed-linux.rst
> +++ b/Documentation/admin-guide/quickly-build-trimmed-linux.rst
> @@ -217,10 +217,10 @@ again.
>
> There is a catch: 'localmodconfig' is likely to disable kernel features you
> did not use since you booted your Linux -- like drivers for currently
> - disconnected peripherals or a virtualization software not haven't used yet.
> - You can reduce or nearly eliminate that risk with tricks the reference
> - section outlines; but when building a kernel just for quick testing purposes
> - it is often negligible if such features are missing. But you should keep that
> + disconnected peripherals or virtualization software not currently in use. You
> + can reduce or nearly eliminate that risk with tricks the reference section
> + outlines; but when building a kernel just for quick testing purposes it is
> + often negligible if such features are missing. But you should keep that
> aspect in mind when using a kernel built with this make target, as it might
> be the reason why something you only use occasionally stopped working.
>
Can't you just modify the first line only and leave the other 3 changed lines
intact?
--
~Randy
^ permalink raw reply
* Re: [PATCH v2] Documentation: bug-hunting.rst: fix grammar
From: Randy Dunlap @ 2026-06-06 18:59 UTC (permalink / raw)
To: Manuel Ebner, Jonathan Corbet, Shuah Khan,
open list:DOCUMENTATION, open list
In-Reply-To: <20260605190055.15921-2-manuelebner@mailbox.org>
On 6/5/26 12:00 PM, Manuel Ebner wrote:
> Fix a grammar issue to improve readability
>
> Signed-off-by: Manuel Ebner <manuelebner@mailbox.org>
Acked-by: Randy Dunlap <rdunlap@infradead.org>
Thanks.
> ---
> Documentation/admin-guide/bug-hunting.rst | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/admin-guide/bug-hunting.rst b/Documentation/admin-guide/bug-hunting.rst
> index 3901b43c96df..642bf8474726 100644
> --- a/Documentation/admin-guide/bug-hunting.rst
> +++ b/Documentation/admin-guide/bug-hunting.rst
> @@ -63,8 +63,8 @@ Documentation/admin-guide/tainted-kernels.rst, "being loaded" is
> annotated with "+", and "being unloaded" is annotated with "-".
>
>
> -Where is the Oops message is located?
> --------------------------------------
> +Where is the Oops message located?
> +----------------------------------
>
> Normally the Oops text is read from the kernel buffers by klogd and
> handed to ``syslogd`` which writes it to a syslog file, typically
--
~Randy
^ 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