* Re: [PATCH v6 05/12] PCI: liveupdate: Keep bus numbers constant during Live Update
From: Pasha Tatashin @ 2026-06-14 14:01 UTC (permalink / raw)
To: Pranjal Shrivastava
Cc: David Matlack, 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: <aiQAJRINEKiwCmVm@google.com>
On 2026-06-06 11:10:29+00:00, Pranjal Shrivastava wrote:
> On Fri, May 22, 2026 at 08:24:03PM +0000, David Matlack wrote:
>
> > During a Live Update, preserved devices must be allowed to continue
> > performing memory transactions so the kernel cannot change the fabric
> > topology, including bus numbers, since that would require disabling
> > and flushing any memory transactions first.
> >
> > To keep bus numbers constant, always inherit the secondary and
> > subordinate bus numbers assigned to bridges during scanning, instead of
> > assigning new ones, if any PCI devices are being preserved. Note that
> > the kernel inherits bus numbers even on bridges without any downstream
> > endpoints that were preserved. This avoids accidentally assigning a
> > bridge a new window that overlaps with a preserved device that is
> > downstream of a different bridge.
> >
> > If a bridge is scanned with a broken topology or has no bus numbers
> > set during a Live Update, refuse to assign it new bus numbers and refuse
> > to enumerate devices below it until the Live Update is finished. This is
> > a safety measure to prevent topology conflicts.
> >
> > Require that CONFIG_CARDBUS is not enabled to enable
> > CONFIG_PCI_LIVEUPDATE since inheriting bus numbers on PCI-to-CardBus
> > bridges requires additional work but is not a priority at the moment.
> >
> > Signed-off-by: David Matlack <dmatlack@google.com>
> > ---
> > .../admin-guide/kernel-parameters.txt | 6 +-
> > drivers/pci/Kconfig | 2 +-
> > drivers/pci/liveupdate.c | 83 ++++++++++++++++++-
> > drivers/pci/liveupdate.h | 14 ++++
> > drivers/pci/probe.c | 17 +++-
> > include/linux/pci_liveupdate.h | 4 +
> > 6 files changed, 119 insertions(+), 7 deletions(-)
>
> [...]
>
> > + incoming = pci_liveupdate_flb_get_incoming();
> > + if (!incoming) {
> > + dev->liveupdate.inherit_buses = false;
> > + goto out;
> > + }
> > +
> > + /*
> > + * It is safe to sample incoming->ser->nr_devices and then
> > + * drop the rwsem since nr_devices will only decrease. Thus the
> > + * only "race" is that the current scan will be overly
> > + * conservative and force bus inheritance.
> > + */
> > + dev->liveupdate.inherit_buses = incoming->ser->nr_devices;
>
> Nit: inherit_buses is a bool, while compiler will handle it correctly,
> maybe we could:
>
> dev->liveupdate.inherit_buses = !!incoming->ser->nr_devices
+1
>
> OR
>
> dev->liveupdate.inherit_buses = (incoming->ser->nr_devices > 0)
>
> for readability?
>
> > + pci_liveupdate_flb_put_incoming();
> > + }
> > +
> > +out:
> > + return dev->liveupdate.inherit_buses;
> > +}
> > +
>
> [...]
>
> > /*
> > @@ -1497,8 +1501,7 @@ static int pci_scan_bridge_extend(struct pci_bus *bus, struct pci_dev *dev,
> > * do in the second pass.
> > */
> > if (!pass) {
> > - if (pcibios_assign_all_busses() || broken)
> > -
> > + if (assign_new_buses || broken)
> > /*
> > * Temporarily disable forwarding of the
> > * configuration cycles on all bridges in
> > @@ -1512,6 +1515,11 @@ static int pci_scan_bridge_extend(struct pci_bus *bus, struct pci_dev *dev,
> > goto out;
> > }
> >
> > + if (liveupdate) {
> > + pci_err(dev, "Cannot reconfigure bridge during Live Update, skipping\n");
> > + goto out;
> > + }
>
> Quite helpful! Thanks :)
>
> > +
> > /* Clear errors */
> > pci_write_config_word(dev, PCI_STATUS, 0xffff);
> >
> > @@ -1572,6 +1580,7 @@ static int pci_scan_bridge_extend(struct pci_bus *bus, struct pci_dev *dev,
> > pci_write_config_word(dev, PCI_BRIDGE_CONTROL, bctl);
> >
> > pm_runtime_put(&dev->dev);
> > + pci_liveupdate_scan_bridge_end(dev, pass);
> >
> > return max;
> > }
>
> With the minor nit above,
> Reviewed-by: Pranjal Shrivastava <praan@google.com>
>
> Thanks,
> Praan
^ permalink raw reply
* Re: [PATCH v6 05/12] PCI: liveupdate: Keep bus numbers constant during Live Update
From: Pasha Tatashin @ 2026-06-14 13:57 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,
Pranjal Shrivastava, Pratyush Yadav, Saeed Mahameed,
Samiullah Khawaja, Shuah Khan, Vipin Sharma, William Tu, Yi Liu
In-Reply-To: <20260522202410.3104264-6-dmatlack@google.com>
On Fri, 22 May 2026 20:24:03 +0000, David Matlack <dmatlack@google.com> wrote:
> diff --git a/drivers/pci/liveupdate.c b/drivers/pci/liveupdate.c
> index 4f2ec6ffdd16..2421bc218916 100644
> --- a/drivers/pci/liveupdate.c
> +++ b/drivers/pci/liveupdate.c
> @@ -103,7 +118,7 @@
> /**
> * struct pci_liveupdate_global - Global state for PCI Live Update support
> * @rwsem: Reader/writer semaphore used to protect the incoming and outgoing
> - * FLBs, and the references to them in struct pci_dev.
> + * FLBs and references to them in struct pci_dev.
This change does not belong to this patch.
> @@ -396,6 +411,72 @@ static void pci_liveupdate_flb_put_incoming(void)
> liveupdate_flb_put_incoming(&pci_liveupdate_flb);
> }
>
> +bool pci_liveupdate_scan_bridge_begin(struct pci_bus *bus, struct pci_dev *dev,
> + int pass)
This function requires a header comment; it is public and not self-descriptive.
--
Pasha Tatashin <pasha.tatashin@soleen.com>
^ permalink raw reply
* Re: [PATCH v6 04/12] PCI: liveupdate: Document driver binding responsibilities
From: Pasha Tatashin @ 2026-06-14 13:41 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,
Pranjal Shrivastava, Pratyush Yadav, Saeed Mahameed,
Samiullah Khawaja, Shuah Khan, Vipin Sharma, William Tu, Yi Liu
In-Reply-To: <20260522202410.3104264-5-dmatlack@google.com>
On Fri, 22 May 2026 20:24:02 +0000, David Matlack <dmatlack@google.com> wrote:
> Document how driver binding works during a Live Update and what the PCI
> core expects of drivers and users. Note that this is only a description
> of the current division of responsibilities. These can change in the
> future if we decide.
Reviewed-by: Pasha Tatashin <pasha.tatashin@soleen.com>
--
Pasha Tatashin <pasha.tatashin@soleen.com>
^ permalink raw reply
* Re: [PATCH v6 03/12] PCI: liveupdate: Track incoming preserved PCI devices
From: Pasha Tatashin @ 2026-06-14 13:38 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,
Pranjal Shrivastava, Pratyush Yadav, Saeed Mahameed,
Samiullah Khawaja, Shuah Khan, Vipin Sharma, William Tu, Yi Liu
In-Reply-To: <20260522202410.3104264-4-dmatlack@google.com>
On Fri, 22 May 2026 20:24:01 +0000, David Matlack <dmatlack@google.com> wrote:
> diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig
> index 10c9b65aa242..e68ae5c172d4 100644
> --- a/drivers/pci/Kconfig
> +++ b/drivers/pci/Kconfig
> @@ -330,7 +330,7 @@ config VGA_ARB_MAX_GPUS
>
> config PCI_LIVEUPDATE
> bool "PCI Live Update Support"
> - depends on PCI && LIVEUPDATE
> + depends on PCI && LIVEUPDATE && 64BIT
Please move this to the first patch, fewer changes between patches, and
also KHO does not support anything but 64-bit mode.
>
> diff --git a/drivers/pci/liveupdate.c b/drivers/pci/liveupdate.c
> index 065d5af822f7..96c43b84532c 100644
> --- a/drivers/pci/liveupdate.c
> +++ b/drivers/pci/liveupdate.c
> @@ -128,13 +157,49 @@ static void pci_flb_unpreserve(struct liveupdate_flb_op_args *args)
> [ ... skip 31 lines ... ]
> +
> +err_xa_destroy:
> + xa_destroy(&incoming->xa);
> + kfree(incoming);
> +err_restore_free:
> + kho_restore_free(ser);
This is the pattern we have been enforcing in other places in LUO. If
the first retrieval fails, return the same error thereafter.
> @@ -270,6 +335,91 @@ void pci_liveupdate_unpreserve(struct pci_dev *dev)
> }
> EXPORT_SYMBOL_GPL(pci_liveupdate_unpreserve);
>
> +static struct pci_flb_incoming *pci_liveupdate_flb_get_incoming(void)
> +{
> + struct pci_flb_incoming *incoming = NULL;
> + int ret;
Maybe make the error return static, and avoid another search through compatible
FLBs if it failed before?
1. Add "saved_err;"; if it is set, return it right away.
2. Change all errors to use goto save_err;, and at the end of the
function, assign ret to saved_err;
> [ ... skip 15 lines ... ]
> + * This could mean that no PCI FLB data was passed by the previous
> + * kernel, but it could also mean the previous kernel used a different
> + * compatibility string (i.e. a different ABI).
> + */
> + if (ret == -ENOENT) {
> + pr_info_once("No incoming FLB matched %s\n", pci_liveupdate_flb.compatible);
I would assume this is very normal, e.g., no devices were preserved but
memfd+hugetlb was preserved. Maybe use pr_debug_once().
> + return NULL;
> + }
> +
> + /*
> + * There is incoming FLB data that matches pci_liveupdate_flb.compatible
> + * but it cannot be retrieved.
> + */
> + if (ret) {
> + WARN_ONCE(ret, "Failed to retrieve incoming FLB data\n");
No need to print backtrace, please just print a warning:
pr_warn_once("Failed to retrieve incoming FLB data: %pe\n", ERR_PTR(ret));
> [ ... skip 34 lines ... ]
> + * through pci_liveupdate_finish(). This can happen if PCI core probes
> + * the same device multiple times, e.g. due to hotplug.
> + */
> + if (!dev_ser->refcount) {
> + pci_liveupdate_flb_put_incoming();
> + return;
Pleaes use 'goto put_incoming'
> + }
> +
> + pci_info(dev, "Device was preserved by previous kernel across Live Update\n");
> + dev->liveupdate.incoming = dev_ser;
> +
> + /*
> + * Hold the ref on the incoming FLB until pci_liveupdate_finish() so
> + * that dev->liveupdate.incoming does not get freed while it is in use.
> + */
How would that work? If finish is not called FLB stays around until the
next reboot.
--
Pasha Tatashin <pasha.tatashin@soleen.com>
^ permalink raw reply
* Re: [PATCH RFC 4/4] Documentation/kernel-parameters: add/update printk_delay/boot_delay
From: Andrew Murray @ 2026-06-14 12:55 UTC (permalink / raw)
To: Petr Mladek
Cc: Jonathan Corbet, Shuah Khan, Russell King, Florian Fainelli,
Broadcom internal kernel review list, Ray Jui, Scott Branden,
Steven Rostedt, John Ogness, Sergey Senozhatsky, Andrew Morton,
Sebastian Andrzej Siewior, Clark Williams, Randy Dunlap,
Linus Torvalds, linux-doc, linux-kernel, linux-arm-kernel,
linux-rpi-kernel, linux-rt-devel
In-Reply-To: <aibfFQpK0Se-SiaT@pathway.suse.cz>
On Mon, 8 Jun 2026 at 16:26, Petr Mladek <pmladek@suse.com> wrote:
>
> On Mon 2026-06-01 00:17:40, Andrew Murray wrote:
> > boot_delay has been deprecated in favour of an extended printk_delay,
> > let's update kernel-parameters to reflect the addition of printk_delay
> > and the deprecation of boot_delay.
> >
> > Signed-off-by: Andrew Murray <amurray@thegoodpenguin.co.uk>
>
> LGTM:
>
> Reviewed-by: Petr Mladek <pmladek@suse.com>
>
> Best Regards,
> Petr
Thanks for the reviews!
Andrew Murray
^ permalink raw reply
* Re: [PATCH RFC 3/4] printk: nbcon: move printk_delay to console emiting code
From: Andrew Murray @ 2026-06-14 12:55 UTC (permalink / raw)
To: Petr Mladek
Cc: Jonathan Corbet, Shuah Khan, Russell King, Florian Fainelli,
Broadcom internal kernel review list, Ray Jui, Scott Branden,
Steven Rostedt, John Ogness, Sergey Senozhatsky, Andrew Morton,
Sebastian Andrzej Siewior, Clark Williams, Randy Dunlap,
Linus Torvalds, linux-doc, linux-kernel, linux-arm-kernel,
linux-rpi-kernel, linux-rt-devel
In-Reply-To: <aibe12WcrLxVWTez@pathway.suse.cz>
On Mon, 8 Jun 2026 at 16:25, Petr Mladek <pmladek@suse.com> wrote:
>
> On Mon 2026-06-01 00:17:39, Andrew Murray wrote:
> > The printk_delay and boot_delay features are helpful for debugging
> > as kernel output can be slowed down during boot allowing messages to
> > be seen before scrolling off the screen, or to correlate timing between
> > some physical event and console output.
> >
> > However, since the introduction of nbcon and the legacy printer thread
> > for PREEMPT_RT kernels, printk records are now emited to the console
> > asynchronously to the caller of printk. Thus, any printk delay added by
> > boot_delay/printk_delay continues to slow down the calling process but
> > may not have any impact to the rate in which records are emited to the
> > console.
> >
> > Let's address this by moving the printk delay from the calling code
> > to the console emiting code instead. Whilst this ensures that delays
> > are still observed (especially for slower consoles), it doesn't improve
> > the use-case of using boot_delay/printk_delay to correlate timings
> > between physical events and console output.
> >
> > --- a/include/linux/printk.h
> > +++ b/include/linux/printk.h
>
> The declaration is needed just inside kernel/printk/ directory.
> It should better be done via kernel/printk/internal.h
OK.
>
> > @@ -209,6 +209,7 @@ extern bool nbcon_device_try_acquire(struct console *con);
> > extern void nbcon_device_release(struct console *con);
> > void nbcon_atomic_flush_unsafe(void);
> > bool pr_flush(int timeout_ms, bool reset_on_progress);
> > +void printk_delay(bool use_atomic);
> > #else
> > static inline __printf(1, 0)
> > int vprintk(const char *s, va_list args)
> > @@ -326,6 +327,9 @@ static inline bool pr_flush(int timeout_ms, bool reset_on_progress)
> > {
> > return true;
> > }
> > +static inline void printk_delay(bool use_atomic)
> > +{
> > +}
> >
> > #endif
> >
> > diff --git a/kernel/printk/nbcon.c b/kernel/printk/nbcon.c
> > index d7044a7a214bdd4537a5e20d876d99bc3ffe8b3a..a507a2fed5bf4366e24330f763b842a698ecf6f7 100644
> > --- a/kernel/printk/nbcon.c
> > +++ b/kernel/printk/nbcon.c
> > @@ -1267,11 +1267,16 @@ static int nbcon_kthread_func(void *__console)
> >
> > con_flags = console_srcu_read_flags(con);
> >
> > + wctxt.len = 0;
> > +
> > if (console_is_usable(con, con_flags, false))
> > backlog = nbcon_emit_one(&wctxt, false);
> >
> > console_srcu_read_unlock(cookie);
> >
> > + if (backlog && wctxt.len > 0)
>
> Heh, this is tricky. It might probably work but it is not guarantted
> by design.
>
> The "backlog" name is a bit misleading. The value is basically
> wctxt.ctxt.backlog. The real meaning is that printk_get_next_message()
> was able to read a message. It means that there _was_ a backlog.
> But it is not clear whether there are still pending messages or not.
Yes I found that to be the case (see my notes in the cover letter) -
backlog is only true if a record was successfully retrieved, though
that record may be one that is suppressed.
>
> Also it is not clear that whether the message was pushed to the
> console or not. It might have been supressed in which case
> (wctxt.len == 0). But it might also be emitted only partially
> when a higher priority context took over the console context
> ownership.
You say it might probably work but isn't guaranteed by design, I'm
struggling to see what I've missed...
As far as I could tell, nbcon_emit_next_record only returns true when
a record has been printed and it still has context. The only exception
to that is where pmsg.outbuf_len is zero (suppressed), in which case
it may return true. Thus if (nbcon_emit_next_record() &&
!pmsg.outbuf_len) then we can be sure a record was printed. In order
to apply this test from the various callers...
for nbcon_emit_one - this returns ctxt->backlog if
nbcon_emit_next_record returned true. But backlog is *always* true
when nbcon_emit_next_record returns true. Thus the test of (backlog &&
wctxt.len) is equivelant to (nbcon_emit_next_record() &&
!pmsg.outbuf_len).
So I still think this implementation is valid.
>
> I would prefer to explicitely set some flag when
> nbcon_emit_next_record() really called con->write*().
> See below.
>
> > + printk_delay(false);
> > +
> > cond_resched();
> >
> > } while (backlog);
> > @@ -1525,6 +1530,8 @@ bool nbcon_legacy_emit_next_record(struct console *con, bool *handover,
> > }
> >
> > progress = nbcon_emit_one(&wctxt, use_atomic);
> > + if (progress && wctxt.len > 0)
>
> Same here.
>
> > + printk_delay(use_atomic);
> >
> > if (use_atomic) {
> > start_critical_timings();
> > @@ -1584,6 +1591,8 @@ static int __nbcon_atomic_flush_pending_con(struct console *con, u64 stop_seq)
> > if (!nbcon_context_try_acquire(ctxt, false))
> > return -EPERM;
> >
> > + wctxt.len = 0;
> > +
> > /*
> > * nbcon_emit_next_record() returns false when
> > * the console was handed over or taken over.
> > @@ -1595,7 +1604,9 @@ static int __nbcon_atomic_flush_pending_con(struct console *con, u64 stop_seq)
> > nbcon_context_release(ctxt);
> > }
> >
> > - if (!ctxt->backlog) {
> > + if (ctxt->backlog && wctxt.len > 0) {
> > + printk_delay(true);
> > + } else {
>
> This changes the semantic. The original code call this when
> no message was read. The new code would call this path also
> when the output was suppressed. It would probably work.
> But still.
Ah, good spot! I missed that.
>
> > /* Are there reserved but not yet finalized records? */
> > if (nbcon_seq_read(con) < stop_seq)
> > err = -ENOENT;
>
>
> As mentioned above, I would add a flag which would be set when
> con->write*() was called.
I'm not sure why I tried to avoid adding members to nbcon_context, but
I prefer your solution, it isn't so fragile, and makes it easier to
understand. I'll update for my next revision.
>
> It modifies the type of unsafe_takeover in struct nbcon_write_context.
> But it actually makes it more compatible with struct nbcon_state.
What is the intent of this change (bool to unsigned char)?
>
> My proposal (on top of this patch):
>
> diff --git a/include/linux/console.h b/include/linux/console.h
> index 5520e4477ad7..5a86942e55ef 100644
> --- a/include/linux/console.h
> +++ b/include/linux/console.h
> @@ -290,6 +290,7 @@ struct nbcon_context {
> * @outbuf: Pointer to the text buffer for output
> * @len: Length to write
> * @unsafe_takeover: If a hostile takeover in an unsafe state has occurred
> + * @emitted: The write context tried to emit the message. Might be incomplete.
> * @cpu: CPU on which the message was generated
> * @pid: PID of the task that generated the message
> * @comm: Name of the task that generated the message
> @@ -298,7 +299,8 @@ struct nbcon_write_context {
> struct nbcon_context __private ctxt;
> char *outbuf;
> unsigned int len;
> - bool unsafe_takeover;
> + unsigned char unsafe_takeover : 1;
> + unsigned char emitted : 1
> #ifdef CONFIG_PRINTK_EXECUTION_CTX
> int cpu;
> pid_t pid;
> diff --git a/kernel/printk/nbcon.c b/kernel/printk/nbcon.c
> index a507a2fed5bf..060534becefc 100644
> --- a/kernel/printk/nbcon.c
> +++ b/kernel/printk/nbcon.c
> @@ -1069,6 +1069,9 @@ static bool nbcon_emit_next_record(struct nbcon_write_context *wctxt, bool use_a
> else
> con->write_thread(con, wctxt);
>
> + /* Tried to emit something. Might be incomplete. */
> + wctxt.emitted = 1;
> +
> if (!wctxt->outbuf) {
> /*
> * Ownership was lost and reacquired by the driver. Handle it
> @@ -1267,14 +1270,14 @@ static int nbcon_kthread_func(void *__console)
>
> con_flags = console_srcu_read_flags(con);
>
> - wctxt.len = 0;
> + wctxt.emitted = 0;
>
> if (console_is_usable(con, con_flags, false))
> backlog = nbcon_emit_one(&wctxt, false);
>
> console_srcu_read_unlock(cookie);
>
> - if (backlog && wctxt.len > 0)
> + if (wctxt.emitted)
> printk_delay(false);
>
> cond_resched();
> @@ -1530,7 +1533,7 @@ bool nbcon_legacy_emit_next_record(struct console *con, bool *handover,
> }
>
> progress = nbcon_emit_one(&wctxt, use_atomic);
> - if (progress && wctxt.len > 0)
> + if (wctxt.emitted)
> printk_delay(use_atomic);
>
> if (use_atomic) {
> @@ -1591,7 +1594,7 @@ static int __nbcon_atomic_flush_pending_con(struct console *con, u64 stop_seq)
> if (!nbcon_context_try_acquire(ctxt, false))
> return -EPERM;
>
> - wctxt.len = 0;
> + wctxt.emitted = 0;
>
> /*
> * nbcon_emit_next_record() returns false when
> @@ -1604,9 +1607,10 @@ static int __nbcon_atomic_flush_pending_con(struct console *con, u64 stop_seq)
> nbcon_context_release(ctxt);
> }
>
> - if (ctxt->backlog && wctxt.len > 0) {
> + if (wctxt.emitted)
> printk_delay(true);
> - } else {
> +
> + if (!ctxt->backlog) {
> /* Are there reserved but not yet finalized records? */
> if (nbcon_seq_read(con) < stop_seq)
> err = -ENOENT;
Thanks,
Andrew Murray
^ permalink raw reply
* Re: [PATCH iproute2-next 7/7] devlink: add scope filter to resource show
From: Or Har-Toov @ 2026-06-14 12:10 UTC (permalink / raw)
To: David Ahern, Tariq Toukan, Stephen Hemminger, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Andrew Lunn, David S. Miller
Cc: Donald Hunter, Simon Horman, Jiri Pirko, Jonathan Corbet,
Shuah Khan, Saeed Mahameed, Leon Romanovsky, Mark Bloch,
Shuah Khan, Matthieu Baerts (NGI0), Chuck Lever, Carolina Jubran,
Moshe Shemesh, Shay Drori, Dragos Tatulea, Daniel Zahka,
Shahar Shitrit, Jacob Keller, Cosmin Ratiu, Parav Pandit,
Kees Cook, Adithya Jayachandran, Daniel Jurgens, netdev,
linux-kernel, linux-doc, linux-rdma, linux-kselftest,
Gal Pressman, Ido Schimmel, Jiri Pirko, Petr Machata
In-Reply-To: <943b4932-17f4-4a52-af92-b9485a0e8c7a@kernel.org>
On 11/06/2026 21:53, David Ahern wrote:
>
> On 6/8/26 11:39 PM, Tariq Toukan wrote:
>> @@ -9010,13 +9029,29 @@ static int cmd_resource_show(struct dl *dl)
>> uint16_t flags = NLM_F_REQUEST | NLM_F_ACK;
>> struct nlmsghdr *nlh;
>> struct resource_ctx resource_ctx = {};
>> + struct dl_opts *opts = &dl->opts;
>> int err;
>>
>> - err = dl_argv_parse_with_selector(dl, &flags, DEVLINK_CMD_RESOURCE_DUMP,
>> - DL_OPT_HANDLE | DL_OPT_HANDLEP,
>> - 0, 0, 0);
>> - if (err)
>> - return err;
>> + if (dl_argv_match(dl, "scope")) {
>> + const char *scopestr;
>> +
>> + dl_arg_inc(dl);
>> + err = dl_argv_str(dl, &scopestr);
>> + if (err)
>> + return err;
>> + err = resource_scope_get(scopestr, &opts->resource_scope_mask);
>> + if (err)
>> + return err;
>> + opts->present |= DL_OPT_RESOURCE_SCOPE;
>
> Comment from Claude that seems legit:
>
> Issue found: In cmd_resource_show, the scope path sets opts->present |=
> DL_OPT_RESOURCE_SCOPE without first clearing opts->present. In batch
> mode, dl->opts is shared across commands, and the non-scope path
> correctly resets opts->present via dl_argv_parse(). But the scope path
> bypasses dl_argv_parse(), so stale bits (e.g. DL_OPT_HANDLE from a
> previous dev show) remain. When dl_opts_put() runs, it writes the stale
> DEVLINK_ATTR_BUS_NAME/DEV_NAME attributes into the dump request,
> silently filtering to a single device instead of all devices. Fix: use =
> instead of |=
>
> Are you ok with the suggested resolution?
>
yes, thank you. let me know if I should resend.
^ permalink raw reply
* Re: [PATCH iproute2-next 7/7] devlink: add scope filter to resource show
From: Or Har-Toov @ 2026-06-14 12:02 UTC (permalink / raw)
To: David Ahern, Tariq Toukan, Stephen Hemminger, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Andrew Lunn, David S. Miller
Cc: Donald Hunter, Simon Horman, Jiri Pirko, Jonathan Corbet,
Shuah Khan, Saeed Mahameed, Leon Romanovsky, Mark Bloch,
Shuah Khan, Matthieu Baerts (NGI0), Chuck Lever, Carolina Jubran,
Moshe Shemesh, Shay Drori, Dragos Tatulea, Daniel Zahka,
Shahar Shitrit, Jacob Keller, Cosmin Ratiu, Parav Pandit,
Kees Cook, Adithya Jayachandran, Daniel Jurgens, netdev,
linux-kernel, linux-doc, linux-rdma, linux-kselftest,
Gal Pressman, Ido Schimmel, Jiri Pirko, Petr Machata
In-Reply-To: <943b4932-17f4-4a52-af92-b9485a0e8c7a@kernel.org>
On 11/06/2026 21:53, David Ahern wrote:
>
> On 6/8/26 11:39 PM, Tariq Toukan wrote:
>> @@ -9010,13 +9029,29 @@ static int cmd_resource_show(struct dl *dl)
>> uint16_t flags = NLM_F_REQUEST | NLM_F_ACK;
>> struct nlmsghdr *nlh;
>> struct resource_ctx resource_ctx = {};
>> + struct dl_opts *opts = &dl->opts;
>> int err;
>>
>> - err = dl_argv_parse_with_selector(dl, &flags, DEVLINK_CMD_RESOURCE_DUMP,
>> - DL_OPT_HANDLE | DL_OPT_HANDLEP,
>> - 0, 0, 0);
>> - if (err)
>> - return err;
>> + if (dl_argv_match(dl, "scope")) {
>> + const char *scopestr;
>> +
>> + dl_arg_inc(dl);
>> + err = dl_argv_str(dl, &scopestr);
>> + if (err)
>> + return err;
>> + err = resource_scope_get(scopestr, &opts->resource_scope_mask);
>> + if (err)
>> + return err;
>> + opts->present |= DL_OPT_RESOURCE_SCOPE;
>
> Comment from Claude that seems legit:
>
> Issue found: In cmd_resource_show, the scope path sets opts->present |=
> DL_OPT_RESOURCE_SCOPE without first clearing opts->present. In batch
> mode, dl->opts is shared across commands, and the non-scope path
> correctly resets opts->present via dl_argv_parse(). But the scope path
> bypasses dl_argv_parse(), so stale bits (e.g. DL_OPT_HANDLE from a
> previous dev show) remain. When dl_opts_put() runs, it writes the stale
> DEVLINK_ATTR_BUS_NAME/DEV_NAME attributes into the dump request,
> silently filtering to a single device instead of all devices. Fix: use =
> instead of |=
>
> Are you ok with the suggested resolution?
>
yes, thank you. let me know if I should resend.
^ permalink raw reply
* Re: [PATCH RFC 2/4] printk: deprecate boot_delay in favour of printk_delay
From: Andrew Murray @ 2026-06-14 11:45 UTC (permalink / raw)
To: Petr Mladek
Cc: Jonathan Corbet, Shuah Khan, Russell King, Florian Fainelli,
Broadcom internal kernel review list, Ray Jui, Scott Branden,
Steven Rostedt, John Ogness, Sergey Senozhatsky, Andrew Morton,
Sebastian Andrzej Siewior, Clark Williams, Randy Dunlap,
Linus Torvalds, linux-doc, linux-kernel, linux-arm-kernel,
linux-rpi-kernel, linux-rt-devel
In-Reply-To: <aibMr16r55xE26rU@pathway.suse.cz>
On Mon, 8 Jun 2026 at 15:07, Petr Mladek <pmladek@suse.com> wrote:
>
> On Mon 2026-06-01 00:17:38, Andrew Murray wrote:
> > The boot_delay (BOOT_PRINTK_DELAY) kernel parameter and printk_delay sysctl
> > are two distinct mechanisms for providing similar functionality which add a
> > delay prior to each printed printk message.
> >
> > boot_delay provides a kernel parameter for delaying printk output from
> > kernel start through to boot (SYSTEM_RUNNING), whereas printk_delay is
> > configurable only via sysctl and thus is only used post boot.
> >
> > Let's deprecate the boot_delay feature in favour of printk_delay. In order
> > to preserve functionality, we'll also extend printk_delay such that it can
> > additionally configured via a kernel parameter.
>
> I would make it clear and say: "via an early kernel parameter".
>
> Note that there are also kernel parameters which can be modified at runtime
> via /sys/module/kernel/paramters/<parameter>
OK thanks, I will update.
>
> Also I would make it clear that this changes the behavior, for
> example:
>
> <proposal>
> Behavior change:
>
> The delay enabled by both "boot_delay" and "printk_delay" continues
> working even in SYSTEM_RUNNING state. It must be explicitly stopped
> by setting printk_delay=0 via sysctl.
>
> The delay is skipped when the message is suppressed in all system
> states. It used to skipped only for the boot_delay.
> </proposal>
Yes, I'm happy to make that clearer.
>
> > --- a/kernel/printk/printk.c
> > +++ b/kernel/printk/printk.c
> > @@ -1339,11 +1327,34 @@ static void boot_delay_msec(int level)
> > }
> > }
> > #else
> > -static inline void boot_delay_msec(int level)
> > +static inline void __init printk_delay_calculate(void)
> > +{
> > +}
> > +
> > +static inline void early_boot_delay_msec(void)
> > {
>
> It would be nice to print a warning that the early boot delay
> does not work, something like:
>
> pr_warn_once("Early boot delay does not work without CONFIG_GENERIC_CALIBRATE_DELAY enabled.\n");
>
> > }
> > #endif
> >
> > +static int __init printk_delay_setup(char *str)
> > +{
> > + get_option(&str, &printk_delay_msec);
> > + if (printk_delay_msec > 10 * 1000)
> > + printk_delay_msec = 0;
>
> Sashiko AI warns that this code accepts negative values.
> It might cause long delays, see
> https://sashiko.dev/#/patchset/20260601-deprecate_boot_delay-v1-0-c34c187142a6%40thegoodpenguin.co.uk
>
> The problem has already been there even before. But it would be nice
> to fix it.
Thanks for pointing out Sashiko, I hadn't seen its review on my
patches. Are authors expected to get emails from it, as I didn't?
In any case, it's a good spot, so I'll address.
>
> > +
> > + printk_delay_calculate();
> > +
> > + return 0;
> > +}
> > +early_param("printk_delay", printk_delay_setup);
> > +
> > +static int __init boot_delay_setup(char *str)
> > +{
> > + pr_warn("boot_delay will soon be deprecated, please use printk_delay instead");
> > + return printk_delay_setup(str);
> > +}
> > +early_param("boot_delay", boot_delay_setup);
> > +
> > static bool printk_time = IS_ENABLED(CONFIG_PRINTK_TIME);
> > module_param_named(time, printk_time, bool, S_IRUGO | S_IWUSR);
>
> Otherwise, it looks good to me.
>
> Best Regards,
> Petr
Thanks,
Andrew Murray
^ permalink raw reply
* Re: [PATCH RFC 1/4] printk: remove BOOT_PRINTK_DELAY config option
From: Andrew Murray @ 2026-06-14 11:41 UTC (permalink / raw)
To: Petr Mladek
Cc: Jonathan Corbet, Shuah Khan, Russell King, Florian Fainelli,
Broadcom internal kernel review list, Ray Jui, Scott Branden,
Steven Rostedt, John Ogness, Sergey Senozhatsky, Andrew Morton,
Sebastian Andrzej Siewior, Clark Williams, Randy Dunlap,
Linus Torvalds, linux-doc, linux-kernel, linux-arm-kernel,
linux-rpi-kernel, linux-rt-devel
In-Reply-To: <aibCBGjVk4yqtYyT@pathway.suse.cz>
On Mon, 8 Jun 2026 at 14:22, Petr Mladek <pmladek@suse.com> wrote:
>
> On Mon 2026-06-01 00:17:37, Andrew Murray wrote:
> > The boot_delay (BOOT_PRINTK_DELAY) kernel parameter and printk_delay sysctl
> > are two distinct mechanisms for providing similar functionality which add a
> > delay prior to each printed printk message.
> >
> > In preparation of combining them into a single configurable feature, let's
> > first remove the kconfig option BOOT_PRINTK_DELAY.
> >
> > Signed-off-by: Andrew Murray <amurray@thegoodpenguin.co.uk>
>
> The option allowed to reduce a bit the vmlinux size when people were
> not interested into the functionality. I am not sure if it is worth
> it though. I am personally fine with this change.
I hadn't considered that need.
I'm happy to add this back in, but it would only make sense if this
option covered both boot_delay and printk_delay. That would change the
meaning of this existing Kconfig option, and would also allow the
removal of the printk_delay sysctl, I'm not sure if userspace assumes
this will always be there (probably not).
I'll leave this as is, unless there are objections.
Thanks,
Andrew Murray
>
> Reviewed-by: Petr Mladek <pmladek@suse.com>
>
> Best Regards,
> Petr
^ permalink raw reply
* Re: [swap tier discussion] Re: [PATCH v3 2/4] mm/zswap: Implement proactive writeback
From: YoungJun Park @ 2026-06-14 9:23 UTC (permalink / raw)
To: Shakeel Butt
Cc: Yosry Ahmed, Hao Jia, Johannes Weiner, mhocko, tj, mkoutny,
roman.gushchin, Nhat Pham, akpm, chengming.zhou, muchun.song,
cgroups, linux-mm, linux-kernel, linux-doc, Hao Jia, chrisl,
kasong, baoquan.he, joshua.hahnjy
In-Reply-To: <aiw2p5ANjsQUCIHA@linux.dev>
....
> >Based on the memcg interface currently proposed in swap_tier
> > (memory.swap.tiers, memory.swap.tiers.effective), I think it aligns well
> > with the current direction. It provides a foundation for selectively
> > targeting devices in tier order.
>
> Here instead of cpuset like interface, we may want more zswap like interface
> where you can put limit on the usage i.e. memory.swap.tier*.max. We can start
> with allowing only two values i.e. 0 and max which effectively will be the
> same as what you need.
>
Good idea, and it's certainly feasible. When I considered this a while
ago, the reasons I didn't take this direction were:
1. There's no real-world usage for adjusting the swap tier amount (it's
either 0 or MAX). That said, your suggestion to initially allow only
0 and max is the killing point, and it's making me reconsider.
2. The implementation cost seems high. The current implementation
handles this at runtime via simple masking.
3. Relationship with swap.max:
- If we tie it to the current interface, wouldn't limiting the swap
amount within a selected tier already be possible? I wonder if
that alone is enough.
- If we add tier.max, it would need to be a subset of swap.max.
(Any other complexities here?)
4. vswap enable/disable: vswap doesn't seem to have an amount-control
aspect, so an on/off semantic would be clearer.
https://lore.kernel.org/linux-mm/ai5kOOmR1LPTWs1J@yjaykim-PowerEdge-T330/T/#m8831ec057bf9387978d3bd698f51920600e09a04
In that case, the internal logic could stay roughly the same rather
than counting via a page counter. Something like:
1. Change the interface shell: tier.*.max — allow only 0 ~ max.
2. Keep the internal logic as is: 0 disables the mask (child memcgs
off too), max enables it (child memcgs on too).
3. memory.zswap.max integrates naturally (it's memory."tier_name".max).
4. Extend later if use cases arise.
On balance I still lean toward the current interface, but if a per-tier
max is the better fit for memcg's direction and others feel the same,
I'm happy to switch. I'd like to hear Shakeel's thoughts again, and I'm
curious about others' opinions too.
A few more perspectives on the points below.
> I will respond to your other points later when I have time.
> >
> > To summarize the discussions so far, the following points align well.
> >
> > - Per-cgroup swap control, as I suggested.
> > - Proactive zswap writeback (Hao's usecase)
> > - Swap device target demotion(if it wants selective, then it is more better), as you mentioned:
> > https://lore.kernel.org/linux-mm/aicZ-5GX9De3MAU7@linux.dev/
> > - Virtual Swap on/off in the future, as Nhat mentioned:
> > https://lore.kernel.org/linux-mm/20260528212955.1912856-1-nphamcs@gmail.com/
> > - The memory.zswap.writeback alternative (no hierarchy model conflict)
> > - zswap is first swap tier.
> > - Promotion. (Also better for selectve usage)
> > - tier based swap policy (e.g round-robin...)
> >
> > To accelerate this work, I believe we should reach a consensus and
> > merge the currently proposed swap_tier interface :)
> >
> > If the above approach is difficult, I would like to suggest an
> > alternative for progress with the memcg interfaces removed:
> >
> > 1) We could make zswap the first tier and create
> > a use case where memory.zswap.writeback internally is handled by tier logic.
> >
> > 2) Or simply merge the swap_tier infrastructure itself first.
> >
> > This would allow the swap_tier infrastructure to be merged and discussed
> > more easily.
> >
> > If it takes longer to adopt swap_tier anyway, by doing so we progress next step
> > as a experimental feature.
> >
> > - Apply per-cgroup swap as an experimental (debugfs) feature.
> > - Apply Hao's use case experimentally or as it is as Yosry suggested.
> > (future migration to swap tier)
> >
> > How do you think?
> >
> > (FYI: My emails to kernel.org are failing due to internal server issues.)
> >
> > Thank you
> > Youngjun Park
Let me clarify a part I wrote confusingly. Handling
memory.zswap.writeback via tiers is possible, but I don't think the
interface itself would be replaced even if memory.swap.tiers is adopted.
Selecting only zswap in memory.swap.tiers would not just disable
writeback.it would also block regular swap entirely, which differs
slightly from the current semantic. (... "Per the cgroup v2 docs: a
zswap-only tier setting is subtly different from setting
memory.swap.max to 0, since it still allows pages to be written to the
zswap pool; this has no effect if zswap is disabled, and swapping is
allowed unless memory.swap.max is set to 0.")
So the interface itself needs to be retained, and it could be extended
toward selective writeback — e.g., passing a desired tier into
memory.zswap.writeback so writeback targets only that tier. Currently
it only controls on/off. Other tiers probably don't need this. demotion
based on the selected tier should be enough.
Thanks,
Youngjun Park
^ permalink raw reply
* Re: [RFC PATCH 1/3] mm/numa: add exclusive node pool and numa=standby boot parameter
From: Mike Rapoport @ 2026-06-14 9:08 UTC (permalink / raw)
To: Gregory Price
Cc: linux-mm, x86, linux-doc, linux-kernel, linux-acpi, driver-core,
kernel-team, corbet, skhan, dave.hansen, luto, peterz, tglx,
mingo, bp, hpa, rafael, lenb, gregkh, dakr, akpm, rdunlap,
feng.tang, dapeng1.mi, elver, kuba, ebiggers, lirongqing, paulmck,
dave.jiang, jic23, xueshuai, kai.huang
In-Reply-To: <airAUSrNjbSEwuti@gourry-fedora-PF4VCD3F>
On Thu, Jun 11, 2026 at 10:04:01AM -0400, Gregory Price wrote:
> On Thu, Jun 11, 2026 at 12:00:17PM +0300, Mike Rapoport wrote:
> > > 1) Can we do dynamic addition of nodes?
> > >
> > > Not Trivially
> > >
> > > Some services utilize num_possible_nodes() as a static value to
> > > calculate the amount of resources to use at runtime (bpf, md/raid5).
> > >
> > > Example: futex_init uses num_possible_nodes() as part of its
> > > hashsize calculation during __init.
> >
> > AFAIU, we don't add the additional nodes for generic hotplug memory but
> > rather for exclusive use of by drivers/applications that are aware of these
> > nodes.
>
> The intent is to use for "non-generic" hotplug (see the whole private
> node series [1]), which would eventually still use the hotplug mechanism
> just not for generic memory.
>
> [1] https://lore.kernel.org/linux-mm/20260222084842.1824063-1-gourry@gourry.net/
>
> > Wouldn't adding them to possible nodes actually skew the calculation of the
> > resources by the services utilizing num_possible_nodes()?
> >
> > With the futex_init() example, won't be hashsize scaled down two much
> > because we've added these special nodes to the possible mask?
> >
>
> The result is the same as BIOS reserving nodes with PXM entries that
> don't get used. The CXL ACPI Tables do this for CXL Fixed Memory
> Windows that may never be hotplugged.
Well, even without CXL there could be nodes that may never be hotplugged, I
suppose that with CXL the difference between available and possible
nodes can get much larger.
> So really i think you're pointing out that futex_init() here probably
> shouldn't be using num_possible_nodes?
I'd rather say that num_possible_nodes() with and without CXL (or other
differentiated memory) has different semantics.
Maybe we need to add a new primitive for possible differentiated nodes and
keep num_possible_nodes() to mean "number of possible nodes with normal
memory".
> ~Gregory
--
Sincerely yours,
Mike.
^ permalink raw reply
* [PATCH] kdoc: xforms_lists: handle DECLARE_PER_CPU() in kernel-doc
From: Randy Dunlap @ 2026-06-14 5:24 UTC (permalink / raw)
To: linux-doc
Cc: Randy Dunlap, Jonathan Corbet, Shuah Khan, Mauro Carvalho Chehab,
netfilter-devel
Add support for DECLARE_PER_CPU() as a var (variable) as used in
<linux/netfilter/x_tables.h>.
Warning: include/linux/netfilter/x_tables.h:345 function parameter 'seqcount_t' not described in 'DECLARE_PER_CPU'
Warning: include/linux/netfilter/x_tables.h:345 function parameter 'xt_recseq' not described in 'DECLARE_PER_CPU'
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
---
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Shuah Khan <skhan@linuxfoundation.org>
Cc: Mauro Carvalho Chehab <mchehab@kernel.org>
Cc: netfilter-devel@vger.kernel.org
tools/lib/python/kdoc/xforms_lists.py | 1 +
1 file changed, 1 insertion(+)
--- linext-2026-0610.orig/tools/lib/python/kdoc/xforms_lists.py
+++ linext-2026-0610/tools/lib/python/kdoc/xforms_lists.py
@@ -118,6 +118,7 @@ class CTransforms:
(CMatch("__guarded_by"), ""),
(CMatch("__pt_guarded_by"), ""),
(CMatch("LIST_HEAD"), r"struct list_head \1"),
+ (CMatch("DECLARE_PER_CPU"), r"\1 \2[PER_CPU]; }"),
(KernRe(r"(?://.*)$"), ""),
(KernRe(r"(?:/\*.*\*/)"), ""),
^ permalink raw reply
* Re: [PATCH] docs/zh_CN: fix CONFIG_CGROUP typo for CONFIG_CGROUPS
From: Dongliang Mu @ 2026-06-14 2:10 UTC (permalink / raw)
To: Ethan Nelson-Moore, Shuah Khan, linux-doc
Cc: Alex Shi, Yanteng Si, Jonathan Corbet
In-Reply-To: <20260613211300.86016-1-enelsonmoore@gmail.com>
On 6/14/26 5:12 AM, Ethan Nelson-Moore wrote:
> The Simplified Chinese translation of accounting/psi.rst
> contains a typo CONFIG_CGROUP for CONFIG_CGROUPS. Fix it.
>
> Signed-off-by: Ethan Nelson-Moore <enelsonmoore@gmail.com>
Reviewed-by: Dongliang Mu <dzm91@hust.edu.cn>
> ---
> Documentation/translations/zh_CN/accounting/psi.rst | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/translations/zh_CN/accounting/psi.rst b/Documentation/translations/zh_CN/accounting/psi.rst
> index a0ddb7bd257c..703bc81ff9be 100644
> --- a/Documentation/translations/zh_CN/accounting/psi.rst
> +++ b/Documentation/translations/zh_CN/accounting/psi.rst
> @@ -148,7 +148,7 @@ psi接口提供的均值即可。
> Cgroup2接口
> ===========
>
> -对于CONFIG_CGROUP=y及挂载了cgroup2文件系统的系统，能够获取cgroups内任务的psi。
> +对于CONFIG_CGROUPS=y及挂载了cgroup2文件系统的系统，能够获取cgroups内任务的psi。
> 此场景下cgroupfs挂载点的子目录包含cpu.pressure、memory.pressure、io.pressure文件，
> 内容格式与/proc/pressure/下的文件相同。
>
^ permalink raw reply
* Re: [PATCH v2] docs/zh_CN: fix CONFIG_CONPAT typo for CONFIG_COMPAT
From: Dongliang Mu @ 2026-06-14 2:08 UTC (permalink / raw)
To: Ethan Nelson-Moore, Shuah Khan, Kees Cook, linux-doc
Cc: Alex Shi, Yanteng Si, Jonathan Corbet
In-Reply-To: <20260613183737.11434-1-enelsonmoore@gmail.com>
On 6/14/26 2:37 AM, Ethan Nelson-Moore wrote:
> The Simplified Chinese translation of security/self-protection.rst
> contains a typo CONFIG_CONPAT for CONFIG_COMPAT. Fix it.
>
> Signed-off-by: Ethan Nelson-Moore <enelsonmoore@gmail.com>
Reviewed-by: Dongliang Mu <dzm91@hust.edu.cn>
> ---
> Changes in v2: remove unnecessary information from commit message
>
> Documentation/translations/zh_CN/security/self-protection.rst | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/translations/zh_CN/security/self-protection.rst b/Documentation/translations/zh_CN/security/self-protection.rst
> index 93de9cee5c1a..ad96bb4a4995 100644
> --- a/Documentation/translations/zh_CN/security/self-protection.rst
> +++ b/Documentation/translations/zh_CN/security/self-protection.rst
> @@ -97,7 +97,7 @@ ARCH_OPTIONAL_KERNEL_RWX时的默认设置。
> --------------------
>
> 对于64位系统，一种消除许多系统调用最简单的方法是构建时不启用
> -CONFIG_CONPAT。然而，这种情况通常不可行。
> +CONFIG_COMPAT。然而，这种情况通常不可行。
>
> “seccomp”系统为用户空间提供了一种可选功能，提供了一种减少可供
> 运行中进程使用内核入口点数量的方法。这限制了可以访问内核代码
^ permalink raw reply
* [PATCH v1] docs/ja_JP: translate submitting-patches.rst (sign-off)
From: Akiyoshi Kurita @ 2026-06-13 23:35 UTC (permalink / raw)
To: linux-doc; +Cc: linux-kernel, corbet, akiyks, Akiyoshi Kurita
Translate the "Include PATCH in the subject" and "Sign your work -
the Developer's Certificate of Origin" sections in
Documentation/translations/ja_JP/process/submitting-patches.rst.
Keep the wording close to the English text and wrap lines to match
the style used in the surrounding Japanese translation.
Signed-off-by: Akiyoshi Kurita <weibu@redadmin.org>
---
.../ja_JP/process/submitting-patches.rst | 70 +++++++++++++++++++
1 file changed, 70 insertions(+)
diff --git a/Documentation/translations/ja_JP/process/submitting-patches.rst b/Documentation/translations/ja_JP/process/submitting-patches.rst
index d31d469909e4..56494bac169c 100644
--- a/Documentation/translations/ja_JP/process/submitting-patches.rst
+++ b/Documentation/translations/ja_JP/process/submitting-patches.rst
@@ -402,3 +402,73 @@ ping したりする前に、少なくとも 1 週間は待ってください。
パッチまたはパッチシリーズの修正版を投稿する場合は、"RESEND" を
追加しないでください。"RESEND" は、前回の投稿から一切変更していない
パッチまたはパッチシリーズを再送する場合にのみ使います。
+
+
+件名に PATCH を含める
+----------------------
+
+Linus と linux-kernel には大量のメールが届くため、メールの件名の
+先頭に ``[PATCH]`` を付けるのが一般的な慣例です。これにより、
+Linus や他のカーネル開発者は、パッチを他のメール議論からより
+簡単に区別できるようになります。
+
+``git send-email`` は、これを自動的に行ってくれます。
+
+
+自分の作業に署名する - Developer's Certificate of Origin
+---------------------------------------------------------
+
+誰が何を行ったのかを追跡しやすくするため、特に、複数階層の
+メンテナを経由して、最終的にカーネル内のあるべき場所へたどり着く
+可能性があるパッチについて、メールでやり取りされるパッチに
+``sign-off`` 手続きを導入しています。
+
+``sign-off`` は、パッチ説明の末尾に置く単純な 1 行です。これは、
+あなたがそのパッチを書いたこと、またはオープンソースのパッチとして
+渡す権利を持っていることを証明するものです。ルールは非常に単純です。
+以下を証明できるなら:
+
+Developer's Certificate of Origin 1.1
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+このプロジェクトへ貢献することにより、私は以下を証明します:
+
+ (a) この貢献は、全部または一部を私が作成したものであり、
+ ファイルに示されているオープンソースライセンスの下で
+ 提出する権利を私が持っていること。または、
+
+ (b) この貢献は、私の知る限り、適切なオープンソース
+ ライセンスの下にある過去の成果物に基づくものであり、
+ そのライセンスの下で、その成果物を、全部または一部を
+ 私が作成した修正とともに、同じオープンソースライセンスの
+ 下で提出する権利を私が持っていること。ただし、
+ ファイルに示されているように、異なるライセンスでの提出が
+ 許可されている場合を除きます。または、
+
+ (c) この貢献は、(a)、(b)、または (c) を証明した別の人物から
+ 直接私に提供されたものであり、私はそれを変更していないこと。
+
+ (d) このプロジェクトと貢献が公開されること、ならびに、
+ 貢献の記録（私が提出したすべての個人情報、私の sign-off を
+ 含む）が無期限に維持され、このプロジェクトまたは関係する
+ オープンソースライセンスに従って再配布される可能性がある
+ ことを、私は理解し同意します。
+
+その場合は、次のような行を追加するだけです::
+
+ Signed-off-by: Random J Developer <random@developer.example.org>
+
+確認可能な身元情報を使ってください（残念ながら、匿名での貢献は
+受け付けられません）。これは ``git commit -s`` を使えば自動的に
+行われます。Revert パッチにも ``Signed-off-by`` を含めるべきです。
+``git revert -s`` はこれを自動的に行ってくれます。
+
+パッチ末尾に追加のタグを付ける人もいます。それらは今のところ単に
+無視されますが、社内手続きを示したり、sign-off に関する特別な
+詳細を示したりするために使うことはできます。
+
+作者の SoB に続くそれ以降の SoB (Signed-off-by:) は、パッチを
+取り扱い、次へ受け渡した人々によるものですが、その開発に関与した
+ことを意味しません。SoB の連鎖は、パッチがメンテナへ伝わり、
+最終的に Linus へ届くまでに実際にたどった **本当の** 経路を
+反映すべきです。先頭の SoB エントリは、単独の主たる作者を示します。
--
2.52.0
^ permalink raw reply related
* Re: [PATCH v2] docs/zh_CN: fix CONFIG_CONPAT typo for CONFIG_COMPAT
From: Zenghui Yu @ 2026-06-14 0:33 UTC (permalink / raw)
To: Ethan Nelson-Moore
Cc: Dongliang Mu, Shuah Khan, Kees Cook, linux-doc, Alex Shi,
Yanteng Si, Jonathan Corbet
In-Reply-To: <20260613183737.11434-1-enelsonmoore@gmail.com>
On 6/14/26 2:37 AM, Ethan Nelson-Moore wrote:
> The Simplified Chinese translation of security/self-protection.rst
> contains a typo CONFIG_CONPAT for CONFIG_COMPAT. Fix it.
>
> Signed-off-by: Ethan Nelson-Moore <enelsonmoore@gmail.com>
> ---
> Changes in v2: remove unnecessary information from commit message
>
> Documentation/translations/zh_CN/security/self-protection.rst | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/translations/zh_CN/security/self-protection.rst b/Documentation/translations/zh_CN/security/self-protection.rst
> index 93de9cee5c1a..ad96bb4a4995 100644
> --- a/Documentation/translations/zh_CN/security/self-protection.rst
> +++ b/Documentation/translations/zh_CN/security/self-protection.rst
> @@ -97,7 +97,7 @@ ARCH_OPTIONAL_KERNEL_RWX时的默认设置。
> --------------------
>
> 对于64位系统，一种消除许多系统调用最简单的方法是构建时不启用
> -CONFIG_CONPAT。然而，这种情况通常不可行。
> +CONFIG_COMPAT。然而，这种情况通常不可行。
>
> “seccomp”系统为用户空间提供了一种可选功能，提供了一种减少可供
> 运行中进程使用内核入口点数量的方法。这限制了可以访问内核代码
Reviewed-by: Zenghui Yu <zenghui.yu@linux.dev>
Thanks,
Zenghui
^ permalink raw reply
* Re: [PATCH v2 3/7] net: wwan: t9xx: Add control DMA interface
From: Jakub Kicinski @ 2026-06-14 0:30 UTC (permalink / raw)
To: Jack Wu via B4 Relay
Cc: jackbb_wu, Loic Poulain, Sergey Ryazanov, Johannes Berg,
Andrew Lunn, David S. Miller, Eric Dumazet, Paolo Abeni,
Wen-Zhi Huang, Shi-Wei Yeh, Minano Tseng, Matthias Brugger,
AngeloGioacchino Del Regno, Simon Horman, Jonathan Corbet,
Shuah Khan, linux-kernel, netdev, linux-arm-kernel,
linux-mediatek, linux-doc
In-Reply-To: <20260610-t9xx_driver_v1-v2-3-c65addf23b3f@compal.com>
On Wed, 10 Jun 2026 18:41:06 +0800 Jack Wu via B4 Relay wrote:
> From: Jack Wu <jackbb_wu@compal.com>
>
> Cross Layer Direct Memory Access(CLDMA) is the hardware
> interface used by the control plane and designated to
> translate data between the host and the device. It supports
> 8 hardware queues for the device AP and modem respectively.
Transient build warnings:
+../drivers/net/wwan/t9xx/pcie/mtk_pci_drv_m9xx.c:52:30: warning: symbol 'mtk_dev_cfg_0900' was not declared. Should it be static?
+../drivers/net/wwan/t9xx/pcie/mtk_ctrl_cfg_m9xx.c:19:22: warning: symbol 'mtk_ctrl_info_m9xx' was not declared. Should it be static?
+../drivers/net/wwan/t9xx/pcie/mtk_cldma_drv_m9xx.c:33:22: warning: symbol 'mtk_cldma_regs_m9xx' was not declared. Should it be static?
+../drivers/net/wwan/t9xx/pcie/mtk_cldma_drv_m9xx.c:166:22: warning: symbol 'cldma_drv_ops_m9xx' was not declared. Should it be static?
please also see all the AI code comments at:
https://sashiko.dev/#/patchset/20260610-t9xx_driver_v1-v2-3-c65addf23b3f@compal.com
--
pw-bot: cr
^ permalink raw reply
* [PATCH] docs: kbuild: remove ISDN references in Makefile examples
From: Ethan Nelson-Moore @ 2026-06-13 23:28 UTC (permalink / raw)
To: Shuah Khan, Chen Pei, Randy Dunlap, Jonathan Corbet,
Ethan Nelson-Moore, linux-kbuild, linux-doc
Cc: Nathan Chancellor, Nicolas Schier
Documentation/kbuild/makefiles.rst uses some extracts from now-removed
ISDN code as examples. While they are harmless, they appeared in my
checks for CONFIG_* symbols referenced but not defined in the kernel.
Replace them with generic examples.
Signed-off-by: Ethan Nelson-Moore <enelsonmoore@gmail.com>
---
Documentation/kbuild/makefiles.rst | 23 +++++++++--------------
1 file changed, 9 insertions(+), 14 deletions(-)
diff --git a/Documentation/kbuild/makefiles.rst b/Documentation/kbuild/makefiles.rst
index 24a4708d26e8..dfac8c9611f4 100644
--- a/Documentation/kbuild/makefiles.rst
+++ b/Documentation/kbuild/makefiles.rst
@@ -127,11 +127,8 @@ controllers are detected, and thus your disks are renumbered.
Example::
- #drivers/isdn/i4l/Makefile
- # Makefile for the kernel ISDN subsystem and device drivers.
- # Each configuration option enables a list of files.
- obj-$(CONFIG_ISDN_I4L) += isdn.o
- obj-$(CONFIG_ISDN_PPP_BSDCOMP) += isdn_bsdcomp.o
+ obj-$(CONFIG_FOO) += foo.o
+ obj-$(CONFIG_BAR) += bar.o
Loadable module goals - obj-m
-----------------------------
@@ -145,10 +142,9 @@ simply adds the file to $(obj-m).
Example::
- #drivers/isdn/i4l/Makefile
- obj-$(CONFIG_ISDN_PPP_BSDCOMP) += isdn_bsdcomp.o
+ obj-$(CONFIG_FOO) += foo.o
-Note: In this example $(CONFIG_ISDN_PPP_BSDCOMP) evaluates to "m"
+Note: In this example $(CONFIG_FOO) evaluates to "m".
If a kernel module is built from several source files, you specify
that you want to build a module in the same way as above; however,
@@ -158,13 +154,12 @@ variable.
Example::
- #drivers/isdn/i4l/Makefile
- obj-$(CONFIG_ISDN_I4L) += isdn.o
- isdn-y := isdn_net_lib.o isdn_v110.o isdn_common.o
+ obj-$(CONFIG_FOO) += foo.o
+ foo-y := foo_1.o foo_2.o foo_3.o
-In this example, the module name will be isdn.o. Kbuild will
-compile the objects listed in $(isdn-y) and then run
-``$(LD) -r`` on the list of these files to generate isdn.o.
+In this example, the module name will be foo.o. Kbuild will
+compile the objects listed in $(foo-y) and then run
+``$(LD) -r`` on the list of these files to generate foo.o.
Due to kbuild recognizing $(<module_name>-y) for composite objects,
you can use the value of a ``CONFIG_`` symbol to optionally include an
--
2.43.0
^ permalink raw reply related
* [PATCH v3] platform/x86: thinkpad_acpi: Add USB-C Security (USCS) support
From: Vishnu Sankar @ 2026-06-13 22:57 UTC (permalink / raw)
To: mpearson-lenovo, skhan, corbet, hmh, hansg, derekjohn.clark,
ilpo.jarvinen
Cc: linux-kernel, ibm-acpi-devel, linux-doc, platform-driver-x86,
vsankar, Vishnu Sankar
Newer ThinkPad systems expose a USB-C Security (Restricted Mode) feature.
When active, USB-C data connections are disabled while power delivery is
preserved. This is useful for kiosk and physically-secured deployments.
Hardware interface:
The HKEY device exposes a read-only ACPI method USCS():
Return value bit layout:
Bit 16 : Capability flag (1 = feature present on this SKU)
Bit 0 : Current state (0 = security OFF, 1 = security ON)
The sysfs attribute is read-only.
The Fn+U followed by Fn+S hotkey chord is the only way to toggle the
hardware state.
Hotkey:
Fn+U followed by Fn+S generates HKEY event 0x131e.
sysfs interface:
/sys/devices/platform/thinkpad_acpi/usb_c_security (read-only)
"enabled\n" -- data connections are currently blocked
"disabled\n" -- data connections are currently allowed
The attribute is hidden on SKUs where the USCS capability bit (bit 16)
is not set, so there is no ABI impact on unsupported hardware.
Suggested-by: Mark Pearson <mpearson-lenovo@squebb.ca>
Signed-off-by: Vishnu Sankar <vishnuocv@gmail.com>
---
Changes since v2:
- Move usbc_security_enabled out of tp_features bitfield to a bool
member of tp_features to avoid unsafe concurrent bitfield RMW;
usbc_security_supported remains a bitfield as it is init-only.
- Pass &tp_features.usbc_security_enabled directly to
usbc_security_query() removing the local bool intermediary
in both init and hotkey paths.
- Remove extra blank line before */ in block comment.
- Fix kerneldoc Returns: syntax and rewrite return value description
to match the int return type.
- Split ternary return into two separate if statements for clarity
Changes since v1:
- Use guard(mutex) from cleanup.h instead of manual mutex_lock/unlock
- Revert usbc_security_query() to return int (-EIO/-ENODEV/0) instead
of bool to avoid uninitialized *enabled bug on unsupported platforms
- Remove !! when assigning to bool in usbc_security_query()
- Remove dead tp_features.usbc_security_supported check in show()
since is_visible() already gates the attribute on unsupported SKUs
- Use str_enabled_disabled() from string_choices.h in show()
- Fix uninitialized *enabled bug in tpacpi_usbc_security_init() by
only assigning usbc_security_enabled after a successful query
---
.../admin-guide/laptops/thinkpad-acpi.rst | 24 ++++
drivers/platform/x86/lenovo/thinkpad_acpi.c | 116 ++++++++++++++++++
2 files changed, 140 insertions(+)
diff --git a/Documentation/admin-guide/laptops/thinkpad-acpi.rst b/Documentation/admin-guide/laptops/thinkpad-acpi.rst
index f874db31801d..db4588af0278 100644
--- a/Documentation/admin-guide/laptops/thinkpad-acpi.rst
+++ b/Documentation/admin-guide/laptops/thinkpad-acpi.rst
@@ -1543,6 +1543,30 @@ Values:
This setting can also be toggled via the Fn+doubletap hotkey.
+USB-C Security
+--------------
+
+sysfs: usb_c_security
+
+Reports the current state of the USB-C Security (Restricted Mode) feature
+on supported ThinkPad systems. When enabled, USB-C data connections are
+disabled while power delivery is preserved.
+
+The available command is::
+
+ cat /sys/devices/platform/thinkpad_acpi/usb_c_security
+
+Values:
+
+ * ``enabled`` - USB-C data connections are currently blocked
+ * ``disabled`` - USB-C data connections are currently allowed
+
+The attribute is read-only. The USB-C Security state can only be toggled
+via the Fn+U followed by Fn+S hotkey chord.
+
+The sysfs attribute is not created on platforms that do not support this
+feature.
+
Auxmac
------
diff --git a/drivers/platform/x86/lenovo/thinkpad_acpi.c b/drivers/platform/x86/lenovo/thinkpad_acpi.c
index e1cee42a1683..59b485a57ffe 100644
--- a/drivers/platform/x86/lenovo/thinkpad_acpi.c
+++ b/drivers/platform/x86/lenovo/thinkpad_acpi.c
@@ -38,6 +38,7 @@
#include <linux/backlight.h>
#include <linux/bitfield.h>
#include <linux/bitops.h>
+#include <linux/cleanup.h>
#include <linux/delay.h>
#include <linux/dmi.h>
#include <linux/freezer.h>
@@ -66,6 +67,7 @@
#include <linux/seq_file.h>
#include <linux/slab.h>
#include <linux/string.h>
+#include <linux/string_choices.h>
#include <linux/string_helpers.h>
#include <linux/sysfs.h>
#include <linux/types.h>
@@ -185,6 +187,7 @@ enum tpacpi_hkey_event_t {
TP_HKEY_EV_AMT_TOGGLE = 0x131a, /* Toggle AMT on/off */
TP_HKEY_EV_CAMERASHUTTER_TOGGLE = 0x131b, /* Toggle Camera Shutter */
TP_HKEY_EV_DOUBLETAP_TOGGLE = 0x131c, /* Toggle trackpoint doubletap on/off */
+ TP_HKEY_EV_USB_C_SECURITY = 0x131e, /* USB C Security (Fn+U, Fn+S) */
TP_HKEY_EV_PROFILE_TOGGLE = 0x131f, /* Toggle platform profile in 2024 systems */
TP_HKEY_EV_PROFILE_TOGGLE2 = 0x1401, /* Toggle platform profile in 2025 + systems */
@@ -373,6 +376,8 @@ static struct {
u32 has_adaptive_kbd:1;
u32 kbd_lang:1;
u32 trackpoint_doubletap_enable:1;
+ u32 usbc_security_supported:1;
+ bool usbc_security_enabled;
struct quirk_entry *quirks;
} tp_features;
@@ -11265,6 +11270,110 @@ static struct ibm_struct hwdd_driver_data = {
.name = "hwdd",
};
+/*************************************************************************
+ * USB-C Security subdriver
+ *
+ * HKEY.USCS(0) is a read-only ACPI method; its argument is ignored.
+ * It always returns:
+ * bit 16 - USB-C security capability present on this SKU or not
+ * bit 0 - USB-C Security state (enable or disable)
+ *
+ * Hotkey
+ * ------
+ * 0x131e (Fn+U, Fn+S): firmware toggles USBS before firing the event.
+ * The driver reads back the new state and notifies the sysfs attribute.
+ */
+
+/* USCS() return word bit layout */
+#define USCS_CAP_BIT BIT(16) /* capability: feature present on SKU */
+#define USCS_STATUS_BIT BIT(0) /* current security state */
+
+static DEFINE_MUTEX(usbc_security_mutex);
+
+/**
+ * usbc_security_query - read current USB-C security state via USCS()
+ * @enabled: out - true when security is ON (data connections blocked)
+ *
+ * Returns:
+ * 0 success, @enabled contains the current state
+ * -EIO ACPI evaluation failed
+ * -ENODEV capability bit absent; feature not present on this SKU*
+ */
+static int usbc_security_query(bool *enabled)
+{
+ int status;
+
+ guard(mutex)(&usbc_security_mutex);
+ if (!acpi_evalf(hkey_handle, &status, "USCS", "dd", 0))
+ return -EIO;
+
+ if (!(status & USCS_CAP_BIT)) {
+ pr_debug("USCS cap bit absent (raw=0x%x)\n", status);
+ return -ENODEV;
+ }
+
+ *enabled = status & USCS_STATUS_BIT;
+ return 0;
+}
+
+/* sysfs: /sys/devices/platform/thinkpad_acpi/usb_c_security ---------- */
+static ssize_t usb_c_security_show(struct device *dev,
+ struct device_attribute *attr,
+ char *buf)
+{
+ return sysfs_emit(buf, "%s\n",
+ str_enabled_disabled(tp_features.usbc_security_enabled));
+}
+
+static DEVICE_ATTR_RO(usb_c_security);
+
+static struct attribute *usbc_security_attributes[] = {
+ &dev_attr_usb_c_security.attr,
+ NULL,
+};
+
+static umode_t usbc_security_attr_is_visible(struct kobject *kobj,
+ struct attribute *attr, int n)
+{
+ return tp_features.usbc_security_supported ? attr->mode : 0;
+}
+
+static const struct attribute_group usbc_security_attr_group = {
+ .is_visible = usbc_security_attr_is_visible,
+ .attrs = usbc_security_attributes,
+};
+
+static int tpacpi_usbc_security_init(struct ibm_init_struct *iibm)
+{
+ int err;
+
+ err = usbc_security_query(&tp_features.usbc_security_enabled);
+ if (err == -ENODEV)
+ return 0;
+ if (err)
+ return err;
+
+ tp_features.usbc_security_supported = true;
+ return 0;
+}
+
+/* tpacpi_usbc_security_hotkey - handle Fn+U Fn+S hotkey (0x131e) */
+static bool tpacpi_usbc_security_hotkey(void)
+{
+ if (!tp_features.usbc_security_supported)
+ return false;
+
+ if (usbc_security_query(&tp_features.usbc_security_enabled))
+ return false;
+
+ sysfs_notify(&tpacpi_pdev->dev.kobj, NULL, "usb_c_security");
+ return true;
+}
+
+static struct ibm_struct usbc_security_driver_data = {
+ .name = "usbc_security",
+};
+
/* --------------------------------------------------------------------- */
static struct attribute *tpacpi_driver_attributes[] = {
@@ -11325,6 +11434,7 @@ static const struct attribute_group *tpacpi_groups[] = {
&dprc_attr_group,
&auxmac_attr_group,
&hwdd_attr_group,
+ &usbc_security_attr_group,
NULL,
};
@@ -11479,6 +11589,8 @@ static bool tpacpi_driver_event(const unsigned int hkey_event)
case TP_HKEY_EV_PROFILE_TOGGLE2:
platform_profile_cycle();
return true;
+ case TP_HKEY_EV_USB_C_SECURITY:
+ return tpacpi_usbc_security_hotkey();
}
return false;
@@ -11930,6 +12042,10 @@ static struct ibm_init_struct ibms_init[] __initdata = {
.init = tpacpi_hwdd_init,
.data = &hwdd_driver_data,
},
+ {
+ .init = tpacpi_usbc_security_init,
+ .data = &usbc_security_driver_data,
+ },
};
static int __init set_ibm_param(const char *val, const struct kernel_param *kp)
--
2.51.0
^ permalink raw reply related
* [PATCH] docs/mm: describe current criteria for enabling split page table lock for PTE tables
From: Ethan Nelson-Moore @ 2026-06-13 22:14 UTC (permalink / raw)
To: Lorenzo Stoakes, Liam R. Howlett, Vlastimil Babka, Mike Rapoport,
Suren Baghdasaryan, Michal Hocko, Shuah Khan, linux-mm, linux-doc
Cc: Ethan Nelson-Moore, Andrew Morton, David Hildenbrand,
Jonathan Corbet
The mm documentation regarding split page table lock for PTE tables
refers to the CONFIG_SPLIT_PTLOCK_CPUS config option, which was
superseded by CONFIG_SPLIT_PTE_PTLOCKS in commit 394290cba966 ("mm:
turn USE_SPLIT_PTE_PTLOCKS / USE_SPLIT_PTE_PTLOCKS into Kconfig
options"). Update the documentation to refer to the current option and
document the situations in which this feature is not supported.
Discovered while searching for CONFIG_* symbols referenced in the
kernel but not defined in any Kconfig file.
Signed-off-by: Ethan Nelson-Moore <enelsonmoore@gmail.com>
---
Documentation/mm/split_page_table_lock.rst | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/Documentation/mm/split_page_table_lock.rst b/Documentation/mm/split_page_table_lock.rst
index cc3cd46abd1b..c9d16024543b 100644
--- a/Documentation/mm/split_page_table_lock.rst
+++ b/Documentation/mm/split_page_table_lock.rst
@@ -37,9 +37,12 @@ There are helpers to lock/unlock a table and other accessor functions:
- pmd_lockptr()
returns pointer to PMD table lock;
-Split page table lock for PTE tables is enabled compile-time if
-CONFIG_SPLIT_PTLOCK_CPUS (usually 4) is less or equal to NR_CPUS.
-If split lock is disabled, all tables are guarded by mm->page_table_lock.
+Split page table lock for PTE tables is enabled compile-time (via
+CONFIG_SPLIT_PTE_PTLOCKS) if NR_CPUS is greater than or equal to 4 and an
+MMU is being used. However, it is not supported on ARM processors with
+virtually indexed, physically tagged caches, PA-RISC processors older than
+the PA-8000, or 32-bit SPARC processors. If split lock is disabled, all
+tables are guarded by mm->page_table_lock.
Split page table lock for PMD tables is enabled, if it's enabled for PTE
tables and the architecture supports it (see below).
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v3 net-next 1/1] dt-bindings: net: dsa: Convert lan9303.txt to yaml format
From: patchwork-bot+netdevbpf @ 2026-06-13 22:10 UTC (permalink / raw)
To: Frank Li
Cc: andrew, olteanv, davem, edumazet, kuba, pabeni, robh, krzk+dt,
conor+dt, horms, corbet, skhan, Frank.Li, netdev, devicetree,
linux-kernel, linux-doc, imx
In-Reply-To: <20260610150533.515914-1-Frank.Li@oss.nxp.com>
Hello:
This patch was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Wed, 10 Jun 2026 11:05:30 -0400 you wrote:
> From: Frank Li <Frank.Li@nxp.com>
>
> Convert lan9303.txt to yaml format to fix below CHECK_DTBS warnings:
> arch/arm/boot/dts/nxp/imx/imx53-kp-hsc.dtb: /soc/bus@50000000/i2c@53fec000/switch@a: failed to match any schema with compatible: ['smsc,lan9303-i2c']
>
> Additional changes:
> - rename switch-phy to switch in example.
>
> [...]
Here is the summary with links:
- [v3,net-next,1/1] dt-bindings: net: dsa: Convert lan9303.txt to yaml format
https://git.kernel.org/netdev/net-next/c/b693b51e0829
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* [PATCH] docs/zh_CN: fix CONFIG_CGROUP typo for CONFIG_CGROUPS
From: Ethan Nelson-Moore @ 2026-06-13 21:12 UTC (permalink / raw)
To: Dongliang Mu, Shuah Khan, GitAuthor: Ethan Nelson-Moore,
linux-doc
Cc: Alex Shi, Yanteng Si, Jonathan Corbet
The Simplified Chinese translation of accounting/psi.rst
contains a typo CONFIG_CGROUP for CONFIG_CGROUPS. Fix it.
Signed-off-by: Ethan Nelson-Moore <enelsonmoore@gmail.com>
---
Documentation/translations/zh_CN/accounting/psi.rst | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/translations/zh_CN/accounting/psi.rst b/Documentation/translations/zh_CN/accounting/psi.rst
index a0ddb7bd257c..703bc81ff9be 100644
--- a/Documentation/translations/zh_CN/accounting/psi.rst
+++ b/Documentation/translations/zh_CN/accounting/psi.rst
@@ -148,7 +148,7 @@ psi接口提供的均值即可。
Cgroup2接口
===========
-对于CONFIG_CGROUP=y及挂载了cgroup2文件系统的系统，能够获取cgroups内任务的psi。
+对于CONFIG_CGROUPS=y及挂载了cgroup2文件系统的系统，能够获取cgroups内任务的psi。
此场景下cgroupfs挂载点的子目录包含cpu.pressure、memory.pressure、io.pressure文件，
内容格式与/proc/pressure/下的文件相同。
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v5] PM: QoS: Introduce boot parameter pm_qos_resume_latency_us
From: Aaron Tomlin @ 2026-06-13 20:33 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: gregkh, dakr, pavel, lenb, zhongqiu.han, akpm, bp, pmladek,
rdunlap, feng.tang, pawan.kumar.gupta, kees, elver, arnd, fvdl,
lirongqing, bhelgaas, neelx, sean, mproche, chjohnst, nick.lange,
linux-kernel, linux-pm, linux-doc
In-Reply-To: <3uztb63u72mniljqb2cd4q7cbma2hvns27gn2j2xfm4q4ouuu6@zqyc2wjt55rp>
[-- Attachment #1: Type: text/plain, Size: 2122 bytes --]
On Tue, Jun 02, 2026 at 09:03:28PM -0400, Aaron Tomlin wrote:
> Hi Rafael,
>
> Thank you for your review and the constructive feedback.
>
> I certainly appreciate your reasoning concerning the naming convention and
> its current CPU-specific scope.
>
> However, before I prepare the next iteration, I thought it prudent to
> briefly outline my original architectural reasoning for housing it within
> the generic PM QoS code, simply to ascertain whether you remain of the view
> that cpuidle is the most appropriate home.
>
> My primary motivation for retaining it within the generic PM QoS framework
> was to maintain strict symmetry with the existing sysfs interface.
>
> The parameter is designed to align precisely with
> /sys/devices/system/cpu/cpuN/power/pm_qos_resume_latency_us. That sysfs
> attribute is exposed and managed by the generic device PM QoS code, quite
> independently of cpuidle. Furthermore, the boot constraint itself is
> applied via dev_pm_qos_expose_latency_limit(&cpu->dev, ...), which is
> fundamentally a core QoS API.
>
> Should we move the boot parameter parsing into cpuidle, the consequence is
> that the cpuidle subsystem becomes responsible for parsing a boot string,
> only to immediately pass that data back into the generic PM QoS framework
> during CPU registration. Keeping the implementation within qos.c ensures
> that the parsing logic and the underlying data structures remain cohesively
> in the same subsystem. Crucially, it also preserves the flexibility to
> extend this syntax to non-CPU devices in the future without necessitating
> further refactoring.
>
> I look forward to hearing your preference.
Hi Rafael,
I am writing to politely enquire whether you have had an opportunity to
consider my reasoning concerning the generic PM QoS framework.
There is absolutely no urgency on my part; however, I am standing by to
rebase and prepare v6 as soon as we reach a consensus on the most
appropriate home for the parsing logic. Please do let me know how you would
prefer to proceed.
Kind regards,
--
Aaron Tomlin
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* [PATCH v2] docs/zh_CN: fix CONFIG_CONPAT typo for CONFIG_COMPAT
From: Ethan Nelson-Moore @ 2026-06-13 18:37 UTC (permalink / raw)
To: Dongliang Mu, Shuah Khan, Kees Cook, Ethan Nelson-Moore,
linux-doc
Cc: Alex Shi, Yanteng Si, Jonathan Corbet
The Simplified Chinese translation of security/self-protection.rst
contains a typo CONFIG_CONPAT for CONFIG_COMPAT. Fix it.
Signed-off-by: Ethan Nelson-Moore <enelsonmoore@gmail.com>
---
Changes in v2: remove unnecessary information from commit message
Documentation/translations/zh_CN/security/self-protection.rst | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/translations/zh_CN/security/self-protection.rst b/Documentation/translations/zh_CN/security/self-protection.rst
index 93de9cee5c1a..ad96bb4a4995 100644
--- a/Documentation/translations/zh_CN/security/self-protection.rst
+++ b/Documentation/translations/zh_CN/security/self-protection.rst
@@ -97,7 +97,7 @@ ARCH_OPTIONAL_KERNEL_RWX时的默认设置。
--------------------
对于64位系统，一种消除许多系统调用最简单的方法是构建时不启用
-CONFIG_CONPAT。然而，这种情况通常不可行。
+CONFIG_COMPAT。然而，这种情况通常不可行。
“seccomp”系统为用户空间提供了一种可选功能，提供了一种减少可供
运行中进程使用内核入口点数量的方法。这限制了可以访问内核代码
--
2.43.0
^ permalink raw reply related
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