* Re: [PATCH v5 02/22] liveupdate: luo_core: integrate with KHO
From: Mike Rapoport @ 2025-11-13 16:31 UTC (permalink / raw)
To: Pasha Tatashin
Cc: pratyush, jasonmiu, graf, dmatlack, rientjes, corbet, rdunlap,
ilpo.jarvinen, kanie, ojeda, aliceryhl, masahiroy, akpm, tj,
yoann.congal, mmaurer, roman.gushchin, chenridong, axboe,
mark.rutland, jannh, vincent.guittot, hannes, dan.j.williams,
david, joel.granados, rostedt, anna.schumaker, song, zhangguopeng,
linux, linux-kernel, linux-doc, linux-mm, gregkh, tglx, mingo, bp,
dave.hansen, x86, hpa, rafael, dakr, bartosz.golaszewski,
cw00.choi, myungjoo.ham, yesanishhere, Jonathan.Cameron,
quic_zijuhu, aleksander.lobakin, ira.weiny, andriy.shevchenko,
leon, lukas, bhelgaas, wagi, djeffery, stuart.w.hayes, ptyadav,
lennart, brauner, linux-api, linux-fsdevel, saeedm, ajayachandra,
jgg, parav, leonro, witu, hughd, skhawaja, chrisl
In-Reply-To: <CA+CK2bAq-0Vz4jSRWnb_ut9AqG3RcH67JQj76GhoH0BaspWs2A@mail.gmail.com>
On Wed, Nov 12, 2025 at 09:58:27AM -0500, Pasha Tatashin wrote:
> On Wed, Nov 12, 2025 at 8:25 AM Mike Rapoport <rppt@kernel.org> wrote:
> >
> > Hi Pasha,
> >
> > On Tue, Nov 11, 2025 at 03:57:39PM -0500, Pasha Tatashin wrote:
> > > Hi Mike,
> > >
> > > Thank you for review, my comments below:
> > >
> > > > > This is why this call is placed first in reboot(), before any
> > > > > irreversible reboot notifiers or shutdown callbacks are performed. If
> > > > > an allocation problem occurs in KHO, the error is simply reported back
> > > > > to userspace, and the live update update is safely aborted.
> >
> > The call to liveupdate_reboot() is just before kernel_kexec(). Why we don't
> > move it there?
>
> Yes, I can move that call into kernel_kexec().
>
> > And all the liveupdate_reboot() does if kho_finalize() fails it's massaging
> > the error value before returning it to userspace. Why kernel_kexec() can't
> > do the same?
>
> We could do that. It would look something like this:
>
> if (liveupdate_enabled())
> kho_finalize();
>
> Because we want to do kho_finalize() from kernel_kexec only when we do
> live update.
>
> > > > This is fine. But what I don't like is that we can't use kho without
> > > > liveupdate. We are making debugfs optional, we have a way to call
>
> This is exactly the fix I proposed:
>
> 1. When live-update is enabled, always disable "finalize" debugfs API.
> 2. When live-update is disabled, always enable "finalize" debugfs API.
I don't mind the concept, what I do mind is sprinkling liveupdate_enabled()
in KHO.
How about we kill debugfs/kho/out/abort and make kho_finalize() overwrite
an existing FDT if there was any?
Abort was required to allow rollback for subsystems that had kho notifiers,
but now notifiers are gone and kho_abort() only frees the memory
serialization data. I don't see an issue with kho_finalize() from debugfs
being a tad slower because of a call to kho_abort() and the liveupdate path
anyway won't incur that penalty.
> > KHO should not call into liveupdate. That's layering violation.
> > And "stateless KHO" does not really make it stateless, it only removes the
> > memory serialization from kho_finalize(), but it's still required to pack
> > the FDT.
>
> This touches on a point I've raised in the KHO sync meetings: to be
> effective, the "stateless KHO" work must also make subtree add/remove
> stateless. There should not be a separate "finalize" state just to
> finish the FDT. The KHO FDT is tiny (only one page), and there are
> only a handful of subtrees. Adding and removing subtrees is cheap; we
> should be able to open FDT, modify it, and finish FDT on every
> operation. There's no need for a special finalization state at kexec
> time. KHO should be totally stateless.
And as the first step we can drop 'if (!kho_out.finalized)' from
kho_fill_kimage(). We might need to massage the check for valid FDT in
kho_populate() to avoid unnecessary noise, but largely there's no issue
with always passing KHO data in kimage.
> Thanks,
> Pasha
--
Sincerely yours,
Mike.
^ permalink raw reply
* Re: [PATCH RFC 4/4] arm64/io: Add {__raw_read|__raw_write}128 support
From: huangchenghai @ 2025-11-13 14:19 UTC (permalink / raw)
To: Mark Rutland
Cc: arnd, catalin.marinas, will, akpm, anshuman.khandual,
ryan.roberts, andriy.shevchenko, herbert, linux-kernel,
linux-arch, linux-arm-kernel, linux-crypto, linux-api, fanghao11,
shenyang39, liulongfang, qianweili
In-Reply-To: <aRR9UesvUCFLdVoW@J2N7QTR9R3>
在 2025/11/12 20:28, Mark Rutland 写道:
> On Wed, Nov 12, 2025 at 09:58:46AM +0800, Chenghai Huang wrote:
>> From: Weili Qian <qianweili@huawei.com>
>>
>> Starting from ARMv8.4, stp and ldp instructions become atomic.
> That's not true for accesses to Device memory types.
>
> Per ARM DDI 0487, L.b, section B2.2.1.1 ("Changes to single-copy atomicity in
> Armv8.4"):
>
> If FEAT_LSE2 is implemented, LDP, LDNP, and STP instructions that load
> or store two 64-bit registers are single-copy atomic when all of the
> following conditions are true:
> • The overall memory access is aligned to 16 bytes.
> • Accesses are to Inner Write-Back, Outer Write-Back Normal cacheable memory.
>
> IIUC when used for Device memory types, those can be split, and a part
> of the access could be replayed multiple times (e.g. due to an
> intetrupt).
>
> I don't think we can add this generally. It is not atomic, and not
> generally safe.
>
> Mark.
Thanks for your correction. I misunderstood the behavior of LDP and
STP instructions. So, regarding device memory types, LDP and STP
instructions do not guarantee single-copy atomicity.
For devices that require 128-bit atomic access, is it only possible
to implement this functionality in the driver?
Chenghai
>
>> Currently, device drivers depend on 128-bit atomic memory IO access,
>> but these are implemented within the drivers. Therefore, this introduces
>> generic {__raw_read|__raw_write}128 function for 128-bit memory access.
>>
>> Signed-off-by: Weili Qian <qianweili@huawei.com>
>> Signed-off-by: Chenghai Huang <huangchenghai2@huawei.com>
>> ---
>> arch/arm64/include/asm/io.h | 21 +++++++++++++++++++++
>> 1 file changed, 21 insertions(+)
>>
>> diff --git a/arch/arm64/include/asm/io.h b/arch/arm64/include/asm/io.h
>> index 83e03abbb2ca..80430750a28c 100644
>> --- a/arch/arm64/include/asm/io.h
>> +++ b/arch/arm64/include/asm/io.h
>> @@ -50,6 +50,17 @@ static __always_inline void __raw_writeq(u64 val, volatile void __iomem *addr)
>> asm volatile("str %x0, %1" : : "rZ" (val), "Qo" (*ptr));
>> }
>>
>> +#define __raw_write128 __raw_write128
>> +static __always_inline void __raw_write128(u128 val, volatile void __iomem *addr)
>> +{
>> + u64 low, high;
>> +
>> + low = val;
>> + high = (u64)(val >> 64);
>> +
>> + asm volatile ("stp %x0, %x1, [%2]\n" :: "rZ"(low), "rZ"(high), "r"(addr));
>> +}
>> +
>> #define __raw_readb __raw_readb
>> static __always_inline u8 __raw_readb(const volatile void __iomem *addr)
>> {
>> @@ -95,6 +106,16 @@ static __always_inline u64 __raw_readq(const volatile void __iomem *addr)
>> return val;
>> }
>>
>> +#define __raw_read128 __raw_read128
>> +static __always_inline u128 __raw_read128(const volatile void __iomem *addr)
>> +{
>> + u64 high, low;
>> +
>> + asm volatile("ldp %0, %1, [%2]" : "=r" (low), "=r" (high) : "r" (addr));
>> +
>> + return (((u128)high << 64) | (u128)low);
>> +}
>> +
>> /* IO barriers */
>> #define __io_ar(v) \
>> ({ \
>> --
>> 2.33.0
>>
>>
^ permalink raw reply
* Re: [PATCH v5 01/22] liveupdate: luo_core: luo_ioctl: Live Update Orchestrator
From: Pasha Tatashin @ 2025-11-13 13:56 UTC (permalink / raw)
To: Mike Rapoport
Cc: pratyush, jasonmiu, graf, dmatlack, rientjes, corbet, rdunlap,
ilpo.jarvinen, kanie, ojeda, aliceryhl, masahiroy, akpm, tj,
yoann.congal, mmaurer, roman.gushchin, chenridong, axboe,
mark.rutland, jannh, vincent.guittot, hannes, dan.j.williams,
david, joel.granados, rostedt, anna.schumaker, song, zhangguopeng,
linux, linux-kernel, linux-doc, linux-mm, gregkh, tglx, mingo, bp,
dave.hansen, x86, hpa, rafael, dakr, bartosz.golaszewski,
cw00.choi, myungjoo.ham, yesanishhere, Jonathan.Cameron,
quic_zijuhu, aleksander.lobakin, ira.weiny, andriy.shevchenko,
leon, lukas, bhelgaas, wagi, djeffery, stuart.w.hayes, ptyadav,
lennart, brauner, linux-api, linux-fsdevel, saeedm, ajayachandra,
jgg, parav, leonro, witu, hughd, skhawaja, chrisl
In-Reply-To: <aRXfKPfoi96B68Ef@kernel.org>
> > +/**
> > + * DOC: General ioctl format
> > + *
>
> It seems it's not linked from Documentation/.../liveupdate.rst
It is linked:
Here is uAPI: https://docs.kernel.org/next/userspace-api/liveupdate.html
And also from the main Doc:
https://docs.kernel.org/next/core-api/liveupdate.html
There is a link in "Sea Also" section: Live Update uAPI
> > + * The ioctl interface follows a general format to allow for extensibility. Each
> > + * ioctl is passed in a structure pointer as the argument providing the size of
> > + * the structure in the first u32. The kernel checks that any structure space
> > + * beyond what it understands is 0. This allows userspace to use the backward
> > + * compatible portion while consistently using the newer, larger, structures.
> > + *
> > + * ioctls use a standard meaning for common errnos:
> > + *
> > + * - ENOTTY: The IOCTL number itself is not supported at all
> > + * - E2BIG: The IOCTL number is supported, but the provided structure has
> > + * non-zero in a part the kernel does not understand.
> > + * - EOPNOTSUPP: The IOCTL number is supported, and the structure is
> > + * understood, however a known field has a value the kernel does not
> > + * understand or support.
> > + * - EINVAL: Everything about the IOCTL was understood, but a field is not
> > + * correct.
> > + * - ENOENT: A provided token does not exist.
> > + * - ENOMEM: Out of memory.
> > + * - EOVERFLOW: Mathematics overflowed.
> > + *
> > + * As well as additional errnos, within specific ioctls.
>
> ...
>
> > --- a/kernel/liveupdate/Kconfig
> > +++ b/kernel/liveupdate/Kconfig
> > @@ -1,7 +1,34 @@
> > # SPDX-License-Identifier: GPL-2.0-only
> > +#
> > +# Copyright (c) 2025, Google LLC.
> > +# Pasha Tatashin <pasha.tatashin@soleen.com>
> > +#
> > +# Live Update Orchestrator
> > +#
> >
> > menu "Live Update and Kexec HandOver"
> >
> > +config LIVEUPDATE
> > + bool "Live Update Orchestrator"
> > + depends on KEXEC_HANDOVER
> > + help
> > + Enable the Live Update Orchestrator. Live Update is a mechanism,
> > + typically based on kexec, that allows the kernel to be updated
> > + while keeping selected devices operational across the transition.
> > + These devices are intended to be reclaimed by the new kernel and
> > + re-attached to their original workload without requiring a device
> > + reset.
> > +
> > + Ability to handover a device from current to the next kernel depends
> > + on specific support within device drivers and related kernel
> > + subsystems.
> > +
> > + This feature primarily targets virtual machine hosts to quickly update
> > + the kernel hypervisor with minimal disruption to the running virtual
> > + machines.
> > +
> > + If unsure, say N.
> > +
>
> Not a big deal, but since LIVEUPDATE depends on KEXEC_HANDOVER, shouldn't
> it go after KEXEC_HANDOVER?
Sure, I'll move them to the end of the file.
Thanks,
Pasha
^ permalink raw reply
* Re: [PATCH v5 01/22] liveupdate: luo_core: luo_ioctl: Live Update Orchestrator
From: Mike Rapoport @ 2025-11-13 13:37 UTC (permalink / raw)
To: Pasha Tatashin
Cc: pratyush, jasonmiu, graf, dmatlack, rientjes, corbet, rdunlap,
ilpo.jarvinen, kanie, ojeda, aliceryhl, masahiroy, akpm, tj,
yoann.congal, mmaurer, roman.gushchin, chenridong, axboe,
mark.rutland, jannh, vincent.guittot, hannes, dan.j.williams,
david, joel.granados, rostedt, anna.schumaker, song, zhangguopeng,
linux, linux-kernel, linux-doc, linux-mm, gregkh, tglx, mingo, bp,
dave.hansen, x86, hpa, rafael, dakr, bartosz.golaszewski,
cw00.choi, myungjoo.ham, yesanishhere, Jonathan.Cameron,
quic_zijuhu, aleksander.lobakin, ira.weiny, andriy.shevchenko,
leon, lukas, bhelgaas, wagi, djeffery, stuart.w.hayes, ptyadav,
lennart, brauner, linux-api, linux-fsdevel, saeedm, ajayachandra,
jgg, parav, leonro, witu, hughd, skhawaja, chrisl
In-Reply-To: <20251107210526.257742-2-pasha.tatashin@soleen.com>
On Fri, Nov 07, 2025 at 04:02:59PM -0500, Pasha Tatashin wrote:
> Introduce LUO, a mechanism intended to facilitate kernel updates while
> keeping designated devices operational across the transition (e.g., via
> kexec). The primary use case is updating hypervisors with minimal
> disruption to running virtual machines. For userspace side of hypervisor
> update we have copyless migration. LUO is for updating the kernel.
>
> This initial patch lays the groundwork for the LUO subsystem.
>
> Further functionality, including the implementation of state transition
> logic, integration with KHO, and hooks for subsystems and file
> descriptors, will be added in subsequent patches.
>
> Create a character device at /dev/liveupdate.
>
> A new uAPI header, <uapi/linux/liveupdate.h>, will define the necessary
> structures. The magic number for IOCTL is registered in
> Documentation/userspace-api/ioctl/ioctl-number.rst.
>
> Signed-off-by: Pasha Tatashin <pasha.tatashin@soleen.com>
> ---
...
> @@ -0,0 +1,46 @@
> +/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
> +
> +/*
> + * Userspace interface for /dev/liveupdate
> + * Live Update Orchestrator
> + *
> + * Copyright (c) 2025, Google LLC.
> + * Pasha Tatashin <pasha.tatashin@soleen.com>
> + */
> +
> +#ifndef _UAPI_LIVEUPDATE_H
> +#define _UAPI_LIVEUPDATE_H
> +
> +#include <linux/ioctl.h>
> +#include <linux/types.h>
> +
> +/**
> + * DOC: General ioctl format
> + *
It seems it's not linked from Documentation/.../liveupdate.rst
> + * The ioctl interface follows a general format to allow for extensibility. Each
> + * ioctl is passed in a structure pointer as the argument providing the size of
> + * the structure in the first u32. The kernel checks that any structure space
> + * beyond what it understands is 0. This allows userspace to use the backward
> + * compatible portion while consistently using the newer, larger, structures.
> + *
> + * ioctls use a standard meaning for common errnos:
> + *
> + * - ENOTTY: The IOCTL number itself is not supported at all
> + * - E2BIG: The IOCTL number is supported, but the provided structure has
> + * non-zero in a part the kernel does not understand.
> + * - EOPNOTSUPP: The IOCTL number is supported, and the structure is
> + * understood, however a known field has a value the kernel does not
> + * understand or support.
> + * - EINVAL: Everything about the IOCTL was understood, but a field is not
> + * correct.
> + * - ENOENT: A provided token does not exist.
> + * - ENOMEM: Out of memory.
> + * - EOVERFLOW: Mathematics overflowed.
> + *
> + * As well as additional errnos, within specific ioctls.
...
> --- a/kernel/liveupdate/Kconfig
> +++ b/kernel/liveupdate/Kconfig
> @@ -1,7 +1,34 @@
> # SPDX-License-Identifier: GPL-2.0-only
> +#
> +# Copyright (c) 2025, Google LLC.
> +# Pasha Tatashin <pasha.tatashin@soleen.com>
> +#
> +# Live Update Orchestrator
> +#
>
> menu "Live Update and Kexec HandOver"
>
> +config LIVEUPDATE
> + bool "Live Update Orchestrator"
> + depends on KEXEC_HANDOVER
> + help
> + Enable the Live Update Orchestrator. Live Update is a mechanism,
> + typically based on kexec, that allows the kernel to be updated
> + while keeping selected devices operational across the transition.
> + These devices are intended to be reclaimed by the new kernel and
> + re-attached to their original workload without requiring a device
> + reset.
> +
> + Ability to handover a device from current to the next kernel depends
> + on specific support within device drivers and related kernel
> + subsystems.
> +
> + This feature primarily targets virtual machine hosts to quickly update
> + the kernel hypervisor with minimal disruption to the running virtual
> + machines.
> +
> + If unsure, say N.
> +
Not a big deal, but since LIVEUPDATE depends on KEXEC_HANDOVER, shouldn't
it go after KEXEC_HANDOVER?
> config KEXEC_HANDOVER
> bool "kexec handover"
> depends on ARCH_SUPPORTS_KEXEC_HANDOVER && ARCH_SUPPORTS_KEXEC_FILE
--
Sincerely yours,
Mike.
^ permalink raw reply
* Re: [PATCH RFC 3/4] io-128-nonatomic: introduce io{read|write}128_{lo_hi|hi_lo}
From: huangchenghai @ 2025-11-13 11:10 UTC (permalink / raw)
To: Ben Dooks, arnd, catalin.marinas, will, akpm, anshuman.khandual,
ryan.roberts, andriy.shevchenko, herbert, linux-kernel,
linux-arch, linux-arm-kernel, linux-crypto, linux-api
Cc: fanghao11, shenyang39, liulongfang, qianweili
In-Reply-To: <59f8bc30-c1c6-4f07-87dd-cd2893ae87f7@codethink.co.uk>
在 2025/11/12 22:48, Ben Dooks 写道:
> On 12/11/2025 01:58, Chenghai Huang wrote:
>> From: Weili Qian <qianweili@huawei.com>
>>
>> In order to provide non-atomic functions for io{read|write}128.
>> We define a number of variants of these functions in the generic
>> iomap that will do non-atomic operations.
>>
>> These functions are only defined if io{read|write}128 are defined.
>> If they are not, then the wrappers that always use non-atomic operations
>> from include/linux/io-128-nonatomic*.h will be used.
>>
>> Signed-off-by: Weili Qian <qianweili@huawei.com>
>> Signed-off-by: Chenghai Huang <huangchenghai2@huawei.com>
>> ---
>> include/linux/io-128-nonatomic-hi-lo.h | 35 ++++++++++++++++++++++++++
>> include/linux/io-128-nonatomic-lo-hi.h | 34 +++++++++++++++++++++++++
>> 2 files changed, 69 insertions(+)
>> create mode 100644 include/linux/io-128-nonatomic-hi-lo.h
>> create mode 100644 include/linux/io-128-nonatomic-lo-hi.h
>>
>> diff --git a/include/linux/io-128-nonatomic-hi-lo.h
>> b/include/linux/io-128-nonatomic-hi-lo.h
>> new file mode 100644
>> index 000000000000..b5b083a9e81b
>> --- /dev/null
>> +++ b/include/linux/io-128-nonatomic-hi-lo.h
>> @@ -0,0 +1,35 @@
>> +/* SPDX-License-Identifier: GPL-2.0 */
>> +#ifndef _LINUX_IO_128_NONATOMIC_HI_LO_H_
>> +#define _LINUX_IO_128_NONATOMIC_HI_LO_H_
>> +
>> +#include <linux/io.h>
>> +#include <asm-generic/int-ll64.h>
>> +
>> +static inline u128 ioread128_hi_lo(const void __iomem *addr)
>> +{
>> + u32 low, high;
>
> did you mean u64 here?
>
Thank you for your reminder, I made a rookie mistake.
Chenghai
>> + high = ioread64(addr + sizeof(u64));
>> + low = ioread64(addr);
>> +
>> + return low + ((u128)high << 64);
>> +}
>> +
>> +static inline void iowrite128_hi_lo(u128 val, void __iomem *addr)
>> +{
>> + iowrite64(val >> 64, addr + sizeof(u64));
>> + iowrite64(val, addr);
>> +}
>> +
>
^ permalink raw reply
* Re: [PATCH v5 06/22] liveupdate: luo_session: add sessions support
From: Pasha Tatashin @ 2025-11-12 20:47 UTC (permalink / raw)
To: Mike Rapoport
Cc: pratyush, jasonmiu, graf, dmatlack, rientjes, corbet, rdunlap,
ilpo.jarvinen, kanie, ojeda, aliceryhl, masahiroy, akpm, tj,
yoann.congal, mmaurer, roman.gushchin, chenridong, axboe,
mark.rutland, jannh, vincent.guittot, hannes, dan.j.williams,
david, joel.granados, rostedt, anna.schumaker, song, zhangguopeng,
linux, linux-kernel, linux-doc, linux-mm, gregkh, tglx, mingo, bp,
dave.hansen, x86, hpa, rafael, dakr, bartosz.golaszewski,
cw00.choi, myungjoo.ham, yesanishhere, Jonathan.Cameron,
quic_zijuhu, aleksander.lobakin, ira.weiny, andriy.shevchenko,
leon, lukas, bhelgaas, wagi, djeffery, stuart.w.hayes, ptyadav,
lennart, brauner, linux-api, linux-fsdevel, saeedm, ajayachandra,
jgg, parav, leonro, witu, hughd, skhawaja, chrisl
In-Reply-To: <aRTwZNKFvDqb1NG5@kernel.org>
On Wed, Nov 12, 2025 at 3:39 PM Mike Rapoport <rppt@kernel.org> wrote:
>
> On Fri, Nov 07, 2025 at 04:03:04PM -0500, Pasha Tatashin wrote:
> > Introduce concept of "Live Update Sessions" within the LUO framework.
> > LUO sessions provide a mechanism to group and manage `struct file *`
> > instances (representing file descriptors) that need to be preserved
> > across a kexec-based live update.
> >
> > Each session is identified by a unique name and acts as a container
> > for file objects whose state is critical to a userspace workload, such
> > as a virtual machine or a high-performance database, aiming to maintain
> > their functionality across a kernel transition.
> >
> > This groundwork establishes the framework for preserving file-backed
> > state across kernel updates, with the actual file data preservation
> > mechanisms to be implemented in subsequent patches.
> >
> > Signed-off-by: Pasha Tatashin <pasha.tatashin@soleen.com>
> > ---
> > include/linux/liveupdate/abi/luo.h | 81 ++++++
> > include/uapi/linux/liveupdate.h | 3 +
> > kernel/liveupdate/Makefile | 3 +-
> > kernel/liveupdate/luo_core.c | 9 +
> > kernel/liveupdate/luo_internal.h | 39 +++
> > kernel/liveupdate/luo_session.c | 405 +++++++++++++++++++++++++++++
> > 6 files changed, 539 insertions(+), 1 deletion(-)
> > create mode 100644 kernel/liveupdate/luo_session.c
> >
> > diff --git a/include/linux/liveupdate/abi/luo.h b/include/linux/liveupdate/abi/luo.h
> > index 9483a294287f..37b9fecef3f7 100644
> > --- a/include/linux/liveupdate/abi/luo.h
> > +++ b/include/linux/liveupdate/abi/luo.h
> > @@ -28,6 +28,11 @@
> > * / {
> > * compatible = "luo-v1";
> > * liveupdate-number = <...>;
> > + *
> > + * luo-session {
> > + * compatible = "luo-session-v1";
> > + * luo-session-head = <phys_addr_of_session_head_ser>;
>
> 'head' reads to me as list head rather than a header. I'd use 'hdr' for the
> latter.
Or just use the full name: "header" ? It is not too long as well.
Pasha
>
> --
> Sincerely yours,
> Mike.
^ permalink raw reply
* Re: [PATCH v5 22/22] tests/liveupdate: Add in-kernel liveupdate test
From: Pasha Tatashin @ 2025-11-12 20:40 UTC (permalink / raw)
To: Mike Rapoport
Cc: pratyush, jasonmiu, graf, dmatlack, rientjes, corbet, rdunlap,
ilpo.jarvinen, kanie, ojeda, aliceryhl, masahiroy, akpm, tj,
yoann.congal, mmaurer, roman.gushchin, chenridong, axboe,
mark.rutland, jannh, vincent.guittot, hannes, dan.j.williams,
david, joel.granados, rostedt, anna.schumaker, song, zhangguopeng,
linux, linux-kernel, linux-doc, linux-mm, gregkh, tglx, mingo, bp,
dave.hansen, x86, hpa, rafael, dakr, bartosz.golaszewski,
cw00.choi, myungjoo.ham, yesanishhere, Jonathan.Cameron,
quic_zijuhu, aleksander.lobakin, ira.weiny, andriy.shevchenko,
leon, lukas, bhelgaas, wagi, djeffery, stuart.w.hayes, ptyadav,
lennart, brauner, linux-api, linux-fsdevel, saeedm, ajayachandra,
jgg, parav, leonro, witu, hughd, skhawaja, chrisl
In-Reply-To: <aRTs3ZouoL1CGHst@kernel.org>
On Wed, Nov 12, 2025 at 3:24 PM Mike Rapoport <rppt@kernel.org> wrote:
>
> On Fri, Nov 07, 2025 at 04:03:20PM -0500, Pasha Tatashin wrote:
> > Introduce an in-kernel test module to validate the core logic of the
> > Live Update Orchestrator's File-Lifecycle-Bound feature. This
> > provides a low-level, controlled environment to test FLB registration
> > and callback invocation without requiring userspace interaction or
> > actual kexec reboots.
> >
> > The test is enabled by the CONFIG_LIVEUPDATE_TEST Kconfig option.
> >
> > Signed-off-by: Pasha Tatashin <pasha.tatashin@soleen.com>
> > ---
> > kernel/liveupdate/luo_file.c | 2 +
> > kernel/liveupdate/luo_internal.h | 8 ++
> > lib/Kconfig.debug | 23 ++++++
> > lib/tests/Makefile | 1 +
> > lib/tests/liveupdate.c | 130 +++++++++++++++++++++++++++++++
> > 5 files changed, 164 insertions(+)
> > create mode 100644 lib/tests/liveupdate.c
> >
> > diff --git a/kernel/liveupdate/luo_file.c b/kernel/liveupdate/luo_file.c
> > index 713069b96278..4c0a75918f3d 100644
> > --- a/kernel/liveupdate/luo_file.c
> > +++ b/kernel/liveupdate/luo_file.c
> > @@ -829,6 +829,8 @@ int liveupdate_register_file_handler(struct liveupdate_file_handler *fh)
> > INIT_LIST_HEAD(&fh->flb_list);
> > list_add_tail(&fh->list, &luo_file_handler_list);
> >
> > + liveupdate_test_register(fh);
> > +
>
> Do it mean that every flb user will be added here?
No, FLB users will use:
liveupdate_register_flb() from various subsystems. This
liveupdate_test_register() is only to allow kernel test to register
test-FLBs to every single file-handler for in-kernel testing purpose
only.
Pasha
^ permalink raw reply
* Re: [PATCH v5 06/22] liveupdate: luo_session: add sessions support
From: Mike Rapoport @ 2025-11-12 20:39 UTC (permalink / raw)
To: Pasha Tatashin
Cc: pratyush, jasonmiu, graf, dmatlack, rientjes, corbet, rdunlap,
ilpo.jarvinen, kanie, ojeda, aliceryhl, masahiroy, akpm, tj,
yoann.congal, mmaurer, roman.gushchin, chenridong, axboe,
mark.rutland, jannh, vincent.guittot, hannes, dan.j.williams,
david, joel.granados, rostedt, anna.schumaker, song, zhangguopeng,
linux, linux-kernel, linux-doc, linux-mm, gregkh, tglx, mingo, bp,
dave.hansen, x86, hpa, rafael, dakr, bartosz.golaszewski,
cw00.choi, myungjoo.ham, yesanishhere, Jonathan.Cameron,
quic_zijuhu, aleksander.lobakin, ira.weiny, andriy.shevchenko,
leon, lukas, bhelgaas, wagi, djeffery, stuart.w.hayes, ptyadav,
lennart, brauner, linux-api, linux-fsdevel, saeedm, ajayachandra,
jgg, parav, leonro, witu, hughd, skhawaja, chrisl
In-Reply-To: <20251107210526.257742-7-pasha.tatashin@soleen.com>
On Fri, Nov 07, 2025 at 04:03:04PM -0500, Pasha Tatashin wrote:
> Introduce concept of "Live Update Sessions" within the LUO framework.
> LUO sessions provide a mechanism to group and manage `struct file *`
> instances (representing file descriptors) that need to be preserved
> across a kexec-based live update.
>
> Each session is identified by a unique name and acts as a container
> for file objects whose state is critical to a userspace workload, such
> as a virtual machine or a high-performance database, aiming to maintain
> their functionality across a kernel transition.
>
> This groundwork establishes the framework for preserving file-backed
> state across kernel updates, with the actual file data preservation
> mechanisms to be implemented in subsequent patches.
>
> Signed-off-by: Pasha Tatashin <pasha.tatashin@soleen.com>
> ---
> include/linux/liveupdate/abi/luo.h | 81 ++++++
> include/uapi/linux/liveupdate.h | 3 +
> kernel/liveupdate/Makefile | 3 +-
> kernel/liveupdate/luo_core.c | 9 +
> kernel/liveupdate/luo_internal.h | 39 +++
> kernel/liveupdate/luo_session.c | 405 +++++++++++++++++++++++++++++
> 6 files changed, 539 insertions(+), 1 deletion(-)
> create mode 100644 kernel/liveupdate/luo_session.c
>
> diff --git a/include/linux/liveupdate/abi/luo.h b/include/linux/liveupdate/abi/luo.h
> index 9483a294287f..37b9fecef3f7 100644
> --- a/include/linux/liveupdate/abi/luo.h
> +++ b/include/linux/liveupdate/abi/luo.h
> @@ -28,6 +28,11 @@
> * / {
> * compatible = "luo-v1";
> * liveupdate-number = <...>;
> + *
> + * luo-session {
> + * compatible = "luo-session-v1";
> + * luo-session-head = <phys_addr_of_session_head_ser>;
'head' reads to me as list head rather than a header. I'd use 'hdr' for the
latter.
--
Sincerely yours,
Mike.
^ permalink raw reply
* Re: [PATCH v5 22/22] tests/liveupdate: Add in-kernel liveupdate test
From: Mike Rapoport @ 2025-11-12 20:23 UTC (permalink / raw)
To: Pasha Tatashin
Cc: pratyush, jasonmiu, graf, dmatlack, rientjes, corbet, rdunlap,
ilpo.jarvinen, kanie, ojeda, aliceryhl, masahiroy, akpm, tj,
yoann.congal, mmaurer, roman.gushchin, chenridong, axboe,
mark.rutland, jannh, vincent.guittot, hannes, dan.j.williams,
david, joel.granados, rostedt, anna.schumaker, song, zhangguopeng,
linux, linux-kernel, linux-doc, linux-mm, gregkh, tglx, mingo, bp,
dave.hansen, x86, hpa, rafael, dakr, bartosz.golaszewski,
cw00.choi, myungjoo.ham, yesanishhere, Jonathan.Cameron,
quic_zijuhu, aleksander.lobakin, ira.weiny, andriy.shevchenko,
leon, lukas, bhelgaas, wagi, djeffery, stuart.w.hayes, ptyadav,
lennart, brauner, linux-api, linux-fsdevel, saeedm, ajayachandra,
jgg, parav, leonro, witu, hughd, skhawaja, chrisl
In-Reply-To: <20251107210526.257742-23-pasha.tatashin@soleen.com>
On Fri, Nov 07, 2025 at 04:03:20PM -0500, Pasha Tatashin wrote:
> Introduce an in-kernel test module to validate the core logic of the
> Live Update Orchestrator's File-Lifecycle-Bound feature. This
> provides a low-level, controlled environment to test FLB registration
> and callback invocation without requiring userspace interaction or
> actual kexec reboots.
>
> The test is enabled by the CONFIG_LIVEUPDATE_TEST Kconfig option.
>
> Signed-off-by: Pasha Tatashin <pasha.tatashin@soleen.com>
> ---
> kernel/liveupdate/luo_file.c | 2 +
> kernel/liveupdate/luo_internal.h | 8 ++
> lib/Kconfig.debug | 23 ++++++
> lib/tests/Makefile | 1 +
> lib/tests/liveupdate.c | 130 +++++++++++++++++++++++++++++++
> 5 files changed, 164 insertions(+)
> create mode 100644 lib/tests/liveupdate.c
>
> diff --git a/kernel/liveupdate/luo_file.c b/kernel/liveupdate/luo_file.c
> index 713069b96278..4c0a75918f3d 100644
> --- a/kernel/liveupdate/luo_file.c
> +++ b/kernel/liveupdate/luo_file.c
> @@ -829,6 +829,8 @@ int liveupdate_register_file_handler(struct liveupdate_file_handler *fh)
> INIT_LIST_HEAD(&fh->flb_list);
> list_add_tail(&fh->list, &luo_file_handler_list);
>
> + liveupdate_test_register(fh);
> +
Do it mean that every flb user will be added here?
> return 0;
> }
>
--
Sincerely yours,
Mike.
^ permalink raw reply
* Re: RFC: Serial port DTR/RTS - O_NRESETDEV
From: H. Peter Anvin @ 2025-11-12 19:55 UTC (permalink / raw)
To: Greg KH
Cc: Theodore Ts'o, Maarten Brock, linux-serial@vger.kernel.org,
linux-api@vger.kernel.org, LKML
In-Reply-To: <2025111227-equipment-magnetism-1443@gregkh>
On 2025-11-12 11:39, Greg KH wrote:
> Trimming out stuff to get to the real questions:
>
> On Wed, Nov 12, 2025 at 11:12:22AM -0800, H. Peter Anvin wrote:
>> Things that I have identified, at least in my opinion:
>>
>> 1. Opening a device for configuration as opposed to data streaming; in the tty case that doesn't just improve the DTR# and RTS# issue but allows setserial, configuring line disciplines and so on.
>>
>> As I have said, this is application-specific intent, which is why I strongly believe that it needs to be part of the open system call. I furthermore believe that it would have use cases beyond ttys and serial ports, which is why I'm proposing a new open flag as opposed to a sysfs attribute, which actually was my initial approach (yes, I have already prototyped some of this, and as referenced before there is an existing patchset that was never merged.)
>
> I think this is going to be the most difficult. I don't remember why I
> rejected the old submission, but maybe it would have modified the
> existing behaviour? A new open flag "O_DO_NOT_TOUCH_ANYTHING" might be
> the simplest?
That was exactly my proposal - see the header of this thread :)
>> 3. The only way to determine the type of a tty driver is reading and parsing /proc/tty/drivers; that information is exported neither through ioctl nor sysfs. Exporting *that* through sysfs is probably the easiest of all the improvements.
>
> The "type" is interesting. We keep adding new "types" of serial ports
> to the uapi list, and they don't really show up very well to userspace,
> as you say. Adding this export to sysfs is fine with me, but we should
> make it a string somehow, and not just a random number like the current
> types are listed as, to give people a chance to keep track of this.
>
> So yes, this too should be done.
I meant to add this to the previous email -- the obvious choice (and what is
in my prototype) is to use the same string as is currently exposed in
/proc/tty/drivers.
-hpa
^ permalink raw reply
* Re: RFC: Serial port DTR/RTS - O_NRESETDEV
From: H. Peter Anvin @ 2025-11-12 19:53 UTC (permalink / raw)
To: Greg KH
Cc: Theodore Ts'o, Maarten Brock, linux-serial@vger.kernel.org,
linux-api@vger.kernel.org, LKML
In-Reply-To: <2025111227-equipment-magnetism-1443@gregkh>
On 2025-11-12 11:39, Greg KH wrote:
>
>> 3. The only way to determine the type of a tty driver is reading and parsing /proc/tty/drivers; that information is exported neither through ioctl nor sysfs. Exporting *that* through sysfs is probably the easiest of all the improvements.
>
> The "type" is interesting. We keep adding new "types" of serial ports
> to the uapi list, and they don't really show up very well to userspace,
> as you say. Adding this export to sysfs is fine with me, but we should
> make it a string somehow, and not just a random number like the current
> types are listed as, to give people a chance to keep track of this.
>
> So yes, this too should be done.
>
Yes, this one is pretty obvious:
>> 4. There isn't a device-independent way to determine if a device is "real" (configured for hardware) or not without opening it and executing one of the termios ioctls like TCGETS (returns -EIO if there isn't anything behind it.) For a UART port it is possible to come up with an educated guess based on the aforementioned sysfs properties (does it have any kind of address associated with it?), but seriously, should stty -a /dev/ttyS0 really glitch RTS# and DTR# even though there is no intent of using the port for communication?
>
> Determining "realness" is going to be hard I think (is a usb-serial
> device real or not? Some are, some are not, but how do we even know?)
> Does a "real" uart mean that the device is real? How do you define
> that? What about virtual ones? Modem chips that do have full line
> discipline support on USB connections? There's a lot out there to deal
> with here and I think some "fake" ones do pass TCGETS calls just because
> they lie.)
>
What I mean with "real" is that the device exists at all, unlike e.g.
/dev/ttyS* device nodes which are *only* available for the purpose of binding.
So "bound to a hardware device" is what I mean, not that it is a device with
RS232 drivers on it (which would be impossible to determine, as you very
correctly point out.)
> And addresses are only the "very old" method, many "real" PCI uarts
> don't have them, same for USB ones.
>
> And changing 'stty -a' is going to be hard, unless you want to use the
> new flag?
That's exactly the idea: use the new open flag.
> But yes, making this more sane is always good, 2 of your things here
> should be pretty simple to knock up if someone wants to. The others
> might be more difficult just due to backwards compatibility issues.
Indeed. Which is the whole reason for this RFC thread.
-hpa
^ permalink raw reply
* Re: RFC: Serial port DTR/RTS - O_NRESETDEV
From: Greg KH @ 2025-11-12 19:39 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Theodore Ts'o, Maarten Brock, linux-serial@vger.kernel.org,
linux-api@vger.kernel.org, LKML
In-Reply-To: <DD67C0CF-D330-4D40-B610-FD3EB7AA0218@zytor.com>
Trimming out stuff to get to the real questions:
On Wed, Nov 12, 2025 at 11:12:22AM -0800, H. Peter Anvin wrote:
> Things that I have identified, at least in my opinion:
>
> 1. Opening a device for configuration as opposed to data streaming; in the tty case that doesn't just improve the DTR# and RTS# issue but allows setserial, configuring line disciplines and so on.
>
> As I have said, this is application-specific intent, which is why I strongly believe that it needs to be part of the open system call. I furthermore believe that it would have use cases beyond ttys and serial ports, which is why I'm proposing a new open flag as opposed to a sysfs attribute, which actually was my initial approach (yes, I have already prototyped some of this, and as referenced before there is an existing patchset that was never merged.)
I think this is going to be the most difficult. I don't remember why I
rejected the old submission, but maybe it would have modified the
existing behaviour? A new open flag "O_DO_NOT_TOUCH_ANYTHING" might be
the simplest?
> 2. Currently the setserial configurables are available in sysfs, but *only* for UARTs, whereas TIOC[GS]SERIAL is at least available to all serial devices. That code should presumably be hoisted into a higher layer; this shouldn't be too difficult.
I agree, this shouldn't be hard, no reason to not do this.
> 3. The only way to determine the type of a tty driver is reading and parsing /proc/tty/drivers; that information is exported neither through ioctl nor sysfs. Exporting *that* through sysfs is probably the easiest of all the improvements.
The "type" is interesting. We keep adding new "types" of serial ports
to the uapi list, and they don't really show up very well to userspace,
as you say. Adding this export to sysfs is fine with me, but we should
make it a string somehow, and not just a random number like the current
types are listed as, to give people a chance to keep track of this.
So yes, this too should be done.
> 4. There isn't a device-independent way to determine if a device is "real" (configured for hardware) or not without opening it and executing one of the termios ioctls like TCGETS (returns -EIO if there isn't anything behind it.) For a UART port it is possible to come up with an educated guess based on the aforementioned sysfs properties (does it have any kind of address associated with it?), but seriously, should stty -a /dev/ttyS0 really glitch RTS# and DTR# even though there is no intent of using the port for communication?
Determining "realness" is going to be hard I think (is a usb-serial
device real or not? Some are, some are not, but how do we even know?)
Does a "real" uart mean that the device is real? How do you define
that? What about virtual ones? Modem chips that do have full line
discipline support on USB connections? There's a lot out there to deal
with here and I think some "fake" ones do pass TCGETS calls just because
they lie.)
And addresses are only the "very old" method, many "real" PCI uarts
don't have them, same for USB ones.
And changing 'stty -a' is going to be hard, unless you want to use the
new flag?
But yes, making this more sane is always good, 2 of your things here
should be pretty simple to knock up if someone wants to. The others
might be more difficult just due to backwards compatibility issues.
thanks,
greg k-h
^ permalink raw reply
* Re: RFC: Serial port DTR/RTS - O_NRESETDEV
From: H. Peter Anvin @ 2025-11-12 19:12 UTC (permalink / raw)
To: Greg KH
Cc: Theodore Ts'o, Maarten Brock, linux-serial@vger.kernel.org,
linux-api@vger.kernel.org, LKML
In-Reply-To: <2025111241-domestic-moonstone-f75f@gregkh>
On November 12, 2025 8:46:50 AM PST, Greg KH <gregkh@linuxfoundation.org> wrote:
>On Wed, Nov 12, 2025 at 08:09:45AM -0800, H. Peter Anvin wrote:
>> On November 12, 2025 3:22:56 AM PST, Greg KH <gregkh@linuxfoundation.org> wrote:
>> >On Mon, Nov 10, 2025 at 07:57:22PM -0800, H. Peter Anvin wrote:
>> >> Honestly, though, I'm far less interested in what 8250-based hardware does than e.g. USB.
>> >
>> >hahahahahahaha {snort}
>> >
>> >Hah. that's a good one.
>> >
>> >Oh, you aren't kidding.
>> >
>> >Wow, good luck with this. USB-serial adaptors are all over the place,
>> >some have real uarts in them (and so do buffering in the device, and
>> >line handling in odd ways when powered up), and some are almost just a
>> >straight pipe through to the USB host with control line handling ideas
>> >tacked on to the side as an afterthought, if at all.
>> >
>> >There is no standard here, they all work differently, and even work
>> >differently across the same device type with just barely enough hints
>> >for us to determine what is going on.
>> >
>> >So don't worry about USB, if you throw that into the mix, all bets are
>> >off and you should NEVER rely on that.
>> >
>> >Remeber USB->serial was explicitly rejected by the USB standard group,
>> >only to have it come back in the "side door" through the spec process
>> >when it turned out that Microsoft hated having to write a zillion
>> >different vendor-specific drivers because the vendor provided ones kept
>> >crashing user's machines. So what we ended up with was "just enough" to
>> >make it through the spec process, and even then line signals are
>> >probably never tested so you can't rely on them.
>> >
>> >good luck!
>> >
>> >greg "this brought up too many bad memories" k-h
>>
>> Ugh.
>>
>> I have made it very clear that I am very aware that there is broken hardware.
>
>I would posit that there is NO "non-broken" usb->serial devices out
>there. The closest I have seen was the old IO-Edgeport devices, but
>they were expensive and got bought out by some other company and in the
>end didn't succeed due to all of the "cheap" devices/chips out there
>that just did dumb tx/rx transfers over a fake serial connection.
>
>> What I'm trying to do is to deal with the (occasional) case of
>> *non*-broken hardware. Right now Linux breaks the non-broken hardware
>> for it, and I don't think the existence of broken hardware is a good
>> justification for that.
>
>No, but we have to handle both somehow.
>
>And given that we still get brand-new UART drivers sent to use every few
>months, there is just more and more "broken" hardware out there overall.
>
>Anyway, good luck coming up with a scheme to handle your crazy
>connections, I would push back and say "any device that treats a serial
>control line as a power signal is broken to start with" :)
>
>greg k-h
Yeah, well, I will certainly *not* argue with that one! Quite the contrary... *shudder*.
There are enough facepalms to go around, both on the DTE and DCE sides, and I'm not in any shape, way, or form denying that.
Nor am I trying to boil the ocean here. I'm just trying to figure out how to make the situation a bit more flexible to try to at least reduce the amount of brokenness we throw back in the face of the user.
The reason I brought up USB is that while RTS# briefly glitching on an actual RS232 line is unlikely to actually make it through the driver, which will have a cutoff of at most 10 MHz and usually much less, an ACM device receiving a SET_LINE_CONTROL message may react to it immediately, especially if it is an emulated port.(*)
The same thing is true, of course, for "uart" lines, a.k.a. TTL or CMOS level serial, which have much higher bandwidth than any physical RS232 or RS485 drivers.
Incidentally, I'm not looking at this because of a huge need on my own part; I'm doing it because it irked me to no end that glibc still hadn't implemented support for the almost two decades old support in the Linux kernel for arbitrary serial port speeds, and in the end I ended up Just Writing The Code; but there as well I ended up having several discussions with the glibc maintainers about how to deal with the unavoidable compromises involved in evolving one l the interfaces; the POSIX termios interface design from back in the '80s really caused some serious headaches.
There was fallout, as it exposed bugs in a bunch of software which had implemented their own hacks during the 17 years that glibc didn't provide any support for handling this. It gave me a *lot* of new insights in how various applications in the field actually do things and what they have to do to work around limitations in both hardware and software at the moment, and so I'm feeling kind of motivated to try to make these real life use cases a little bit less obnoxious.
The thing with RTS# and DTR# came up when I started rooting around in gtkterm's serial code probing code, but I had myself run into it using ESP32 modules.
Had I personally designed the ESP32 interface I would have used BREAK to pulse reset instead of RTS#, but that would have required a capacitor and a diode, and omg that would have added *cost!*
(This is in fact exactly what I did when I implemented my own ACM device in an FPGA, but that's a different story.)
As far as actual USB-to-serial devices are concerned, my *personal* experience with quite a few of them is that the line control signals are generally quite reliable, and transmitting BREAK usually works OK; however, whether *receiving* BREAK works is a crapshoot at the very best.
Then there are of course the ones that just lock up randomly, or seriously glitch on the USB side, but that's an entirely different kettle of fish.
And you are most definitely right that not standardizing a USB to serial device class from the very beginning was a very bad mistake. At least now newer devices tend toward using ACM and advertise as "driverless". It also allows the rest of the USB descriptor to contain more useful information about the DCE, assuming it is a device that is physically bound to or integrated in the DCE (virtual.)
I'm not saying you and Ted are *wrong*; you are most certainly not. What I'm hoping for is a bit of pragmatism that would make at least some users' lives a little easier.
None of this will, of course, help when the hardware itself is buggered to the point that there is nothing we can do about it. I'm not trying to deal with anything like that.
Things that I have identified, at least in my opinion:
1. Opening a device for configuration as opposed to data streaming; in the tty case that doesn't just improve the DTR# and RTS# issue but allows setserial, configuring line disciplines and so on.
As I have said, this is application-specific intent, which is why I strongly believe that it needs to be part of the open system call. I furthermore believe that it would have use cases beyond ttys and serial ports, which is why I'm proposing a new open flag as opposed to a sysfs attribute, which actually was my initial approach (yes, I have already prototyped some of this, and as referenced before there is an existing patchset that was never merged.)
2. Currently the setserial configurables are available in sysfs, but *only* for UARTs, whereas TIOC[GS]SERIAL is at least available to all serial devices. That code should presumably be hoisted into a higher layer; this shouldn't be too difficult.
3. The only way to determine the type of a tty driver is reading and parsing /proc/tty/drivers; that information is exported neither through ioctl nor sysfs. Exporting *that* through sysfs is probably the easiest of all the improvements.
4. There isn't a device-independent way to determine if a device is "real" (configured for hardware) or not without opening it and executing one of the termios ioctls like TCGETS (returns -EIO if there isn't anything behind it.) For a UART port it is possible to come up with an educated guess based on the aforementioned sysfs properties (does it have any kind of address associated with it?), but seriously, should stty -a /dev/ttyS0 really glitch RTS# and DTR# even though there is no intent of using the port for communication?
Let me make it very clear that I'm *not* criticizing neither you, Ted, Alan Cox nor anyone else who have been involved: on the contrary, you have done an absolutely fantastic job making Linux work with all these pieces of hardware, each with various "interesting" properties. Nor am I criticizing the tty interface as it is: it is designed to allow both interactive terminal use and use for other purposes under program control, which is really an astonishing level of flexibility. We have already shown that it can evolve to meet new needs, which sometimes requires interface extensions – like O_NOCTTY, O_NONBLOCK, CRTSCTS, termios2, and BOTHER. *And that is perfectly okay.* If anything it is a strength.
And please do recognize that I have stated from the beginning that I expect this to be a "best effort" on the part of kernel, not a guarantee. If the hardware is too broken, the user gets to keep both pieces – that's just reality.
^ permalink raw reply
* Re: [PATCH v5 02/22] liveupdate: luo_core: integrate with KHO
From: Pasha Tatashin @ 2025-11-12 17:39 UTC (permalink / raw)
To: Mike Rapoport
Cc: pratyush, jasonmiu, graf, dmatlack, rientjes, corbet, rdunlap,
ilpo.jarvinen, kanie, ojeda, aliceryhl, masahiroy, akpm, tj,
yoann.congal, mmaurer, roman.gushchin, chenridong, axboe,
mark.rutland, jannh, vincent.guittot, hannes, dan.j.williams,
david, joel.granados, rostedt, anna.schumaker, song, zhangguopeng,
linux, linux-kernel, linux-doc, linux-mm, gregkh, tglx, mingo, bp,
dave.hansen, x86, hpa, rafael, dakr, bartosz.golaszewski,
cw00.choi, myungjoo.ham, yesanishhere, Jonathan.Cameron,
quic_zijuhu, aleksander.lobakin, ira.weiny, andriy.shevchenko,
leon, lukas, bhelgaas, wagi, djeffery, stuart.w.hayes, ptyadav,
lennart, brauner, linux-api, linux-fsdevel, saeedm, ajayachandra,
jgg, parav, leonro, witu, hughd, skhawaja, chrisl
In-Reply-To: <CA+CK2bA6vCH=RkiZjAOsh5iR52BY567bJB3HNAGqDb307YxVdw@mail.gmail.com>
On Wed, Nov 12, 2025 at 10:14 AM Pasha Tatashin
<pasha.tatashin@soleen.com> wrote:
>
> > > FLB global objects act similarly to subsystem-wide data, except their
> > > data has a clear creation and destruction time tied to preserved
> > > files. When the first file of a particular type is added to LUO, this
> > > global data is created; when the last file of that type is removed
> > > (unpreserved or finished), this global data is destroyed, this is why
> > > its life is bound to file lifecycle. Crucially, this global data is
> > > accessible at any time while LUO owns the associated files spanning
> > > the early boot update boundary.
> >
> > But there are no files at mm_core_init(). I'm really confused here.
>
> This isn't about the files themselves, but about the subsystem global
> data. The files are only used to describe the lifetime of this global
> data.
>
> I think mm_core_init() is too late, and the call would need to be
> moved earlier to work correctly with subsystems. At the very least, we
> will have to add some early FDT parsing to retrieve data during early
> boot, but that would be part of the HugeTLB preservation work.
>
> I can move liveupdate_init() inside kho_memory_init(), so we don't
> need to modify mm_core_init(). Or, rename kho_memory_init to
> kho_and_liveupdate_memory_init() and combine the two calls into a
> single function in kexec_handover.c.
>
> > > > So I think for now we can move liveupdate_init() later in boot and we will
> > > > solve the problem of hugetlb reservations when we add support for hugetlb.
> > >
> > > HugeTLB reserves memory early in boot. If we already have preserved
> > > HugeTLB pages via LUO/KHO, we must ensure they are counted against the
> > > boot-time reservation. For example, if hugetlb_cma_reserve() needs to
> > > reserve ten 1G pages, but LUO has already preserved seven, we only
> > > need to reserve three new pages and the rest are going to be restored
> > > with the files.
> > >
> > > Since this count is contained in the FLB global object, that data
> > > needs to be available during the early reservation phase. (Pratyush is
> > > working on HugeTLB preservation and can explain further).
> >
> > Not sure I really follow the design here, but in my understanding the gist
> > here is that hugetlb reservations need to be aware of the preserved state.
> > If that's the case, we definitely can move liveupdate_init() to an initcall
> > and revisit this when hugetlb support for luo comes along.
>
> This will break the in-kernel tests that ensure FLB data is accessible
> and works correctly during early boot, as they use
> early_initcall(liveupdate_test_early_init);.
We had a chat, so we agreed to move liveupdate_init() into
early_initcall() and liveupdate_test_early_init into somewhere later
initcall. And when HugeTLB support is added we will introduce a
variant for read-only access to do it early in boot from setup_arch().
> We cannot rely on early_initcall() for liveupdate_init() because it
> would compete with the test. We also can't move the test to a later
> initcall, as that would break the verification of what FLB is
> promising: early access to global data by subsystems that need it
> (PCI, IOMMU Core, HugeTLB, etc.).
>
> Thanks,
> Pasha
^ permalink raw reply
* Re: RFC: Serial port DTR/RTS - O_NRESETDEV
From: Greg KH @ 2025-11-12 16:46 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Theodore Ts'o, Maarten Brock, linux-serial@vger.kernel.org,
linux-api@vger.kernel.org, LKML
In-Reply-To: <6DBB5931-ACD4-4174-9FCE-96C45FFC4603@zytor.com>
On Wed, Nov 12, 2025 at 08:09:45AM -0800, H. Peter Anvin wrote:
> On November 12, 2025 3:22:56 AM PST, Greg KH <gregkh@linuxfoundation.org> wrote:
> >On Mon, Nov 10, 2025 at 07:57:22PM -0800, H. Peter Anvin wrote:
> >> Honestly, though, I'm far less interested in what 8250-based hardware does than e.g. USB.
> >
> >hahahahahahaha {snort}
> >
> >Hah. that's a good one.
> >
> >Oh, you aren't kidding.
> >
> >Wow, good luck with this. USB-serial adaptors are all over the place,
> >some have real uarts in them (and so do buffering in the device, and
> >line handling in odd ways when powered up), and some are almost just a
> >straight pipe through to the USB host with control line handling ideas
> >tacked on to the side as an afterthought, if at all.
> >
> >There is no standard here, they all work differently, and even work
> >differently across the same device type with just barely enough hints
> >for us to determine what is going on.
> >
> >So don't worry about USB, if you throw that into the mix, all bets are
> >off and you should NEVER rely on that.
> >
> >Remeber USB->serial was explicitly rejected by the USB standard group,
> >only to have it come back in the "side door" through the spec process
> >when it turned out that Microsoft hated having to write a zillion
> >different vendor-specific drivers because the vendor provided ones kept
> >crashing user's machines. So what we ended up with was "just enough" to
> >make it through the spec process, and even then line signals are
> >probably never tested so you can't rely on them.
> >
> >good luck!
> >
> >greg "this brought up too many bad memories" k-h
>
> Ugh.
>
> I have made it very clear that I am very aware that there is broken hardware.
I would posit that there is NO "non-broken" usb->serial devices out
there. The closest I have seen was the old IO-Edgeport devices, but
they were expensive and got bought out by some other company and in the
end didn't succeed due to all of the "cheap" devices/chips out there
that just did dumb tx/rx transfers over a fake serial connection.
> What I'm trying to do is to deal with the (occasional) case of
> *non*-broken hardware. Right now Linux breaks the non-broken hardware
> for it, and I don't think the existence of broken hardware is a good
> justification for that.
No, but we have to handle both somehow.
And given that we still get brand-new UART drivers sent to use every few
months, there is just more and more "broken" hardware out there overall.
Anyway, good luck coming up with a scheme to handle your crazy
connections, I would push back and say "any device that treats a serial
control line as a power signal is broken to start with" :)
greg k-h
^ permalink raw reply
* Re: RFC: Serial port DTR/RTS - O_NRESETDEV
From: H. Peter Anvin @ 2025-11-12 16:09 UTC (permalink / raw)
To: Greg KH
Cc: Theodore Ts'o, Maarten Brock, linux-serial@vger.kernel.org,
linux-api@vger.kernel.org, LKML
In-Reply-To: <2025111214-doily-anyway-b24b@gregkh>
On November 12, 2025 3:22:56 AM PST, Greg KH <gregkh@linuxfoundation.org> wrote:
>On Mon, Nov 10, 2025 at 07:57:22PM -0800, H. Peter Anvin wrote:
>> Honestly, though, I'm far less interested in what 8250-based hardware does than e.g. USB.
>
>hahahahahahaha {snort}
>
>Hah. that's a good one.
>
>Oh, you aren't kidding.
>
>Wow, good luck with this. USB-serial adaptors are all over the place,
>some have real uarts in them (and so do buffering in the device, and
>line handling in odd ways when powered up), and some are almost just a
>straight pipe through to the USB host with control line handling ideas
>tacked on to the side as an afterthought, if at all.
>
>There is no standard here, they all work differently, and even work
>differently across the same device type with just barely enough hints
>for us to determine what is going on.
>
>So don't worry about USB, if you throw that into the mix, all bets are
>off and you should NEVER rely on that.
>
>Remeber USB->serial was explicitly rejected by the USB standard group,
>only to have it come back in the "side door" through the spec process
>when it turned out that Microsoft hated having to write a zillion
>different vendor-specific drivers because the vendor provided ones kept
>crashing user's machines. So what we ended up with was "just enough" to
>make it through the spec process, and even then line signals are
>probably never tested so you can't rely on them.
>
>good luck!
>
>greg "this brought up too many bad memories" k-h
Ugh.
I have made it very clear that I am very aware that there is broken hardware.
What I'm trying to do is to deal with the (occasional) case of *non*-broken hardware. Right now Linux breaks the non-broken hardware for it, and I don't think the existence of broken hardware is a good justification for that.
^ permalink raw reply
* Re: [PATCH v5 02/22] liveupdate: luo_core: integrate with KHO
From: Pasha Tatashin @ 2025-11-12 15:14 UTC (permalink / raw)
To: Mike Rapoport
Cc: pratyush, jasonmiu, graf, dmatlack, rientjes, corbet, rdunlap,
ilpo.jarvinen, kanie, ojeda, aliceryhl, masahiroy, akpm, tj,
yoann.congal, mmaurer, roman.gushchin, chenridong, axboe,
mark.rutland, jannh, vincent.guittot, hannes, dan.j.williams,
david, joel.granados, rostedt, anna.schumaker, song, zhangguopeng,
linux, linux-kernel, linux-doc, linux-mm, gregkh, tglx, mingo, bp,
dave.hansen, x86, hpa, rafael, dakr, bartosz.golaszewski,
cw00.choi, myungjoo.ham, yesanishhere, Jonathan.Cameron,
quic_zijuhu, aleksander.lobakin, ira.weiny, andriy.shevchenko,
leon, lukas, bhelgaas, wagi, djeffery, stuart.w.hayes, ptyadav,
lennart, brauner, linux-api, linux-fsdevel, saeedm, ajayachandra,
jgg, parav, leonro, witu, hughd, skhawaja, chrisl
In-Reply-To: <aRSMsz4zy8QBbsIH@kernel.org>
> > FLB global objects act similarly to subsystem-wide data, except their
> > data has a clear creation and destruction time tied to preserved
> > files. When the first file of a particular type is added to LUO, this
> > global data is created; when the last file of that type is removed
> > (unpreserved or finished), this global data is destroyed, this is why
> > its life is bound to file lifecycle. Crucially, this global data is
> > accessible at any time while LUO owns the associated files spanning
> > the early boot update boundary.
>
> But there are no files at mm_core_init(). I'm really confused here.
This isn't about the files themselves, but about the subsystem global
data. The files are only used to describe the lifetime of this global
data.
I think mm_core_init() is too late, and the call would need to be
moved earlier to work correctly with subsystems. At the very least, we
will have to add some early FDT parsing to retrieve data during early
boot, but that would be part of the HugeTLB preservation work.
I can move liveupdate_init() inside kho_memory_init(), so we don't
need to modify mm_core_init(). Or, rename kho_memory_init to
kho_and_liveupdate_memory_init() and combine the two calls into a
single function in kexec_handover.c.
> > > So I think for now we can move liveupdate_init() later in boot and we will
> > > solve the problem of hugetlb reservations when we add support for hugetlb.
> >
> > HugeTLB reserves memory early in boot. If we already have preserved
> > HugeTLB pages via LUO/KHO, we must ensure they are counted against the
> > boot-time reservation. For example, if hugetlb_cma_reserve() needs to
> > reserve ten 1G pages, but LUO has already preserved seven, we only
> > need to reserve three new pages and the rest are going to be restored
> > with the files.
> >
> > Since this count is contained in the FLB global object, that data
> > needs to be available during the early reservation phase. (Pratyush is
> > working on HugeTLB preservation and can explain further).
>
> Not sure I really follow the design here, but in my understanding the gist
> here is that hugetlb reservations need to be aware of the preserved state.
> If that's the case, we definitely can move liveupdate_init() to an initcall
> and revisit this when hugetlb support for luo comes along.
This will break the in-kernel tests that ensure FLB data is accessible
and works correctly during early boot, as they use
early_initcall(liveupdate_test_early_init);.
We cannot rely on early_initcall() for liveupdate_init() because it
would compete with the test. We also can't move the test to a later
initcall, as that would break the verification of what FLB is
promising: early access to global data by subsystems that need it
(PCI, IOMMU Core, HugeTLB, etc.).
Thanks,
Pasha
^ permalink raw reply
* Re: [PATCH v5 02/22] liveupdate: luo_core: integrate with KHO
From: Pasha Tatashin @ 2025-11-12 14:58 UTC (permalink / raw)
To: Mike Rapoport
Cc: pratyush, jasonmiu, graf, dmatlack, rientjes, corbet, rdunlap,
ilpo.jarvinen, kanie, ojeda, aliceryhl, masahiroy, akpm, tj,
yoann.congal, mmaurer, roman.gushchin, chenridong, axboe,
mark.rutland, jannh, vincent.guittot, hannes, dan.j.williams,
david, joel.granados, rostedt, anna.schumaker, song, zhangguopeng,
linux, linux-kernel, linux-doc, linux-mm, gregkh, tglx, mingo, bp,
dave.hansen, x86, hpa, rafael, dakr, bartosz.golaszewski,
cw00.choi, myungjoo.ham, yesanishhere, Jonathan.Cameron,
quic_zijuhu, aleksander.lobakin, ira.weiny, andriy.shevchenko,
leon, lukas, bhelgaas, wagi, djeffery, stuart.w.hayes, ptyadav,
lennart, brauner, linux-api, linux-fsdevel, saeedm, ajayachandra,
jgg, parav, leonro, witu, hughd, skhawaja, chrisl
In-Reply-To: <aRSKrxfAb_GG_2Mw@kernel.org>
On Wed, Nov 12, 2025 at 8:25 AM Mike Rapoport <rppt@kernel.org> wrote:
>
> Hi Pasha,
>
> On Tue, Nov 11, 2025 at 03:57:39PM -0500, Pasha Tatashin wrote:
> > Hi Mike,
> >
> > Thank you for review, my comments below:
> >
> > > > This is why this call is placed first in reboot(), before any
> > > > irreversible reboot notifiers or shutdown callbacks are performed. If
> > > > an allocation problem occurs in KHO, the error is simply reported back
> > > > to userspace, and the live update update is safely aborted.
>
> The call to liveupdate_reboot() is just before kernel_kexec(). Why we don't
> move it there?
Yes, I can move that call into kernel_kexec().
> And all the liveupdate_reboot() does if kho_finalize() fails it's massaging
> the error value before returning it to userspace. Why kernel_kexec() can't
> do the same?
We could do that. It would look something like this:
if (liveupdate_enabled())
kho_finalize();
Because we want to do kho_finalize() from kernel_kexec only when we do
live update.
> > > This is fine. But what I don't like is that we can't use kho without
> > > liveupdate. We are making debugfs optional, we have a way to call
This is exactly the fix I proposed:
1. When live-update is enabled, always disable "finalize" debugfs API.
2. When live-update is disabled, always enable "finalize" debugfs API.
Once KHO is stateless the "finalize" debugfs API is going to be
removed, and KHO debugfs itself can be optional.
> > Yes you can: you can disable liveupdate (i.e. not supply liveupdate=1
> > via kernel parameter) and use KHO the old way: drive it from the
> > userspace. However, if liveupdate is enabled, liveupdate becomes the
> > driver of KHO as unfortunately KHO has these weird states at the
> > moment.
>
> The "weird state" is the point where KHO builds its FDT. Replacing the
> current memory tracker with one that does not require serialization won't
> change it. We still need a way to tell KHO that "there won't be new nodes
> in FDT, pack it".
>
see my answer below
> > > kho_finalize() on the reboot path and it does not seem an issue to do it
> > > even without liveupdate. But then we force kho_finalize() into
> > > liveupdate_reboot() allowing weird configurations where kho is there but
> > > it's unusable.
> >
> > What do you mean KHO is there but unusable, we should not have such a state...
>
> If you compile a kernel with KEXEC_HANDOVER=y, KEXEC_HANDOVER_DEBUGFS=n and
> LIVEUPDATE=n and boot with kho=1 there is nothing to trigger
> kho_finalize().
>
> > > What I'd like to see is that we can finalize KHO on kexec reboot path even
> > > when liveupdate is not compiled and until then the patch that makes KHO
> > > debugfs optional should not go further IMO.
> > >
> > > Another thing I didn't check in this series yet is how finalization driven
> > > from debugfs interacts with liveupdate internal handling?
> >
> > I think what we can do is the following:
> > - Remove "Kconfig: make debugfs optional" from this series, and
> > instead make that change as part of stateless KHO work.
> > - This will ensure that when liveupdate=0 always KHO finalize is fully
> > support the old way.
> > - When liveupdate=1 always disable KHO debugfs "finalize" API, and
> > allow liveupdate to drive it automatically. It would add another
> > liveupdate_enable() check to KHO, and is going to be removed as part
> > of stateless KHO work.
>
> KHO should not call into liveupdate. That's layering violation.
> And "stateless KHO" does not really make it stateless, it only removes the
> memory serialization from kho_finalize(), but it's still required to pack
> the FDT.
This touches on a point I've raised in the KHO sync meetings: to be
effective, the "stateless KHO" work must also make subtree add/remove
stateless. There should not be a separate "finalize" state just to
finish the FDT. The KHO FDT is tiny (only one page), and there are
only a handful of subtrees. Adding and removing subtrees is cheap; we
should be able to open FDT, modify it, and finish FDT on every
operation. There's no need for a special finalization state at kexec
time. KHO should be totally stateless.
> I think we should allow kho finalization in some form from kernel_kexec().
If we achieve that, we wouldn't need a kho_finalize() call from
kernel_kexec() at all. All KHO operations should be allowed at any
time once KHO is initialized, and they shouldn't depend on the machine
state. So, even late in shutdown or early in boot, it should be
possible to preserve KHO memory or a subtree. I'm not saying it's a
good idea to do that late in shutdown (as preservation may fail), but
that should be the caller's problem.
Thanks,
Pasha
^ permalink raw reply
* Re: [PATCH RFC 3/4] io-128-nonatomic: introduce io{read|write}128_{lo_hi|hi_lo}
From: Ben Dooks @ 2025-11-12 14:48 UTC (permalink / raw)
To: Chenghai Huang, arnd, catalin.marinas, will, akpm,
anshuman.khandual, ryan.roberts, andriy.shevchenko, herbert,
linux-kernel, linux-arch, linux-arm-kernel, linux-crypto,
linux-api
Cc: fanghao11, shenyang39, liulongfang, qianweili
In-Reply-To: <20251112015846.1842207-4-huangchenghai2@huawei.com>
On 12/11/2025 01:58, Chenghai Huang wrote:
> From: Weili Qian <qianweili@huawei.com>
>
> In order to provide non-atomic functions for io{read|write}128.
> We define a number of variants of these functions in the generic
> iomap that will do non-atomic operations.
>
> These functions are only defined if io{read|write}128 are defined.
> If they are not, then the wrappers that always use non-atomic operations
> from include/linux/io-128-nonatomic*.h will be used.
>
> Signed-off-by: Weili Qian <qianweili@huawei.com>
> Signed-off-by: Chenghai Huang <huangchenghai2@huawei.com>
> ---
> include/linux/io-128-nonatomic-hi-lo.h | 35 ++++++++++++++++++++++++++
> include/linux/io-128-nonatomic-lo-hi.h | 34 +++++++++++++++++++++++++
> 2 files changed, 69 insertions(+)
> create mode 100644 include/linux/io-128-nonatomic-hi-lo.h
> create mode 100644 include/linux/io-128-nonatomic-lo-hi.h
>
> diff --git a/include/linux/io-128-nonatomic-hi-lo.h b/include/linux/io-128-nonatomic-hi-lo.h
> new file mode 100644
> index 000000000000..b5b083a9e81b
> --- /dev/null
> +++ b/include/linux/io-128-nonatomic-hi-lo.h
> @@ -0,0 +1,35 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +#ifndef _LINUX_IO_128_NONATOMIC_HI_LO_H_
> +#define _LINUX_IO_128_NONATOMIC_HI_LO_H_
> +
> +#include <linux/io.h>
> +#include <asm-generic/int-ll64.h>
> +
> +static inline u128 ioread128_hi_lo(const void __iomem *addr)
> +{
> + u32 low, high;
did you mean u64 here?
> + high = ioread64(addr + sizeof(u64));
> + low = ioread64(addr);
> +
> + return low + ((u128)high << 64);
> +}
> +
> +static inline void iowrite128_hi_lo(u128 val, void __iomem *addr)
> +{
> + iowrite64(val >> 64, addr + sizeof(u64));
> + iowrite64(val, addr);
> +}
> +
--
Ben Dooks http://www.codethink.co.uk/
Senior Engineer Codethink - Providing Genius
https://www.codethink.co.uk/privacy.html
^ permalink raw reply
* Re: [PATCH RFC 4/4] arm64/io: Add {__raw_read|__raw_write}128 support
From: Mark Rutland @ 2025-11-12 14:17 UTC (permalink / raw)
To: David Laight
Cc: Chenghai Huang, arnd, catalin.marinas, will, akpm,
anshuman.khandual, ryan.roberts, andriy.shevchenko, herbert,
linux-kernel, linux-arch, linux-arm-kernel, linux-crypto,
linux-api, fanghao11, shenyang39, liulongfang, qianweili
In-Reply-To: <20251112140157.24ff4f2e@pumpkin>
On Wed, Nov 12, 2025 at 02:01:57PM +0000, David Laight wrote:
> On Wed, 12 Nov 2025 12:28:01 +0000
> Mark Rutland <mark.rutland@arm.com> wrote:
>
> > On Wed, Nov 12, 2025 at 09:58:46AM +0800, Chenghai Huang wrote:
> > > From: Weili Qian <qianweili@huawei.com>
> > >
> > > Starting from ARMv8.4, stp and ldp instructions become atomic.
> >
> > That's not true for accesses to Device memory types.
> >
> > Per ARM DDI 0487, L.b, section B2.2.1.1 ("Changes to single-copy atomicity in
> > Armv8.4"):
> >
> > If FEAT_LSE2 is implemented, LDP, LDNP, and STP instructions that load
> > or store two 64-bit registers are single-copy atomic when all of the
> > following conditions are true:
> > • The overall memory access is aligned to 16 bytes.
> > • Accesses are to Inner Write-Back, Outer Write-Back Normal cacheable memory.
> >
> > IIUC when used for Device memory types, those can be split, and a part
> > of the access could be replayed multiple times (e.g. due to an
> > intetrupt).
>
> That can't be right.
For better or worse, the architecture permits this, and I understand
that there are implementations on which this can happen.
> IO accesses can reference hardware FIFO so must only happen once.
This has nothing to do with the endpoint, and so any FIFO in the
endpoint is immaterial.
I agree that we want to ensure that the accesses only happen once, which
is why I have raised that it is unsound to use LDP/LDNP/STP in this way.
> (Or is 'Device memory' something different from 'Device register'?
I specifically said "Device memory type", which is an attribute that the
MMU associates with a VA, and determines how the MMU (and memory system
as a whole) treats accesses to that VA.
You can find the architecture documentation I referenced at:
https://developer.arm.com/documentation/ddi0487/lb/
> I'm also not sure that the bus cycles could get split by an interrupt,
> that would require a mid-instruction interrupt - very unlikely.
There are various reasons why an implementation might split the accesses
made by a single instruction, and why an interrupt (or other event)
might occur between accesses and cause a replay of some of the
constituent accesses. This has nothing to do with splitting bus cycles.
Mark.
^ permalink raw reply
* Re: [PATCH RFC 4/4] arm64/io: Add {__raw_read|__raw_write}128 support
From: David Laight @ 2025-11-12 14:01 UTC (permalink / raw)
To: Mark Rutland
Cc: Chenghai Huang, arnd, catalin.marinas, will, akpm,
anshuman.khandual, ryan.roberts, andriy.shevchenko, herbert,
linux-kernel, linux-arch, linux-arm-kernel, linux-crypto,
linux-api, fanghao11, shenyang39, liulongfang, qianweili
In-Reply-To: <aRR9UesvUCFLdVoW@J2N7QTR9R3>
On Wed, 12 Nov 2025 12:28:01 +0000
Mark Rutland <mark.rutland@arm.com> wrote:
> On Wed, Nov 12, 2025 at 09:58:46AM +0800, Chenghai Huang wrote:
> > From: Weili Qian <qianweili@huawei.com>
> >
> > Starting from ARMv8.4, stp and ldp instructions become atomic.
>
> That's not true for accesses to Device memory types.
>
> Per ARM DDI 0487, L.b, section B2.2.1.1 ("Changes to single-copy atomicity in
> Armv8.4"):
>
> If FEAT_LSE2 is implemented, LDP, LDNP, and STP instructions that load
> or store two 64-bit registers are single-copy atomic when all of the
> following conditions are true:
> • The overall memory access is aligned to 16 bytes.
> • Accesses are to Inner Write-Back, Outer Write-Back Normal cacheable memory.
>
> IIUC when used for Device memory types, those can be split, and a part
> of the access could be replayed multiple times (e.g. due to an
> intetrupt).
That can't be right.
IO accesses can reference hardware FIFO so must only happen once.
(Or is 'Device memory' something different from 'Device register'?
I'm also not sure that the bus cycles could get split by an interrupt,
that would require a mid-instruction interrupt - very unlikely.
Interleaving is most likely to come from another cpu.
More interesting would be whether the instructions generate a single
PCIe TLP? (perhaps even only most of the time.)
PCIe reads are high latency, anything that can be done to increase the
size of the TLP improves PIO throughput massively.
David
>
> I don't think we can add this generally. It is not atomic, and not
> generally safe.
>
> Mark.
...
^ permalink raw reply
* Re: [PATCH v5 02/22] liveupdate: luo_core: integrate with KHO
From: Mike Rapoport @ 2025-11-12 13:33 UTC (permalink / raw)
To: Pasha Tatashin
Cc: pratyush, jasonmiu, graf, dmatlack, rientjes, corbet, rdunlap,
ilpo.jarvinen, kanie, ojeda, aliceryhl, masahiroy, akpm, tj,
yoann.congal, mmaurer, roman.gushchin, chenridong, axboe,
mark.rutland, jannh, vincent.guittot, hannes, dan.j.williams,
david, joel.granados, rostedt, anna.schumaker, song, zhangguopeng,
linux, linux-kernel, linux-doc, linux-mm, gregkh, tglx, mingo, bp,
dave.hansen, x86, hpa, rafael, dakr, bartosz.golaszewski,
cw00.choi, myungjoo.ham, yesanishhere, Jonathan.Cameron,
quic_zijuhu, aleksander.lobakin, ira.weiny, andriy.shevchenko,
leon, lukas, bhelgaas, wagi, djeffery, stuart.w.hayes, ptyadav,
lennart, brauner, linux-api, linux-fsdevel, saeedm, ajayachandra,
jgg, parav, leonro, witu, hughd, skhawaja, chrisl
In-Reply-To: <CA+CK2bB8731z-EKv2K8-x5SH8rjOTTuWkfkrc4Qj6skW+Kr7-g@mail.gmail.com>
On Wed, Nov 12, 2025 at 07:46:23AM -0500, Pasha Tatashin wrote:
> On Wed, Nov 12, 2025 at 5:21 AM Mike Rapoport <rppt@kernel.org> wrote:
> >
> > On Tue, Nov 11, 2025 at 03:42:24PM -0500, Pasha Tatashin wrote:
> > > On Tue, Nov 11, 2025 at 3:39 PM Pasha Tatashin
> > > <pasha.tatashin@soleen.com> wrote:
> > > >
> > > > > > kho_memory_init();
> > > > > >
> > > > > > + /* Live Update should follow right after KHO is initialized */
> > > > > > + liveupdate_init();
> > > > > > +
> > > > >
> > > > > Why do you think it should be immediately after kho_memory_init()?
> > > > > Any reason this can't be called from start_kernel() or even later as an
> > > > > early_initcall() or core_initall()?
> > > >
> > > > Unfortunately, no, even here it is too late, and we might need to find
> > > > a way to move the kho_init/liveupdate_init earlier. We must be able to
> > > > preserve HugeTLB pages, and those are reserved earlier in boot.
> > >
> > > Just to clarify: liveupdate_init() is needed to start using:
> > > liveupdate_flb_incoming_* API, and FLB data is needed during HugeTLB
> > > reservation.
> >
> > Since flb is "file-lifecycle-bound", it implies *file*. Early memory
> > reservations in hugetlb are not bound to files, they end up in file objects
> > way later.
>
> FLB global objects act similarly to subsystem-wide data, except their
> data has a clear creation and destruction time tied to preserved
> files. When the first file of a particular type is added to LUO, this
> global data is created; when the last file of that type is removed
> (unpreserved or finished), this global data is destroyed, this is why
> its life is bound to file lifecycle. Crucially, this global data is
> accessible at any time while LUO owns the associated files spanning
> the early boot update boundary.
But there are no files at mm_core_init(). I'm really confused here.
> > So I think for now we can move liveupdate_init() later in boot and we will
> > solve the problem of hugetlb reservations when we add support for hugetlb.
>
> HugeTLB reserves memory early in boot. If we already have preserved
> HugeTLB pages via LUO/KHO, we must ensure they are counted against the
> boot-time reservation. For example, if hugetlb_cma_reserve() needs to
> reserve ten 1G pages, but LUO has already preserved seven, we only
> need to reserve three new pages and the rest are going to be restored
> with the files.
>
> Since this count is contained in the FLB global object, that data
> needs to be available during the early reservation phase. (Pratyush is
> working on HugeTLB preservation and can explain further).
Not sure I really follow the design here, but in my understanding the gist
here is that hugetlb reservations need to be aware of the preserved state.
If that's the case, we definitely can move liveupdate_init() to an initcall
and revisit this when hugetlb support for luo comes along.
> Pasha
>
--
Sincerely yours,
Mike.
^ permalink raw reply
* Re: [PATCH v5 02/22] liveupdate: luo_core: integrate with KHO
From: Mike Rapoport @ 2025-11-12 13:25 UTC (permalink / raw)
To: Pasha Tatashin
Cc: pratyush, jasonmiu, graf, dmatlack, rientjes, corbet, rdunlap,
ilpo.jarvinen, kanie, ojeda, aliceryhl, masahiroy, akpm, tj,
yoann.congal, mmaurer, roman.gushchin, chenridong, axboe,
mark.rutland, jannh, vincent.guittot, hannes, dan.j.williams,
david, joel.granados, rostedt, anna.schumaker, song, zhangguopeng,
linux, linux-kernel, linux-doc, linux-mm, gregkh, tglx, mingo, bp,
dave.hansen, x86, hpa, rafael, dakr, bartosz.golaszewski,
cw00.choi, myungjoo.ham, yesanishhere, Jonathan.Cameron,
quic_zijuhu, aleksander.lobakin, ira.weiny, andriy.shevchenko,
leon, lukas, bhelgaas, wagi, djeffery, stuart.w.hayes, ptyadav,
lennart, brauner, linux-api, linux-fsdevel, saeedm, ajayachandra,
jgg, parav, leonro, witu, hughd, skhawaja, chrisl
In-Reply-To: <CA+CK2bAsrEqpt9d3s0KXpjcO9WPTJjymdwtiiyWVS6uq5KKNgA@mail.gmail.com>
Hi Pasha,
On Tue, Nov 11, 2025 at 03:57:39PM -0500, Pasha Tatashin wrote:
> Hi Mike,
>
> Thank you for review, my comments below:
>
> > > This is why this call is placed first in reboot(), before any
> > > irreversible reboot notifiers or shutdown callbacks are performed. If
> > > an allocation problem occurs in KHO, the error is simply reported back
> > > to userspace, and the live update update is safely aborted.
The call to liveupdate_reboot() is just before kernel_kexec(). Why we don't
move it there?
And all the liveupdate_reboot() does if kho_finalize() fails it's massaging
the error value before returning it to userspace. Why kernel_kexec() can't
do the same?
> > This is fine. But what I don't like is that we can't use kho without
> > liveupdate. We are making debugfs optional, we have a way to call
>
> Yes you can: you can disable liveupdate (i.e. not supply liveupdate=1
> via kernel parameter) and use KHO the old way: drive it from the
> userspace. However, if liveupdate is enabled, liveupdate becomes the
> driver of KHO as unfortunately KHO has these weird states at the
> moment.
The "weird state" is the point where KHO builds its FDT. Replacing the
current memory tracker with one that does not require serialization won't
change it. We still need a way to tell KHO that "there won't be new nodes
in FDT, pack it".
> > kho_finalize() on the reboot path and it does not seem an issue to do it
> > even without liveupdate. But then we force kho_finalize() into
> > liveupdate_reboot() allowing weird configurations where kho is there but
> > it's unusable.
>
> What do you mean KHO is there but unusable, we should not have such a state...
If you compile a kernel with KEXEC_HANDOVER=y, KEXEC_HANDOVER_DEBUGFS=n and
LIVEUPDATE=n and boot with kho=1 there is nothing to trigger
kho_finalize().
> > What I'd like to see is that we can finalize KHO on kexec reboot path even
> > when liveupdate is not compiled and until then the patch that makes KHO
> > debugfs optional should not go further IMO.
> >
> > Another thing I didn't check in this series yet is how finalization driven
> > from debugfs interacts with liveupdate internal handling?
>
> I think what we can do is the following:
> - Remove "Kconfig: make debugfs optional" from this series, and
> instead make that change as part of stateless KHO work.
> - This will ensure that when liveupdate=0 always KHO finalize is fully
> support the old way.
> - When liveupdate=1 always disable KHO debugfs "finalize" API, and
> allow liveupdate to drive it automatically. It would add another
> liveupdate_enable() check to KHO, and is going to be removed as part
> of stateless KHO work.
KHO should not call into liveupdate. That's layering violation.
And "stateless KHO" does not really make it stateless, it only removes the
memory serialization from kho_finalize(), but it's still required to pack
the FDT.
I think we should allow kho finalization in some form from kernel_kexec().
When kho=1 and liveupdate=0, it will actually create the FDT if there was
no previous trigger from debugfs or it will continue with FDT created by
explicit request via debugfs.
When liveupdate=1, liveupdate_reboot() may call a function that actually
finalizes the state to allow safe rollback (although in the current patches
it does not seem necessary). And then kho_finalize() called from
kernel_kexec() will just continue with the state created by
liveupdate_reboot(). If we already finalized the kho state via debugfs,
liveupdate_reboot() can either error out or reset that state.
> Pasha
>
--
Sincerely yours,
Mike.
^ permalink raw reply
* Re: [PATCH v5 02/22] liveupdate: luo_core: integrate with KHO
From: Pasha Tatashin @ 2025-11-12 12:46 UTC (permalink / raw)
To: Mike Rapoport
Cc: pratyush, jasonmiu, graf, dmatlack, rientjes, corbet, rdunlap,
ilpo.jarvinen, kanie, ojeda, aliceryhl, masahiroy, akpm, tj,
yoann.congal, mmaurer, roman.gushchin, chenridong, axboe,
mark.rutland, jannh, vincent.guittot, hannes, dan.j.williams,
david, joel.granados, rostedt, anna.schumaker, song, zhangguopeng,
linux, linux-kernel, linux-doc, linux-mm, gregkh, tglx, mingo, bp,
dave.hansen, x86, hpa, rafael, dakr, bartosz.golaszewski,
cw00.choi, myungjoo.ham, yesanishhere, Jonathan.Cameron,
quic_zijuhu, aleksander.lobakin, ira.weiny, andriy.shevchenko,
leon, lukas, bhelgaas, wagi, djeffery, stuart.w.hayes, ptyadav,
lennart, brauner, linux-api, linux-fsdevel, saeedm, ajayachandra,
jgg, parav, leonro, witu, hughd, skhawaja, chrisl
In-Reply-To: <aRRflLTejNQXWa1Z@kernel.org>
On Wed, Nov 12, 2025 at 5:21 AM Mike Rapoport <rppt@kernel.org> wrote:
>
> On Tue, Nov 11, 2025 at 03:42:24PM -0500, Pasha Tatashin wrote:
> > On Tue, Nov 11, 2025 at 3:39 PM Pasha Tatashin
> > <pasha.tatashin@soleen.com> wrote:
> > >
> > > > > kho_memory_init();
> > > > >
> > > > > + /* Live Update should follow right after KHO is initialized */
> > > > > + liveupdate_init();
> > > > > +
> > > >
> > > > Why do you think it should be immediately after kho_memory_init()?
> > > > Any reason this can't be called from start_kernel() or even later as an
> > > > early_initcall() or core_initall()?
> > >
> > > Unfortunately, no, even here it is too late, and we might need to find
> > > a way to move the kho_init/liveupdate_init earlier. We must be able to
> > > preserve HugeTLB pages, and those are reserved earlier in boot.
> >
> > Just to clarify: liveupdate_init() is needed to start using:
> > liveupdate_flb_incoming_* API, and FLB data is needed during HugeTLB
> > reservation.
>
> Since flb is "file-lifecycle-bound", it implies *file*. Early memory
> reservations in hugetlb are not bound to files, they end up in file objects
> way later.
FLB global objects act similarly to subsystem-wide data, except their
data has a clear creation and destruction time tied to preserved
files. When the first file of a particular type is added to LUO, this
global data is created; when the last file of that type is removed
(unpreserved or finished), this global data is destroyed, this is why
its life is bound to file lifecycle. Crucially, this global data is
accessible at any time while LUO owns the associated files spanning
the early boot update boundary.
> So I think for now we can move liveupdate_init() later in boot and we will
> solve the problem of hugetlb reservations when we add support for hugetlb.
HugeTLB reserves memory early in boot. If we already have preserved
HugeTLB pages via LUO/KHO, we must ensure they are counted against the
boot-time reservation. For example, if hugetlb_cma_reserve() needs to
reserve ten 1G pages, but LUO has already preserved seven, we only
need to reserve three new pages and the rest are going to be restored
with the files.
Since this count is contained in the FLB global object, that data
needs to be available during the early reservation phase. (Pratyush is
working on HugeTLB preservation and can explain further).
Pasha
^ permalink raw reply
* Re: [PATCH RFC 4/4] arm64/io: Add {__raw_read|__raw_write}128 support
From: Mark Rutland @ 2025-11-12 12:28 UTC (permalink / raw)
To: Chenghai Huang
Cc: arnd, catalin.marinas, will, akpm, anshuman.khandual,
ryan.roberts, andriy.shevchenko, herbert, linux-kernel,
linux-arch, linux-arm-kernel, linux-crypto, linux-api, fanghao11,
shenyang39, liulongfang, qianweili
In-Reply-To: <20251112015846.1842207-5-huangchenghai2@huawei.com>
On Wed, Nov 12, 2025 at 09:58:46AM +0800, Chenghai Huang wrote:
> From: Weili Qian <qianweili@huawei.com>
>
> Starting from ARMv8.4, stp and ldp instructions become atomic.
That's not true for accesses to Device memory types.
Per ARM DDI 0487, L.b, section B2.2.1.1 ("Changes to single-copy atomicity in
Armv8.4"):
If FEAT_LSE2 is implemented, LDP, LDNP, and STP instructions that load
or store two 64-bit registers are single-copy atomic when all of the
following conditions are true:
• The overall memory access is aligned to 16 bytes.
• Accesses are to Inner Write-Back, Outer Write-Back Normal cacheable memory.
IIUC when used for Device memory types, those can be split, and a part
of the access could be replayed multiple times (e.g. due to an
intetrupt).
I don't think we can add this generally. It is not atomic, and not
generally safe.
Mark.
> Currently, device drivers depend on 128-bit atomic memory IO access,
> but these are implemented within the drivers. Therefore, this introduces
> generic {__raw_read|__raw_write}128 function for 128-bit memory access.
>
> Signed-off-by: Weili Qian <qianweili@huawei.com>
> Signed-off-by: Chenghai Huang <huangchenghai2@huawei.com>
> ---
> arch/arm64/include/asm/io.h | 21 +++++++++++++++++++++
> 1 file changed, 21 insertions(+)
>
> diff --git a/arch/arm64/include/asm/io.h b/arch/arm64/include/asm/io.h
> index 83e03abbb2ca..80430750a28c 100644
> --- a/arch/arm64/include/asm/io.h
> +++ b/arch/arm64/include/asm/io.h
> @@ -50,6 +50,17 @@ static __always_inline void __raw_writeq(u64 val, volatile void __iomem *addr)
> asm volatile("str %x0, %1" : : "rZ" (val), "Qo" (*ptr));
> }
>
> +#define __raw_write128 __raw_write128
> +static __always_inline void __raw_write128(u128 val, volatile void __iomem *addr)
> +{
> + u64 low, high;
> +
> + low = val;
> + high = (u64)(val >> 64);
> +
> + asm volatile ("stp %x0, %x1, [%2]\n" :: "rZ"(low), "rZ"(high), "r"(addr));
> +}
> +
> #define __raw_readb __raw_readb
> static __always_inline u8 __raw_readb(const volatile void __iomem *addr)
> {
> @@ -95,6 +106,16 @@ static __always_inline u64 __raw_readq(const volatile void __iomem *addr)
> return val;
> }
>
> +#define __raw_read128 __raw_read128
> +static __always_inline u128 __raw_read128(const volatile void __iomem *addr)
> +{
> + u64 high, low;
> +
> + asm volatile("ldp %0, %1, [%2]" : "=r" (low), "=r" (high) : "r" (addr));
> +
> + return (((u128)high << 64) | (u128)low);
> +}
> +
> /* IO barriers */
> #define __io_ar(v) \
> ({ \
> --
> 2.33.0
>
>
^ 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