* Re: [PATCH v4 3/4] procfs: add PROCFS_GET_PID_NAMESPACE ioctl
From: Christian Brauner @ 2025-08-08 14:12 UTC (permalink / raw)
To: Randy Dunlap, Arnd Bergmann
Cc: Aleksa Sarai, Alexander Viro, Jan Kara, Jonathan Corbet,
Shuah Khan, Andy Lutomirski, linux-kernel, linux-fsdevel,
linux-api, linux-doc, linux-kselftest
In-Reply-To: <1ea6f1d9-550d-4b81-bade-1a0ca14c27c6@infradead.org>
On Wed, Aug 06, 2025 at 11:57:42AM -0700, Randy Dunlap wrote:
>
>
> On 8/6/25 11:02 AM, Aleksa Sarai wrote:
> > On 2025-08-05, Randy Dunlap <rdunlap@infradead.org> wrote:
> >>
> >>
> >> On 8/4/25 10:45 PM, Aleksa Sarai wrote:
> >>> /proc has historically had very opaque semantics about PID namespaces,
> >>> which is a little unfortunate for container runtimes and other programs
> >>> that deal with switching namespaces very often. One common issue is that
> >>> of converting between PIDs in the process's namespace and PIDs in the
> >>> namespace of /proc.
> >>>
> >>> In principle, it is possible to do this today by opening a pidfd with
> >>> pidfd_open(2) and then looking at /proc/self/fdinfo/$n (which will
> >>> contain a PID value translated to the pid namespace associated with that
> >>> procfs superblock). However, allocating a new file for each PID to be
> >>> converted is less than ideal for programs that may need to scan procfs,
> >>> and it is generally useful for userspace to be able to finally get this
> >>> information from procfs.
> >>>
> >>> So, add a new API to get the pid namespace of a procfs instance, in the
> >>> form of an ioctl(2) you can call on the root directory of said procfs.
> >>> The returned file descriptor will have O_CLOEXEC set. This acts as a
> >>> sister feature to the new "pidns" mount option, finally allowing
> >>> userspace full control of the pid namespaces associated with procfs
> >>> instances.
> >>>
> >>> The permission model for this is a bit looser than that of the "pidns"
> >>> mount option (and also setns(2)) because /proc/1/ns/pid provides the
> >>> same information, so as long as you have access to that magic-link (or
> >>> something equivalently reasonable such as being in an ancestor pid
> >>> namespace) it makes sense to allow userspace to grab a handle. Ideally
> >>> we would check for ptrace-read access against all processes in the pidns
> >>> (which is very likely to be true for at least one process, as
> >>> SUID_DUMP_DISABLE is cleared on exec(2) and is rarely set by most
> >>> programs), but this would obviously not scale.
> >>>
> >>> setns(2) will still have their own permission checks, so being able to
> >>> open a pidns handle doesn't really provide too many other capabilities.
> >>>
> >>> Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>
> >>> ---
> >>> Documentation/filesystems/proc.rst | 4 +++
> >>> fs/proc/root.c | 68 ++++++++++++++++++++++++++++++++++++--
> >>> include/uapi/linux/fs.h | 4 +++
> >>> 3 files changed, 74 insertions(+), 2 deletions(-)
> >>>
> >>
> >>
> >>> diff --git a/include/uapi/linux/fs.h b/include/uapi/linux/fs.h
> >>> index 0bd678a4a10e..68e65e6d7d6b 100644
> >>> --- a/include/uapi/linux/fs.h
> >>> +++ b/include/uapi/linux/fs.h
> >>> @@ -435,8 +435,12 @@ typedef int __bitwise __kernel_rwf_t;
> >>> RWF_APPEND | RWF_NOAPPEND | RWF_ATOMIC |\
> >>> RWF_DONTCACHE)
> >>>
> >>> +/* This matches XSDFEC_MAGIC, so we need to allocate subvalues carefully. */
> >>> #define PROCFS_IOCTL_MAGIC 'f'
> >>>
> >>> +/* procfs root ioctls */
> >>> +#define PROCFS_GET_PID_NAMESPACE _IO(PROCFS_IOCTL_MAGIC, 32)
> >>
> >> Since the _IO() nr here is 32, Documentation/userspace-api/ioctl/ioctl-number.rst
> >> should be updated like:
> >>
> >> -'f' 00-0F linux/fs.h conflict!
> >> +'f' 00-1F linux/fs.h conflict!
> >
> > Should this be 00-20 (or 00-2F) instead?
>
> Oops, yes, it should be one of those. Thanks.
>
> > Also, is there a better value to use for this new ioctl? I'm not quite
> > sure what is the best practice to handle these kinds of conflicts...
>
> I wouldn't worry about it. We have *many* conflicts.
> (unless Al or Christian are concerned)
We try to minimize conflicts but we unfortunately give no strong
guarantees in any way. I always defer to Arnd in such matters as he's
got a pretty good mental model of what is best to do for ioctls.
>
> >> (17 is already used for PROCFS_IOCTL_MAGIC somewhere else, so that probably should
> >> have update the Doc/rst file.)
^ permalink raw reply
* Re: [PATCH v4 2/4] procfs: add "pidns" mount option
From: Christian Brauner @ 2025-08-08 14:09 UTC (permalink / raw)
To: Aleksa Sarai
Cc: Askar Safin, amir73il, corbet, jack, linux-api, linux-doc,
linux-fsdevel, linux-kernel, linux-kselftest, luto, shuah, viro
In-Reply-To: <2025-08-07.1754550206-glad-sneeze-upstate-sorts-swank-courts-YKmj7E@cyphar.com>
On Thu, Aug 07, 2025 at 05:17:56PM +1000, Aleksa Sarai wrote:
> On 2025-08-07, Aleksa Sarai <cyphar@cyphar.com> wrote:
> > On 2025-08-06, Askar Safin <safinaskar@zohomail.com> wrote:
> > > > I just realised that we probably also want to support FSCONFIG_SET_PATH
> > >
> > > I just checked kernel code. Indeed nobody uses FSCONFIG_SET_PATH.
> > > Moreover, fsparam_path macro is present since 5.1. And for all this
> > > time nobody used it. So, let's just remove FSCONFIG_SET_PATH. Nobody
> > > used it, so this will not break anything.
> > >
> > > If you okay with that, I can submit patch, removing it.
> >
> > I would prefer you didn't -- "*at()" semantics are very useful to a lot
> > of programs (*especially* AT_EMPTY_PATH). I would like the pidns= stuff
> > to support it, and probably also overlayfs...
> >
> > I suspect the primary issue is that when migrating to the new mount API,
> > filesystem devs just went with the easiest thing to use
> > (FSCONFIG_SET_STRING) even though FSCONFIG_SET_PATH would be better. I
> > suspect the lack of documentation around fsconfig(2) played a part too.
> >
> > My impression is that interest in the minutia about fsconfig(2) is quite
> > low on the list of priorities for most filesystem devs, and so the neat
> > aspects of fsconfig(2) haven't been fully utilised. (In LPC last year,
> > we struggled to come to an agreement on how filesystems should use the
> > read(2)-based error interface.)
> >
> > We can very easily move fsparam_string() or fsparam_file_or_string()
> > parameters to fsparam_path() and a future fsparam_file_or_path(). I
> > would much prefer that as a user.
>
> Actually, fsparam_bdev() accepts FSCONFIG_SET_PATH in a very roundabout
> way (and the checker doesn't verify anything...?). So there is at least
> one user (ext4's "journal_path"), it's just not well-documented (which
> I'm trying to fix ;]).
>
> My plan is to update fs_lookup_param() to be more useful for the (fairly
> common) use-case of wanting to support paths and file descriptors, and
> going through to clean up some of these unused fsparam_* helpers (or
> fsparam_* helpers being abused to implement stuff that the fs_parser
> core already supports).
>
> At the very least, overlayfs, ext4, and this procfs patchset can make
> use of it.
I've never bothered with actually iplementing FSCONFIG_SET_PATH
semantics because I think it's really weird to allow *at semantics when
setting filesystem parameters. I always thought it's better to force
userspace to provide a file descriptor for the final destination instead
of doing some arcane lookup variant for mount configuration. But I'm
happy to be convinced of its usefulness...
^ permalink raw reply
* Re: [PATCH v3 02/30] kho: mm: Don't allow deferred struct page with KHO
From: Pasha Tatashin @ 2025-08-08 14:01 UTC (permalink / raw)
To: Pratyush Yadav
Cc: jasonmiu, graf, changyuanl, rppt, 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, lennart,
brauner, linux-api, linux-fsdevel, saeedm, ajayachandra, jgg,
parav, leonro, witu
In-Reply-To: <mafs0jz3eavci.fsf@kernel.org>
On Fri, Aug 8, 2025 at 11:47 AM Pratyush Yadav <pratyush@kernel.org> wrote:
>
> On Thu, Aug 07 2025, Pasha Tatashin wrote:
>
> > KHO uses struct pages for the preserved memory early in boot, however,
> > with deferred struct page initialization, only a small portion of
> > memory has properly initialized struct pages.
> >
> > This problem was detected where vmemmap is poisoned, and illegal flag
> > combinations are detected.
> >
> > Don't allow them to be enabled together, and later we will have to
> > teach KHO to work properly with deferred struct page init kernel
> > feature.
> >
> > Fixes: 990a950fe8fd ("kexec: add config option for KHO")
> >
> > Signed-off-by: Pasha Tatashin <pasha.tatashin@soleen.com>
>
> Nit: Drop the blank line before fixes. git interpret-trailers doesn't
Makes sense.
> seem to recognize the fixes otherwise, so this may break some tooling.
> Try it yourself:
>
> $ git interpret-trailers --parse commit_message.txt
>
> Other than this,
>
> Acked-by: Pratyush Yadav <pratyush@kernel.org>
Thank you for the review.
Pasha
>
> > Acked-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
> > ---
> > kernel/Kconfig.kexec | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/kernel/Kconfig.kexec b/kernel/Kconfig.kexec
> > index 2ee603a98813..1224dd937df0 100644
> > --- a/kernel/Kconfig.kexec
> > +++ b/kernel/Kconfig.kexec
> > @@ -97,6 +97,7 @@ config KEXEC_JUMP
> > config KEXEC_HANDOVER
> > bool "kexec handover"
> > depends on ARCH_SUPPORTS_KEXEC_HANDOVER && ARCH_SUPPORTS_KEXEC_FILE
> > + depends on !DEFERRED_STRUCT_PAGE_INIT
> > select MEMBLOCK_KHO_SCRATCH
> > select KEXEC_FILE
> > select DEBUG_FS
>
> --
> Regards,
> Pratyush Yadav
^ permalink raw reply
* Re: [PATCH v2 05/11] fsconfig.2: document 'new' mount api
From: Askar Safin @ 2025-08-08 14:00 UTC (permalink / raw)
To: Aleksa Sarai
Cc: Alejandro Colomar, Michael T. Kerrisk, Alexander Viro, Jan Kara,
G. Branden Robinson, linux-man, linux-api, linux-fsdevel,
linux-kernel, David Howells, Christian Brauner
In-Reply-To: <20250807-new-mount-api-v2-5-558a27b8068c@cyphar.com>
Let's consider this example:
int fsfd, mntfd, nsfd, nsdirfd;
nsfd = open("/proc/self/ns/pid", O_PATH);
nsdirfd = open("/proc/1/ns", O_DIRECTORY);
fsfd = fsopen("proc", FSOPEN_CLOEXEC);
/* "pidns" changes the value each time. */
fsconfig(fsfd, FSCONFIG_SET_PATH, "pidns", "/proc/self/ns/pid", AT_FDCWD);
fsconfig(fsfd, FSCONFIG_SET_PATH, "pidns", "pid", NULL, nsdirfd);
fsconfig(fsfd, FSCONFIG_SET_PATH_EMPTY, "pidns", "", nsfd);
fsconfig(fsfd, FSCONFIG_SET_FD, "pidns", NULL, nsfd);
fsconfig(fsfd, FSCONFIG_CMD_CREATE, NULL, NULL, 0);
mntfd = fsmount(fsfd, FSMOUNT_CLOEXEC, 0);
move_mount(mntfd, "", AT_FDCWD, "/proc", MOVE_MOUNT_F_EMPTY_PATH);
I don't like it. /proc/self/ns/pid is our namespace, which is default anyway.
I. e. setting pidns to /proc/self/ns/pid is no-op (assuming that "pidns" option is implemented in our kernel, of course).
Moreover, if /proc is mounted properly, then /proc/1/ns/pid refers to our namespace, too!
Thus, *all* these fsconfig(FSCONFIG_SET_...) calls are no-op.
Thus it is bad example.
I suggest using, say, /proc/2/ns/pid . It has actual chance to refer to some other namespace.
Also, sentence '"pidns" changes the value each time' is a lie: as I explained, all these calls are no-ops,
they don't really change anything.
--
Askar Safin
https://types.pl/@safinaskar
^ permalink raw reply
* Re: [PATCH v3 01/30] kho: init new_physxa->phys_bits to fix lockdep
From: Pasha Tatashin @ 2025-08-08 14:00 UTC (permalink / raw)
To: Pratyush Yadav
Cc: jasonmiu, graf, changyuanl, rppt, 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, lennart,
brauner, linux-api, linux-fsdevel, saeedm, ajayachandra, jgg,
parav, leonro, witu
In-Reply-To: <mafs0bjoqav4j.fsf@kernel.org>
On Fri, Aug 8, 2025 at 11:52 AM Pratyush Yadav <pratyush@kernel.org> wrote:
>
> On Fri, Aug 08 2025, Pratyush Yadav wrote:
> [...]
> >> @@ -144,14 +144,35 @@ static int __kho_preserve_order(struct kho_mem_track *track, unsigned long pfn,
> >> unsigned int order)
> >> {
> >> struct kho_mem_phys_bits *bits;
> >> - struct kho_mem_phys *physxa;
> >> + struct kho_mem_phys *physxa, *new_physxa;
> >> const unsigned long pfn_high = pfn >> order;
> >>
> >> might_sleep();
> >>
> >> - physxa = xa_load_or_alloc(&track->orders, order, sizeof(*physxa));
> >> - if (IS_ERR(physxa))
> >> - return PTR_ERR(physxa);
> >> + physxa = xa_load(&track->orders, order);
> >> + if (!physxa) {
> >> + new_physxa = kzalloc(sizeof(*physxa), GFP_KERNEL);
> >> + if (!new_physxa)
> >> + return -ENOMEM;
> >> +
> >> + xa_init(&new_physxa->phys_bits);
> >> + physxa = xa_cmpxchg(&track->orders, order, NULL, new_physxa,
> >> + GFP_KERNEL);
> >> + if (xa_is_err(physxa)) {
> >> + int err = xa_err(physxa);
> >> +
> >> + xa_destroy(&new_physxa->phys_bits);
> >> + kfree(new_physxa);
> >> +
> >> + return err;
> >> + }
> >> + if (physxa) {
> >> + xa_destroy(&new_physxa->phys_bits);
> >> + kfree(new_physxa);
> >> + } else {
> >> + physxa = new_physxa;
> >> + }
> >
> > I suppose this could be simplified a bit to:
> >
> > err = xa_err(physxa);
> > if (err || physxa) {
> > xa_destroy(&new_physxa->phys_bits);
> > kfree(new_physxa);
> >
> > if (err)
> > return err;
> > } else {
> > physxa = new_physxa;
> > }
>
> My email client completely messed the whitespace up so this is a bit
> unreadable. Here is what I meant:
>
> err = xa_err(physxa);
> if (err || physxa) {
> xa_destroy(&new_physxa->phys_bits);
> kfree(new_physxa);
>
> if (err)
> return err;
> } else {
> physxa = new_physxa;
> }
>
> [...]
Thanks Pratyush, I will make this simplification change if Andrew does
not take this patch in before the next revision.
Pasha
^ permalink raw reply
* Re: [PATCH v3 00/30] Live Update Orchestrator
From: Pasha Tatashin @ 2025-08-08 13:53 UTC (permalink / raw)
To: Pratyush Yadav
Cc: David Hildenbrand, jasonmiu, graf, changyuanl, rppt, 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, 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, lennart, brauner, linux-api, linux-fsdevel,
saeedm, ajayachandra, jgg, parav, leonro, witu, Hugh Dickins,
Baolin Wang
In-Reply-To: <mafs07bzeatmf.fsf@kernel.org>
>
> And now that I think about it, I suppose patch 29 should also add
> memfd_luo.c under the SHMEM MAINTAINERS entry.
Right, let's update this in the next revision.
Thanks,
Pasha
^ permalink raw reply
* Re: [PATCH v3 00/30] Live Update Orchestrator
From: Pasha Tatashin @ 2025-08-08 13:52 UTC (permalink / raw)
To: David Hildenbrand
Cc: pratyush, jasonmiu, graf, changyuanl, rppt, 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, 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,
Hugh Dickins
In-Reply-To: <b227482a-31ec-4c92-a856-bd19f72217b7@redhat.com>
On Fri, Aug 8, 2025 at 12:07 PM David Hildenbrand <david@redhat.com> wrote:
>
> On 07.08.25 03:44, Pasha Tatashin wrote:
> > This series introduces the LUO, a kernel subsystem designed to
> > facilitate live kernel updates with minimal downtime,
> > particularly in cloud delplyoments aiming to update without fully
> > disrupting running virtual machines.
> >
> > This series builds upon KHO framework by adding programmatic
> > control over KHO's lifecycle and leveraging KHO for persisting LUO's
> > own metadata across the kexec boundary. The git branch for this series
> > can be found at:
> >
> > https://github.com/googleprodkernel/linux-liveupdate/tree/luo/v3
> >
> > Changelog from v2:
> > - Addressed comments from Mike Rapoport and Jason Gunthorpe
> > - Only one user agent (LiveupdateD) can open /dev/liveupdate
> > - Release all preserved resources if /dev/liveupdate closes
> > before reboot.
> > - With the above changes, sessions are not needed, and should be
> > maintained by the user-agent itself, so removed support for
> > sessions.
> > - Added support for changing per-FD state (i.e. some FDs can be
> > prepared or finished before the global transition.
> > - All IOCTLs now follow iommufd/fwctl extendable design.
> > - Replaced locks with guards
> > - Added a callback for registered subsystems to be notified
> > during boot: ops->boot().
> > - Removed args from callbacks, instead use container_of() to
> > carry context specific data (see luo_selftests.c for example).
> > - removed patches for luolib, they are going to be introduced in
> > a separate repository.
> >
> > What is Live Update?
> > Live Update is a kexec based reboot process where selected kernel
> > resources (memory, file descriptors, and eventually devices) are kept
> > operational or their state preserved across a kernel transition. For
> > certain resources, DMA and interrupt activity might continue with
> > minimal interruption during the kernel reboot.
> >
> > LUO provides a framework for coordinating live updates. It features:
> > State Machine: Manages the live update process through states:
> > NORMAL, PREPARED, FROZEN, UPDATED.
> >
> > KHO Integration:
> >
> > LUO programmatically drives KHO's finalization and abort sequences.
> > KHO's debugfs interface is now optional configured via
> > CONFIG_KEXEC_HANDOVER_DEBUG.
> >
> > LUO preserves its own metadata via KHO's kho_add_subtree and
> > kho_preserve_phys() mechanisms.
> >
> > Subsystem Participation: A callback API liveupdate_register_subsystem()
> > allows kernel subsystems (e.g., KVM, IOMMU, VFIO, PCI) to register
> > handlers for LUO events (PREPARE, FREEZE, FINISH, CANCEL) and persist a
> > u64 payload via the LUO FDT.
> >
> > File Descriptor Preservation: Infrastructure
> > liveupdate_register_filesystem, luo_register_file, luo_retrieve_file to
> > allow specific types of file descriptors (e.g., memfd, vfio) to be
> > preserved and restored.
> >
> > Handlers for specific file types can be registered to manage their
> > preservation and restoration, storing a u64 payload in the LUO FDT.
> >
> > User-space Interface:
> >
> > ioctl (/dev/liveupdate): The primary control interface for
> > triggering LUO state transitions (prepare, freeze, finish, cancel)
> > and managing the preservation/restoration of file descriptors.
> > Access requires CAP_SYS_ADMIN.
> >
> > sysfs (/sys/kernel/liveupdate/state): A read-only interface for
> > monitoring the current LUO state. This allows userspace services to
> > track progress and coordinate actions.
> >
> > Selftests: Includes kernel-side hooks and userspace selftests to
> > verify core LUO functionality, particularly subsystem registration and
> > basic state transitions.
> >
> > LUO State Machine and Events:
> >
> > NORMAL: Default operational state.
> > PREPARED: Initial preparation complete after LIVEUPDATE_PREPARE
> > event. Subsystems have saved initial state.
> > FROZEN: Final "blackout window" state after LIVEUPDATE_FREEZE
> > event, just before kexec. Workloads must be suspended.
> > UPDATED: Next kernel has booted via live update. Awaiting restoration
> > and LIVEUPDATE_FINISH.
> >
> > Events:
> > LIVEUPDATE_PREPARE: Prepare for reboot, serialize state.
> > LIVEUPDATE_FREEZE: Final opportunity to save state before kexec.
> > LIVEUPDATE_FINISH: Post-reboot cleanup in the next kernel.
> > LIVEUPDATE_CANCEL: Abort prepare or freeze, revert changes.
> >
> > v2: https://lore.kernel.org/all/20250723144649.1696299-1-pasha.tatashin@soleen.com
> > v1: https://lore.kernel.org/all/20250625231838.1897085-1-pasha.tatashin@soleen.com
> > RFC v2: https://lore.kernel.org/all/20250515182322.117840-1-pasha.tatashin@soleen.com
> > RFC v1: https://lore.kernel.org/all/20250320024011.2995837-1-pasha.tatashin@soleen.com
> >
> > Changyuan Lyu (1):
> > kho: add interfaces to unpreserve folios and physical memory ranges
> >
> > Mike Rapoport (Microsoft) (1):
> > kho: drop notifiers
> >
> > Pasha Tatashin (23):
> > kho: init new_physxa->phys_bits to fix lockdep
> > kho: mm: Don't allow deferred struct page with KHO
> > kho: warn if KHO is disabled due to an error
> > kho: allow to drive kho from within kernel
> > kho: make debugfs interface optional
> > kho: don't unpreserve memory during abort
> > liveupdate: kho: move to kernel/liveupdate
> > liveupdate: luo_core: luo_ioctl: Live Update Orchestrator
> > liveupdate: luo_core: integrate with KHO
> > liveupdate: luo_subsystems: add subsystem registration
> > liveupdate: luo_subsystems: implement subsystem callbacks
> > liveupdate: luo_files: add infrastructure for FDs
> > liveupdate: luo_files: implement file systems callbacks
> > liveupdate: luo_ioctl: add userpsace interface
> > liveupdate: luo_files: luo_ioctl: Unregister all FDs on device close
> > liveupdate: luo_files: luo_ioctl: Add ioctls for per-file state
> > management
> > liveupdate: luo_sysfs: add sysfs state monitoring
> > reboot: call liveupdate_reboot() before kexec
> > kho: move kho debugfs directory to liveupdate
> > liveupdate: add selftests for subsystems un/registration
> > selftests/liveupdate: add subsystem/state tests
> > docs: add luo documentation
> > MAINTAINERS: add liveupdate entry
> >
> > Pratyush Yadav (5):
> > mm: shmem: use SHMEM_F_* flags instead of VM_* flags
> > mm: shmem: allow freezing inode mapping
> > mm: shmem: export some functions to internal.h
> > luo: allow preserving memfd
> > docs: add documentation for memfd preservation via LUO
>
> It's not clear from the description why these mm shmem changes are
> buried in this patch set. It's not even described above in the patch
> description.
Hi David,
Yes, I should update the cover letter to include memfd preservation work.
> I suggest sending that part out separately, so Hugh actually spots this.
> (is he even CC'ed?)
+cc hughd@google.com
While MM list is CCed, you are right, I have not specifically CCed
shmem maintainers. This will be fixed in the next revision.
Thank you,
Pasha
^ permalink raw reply
* Re: [PATCH v2 0/2] vfs: output mount_too_revealing() errors to fscontext
From: Christian Brauner @ 2025-08-08 13:27 UTC (permalink / raw)
To: Aleksa Sarai
Cc: Christian Brauner, David Howells, linux-api, linux-kernel,
linux-fsdevel, Alexander Viro, Jan Kara
In-Reply-To: <20250806-errorfc-mount-too-revealing-v2-0-534b9b4d45bb@cyphar.com>
On Wed, 06 Aug 2025 16:07:04 +1000, Aleksa Sarai wrote:
> It makes little sense for fsmount() to output the warning message when
> mount_too_revealing() is violated to kmsg. Instead, the warning should
> be output (with a "VFS" prefix) to the fscontext log. In addition,
> include the same log message for mount_too_revealing() when doing a
> regular mount for consistency.
>
> With the newest fsopen()-based mount(8) from util-linux, the error
> messages now look like
>
> [...]
Nice, thank you!
---
Applied to the vfs-6.18.mount branch of the vfs/vfs.git tree.
Patches in the vfs-6.18.mount branch should appear in linux-next soon.
Please report any outstanding bugs that were missed during review in a
new review to the original patch series allowing us to drop it.
It's encouraged to provide Acked-bys and Reviewed-bys even though the
patch has now been applied. If possible patch trailers will be updated.
Note that commit hashes shown below are subject to change due to rebase,
trailer updates or similar. If in doubt, please check the listed branch.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs.git
branch: vfs-6.18.mount
[1/2] fscontext: add custom-prefix log helpers
https://git.kernel.org/vfs/vfs/c/49e998eb0154
[2/2] vfs: output mount_too_revealing() errors to fscontext
https://git.kernel.org/vfs/vfs/c/3441e1534e67
^ permalink raw reply
* Re: [PATCH v2 08/11] open_tree.2: document 'new' mount api
From: Aleksa Sarai @ 2025-08-08 13:26 UTC (permalink / raw)
To: Askar Safin
Cc: Alejandro Colomar, Michael T. Kerrisk, Alexander Viro, Jan Kara,
G. Branden Robinson, linux-man, linux-api, linux-fsdevel,
linux-kernel, David Howells, Christian Brauner
In-Reply-To: <19889ab0576.e4d2f37341528.6111844101094013469@zohomail.com>
[-- Attachment #1: Type: text/plain, Size: 1000 bytes --]
On 2025-08-08, Askar Safin <safinaskar@zohomail.com> wrote:
> In "man open_tree":
>
> > As with "*at()" system calls, fspick() uses the dirfd argument in conjunction
>
> You meant "open_tree"
>
> > If flags does not contain OPEN_TREE_CLONE, open_tree() returns
> > a file descriptor that is exactly equivalent to one produced by open(2).
>
> Please, change "by open(2)" to "by openat(2) with O_PATH" (and other similar places).
I think the more common pattern in man-pages is to prefer to refer to
open(2) unless you are explicitly talking about openat(2) features (like
passing a dirfd). If it's just "a file descriptor with O_PATH" then most
man-pages I've seen reference open(2) even if they were written
post-openat(2).
Though in this case, since we are talking about open_tree(2) as an open
operation that takes a dirfd, you're right that openat(2) might be
better.
--
Aleksa Sarai
Senior Software Engineer (Containers)
SUSE Linux GmbH
https://www.cyphar.com/
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v4 0/2] man/man2/mremap.2: describe multiple mapping move, shrink
From: Lorenzo Stoakes @ 2025-08-08 13:15 UTC (permalink / raw)
To: Alejandro Colomar
Cc: linux-man, Andrew Morton, Peter Xu, Alexander Viro,
Christian Brauner, Jan Kara, Liam R . Howlett, Vlastimil Babka,
Jann Horn, Pedro Falcato, Rik van Riel, linux-mm, linux-kernel,
linux-api
In-Reply-To: <cover.1754414738.git.lorenzo.stoakes@oracle.com>
On Tue, Aug 05, 2025 at 06:31:54PM +0100, Lorenzo Stoakes wrote:
> We have added new functionality to mremap() in Linux 6.17, permitting the
> move of multiple VMAs when performing a move alone (that is - providing
> MREMAP_MAYMOVE | MREMAP_FIXED flags and specifying old_size == new_size).
>
> We document this new feature.
>
> Additionally, we document previously undocumented behaviour around
> shrinking of input VMA ranges which permits the input range to span
> multiple VMAs.
>
> v4:
> * Update description of newly discovered mremap() behaviour to highlight the
> fact that, if in-place, [old_address, old_address + new_length) may span
> multiple VMAs also.
> * Fix up commit message for 2/2 to correct typo on specified range.
> * Added code sample to 1/2 as per Alejandro.
>
> v3:
> * Use more precise language around mremap() move description as per Jann.
> * Fix some typos in commit messages.
> https://lore.kernel.org/all/cover.1753795807.git.lorenzo.stoakes@oracle.com/
>
> v2:
> * Split out the two man page changes as requested by Alejandro.
> https://lore.kernel.org/all/cover.1753711160.git.lorenzo.stoakes@oracle.com/
>
> v1:
> https://lore.kernel.org/all/20250723174634.75054-1-lorenzo.stoakes@oracle.com/
>
> Lorenzo Stoakes (2):
> man/man2/mremap.2: describe multiple mapping move
> man/man2/mremap.2: describe previously undocumented shrink behaviour
>
> man/man2/mremap.2 | 111 +++++++++++++++++++++++++++++++++++++++++-----
> 1 file changed, 100 insertions(+), 11 deletions(-)
>
> --
> 2.50.1
Hey Alejandro,
Just wondering if this has everything you need, let me know if there's
anything I need to do here!
Cheers, Lorenzo
^ permalink raw reply
* Re: [PATCH v2 00/11] man2: add man pages for 'new' mount API
From: Christian Brauner @ 2025-08-08 12:53 UTC (permalink / raw)
To: Aleksa Sarai
Cc: Alejandro Colomar, Michael T. Kerrisk, Alexander Viro, Jan Kara,
Askar Safin, G. Branden Robinson, linux-man, linux-api,
linux-fsdevel, linux-kernel, David Howells
In-Reply-To: <20250807-new-mount-api-v2-0-558a27b8068c@cyphar.com>
On Thu, Aug 07, 2025 at 03:44:34AM +1000, Aleksa Sarai wrote:
> Back in 2019, the new mount API was merged into mainline[1]. David Howells
> then set about writing man pages for these new APIs, and sent some
> patches back in 2020[2]. Unfortunately, these patches were never merged,
> which meant that these APIs were practically undocumented for many
> years -- arguably this may have been a contributing factor to the
> relatively slow adoption of these new (far better) APIs. I have often
> discovered that many folks are unaware of the read(2)-based message
> retrieval interface provided by filesystem context file descriptors.
>
> In 2024, Christian Brauner set aside some time to provide some
> documentation of these new APIs and so adapted David Howell's original
> man pages into the easier-to-edit Markdown format and published them on
> GitHub[3]. These have been maintained since, including updated
> information on new features added since David Howells's 2020 draft pages
> (such as MOVE_MOUNT_BENEATH).
>
> While this was a welcome improvement to the previous status quo (that
> had lasted over 6 years), speaking personally my experience is that not
> having access to these man pages from the terminal has been a fairly
> common painpoint.
>
> So, this is a modern version of the man pages for these APIs, in the hopes
> that we can finally (7 years later) get proper documentation for these
> APIs in the man-pages project.
>
> One important thing to note is that most of these were re-written by me,
> with very minimal copying from the versions available from Christian[2].
> The reasons for this are two-fold:
>
> * Both Howells's original version and Christian's maintained versions
> contain crucial mistakes that I have been bitten by in the past (the
"Lies, damned lies, and statistics."
> most obvious being that all of these APIs were merged in Linux 5.2,
> but the man pages all claim they were merged in different versions.)
>
> * As the man pages appear to have been written from Howells's
> perspective while implementing them, some of the wording is a little
> too tied to the implementation (or appears to describe features that
> don't really exist in the merged versions of these APIs).
>
> I decided that the best way to resolve these issues is to rewrite them
> from the perspective of an actual user of these APIs (me), and check
> that we do not repeat the mistakes I found in the originals.
>
> I have also done my best to resolve the issues raised by Michael Kerrisk
> on the original patchset sent by Howells[1].
>
> In addition, I have also included a man page for open_tree_attr(2) (as a
> subsection of the new open_tree(2) man page), which was merged in Linux
> 6.15.
>
> [1]: https://lore.kernel.org/all/20190507204921.GL23075@ZenIV.linux.org.uk/
> [2]: https://lore.kernel.org/linux-man/159680892602.29015.6551860260436544999.stgit@warthog.procyon.org.uk/
> [3]: https://github.com/brauner/man-pages-md
>
> Co-developed-by: David Howells <dhowells@redhat.com>
> Co-developed-by: Christian Brauner <brauner@kernel.org>
> Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>
> ---
Thanks for doing this! Just a point of order. If you add CdB you also
need to add SoB for all of them.
^ permalink raw reply
* Re: [PATCH v2 08/11] open_tree.2: document 'new' mount api
From: Askar Safin @ 2025-08-08 12:32 UTC (permalink / raw)
To: Aleksa Sarai
Cc: Alejandro Colomar, Michael T. Kerrisk, Alexander Viro, Jan Kara,
G. Branden Robinson, linux-man, linux-api, linux-fsdevel,
linux-kernel, David Howells, Christian Brauner
In-Reply-To: <20250807-new-mount-api-v2-8-558a27b8068c@cyphar.com>
In "man open_tree":
> As with "*at()" system calls, fspick() uses the dirfd argument in conjunction
You meant "open_tree"
> If flags does not contain OPEN_TREE_CLONE, open_tree() returns
> a file descriptor that is exactly equivalent to one produced by open(2).
Please, change "by open(2)" to "by openat(2) with O_PATH" (and other similar places).
--
Askar Safin
https://types.pl/@safinaskar
^ permalink raw reply
* Re: [PATCH v3 00/30] Live Update Orchestrator
From: Pratyush Yadav @ 2025-08-08 12:24 UTC (permalink / raw)
To: David Hildenbrand
Cc: Pasha Tatashin, pratyush, jasonmiu, graf, changyuanl, rppt,
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, 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, lennart, brauner, linux-api,
linux-fsdevel, saeedm, ajayachandra, jgg, parav, leonro, witu,
Hugh Dickins, Baolin Wang
In-Reply-To: <b227482a-31ec-4c92-a856-bd19f72217b7@redhat.com>
On Fri, Aug 08 2025, David Hildenbrand wrote:
> On 07.08.25 03:44, Pasha Tatashin wrote:
>> This series introduces the LUO, a kernel subsystem designed to
>> facilitate live kernel updates with minimal downtime,
>> particularly in cloud delplyoments aiming to update without fully
>> disrupting running virtual machines.
>> This series builds upon KHO framework by adding programmatic
>> control over KHO's lifecycle and leveraging KHO for persisting LUO's
>> own metadata across the kexec boundary. The git branch for this series
>> can be found at:
>> https://github.com/googleprodkernel/linux-liveupdate/tree/luo/v3
>> Changelog from v2:
>> - Addressed comments from Mike Rapoport and Jason Gunthorpe
>> - Only one user agent (LiveupdateD) can open /dev/liveupdate
>> - Release all preserved resources if /dev/liveupdate closes
>> before reboot.
>> - With the above changes, sessions are not needed, and should be
>> maintained by the user-agent itself, so removed support for
>> sessions.
>> - Added support for changing per-FD state (i.e. some FDs can be
>> prepared or finished before the global transition.
>> - All IOCTLs now follow iommufd/fwctl extendable design.
>> - Replaced locks with guards
>> - Added a callback for registered subsystems to be notified
>> during boot: ops->boot().
>> - Removed args from callbacks, instead use container_of() to
>> carry context specific data (see luo_selftests.c for example).
>> - removed patches for luolib, they are going to be introduced in
>> a separate repository.
>> What is Live Update?
>> Live Update is a kexec based reboot process where selected kernel
>> resources (memory, file descriptors, and eventually devices) are kept
>> operational or their state preserved across a kernel transition. For
>> certain resources, DMA and interrupt activity might continue with
>> minimal interruption during the kernel reboot.
>> LUO provides a framework for coordinating live updates. It features:
>> State Machine: Manages the live update process through states:
>> NORMAL, PREPARED, FROZEN, UPDATED.
>> KHO Integration:
>> LUO programmatically drives KHO's finalization and abort sequences.
>> KHO's debugfs interface is now optional configured via
>> CONFIG_KEXEC_HANDOVER_DEBUG.
>> LUO preserves its own metadata via KHO's kho_add_subtree and
>> kho_preserve_phys() mechanisms.
>> Subsystem Participation: A callback API liveupdate_register_subsystem()
>> allows kernel subsystems (e.g., KVM, IOMMU, VFIO, PCI) to register
>> handlers for LUO events (PREPARE, FREEZE, FINISH, CANCEL) and persist a
>> u64 payload via the LUO FDT.
>> File Descriptor Preservation: Infrastructure
>> liveupdate_register_filesystem, luo_register_file, luo_retrieve_file to
>> allow specific types of file descriptors (e.g., memfd, vfio) to be
>> preserved and restored.
>> Handlers for specific file types can be registered to manage their
>> preservation and restoration, storing a u64 payload in the LUO FDT.
>> User-space Interface:
>> ioctl (/dev/liveupdate): The primary control interface for
>> triggering LUO state transitions (prepare, freeze, finish, cancel)
>> and managing the preservation/restoration of file descriptors.
>> Access requires CAP_SYS_ADMIN.
>> sysfs (/sys/kernel/liveupdate/state): A read-only interface for
>> monitoring the current LUO state. This allows userspace services to
>> track progress and coordinate actions.
>> Selftests: Includes kernel-side hooks and userspace selftests to
>> verify core LUO functionality, particularly subsystem registration and
>> basic state transitions.
>> LUO State Machine and Events:
>> NORMAL: Default operational state.
>> PREPARED: Initial preparation complete after LIVEUPDATE_PREPARE
>> event. Subsystems have saved initial state.
>> FROZEN: Final "blackout window" state after LIVEUPDATE_FREEZE
>> event, just before kexec. Workloads must be suspended.
>> UPDATED: Next kernel has booted via live update. Awaiting restoration
>> and LIVEUPDATE_FINISH.
>> Events:
>> LIVEUPDATE_PREPARE: Prepare for reboot, serialize state.
>> LIVEUPDATE_FREEZE: Final opportunity to save state before kexec.
>> LIVEUPDATE_FINISH: Post-reboot cleanup in the next kernel.
>> LIVEUPDATE_CANCEL: Abort prepare or freeze, revert changes.
>> v2:
>> https://lore.kernel.org/all/20250723144649.1696299-1-pasha.tatashin@soleen.com
>> v1: https://lore.kernel.org/all/20250625231838.1897085-1-pasha.tatashin@soleen.com
>> RFC v2: https://lore.kernel.org/all/20250515182322.117840-1-pasha.tatashin@soleen.com
>> RFC v1: https://lore.kernel.org/all/20250320024011.2995837-1-pasha.tatashin@soleen.com
>> Changyuan Lyu (1):
>> kho: add interfaces to unpreserve folios and physical memory ranges
>> Mike Rapoport (Microsoft) (1):
>> kho: drop notifiers
>> Pasha Tatashin (23):
>> kho: init new_physxa->phys_bits to fix lockdep
>> kho: mm: Don't allow deferred struct page with KHO
>> kho: warn if KHO is disabled due to an error
>> kho: allow to drive kho from within kernel
>> kho: make debugfs interface optional
>> kho: don't unpreserve memory during abort
>> liveupdate: kho: move to kernel/liveupdate
>> liveupdate: luo_core: luo_ioctl: Live Update Orchestrator
>> liveupdate: luo_core: integrate with KHO
>> liveupdate: luo_subsystems: add subsystem registration
>> liveupdate: luo_subsystems: implement subsystem callbacks
>> liveupdate: luo_files: add infrastructure for FDs
>> liveupdate: luo_files: implement file systems callbacks
>> liveupdate: luo_ioctl: add userpsace interface
>> liveupdate: luo_files: luo_ioctl: Unregister all FDs on device close
>> liveupdate: luo_files: luo_ioctl: Add ioctls for per-file state
>> management
>> liveupdate: luo_sysfs: add sysfs state monitoring
>> reboot: call liveupdate_reboot() before kexec
>> kho: move kho debugfs directory to liveupdate
>> liveupdate: add selftests for subsystems un/registration
>> selftests/liveupdate: add subsystem/state tests
>> docs: add luo documentation
>> MAINTAINERS: add liveupdate entry
>> Pratyush Yadav (5):
>> mm: shmem: use SHMEM_F_* flags instead of VM_* flags
>> mm: shmem: allow freezing inode mapping
>> mm: shmem: export some functions to internal.h
>> luo: allow preserving memfd
>> docs: add documentation for memfd preservation via LUO
>
> It's not clear from the description why these mm shmem changes are buried in
> this patch set. It's not even described above in the patch description.
Patches 26-30 describe the shmem changes in more detail, but you're
right, it should be mentioned in the cover as well.
The idea is, LUO is used to preserve kernel resources across kexec. One
of the most fundamental resources the kernel has is memory. Since LUO
does preservation based on file descriptors, memfd is the way to attach
a FD to memory. So we went with memfd as the first user of LUO. memfd
can be backed by shmem or hugetlb, but currently only shmem is
supported. We do plan to support hugetlb as well in the future.
The idea is to keep the serialization/live update logic out of the way
of the main subsystem. So we decided to keep the logic out in a separate
file.
>
> I suggest sending that part out separately, so Hugh actually spots this.
> (is he even CC'ed?)
Hmm, none of the shmem maintainers are included. I wonder why. The
patches do touch shmem.c and shmem_fs.h so the MAINTAINERS entry for
"TMPFS (SHMEM FILESYSTEM)" should have been hit. My guess is that the
shmem changes weren't part of the original RFC so perhaps Pasha forgot
to update the To/Cc list since then?
Either way, I've added Hugh and Baolin to this email. Hugh, Baolin, you
can find the shmem related patches at [0][1][2][3][4].
Pasha, can you please add them for later versions as well?
And now that I think about it, I suppose patch 29 should also add
memfd_luo.c under the SHMEM MAINTAINERS entry.
[0] https://lore.kernel.org/lkml/20250807014442.3829950-27-pasha.tatashin@soleen.com/
[1] https://lore.kernel.org/lkml/20250807014442.3829950-28-pasha.tatashin@soleen.com/
[2] https://lore.kernel.org/lkml/20250807014442.3829950-29-pasha.tatashin@soleen.com/
[3] https://lore.kernel.org/lkml/20250807014442.3829950-30-pasha.tatashin@soleen.com/
[4] https://lore.kernel.org/lkml/20250807014442.3829950-31-pasha.tatashin@soleen.com/
--
Regards,
Pratyush Yadav
^ permalink raw reply
* Re: [PATCH v3 00/30] Live Update Orchestrator
From: David Hildenbrand @ 2025-08-08 12:07 UTC (permalink / raw)
To: Pasha Tatashin, pratyush, jasonmiu, graf, changyuanl, rppt,
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, 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
In-Reply-To: <20250807014442.3829950-1-pasha.tatashin@soleen.com>
On 07.08.25 03:44, Pasha Tatashin wrote:
> This series introduces the LUO, a kernel subsystem designed to
> facilitate live kernel updates with minimal downtime,
> particularly in cloud delplyoments aiming to update without fully
> disrupting running virtual machines.
>
> This series builds upon KHO framework by adding programmatic
> control over KHO's lifecycle and leveraging KHO for persisting LUO's
> own metadata across the kexec boundary. The git branch for this series
> can be found at:
>
> https://github.com/googleprodkernel/linux-liveupdate/tree/luo/v3
>
> Changelog from v2:
> - Addressed comments from Mike Rapoport and Jason Gunthorpe
> - Only one user agent (LiveupdateD) can open /dev/liveupdate
> - Release all preserved resources if /dev/liveupdate closes
> before reboot.
> - With the above changes, sessions are not needed, and should be
> maintained by the user-agent itself, so removed support for
> sessions.
> - Added support for changing per-FD state (i.e. some FDs can be
> prepared or finished before the global transition.
> - All IOCTLs now follow iommufd/fwctl extendable design.
> - Replaced locks with guards
> - Added a callback for registered subsystems to be notified
> during boot: ops->boot().
> - Removed args from callbacks, instead use container_of() to
> carry context specific data (see luo_selftests.c for example).
> - removed patches for luolib, they are going to be introduced in
> a separate repository.
>
> What is Live Update?
> Live Update is a kexec based reboot process where selected kernel
> resources (memory, file descriptors, and eventually devices) are kept
> operational or their state preserved across a kernel transition. For
> certain resources, DMA and interrupt activity might continue with
> minimal interruption during the kernel reboot.
>
> LUO provides a framework for coordinating live updates. It features:
> State Machine: Manages the live update process through states:
> NORMAL, PREPARED, FROZEN, UPDATED.
>
> KHO Integration:
>
> LUO programmatically drives KHO's finalization and abort sequences.
> KHO's debugfs interface is now optional configured via
> CONFIG_KEXEC_HANDOVER_DEBUG.
>
> LUO preserves its own metadata via KHO's kho_add_subtree and
> kho_preserve_phys() mechanisms.
>
> Subsystem Participation: A callback API liveupdate_register_subsystem()
> allows kernel subsystems (e.g., KVM, IOMMU, VFIO, PCI) to register
> handlers for LUO events (PREPARE, FREEZE, FINISH, CANCEL) and persist a
> u64 payload via the LUO FDT.
>
> File Descriptor Preservation: Infrastructure
> liveupdate_register_filesystem, luo_register_file, luo_retrieve_file to
> allow specific types of file descriptors (e.g., memfd, vfio) to be
> preserved and restored.
>
> Handlers for specific file types can be registered to manage their
> preservation and restoration, storing a u64 payload in the LUO FDT.
>
> User-space Interface:
>
> ioctl (/dev/liveupdate): The primary control interface for
> triggering LUO state transitions (prepare, freeze, finish, cancel)
> and managing the preservation/restoration of file descriptors.
> Access requires CAP_SYS_ADMIN.
>
> sysfs (/sys/kernel/liveupdate/state): A read-only interface for
> monitoring the current LUO state. This allows userspace services to
> track progress and coordinate actions.
>
> Selftests: Includes kernel-side hooks and userspace selftests to
> verify core LUO functionality, particularly subsystem registration and
> basic state transitions.
>
> LUO State Machine and Events:
>
> NORMAL: Default operational state.
> PREPARED: Initial preparation complete after LIVEUPDATE_PREPARE
> event. Subsystems have saved initial state.
> FROZEN: Final "blackout window" state after LIVEUPDATE_FREEZE
> event, just before kexec. Workloads must be suspended.
> UPDATED: Next kernel has booted via live update. Awaiting restoration
> and LIVEUPDATE_FINISH.
>
> Events:
> LIVEUPDATE_PREPARE: Prepare for reboot, serialize state.
> LIVEUPDATE_FREEZE: Final opportunity to save state before kexec.
> LIVEUPDATE_FINISH: Post-reboot cleanup in the next kernel.
> LIVEUPDATE_CANCEL: Abort prepare or freeze, revert changes.
>
> v2: https://lore.kernel.org/all/20250723144649.1696299-1-pasha.tatashin@soleen.com
> v1: https://lore.kernel.org/all/20250625231838.1897085-1-pasha.tatashin@soleen.com
> RFC v2: https://lore.kernel.org/all/20250515182322.117840-1-pasha.tatashin@soleen.com
> RFC v1: https://lore.kernel.org/all/20250320024011.2995837-1-pasha.tatashin@soleen.com
>
> Changyuan Lyu (1):
> kho: add interfaces to unpreserve folios and physical memory ranges
>
> Mike Rapoport (Microsoft) (1):
> kho: drop notifiers
>
> Pasha Tatashin (23):
> kho: init new_physxa->phys_bits to fix lockdep
> kho: mm: Don't allow deferred struct page with KHO
> kho: warn if KHO is disabled due to an error
> kho: allow to drive kho from within kernel
> kho: make debugfs interface optional
> kho: don't unpreserve memory during abort
> liveupdate: kho: move to kernel/liveupdate
> liveupdate: luo_core: luo_ioctl: Live Update Orchestrator
> liveupdate: luo_core: integrate with KHO
> liveupdate: luo_subsystems: add subsystem registration
> liveupdate: luo_subsystems: implement subsystem callbacks
> liveupdate: luo_files: add infrastructure for FDs
> liveupdate: luo_files: implement file systems callbacks
> liveupdate: luo_ioctl: add userpsace interface
> liveupdate: luo_files: luo_ioctl: Unregister all FDs on device close
> liveupdate: luo_files: luo_ioctl: Add ioctls for per-file state
> management
> liveupdate: luo_sysfs: add sysfs state monitoring
> reboot: call liveupdate_reboot() before kexec
> kho: move kho debugfs directory to liveupdate
> liveupdate: add selftests for subsystems un/registration
> selftests/liveupdate: add subsystem/state tests
> docs: add luo documentation
> MAINTAINERS: add liveupdate entry
>
> Pratyush Yadav (5):
> mm: shmem: use SHMEM_F_* flags instead of VM_* flags
> mm: shmem: allow freezing inode mapping
> mm: shmem: export some functions to internal.h
> luo: allow preserving memfd
> docs: add documentation for memfd preservation via LUO
It's not clear from the description why these mm shmem changes are
buried in this patch set. It's not even described above in the patch
description.
I suggest sending that part out separately, so Hugh actually spots this.
(is he even CC'ed?)
--
Cheers,
David / dhildenb
^ permalink raw reply
* Re: [PATCH v2 03/11] fsopen.2: document 'new' mount api
From: Aleksa Sarai @ 2025-08-08 11:57 UTC (permalink / raw)
To: Askar Safin
Cc: Alejandro Colomar, Michael T. Kerrisk, Alexander Viro, Jan Kara,
G. Branden Robinson, linux-man, linux-api, linux-fsdevel,
linux-kernel, David Howells, Christian Brauner
In-Reply-To: <19888ef84eb.11525d76e40004.7721042298577985399@zohomail.com>
[-- Attachment #1: Type: text/plain, Size: 626 bytes --]
On 2025-08-08, Askar Safin <safinaskar@zohomail.com> wrote:
> > If there are no messages in the message queue,
> > read(2) will return no data and errno will be set to ENODATA.
> > If the buf argument to read(2) is not large enough to contain the message,
> > read(2) will return no data and errno will be set to EMSGSIZE.
>
> read(2) will return -1 in these cases? If yes, then, please, write this.
Yes (well, the syscall returns -EMSGSIZE). I'll try to add a note
without making the paragraph too wordy...
--
Aleksa Sarai
Senior Software Engineer (Containers)
SUSE Linux GmbH
https://www.cyphar.com/
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v2 01/11] mount_setattr.2: document glibc >= 2.36 syscall wrappers
From: Aleksa Sarai @ 2025-08-08 11:55 UTC (permalink / raw)
To: Askar Safin
Cc: Alejandro Colomar, Michael T. Kerrisk, Alexander Viro, Jan Kara,
G. Branden Robinson, linux-man, linux-api, linux-fsdevel,
linux-kernel, David Howells, Christian Brauner
In-Reply-To: <19888fe1066.fcb132d640137.7051727418921685299@zohomail.com>
[-- Attachment #1: Type: text/plain, Size: 1243 bytes --]
On 2025-08-08, Askar Safin <safinaskar@zohomail.com> wrote:
> When I render "mount_setattr" from this (v2) pathset, I see weird quote mark. I. e.:
>
> $ MANWIDTH=10000 man /path/to/mount_setattr.2
> ...
> SYNOPSIS
> #include <fcntl.h> /* Definition of AT_* constants */
> #include <sys/mount.h>
>
> int mount_setattr(int dirfd, const char *path, unsigned int flags,
> struct mount_attr *attr, size_t size);"
> ...
Ah, my bad. "make -R lint-man" told me to put end quotes on the synopsis
lines, but I missed that there was a separate quote missing. This should
fix it:
diff --git a/man/man2/mount_setattr.2 b/man/man2/mount_setattr.2
index d44fafc93a20..46fcba927dd8 100644
--- a/man/man2/mount_setattr.2
+++ b/man/man2/mount_setattr.2
@@ -14,7 +14,7 @@ .SH SYNOPSIS
.B #include <sys/mount.h>
.P
.BI "int mount_setattr(int " dirfd ", const char *" path ", unsigned int " flags ","
-.BI " struct mount_attr *" attr ", size_t " size );"
+.BI " struct mount_attr *" attr ", size_t " size ");"
.fi
.SH DESCRIPTION
The
--
Aleksa Sarai
Senior Software Engineer (Containers)
SUSE Linux GmbH
https://www.cyphar.com/
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply related
* Re: [PATCH v3 01/30] kho: init new_physxa->phys_bits to fix lockdep
From: Pratyush Yadav @ 2025-08-08 11:52 UTC (permalink / raw)
To: Pratyush Yadav
Cc: Pasha Tatashin, jasonmiu, graf, changyuanl, rppt, 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, lennart, brauner, linux-api, linux-fsdevel,
saeedm, ajayachandra, jgg, parav, leonro, witu
In-Reply-To: <mafs0o6sqavkx.fsf@kernel.org>
On Fri, Aug 08 2025, Pratyush Yadav wrote:
[...]
>> @@ -144,14 +144,35 @@ static int __kho_preserve_order(struct kho_mem_track *track, unsigned long pfn,
>> unsigned int order)
>> {
>> struct kho_mem_phys_bits *bits;
>> - struct kho_mem_phys *physxa;
>> + struct kho_mem_phys *physxa, *new_physxa;
>> const unsigned long pfn_high = pfn >> order;
>>
>> might_sleep();
>>
>> - physxa = xa_load_or_alloc(&track->orders, order, sizeof(*physxa));
>> - if (IS_ERR(physxa))
>> - return PTR_ERR(physxa);
>> + physxa = xa_load(&track->orders, order);
>> + if (!physxa) {
>> + new_physxa = kzalloc(sizeof(*physxa), GFP_KERNEL);
>> + if (!new_physxa)
>> + return -ENOMEM;
>> +
>> + xa_init(&new_physxa->phys_bits);
>> + physxa = xa_cmpxchg(&track->orders, order, NULL, new_physxa,
>> + GFP_KERNEL);
>> + if (xa_is_err(physxa)) {
>> + int err = xa_err(physxa);
>> +
>> + xa_destroy(&new_physxa->phys_bits);
>> + kfree(new_physxa);
>> +
>> + return err;
>> + }
>> + if (physxa) {
>> + xa_destroy(&new_physxa->phys_bits);
>> + kfree(new_physxa);
>> + } else {
>> + physxa = new_physxa;
>> + }
>
> I suppose this could be simplified a bit to:
>
> err = xa_err(physxa);
> if (err || physxa) {
> xa_destroy(&new_physxa->phys_bits);
> kfree(new_physxa);
>
> if (err)
> return err;
> } else {
> physxa = new_physxa;
> }
My email client completely messed the whitespace up so this is a bit
unreadable. Here is what I meant:
err = xa_err(physxa);
if (err || physxa) {
xa_destroy(&new_physxa->phys_bits);
kfree(new_physxa);
if (err)
return err;
} else {
physxa = new_physxa;
}
[...]
--
Regards,
Pratyush Yadav
^ permalink raw reply
* Re: [PATCH v3 03/30] kho: warn if KHO is disabled due to an error
From: Pratyush Yadav @ 2025-08-08 11:48 UTC (permalink / raw)
To: Pasha Tatashin
Cc: pratyush, jasonmiu, graf, changyuanl, rppt, 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, lennart, brauner, linux-api, linux-fsdevel,
saeedm, ajayachandra, jgg, parav, leonro, witu
In-Reply-To: <20250807014442.3829950-4-pasha.tatashin@soleen.com>
On Thu, Aug 07 2025, Pasha Tatashin wrote:
> During boot scratch area is allocated based on command line
> parameters or auto calculated. However, scratch area may fail
> to allocate, and in that case KHO is disabled. Currently,
> no warning is printed that KHO is disabled, which makes it
> confusing for the end user to figure out why KHO is not
> available. Add the missing warning message.
>
> Signed-off-by: Pasha Tatashin <pasha.tatashin@soleen.com>
> Acked-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
Acked-by: Pratyush Yadav <pratyush@kernel.org>
--
Regards,
Pratyush Yadav
^ permalink raw reply
* Re: [PATCH v3 02/30] kho: mm: Don't allow deferred struct page with KHO
From: Pratyush Yadav @ 2025-08-08 11:47 UTC (permalink / raw)
To: Pasha Tatashin
Cc: pratyush, jasonmiu, graf, changyuanl, rppt, 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, lennart, brauner, linux-api, linux-fsdevel,
saeedm, ajayachandra, jgg, parav, leonro, witu
In-Reply-To: <20250807014442.3829950-3-pasha.tatashin@soleen.com>
On Thu, Aug 07 2025, Pasha Tatashin wrote:
> KHO uses struct pages for the preserved memory early in boot, however,
> with deferred struct page initialization, only a small portion of
> memory has properly initialized struct pages.
>
> This problem was detected where vmemmap is poisoned, and illegal flag
> combinations are detected.
>
> Don't allow them to be enabled together, and later we will have to
> teach KHO to work properly with deferred struct page init kernel
> feature.
>
> Fixes: 990a950fe8fd ("kexec: add config option for KHO")
>
> Signed-off-by: Pasha Tatashin <pasha.tatashin@soleen.com>
Nit: Drop the blank line before fixes. git interpret-trailers doesn't
seem to recognize the fixes otherwise, so this may break some tooling.
Try it yourself:
$ git interpret-trailers --parse commit_message.txt
Other than this,
Acked-by: Pratyush Yadav <pratyush@kernel.org>
> Acked-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
> ---
> kernel/Kconfig.kexec | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/kernel/Kconfig.kexec b/kernel/Kconfig.kexec
> index 2ee603a98813..1224dd937df0 100644
> --- a/kernel/Kconfig.kexec
> +++ b/kernel/Kconfig.kexec
> @@ -97,6 +97,7 @@ config KEXEC_JUMP
> config KEXEC_HANDOVER
> bool "kexec handover"
> depends on ARCH_SUPPORTS_KEXEC_HANDOVER && ARCH_SUPPORTS_KEXEC_FILE
> + depends on !DEFERRED_STRUCT_PAGE_INIT
> select MEMBLOCK_KHO_SCRATCH
> select KEXEC_FILE
> select DEBUG_FS
--
Regards,
Pratyush Yadav
^ permalink raw reply
* Re: [PATCH v3 01/30] kho: init new_physxa->phys_bits to fix lockdep
From: Pratyush Yadav @ 2025-08-08 11:42 UTC (permalink / raw)
To: Pasha Tatashin
Cc: pratyush, jasonmiu, graf, changyuanl, rppt, 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, lennart, brauner, linux-api, linux-fsdevel,
saeedm, ajayachandra, jgg, parav, leonro, witu
In-Reply-To: <20250807014442.3829950-2-pasha.tatashin@soleen.com>
Hi Pasha,
On Thu, Aug 07 2025, Pasha Tatashin wrote:
> Lockdep shows the following warning:
>
> INFO: trying to register non-static key.
> The code is fine but needs lockdep annotation, or maybe
> you didn't initialize this object before use?
> turning off the locking correctness validator.
>
> [<ffffffff810133a6>] dump_stack_lvl+0x66/0xa0
> [<ffffffff8136012c>] assign_lock_key+0x10c/0x120
> [<ffffffff81358bb4>] register_lock_class+0xf4/0x2f0
> [<ffffffff813597ff>] __lock_acquire+0x7f/0x2c40
> [<ffffffff81360cb0>] ? __pfx_hlock_conflict+0x10/0x10
> [<ffffffff811707be>] ? native_flush_tlb_global+0x8e/0xa0
> [<ffffffff8117096e>] ? __flush_tlb_all+0x4e/0xa0
> [<ffffffff81172fc2>] ? __kernel_map_pages+0x112/0x140
> [<ffffffff813ec327>] ? xa_load_or_alloc+0x67/0xe0
> [<ffffffff81359556>] lock_acquire+0xe6/0x280
> [<ffffffff813ec327>] ? xa_load_or_alloc+0x67/0xe0
> [<ffffffff8100b9e0>] _raw_spin_lock+0x30/0x40
> [<ffffffff813ec327>] ? xa_load_or_alloc+0x67/0xe0
> [<ffffffff813ec327>] xa_load_or_alloc+0x67/0xe0
> [<ffffffff813eb4c0>] kho_preserve_folio+0x90/0x100
> [<ffffffff813ebb7f>] __kho_finalize+0xcf/0x400
> [<ffffffff813ebef4>] kho_finalize+0x34/0x70
>
> This is becase xa has its own lock, that is not initialized in
> xa_load_or_alloc.
>
> Modifiy __kho_preserve_order(), to properly call
> xa_init(&new_physxa->phys_bits);
>
> Fixes: fc33e4b44b27 ("kexec: enable KHO support for memory preservation")
> Signed-off-by: Pasha Tatashin <pasha.tatashin@soleen.com>
> Acked-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
> ---
> kernel/kexec_handover.c | 29 +++++++++++++++++++++++++----
> 1 file changed, 25 insertions(+), 4 deletions(-)
>
> diff --git a/kernel/kexec_handover.c b/kernel/kexec_handover.c
> index e49743ae52c5..6240bc38305b 100644
> --- a/kernel/kexec_handover.c
> +++ b/kernel/kexec_handover.c
> @@ -144,14 +144,35 @@ static int __kho_preserve_order(struct kho_mem_track *track, unsigned long pfn,
> unsigned int order)
> {
> struct kho_mem_phys_bits *bits;
> - struct kho_mem_phys *physxa;
> + struct kho_mem_phys *physxa, *new_physxa;
> const unsigned long pfn_high = pfn >> order;
>
> might_sleep();
>
> - physxa = xa_load_or_alloc(&track->orders, order, sizeof(*physxa));
> - if (IS_ERR(physxa))
> - return PTR_ERR(physxa);
> + physxa = xa_load(&track->orders, order);
> + if (!physxa) {
> + new_physxa = kzalloc(sizeof(*physxa), GFP_KERNEL);
> + if (!new_physxa)
> + return -ENOMEM;
> +
> + xa_init(&new_physxa->phys_bits);
> + physxa = xa_cmpxchg(&track->orders, order, NULL, new_physxa,
> + GFP_KERNEL);
> + if (xa_is_err(physxa)) {
> + int err = xa_err(physxa);
> +
> + xa_destroy(&new_physxa->phys_bits);
> + kfree(new_physxa);
> +
> + return err;
> + }
> + if (physxa) {
> + xa_destroy(&new_physxa->phys_bits);
> + kfree(new_physxa);
> + } else {
> + physxa = new_physxa;
> + }
I suppose this could be simplified a bit to:
err = xa_err(physxa);
if (err || physxa) {
xa_destroy(&new_physxa->phys_bits);
kfree(new_physxa);
if (err)
return err;
} else {
physxa = new_physxa;
}
No strong preference though, so fine either way. Up to you.
Reviewed-by: Pratyush Yadav <pratyush@kernel.org>
> + }
>
> bits = xa_load_or_alloc(&physxa->phys_bits, pfn_high / PRESERVE_BITS,
> sizeof(*bits));
--
Regards,
Pratyush Yadav
^ permalink raw reply
* Re: [PATCH v2 01/11] mount_setattr.2: document glibc >= 2.36 syscall wrappers
From: Askar Safin @ 2025-08-08 9:23 UTC (permalink / raw)
To: Aleksa Sarai
Cc: Alejandro Colomar, Michael T. Kerrisk, Alexander Viro, Jan Kara,
G. Branden Robinson, linux-man, linux-api, linux-fsdevel,
linux-kernel, David Howells, Christian Brauner
In-Reply-To: <20250807-new-mount-api-v2-1-558a27b8068c@cyphar.com>
When I render "mount_setattr" from this (v2) pathset, I see weird quote mark. I. e.:
$ MANWIDTH=10000 man /path/to/mount_setattr.2
...
SYNOPSIS
#include <fcntl.h> /* Definition of AT_* constants */
#include <sys/mount.h>
int mount_setattr(int dirfd, const char *path, unsigned int flags,
struct mount_attr *attr, size_t size);"
...
--
Askar Safin
https://types.pl/@safinaskar
^ permalink raw reply
* Re: [PATCH v2 03/11] fsopen.2: document 'new' mount api
From: Askar Safin @ 2025-08-08 9:07 UTC (permalink / raw)
To: Aleksa Sarai
Cc: Alejandro Colomar, Michael T. Kerrisk, Alexander Viro, Jan Kara,
G. Branden Robinson, linux-man, linux-api, linux-fsdevel,
linux-kernel, David Howells, Christian Brauner
In-Reply-To: <20250807-new-mount-api-v2-3-558a27b8068c@cyphar.com>
> If there are no messages in the message queue,
> read(2) will return no data and errno will be set to ENODATA.
> If the buf argument to read(2) is not large enough to contain the message,
> read(2) will return no data and errno will be set to EMSGSIZE.
read(2) will return -1 in these cases? If yes, then, please, write this.
Also, I see that you addressed all my requests. Thank you!
And thank you again for writing all these manpages!
--
Askar Safin
https://types.pl/@safinaskar
^ permalink raw reply
* Re: [PATCH v2 2/2] vfs: output mount_too_revealing() errors to fscontext
From: Philip Li @ 2025-08-08 1:25 UTC (permalink / raw)
To: Aleksa Sarai
Cc: kernel test robot, Alexander Viro, Christian Brauner, Jan Kara,
oe-kbuild-all, David Howells, linux-api, linux-kernel,
linux-fsdevel
In-Reply-To: <2025-08-07.1754589415-related-cynic-passive-zombies-cute-jaybird-n5AIYt@cyphar.com>
On Fri, Aug 08, 2025 at 03:57:09AM +1000, Aleksa Sarai wrote:
> On 2025-08-07, kernel test robot <lkp@intel.com> wrote:
> > Hi Aleksa,
> >
> > kernel test robot noticed the following build errors:
> >
> > [auto build test ERROR on 66639db858112bf6b0f76677f7517643d586e575]
>
> This really doesn't seem like a bug in my patch...
Sorry for the false report, this is related to [1]. I will disable the further
report of this issue to avoid meaningless report.
[1] https://lore.kernel.org/linux-riscv/d5e49344-e0c2-4095-bd1f-d2d23a8e6534@ghiti.fr/
>
> > url: https://github.com/intel-lab-lkp/linux/commits/Aleksa-Sarai/fscontext-add-custom-prefix-log-helpers/20250806-141024
> > base: 66639db858112bf6b0f76677f7517643d586e575
> > patch link: https://lore.kernel.org/r/20250806-errorfc-mount-too-revealing-v2-2-534b9b4d45bb%40cyphar.com
> > patch subject: [PATCH v2 2/2] vfs: output mount_too_revealing() errors to fscontext
> > config: riscv-randconfig-002-20250807 (https://download.01.org/0day-ci/archive/20250807/202508071236.2BTGpdZx-lkp@intel.com/config)
> > compiler: riscv32-linux-gcc (GCC) 8.5.0
> > reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20250807/202508071236.2BTGpdZx-lkp@intel.com/reproduce)
> >
> > If you fix the issue in a separate patch/commit (i.e. not just a new version of
> > the same patch/commit), kindly add following tags
> > | Reported-by: kernel test robot <lkp@intel.com>
> > | Closes: https://lore.kernel.org/oe-kbuild-all/202508071236.2BTGpdZx-lkp@intel.com/
> >
> > All errors (new ones prefixed by >>, old ones prefixed by <<):
> >
> > WARNING: modpost: vmlinux: section mismatch in reference: prp_dup_discard_out_of_sequence+0x266 (section: .text.prp_dup_discard_out_of_sequence) -> ili9486_spi_driver_exit (section: .exit.text)
> > WARNING: modpost: vmlinux: section mismatch in reference: prp_dup_discard_out_of_sequence+0x2ae (section: .text.prp_dup_discard_out_of_sequence) -> ili9486_spi_driver_exit (section: .exit.text)
> > WARNING: modpost: vmlinux: section mismatch in reference: prp_dup_discard_out_of_sequence+0x2f2 (section: .text.prp_dup_discard_out_of_sequence) -> mi0283qt_spi_driver_exit (section: .exit.text)
> > WARNING: modpost: vmlinux: section mismatch in reference: prp_dup_discard_out_of_sequence+0x33e (section: .text.prp_dup_discard_out_of_sequence) -> mi0283qt_spi_driver_exit (section: .exit.text)
> > WARNING: modpost: vmlinux: section mismatch in reference: ida_free+0xa0 (section: .text.ida_free) -> .L0 (section: .init.text)
> > WARNING: modpost: vmlinux: section mismatch in reference: ida_free+0xba (section: .text.ida_free) -> .L0 (section: .init.text)
> > WARNING: modpost: vmlinux: section mismatch in reference: ida_free+0xdc (section: .text.ida_free) -> devices_init (section: .init.text)
> > WARNING: modpost: vmlinux: section mismatch in reference: ida_alloc_range+0x4c (section: .text.ida_alloc_range) -> devices_init (section: .init.text)
> > WARNING: modpost: vmlinux: section mismatch in reference: ida_alloc_range+0x9c (section: .text.ida_alloc_range) -> .L0 (section: .init.text)
> > WARNING: modpost: vmlinux: section mismatch in reference: ida_alloc_range+0x31a (section: .text.ida_alloc_range) -> devices_init (section: .init.text)
> > WARNING: modpost: vmlinux: section mismatch in reference: kobj_kset_leave+0x2 (section: .text.kobj_kset_leave) -> save_async_options (section: .init.text)
> > WARNING: modpost: vmlinux: section mismatch in reference: __kobject_del+0x18 (section: .text.__kobject_del) -> .LVL39 (section: .init.text)
> > WARNING: modpost: vmlinux: section mismatch in reference: mas_empty_area_rev+0x2aa (section: .text.mas_empty_area_rev) -> classes_init (section: .init.text)
> > WARNING: modpost: vmlinux: section mismatch in reference: mas_empty_area_rev+0x2ba (section: .text.mas_empty_area_rev) -> classes_init (section: .init.text)
> > WARNING: modpost: vmlinux: section mismatch in reference: mas_empty_area_rev+0x2c0 (section: .text.mas_empty_area_rev) -> classes_init (section: .init.text)
> > WARNING: modpost: vmlinux: section mismatch in reference: mas_empty_area_rev+0x2d0 (section: .text.mas_empty_area_rev) -> classes_init (section: .init.text)
> > WARNING: modpost: vmlinux: section mismatch in reference: mas_empty_area_rev+0x2da (section: .text.mas_empty_area_rev) -> classes_init (section: .init.text)
> > WARNING: modpost: vmlinux: section mismatch in reference: mas_empty_area_rev+0x2ec (section: .text.mas_empty_area_rev) -> .L0 (section: .init.text)
> > WARNING: modpost: vmlinux: section mismatch in reference: mas_empty_area_rev+0x2fe (section: .text.mas_empty_area_rev) -> __platform_driver_probe (section: .init.text)
> > WARNING: modpost: vmlinux: section mismatch in reference: mas_empty_area_rev+0x314 (section: .text.mas_empty_area_rev) -> __platform_driver_probe (section: .init.text)
> > WARNING: modpost: vmlinux: section mismatch in reference: mas_empty_area_rev+0x328 (section: .text.mas_empty_area_rev) -> __platform_driver_probe (section: .init.text)
> > WARNING: modpost: vmlinux: section mismatch in reference: mas_empty_area_rev+0x34c (section: .text.mas_empty_area_rev) -> __platform_driver_probe (section: .init.text)
> > WARNING: modpost: vmlinux: section mismatch in reference: mas_empty_area_rev+0x398 (section: .text.mas_empty_area_rev) -> __platform_driver_probe (section: .init.text)
> > WARNING: modpost: vmlinux: section mismatch in reference: mas_empty_area_rev+0x39e (section: .text.mas_empty_area_rev) -> __platform_driver_probe (section: .init.text)
> > WARNING: modpost: vmlinux: section mismatch in reference: mas_empty_area_rev+0x3d4 (section: .text.mas_empty_area_rev) -> classes_init (section: .init.text)
> > WARNING: modpost: vmlinux: section mismatch in reference: mas_empty_area_rev+0x400 (section: .text.mas_empty_area_rev) -> classes_init (section: .init.text)
> > WARNING: modpost: vmlinux: section mismatch in reference: mas_empty_area_rev+0x42a (section: .text.mas_empty_area_rev) -> classes_init (section: .init.text)
> > WARNING: modpost: vmlinux: section mismatch in reference: mt_dump_node+0x230 (section: .text.mt_dump_node) -> classes_init (section: .init.text)
> > WARNING: modpost: vmlinux: section mismatch in reference: mt_dump_node+0x24a (section: .text.mt_dump_node) -> __platform_driver_probe (section: .init.text)
> > WARNING: modpost: vmlinux: section mismatch in reference: mt_dump+0x20 (section: .text.mt_dump) -> classes_init (section: .init.text)
> > WARNING: modpost: vmlinux: section mismatch in reference: mt_dump+0x32 (section: .text.mt_dump) -> classes_init (section: .init.text)
> > WARNING: modpost: vmlinux: section mismatch in reference: mt_dump+0x42 (section: .text.mt_dump) -> classes_init (section: .init.text)
> > WARNING: modpost: vmlinux: section mismatch in reference: mt_dump+0x4c (section: .text.mt_dump) -> classes_init (section: .init.text)
> > WARNING: modpost: vmlinux: section mismatch in reference: mt_dump+0x56 (section: .text.mt_dump) -> classes_init (section: .init.text)
> > WARNING: modpost: vmlinux: section mismatch in reference: mt_dump+0x7c (section: .text.mt_dump) -> classes_init (section: .init.text)
> > WARNING: modpost: vmlinux: section mismatch in reference: mt_dump+0xd4 (section: .text.mt_dump) -> __platform_driver_probe (section: .init.text)
> > WARNING: modpost: vmlinux: section mismatch in reference: mas_empty_area+0x43e (section: .text.mas_empty_area) -> .L0 (section: .init.text)
> > WARNING: modpost: vmlinux: section mismatch in reference: mas_empty_area+0x454 (section: .text.mas_empty_area) -> .L0 (section: .init.text)
> > WARNING: modpost: vmlinux: section mismatch in reference: mas_empty_area+0x466 (section: .text.mas_empty_area) -> .L0 (section: .init.text)
> > WARNING: modpost: vmlinux: section mismatch in reference: mas_empty_area+0x4b2 (section: .text.mas_empty_area) -> platform_bus_init (section: .init.text)
> > WARNING: modpost: vmlinux: section mismatch in reference: mas_empty_area+0x4ba (section: .text.mas_empty_area) -> .L0 (section: .init.text)
> > WARNING: modpost: vmlinux: section mismatch in reference: mas_empty_area+0x4d2 (section: .text.mas_empty_area) -> .L0 (section: .init.text)
> > WARNING: modpost: vmlinux: section mismatch in reference: mas_empty_area+0x532 (section: .text.mas_empty_area) -> .L0 (section: .init.text)
> > WARNING: modpost: vmlinux: section mismatch in reference: mas_empty_area+0x548 (section: .text.mas_empty_area) -> __platform_create_bundle (section: .init.text)
> > WARNING: modpost: vmlinux: section mismatch in reference: mas_empty_area+0x572 (section: .text.mas_empty_area) -> .L461 (section: .init.text)
> > WARNING: modpost: vmlinux: section mismatch in reference: mas_empty_area+0x574 (section: .text.mas_empty_area) -> __platform_create_bundle (section: .init.text)
> > WARNING: modpost: vmlinux: section mismatch in reference: mas_empty_area+0x57a (section: .text.mas_empty_area) -> __platform_create_bundle (section: .init.text)
> > WARNING: modpost: vmlinux: section mismatch in reference: mas_empty_area+0x592 (section: .text.mas_empty_area) -> .L459 (section: .init.text)
> > WARNING: modpost: vmlinux: section mismatch in reference: mas_empty_area+0x5de (section: .text.mas_empty_area) -> .L457 (section: .init.text)
> > WARNING: modpost: vmlinux: section mismatch in reference: mas_empty_area+0x5e4 (section: .text.mas_empty_area) -> .L458 (section: .init.text)
> > WARNING: modpost: vmlinux: section mismatch in reference: mas_empty_area+0x5f0 (section: .text.mas_empty_area) -> .L0 (section: .init.text)
> > WARNING: modpost: vmlinux: section mismatch in reference: mas_root_expand+0x84 (section: .text.mas_root_expand) -> .L495 (section: .init.text)
> > WARNING: modpost: vmlinux: section mismatch in reference: mas_root_expand+0x98 (section: .text.mas_root_expand) -> cpu_dev_init (section: .init.text)
> > WARNING: modpost: vmlinux: section mismatch in reference: mas_prev_range+0x18 (section: .text.mas_prev_range) -> classes_init (section: .init.text)
> > WARNING: modpost: vmlinux: section mismatch in reference: mas_prev+0x18 (section: .text.mas_prev) -> classes_init (section: .init.text)
> > WARNING: modpost: vmlinux: section mismatch in reference: __rb_insert_augmented+0xc8 (section: .text.__rb_insert_augmented) -> auxiliary_bus_init (section: .init.text)
> > WARNING: modpost: vmlinux: section mismatch in reference: __rb_insert_augmented+0xe8 (section: .text.__rb_insert_augmented) -> auxiliary_bus_init (section: .init.text)
> > WARNING: modpost: vmlinux: section mismatch in reference: __rb_insert_augmented+0xf8 (section: .text.__rb_insert_augmented) -> auxiliary_bus_init (section: .init.text)
> > WARNING: modpost: vmlinux: section mismatch in reference: __rb_insert_augmented+0x102 (section: .text.__rb_insert_augmented) -> auxiliary_bus_init (section: .init.text)
> > WARNING: modpost: vmlinux: section mismatch in reference: __rb_insert_augmented+0x114 (section: .text.__rb_insert_augmented) -> mount_param (section: .init.text)
> > WARNING: modpost: vmlinux: section mismatch in reference: rb_first+0x8 (section: .text.rb_first) -> mount_param (section: .init.text)
> > WARNING: modpost: vmlinux: section mismatch in reference: rb_first+0xa (section: .text.rb_first) -> mount_param (section: .init.text)
> > WARNING: modpost: vmlinux: section mismatch in reference: rb_first+0x10 (section: .text.rb_first) -> mount_param (section: .init.text)
> > WARNING: modpost: vmlinux: section mismatch in reference: rb_last+0x8 (section: .text.rb_last) -> mount_param (section: .init.text)
> > WARNING: modpost: vmlinux: section mismatch in reference: rb_last+0xa (section: .text.rb_last) -> mount_param (section: .init.text)
> > WARNING: modpost: vmlinux: section mismatch in reference: rb_last+0x10 (section: .text.rb_last) -> mount_param (section: .init.text)
> > WARNING: modpost: vmlinux: section mismatch in reference: __rb_erase_color+0xda (section: .text.__rb_erase_color) -> auxiliary_bus_init (section: .init.text)
> > WARNING: modpost: vmlinux: section mismatch in reference: __rb_erase_color+0xf8 (section: .text.__rb_erase_color) -> mount_param (section: .init.text)
> > WARNING: modpost: vmlinux: section mismatch in reference: __rb_erase_color+0x188 (section: .text.__rb_erase_color) -> auxiliary_bus_init (section: .init.text)
> > WARNING: modpost: vmlinux: section mismatch in reference: 0x15a8 (section: __ex_table) -> .LASF2568 (section: .debug_str)
> > ERROR: modpost: __ex_table+0x15a8 references non-executable section '.debug_str'
> > WARNING: modpost: vmlinux: section mismatch in reference: 0x15ac (section: __ex_table) -> .LASF2570 (section: .debug_str)
> > ERROR: modpost: __ex_table+0x15ac references non-executable section '.debug_str'
> > WARNING: modpost: vmlinux: section mismatch in reference: 0x15b4 (section: __ex_table) -> .LASF2572 (section: .debug_str)
> > ERROR: modpost: __ex_table+0x15b4 references non-executable section '.debug_str'
> > WARNING: modpost: vmlinux: section mismatch in reference: 0x15b8 (section: __ex_table) -> .LASF2574 (section: .debug_str)
> > ERROR: modpost: __ex_table+0x15b8 references non-executable section '.debug_str'
> > WARNING: modpost: vmlinux: section mismatch in reference: 0x15c0 (section: __ex_table) -> .LASF2576 (section: .debug_str)
> > ERROR: modpost: __ex_table+0x15c0 references non-executable section '.debug_str'
> > WARNING: modpost: vmlinux: section mismatch in reference: 0x15c4 (section: __ex_table) -> .LASF2578 (section: .debug_str)
> > ERROR: modpost: __ex_table+0x15c4 references non-executable section '.debug_str'
> > WARNING: modpost: vmlinux: section mismatch in reference: 0x15cc (section: __ex_table) -> .LASF2580 (section: .debug_str)
> > ERROR: modpost: __ex_table+0x15cc references non-executable section '.debug_str'
> > WARNING: modpost: vmlinux: section mismatch in reference: 0x15d0 (section: __ex_table) -> .LASF2574 (section: .debug_str)
> > ERROR: modpost: __ex_table+0x15d0 references non-executable section '.debug_str'
> > WARNING: modpost: vmlinux: section mismatch in reference: 0x15d8 (section: __ex_table) -> .LASF2583 (section: .debug_str)
> > ERROR: modpost: __ex_table+0x15d8 references non-executable section '.debug_str'
> > WARNING: modpost: vmlinux: section mismatch in reference: 0x15dc (section: __ex_table) -> .LASF2574 (section: .debug_str)
> > ERROR: modpost: __ex_table+0x15dc references non-executable section '.debug_str'
> > WARNING: modpost: vmlinux: section mismatch in reference: 0x15e4 (section: __ex_table) -> .LASF2586 (section: .debug_str)
> > ERROR: modpost: __ex_table+0x15e4 references non-executable section '.debug_str'
> > WARNING: modpost: vmlinux: section mismatch in reference: 0x15e8 (section: __ex_table) -> .LASF2588 (section: .debug_str)
> > ERROR: modpost: __ex_table+0x15e8 references non-executable section '.debug_str'
> > WARNING: modpost: vmlinux: section mismatch in reference: 0x15f0 (section: __ex_table) -> .L0 (section: __ex_table)
> > ERROR: modpost: __ex_table+0x15f0 references non-executable section '__ex_table'
> > WARNING: modpost: vmlinux: section mismatch in reference: 0x15f4 (section: __ex_table) -> .L0 (section: __ex_table)
> > ERROR: modpost: __ex_table+0x15f4 references non-executable section '__ex_table'
> > WARNING: modpost: vmlinux: section mismatch in reference: 0x15fc (section: __ex_table) -> .L0 (section: __ex_table)
> > ERROR: modpost: __ex_table+0x15fc references non-executable section '__ex_table'
> > WARNING: modpost: vmlinux: section mismatch in reference: 0x1600 (section: __ex_table) -> firsttime (section: .data.firsttime.60983)
> > >> ERROR: modpost: __ex_table+0x1600 references non-executable section '.data.firsttime.60983'
> > WARNING: modpost: vmlinux: section mismatch in reference: 0x1614 (section: __ex_table) -> .LASF230 (section: .debug_str)
> > ERROR: modpost: __ex_table+0x1614 references non-executable section '.debug_str'
> > WARNING: modpost: vmlinux: section mismatch in reference: 0x1618 (section: __ex_table) -> .LASF232 (section: .debug_str)
> > ERROR: modpost: __ex_table+0x1618 references non-executable section '.debug_str'
> > WARNING: modpost: vmlinux: section mismatch in reference: 0x1620 (section: __ex_table) -> .LASF234 (section: .debug_str)
> > ERROR: modpost: __ex_table+0x1620 references non-executable section '.debug_str'
> > WARNING: modpost: vmlinux: section mismatch in reference: 0x1624 (section: __ex_table) -> .LASF232 (section: .debug_str)
> > ERROR: modpost: __ex_table+0x1624 references non-executable section '.debug_str'
> > WARNING: modpost: vmlinux: section mismatch in reference: 0x162c (section: __ex_table) -> .LASF237 (section: .debug_str)
> > ERROR: modpost: __ex_table+0x162c references non-executable section '.debug_str'
> > WARNING: modpost: vmlinux: section mismatch in reference: 0x1630 (section: __ex_table) -> .LASF232 (section: .debug_str)
> > ERROR: modpost: __ex_table+0x1630 references non-executable section '.debug_str'
> > WARNING: modpost: vmlinux: section mismatch in reference: 0x1638 (section: __ex_table) -> .LASF240 (section: .debug_str)
> > ERROR: modpost: __ex_table+0x1638 references non-executable section '.debug_str'
> > WARNING: modpost: vmlinux: section mismatch in reference: 0x163c (section: __ex_table) -> .LASF232 (section: .debug_str)
> > ERROR: modpost: __ex_table+0x163c references non-executable section '.debug_str'
> > WARNING: modpost: vmlinux: section mismatch in reference: 0x1644 (section: __ex_table) -> .LASF243 (section: .debug_str)
> > ERROR: modpost: __ex_table+0x1644 references non-executable section '.debug_str'
> > WARNING: modpost: vmlinux: section mismatch in reference: 0x1648 (section: __ex_table) -> .LASF232 (section: .debug_str)
> > ERROR: modpost: __ex_table+0x1648 references non-executable section '.debug_str'
> > WARNING: modpost: vmlinux: section mismatch in reference: 0x1650 (section: __ex_table) -> .LASF246 (section: .debug_str)
> > ERROR: modpost: __ex_table+0x1650 references non-executable section '.debug_str'
> > WARNING: modpost: vmlinux: section mismatch in reference: 0x1654 (section: __ex_table) -> .LASF232 (section: .debug_str)
> > ERROR: modpost: __ex_table+0x1654 references non-executable section '.debug_str'
> > WARNING: modpost: vmlinux: section mismatch in reference: 0x165c (section: __ex_table) -> .LASF249 (section: .debug_str)
> > ERROR: modpost: __ex_table+0x165c references non-executable section '.debug_str'
> > WARNING: modpost: vmlinux: section mismatch in reference: 0x1660 (section: __ex_table) -> .LASF251 (section: .debug_str)
> > ERROR: modpost: __ex_table+0x1660 references non-executable section '.debug_str'
> > WARNING: modpost: vmlinux: section mismatch in reference: 0x1668 (section: __ex_table) -> .LASF253 (section: .debug_str)
> > ERROR: modpost: __ex_table+0x1668 references non-executable section '.debug_str'
> > WARNING: modpost: vmlinux: section mismatch in reference: 0x166c (section: __ex_table) -> .LASF255 (section: .debug_str)
> > ERROR: modpost: __ex_table+0x166c references non-executable section '.debug_str'
> > WARNING: modpost: vmlinux: section mismatch in reference: 0x1674 (section: __ex_table) -> .LASF257 (section: .debug_str)
> > ERROR: modpost: __ex_table+0x1674 references non-executable section '.debug_str'
> > WARNING: modpost: vmlinux: section mismatch in reference: 0x1678 (section: __ex_table) -> .LASF259 (section: .debug_str)
> > ERROR: modpost: __ex_table+0x1678 references non-executable section '.debug_str'
> > WARNING: modpost: vmlinux: section mismatch in reference: 0x1680 (section: __ex_table) -> .LASF261 (section: .debug_str)
> > ERROR: modpost: __ex_table+0x1680 references non-executable section '.debug_str'
> > WARNING: modpost: vmlinux: section mismatch in reference: 0x1684 (section: __ex_table) -> .LASF263 (section: .debug_str)
> > ERROR: modpost: __ex_table+0x1684 references non-executable section '.debug_str'
> > WARNING: modpost: vmlinux: section mismatch in reference: 0x168c (section: __ex_table) -> .LASF265 (section: .debug_str)
> > ERROR: modpost: __ex_table+0x168c references non-executable section '.debug_str'
> > WARNING: modpost: vmlinux: section mismatch in reference: 0x1690 (section: __ex_table) -> .LASF267 (section: .debug_str)
> > ERROR: modpost: __ex_table+0x1690 references non-executable section '.debug_str'
> > WARNING: modpost: vmlinux: section mismatch in reference: 0x1698 (section: __ex_table) -> .LASF269 (section: .debug_str)
> > ERROR: modpost: __ex_table+0x1698 references non-executable section '.debug_str'
> > WARNING: modpost: vmlinux: section mismatch in reference: 0x169c (section: __ex_table) -> .LASF271 (section: .debug_str)
> > ERROR: modpost: __ex_table+0x169c references non-executable section '.debug_str'
> > WARNING: modpost: vmlinux: section mismatch in reference: 0x16a4 (section: __ex_table) -> .LASF273 (section: .debug_str)
> > ERROR: modpost: __ex_table+0x16a4 references non-executable section '.debug_str'
> > WARNING: modpost: vmlinux: section mismatch in reference: 0x16a8 (section: __ex_table) -> .LASF275 (section: .debug_str)
> > ERROR: modpost: __ex_table+0x16a8 references non-executable section '.debug_str'
> > WARNING: modpost: vmlinux: section mismatch in reference: 0x16b0 (section: __ex_table) -> .LASF277 (section: .debug_str)
> > ERROR: modpost: __ex_table+0x16b0 references non-executable section '.debug_str'
> > WARNING: modpost: vmlinux: section mismatch in reference: 0x16b4 (section: __ex_table) -> .LASF279 (section: .debug_str)
> > ERROR: modpost: __ex_table+0x16b4 references non-executable section '.debug_str'
> > WARNING: modpost: vmlinux: section mismatch in reference: 0x16bc (section: __ex_table) -> .LASF281 (section: .debug_str)
> > ERROR: modpost: __ex_table+0x16bc references non-executable section '.debug_str'
> > WARNING: modpost: vmlinux: section mismatch in reference: 0x16c0 (section: __ex_table) -> .LASF283 (section: .debug_str)
> > ERROR: modpost: __ex_table+0x16c0 references non-executable section '.debug_str'
> > WARNING: modpost: vmlinux: section mismatch in reference: 0x16c8 (section: __ex_table) -> .LASF285 (section: .debug_str)
> > ERROR: modpost: __ex_table+0x16c8 references non-executable section '.debug_str'
> > WARNING: modpost: vmlinux: section mismatch in reference: 0x16cc (section: __ex_table) -> .LASF287 (section: .debug_str)
> > ERROR: modpost: __ex_table+0x16cc references non-executable section '.debug_str'
> > WARNING: modpost: vmlinux: section mismatch in reference: 0x16d4 (section: __ex_table) -> .LASF289 (section: .debug_str)
> > ERROR: modpost: __ex_table+0x16d4 references non-executable section '.debug_str'
> > WARNING: modpost: vmlinux: section mismatch in reference: 0x16d8 (section: __ex_table) -> .LASF291 (section: .debug_str)
> > ERROR: modpost: __ex_table+0x16d8 references non-executable section '.debug_str'
> > WARNING: modpost: vmlinux: section mismatch in reference: 0x16e4 (section: __ex_table) -> .LASF4984 (section: .debug_str)
> > ERROR: modpost: __ex_table+0x16e4 references non-executable section '.debug_str'
> > WARNING: modpost: vmlinux: section mismatch in reference: 0x16ec (section: __ex_table) -> .LASF4986 (section: .debug_str)
> > ERROR: modpost: __ex_table+0x16ec references non-executable section '.debug_str'
> > WARNING: modpost: vmlinux: section mismatch in reference: 0x16f0 (section: __ex_table) -> .LASF4984 (section: .debug_str)
> > ERROR: modpost: __ex_table+0x16f0 references non-executable section '.debug_str'
> > WARNING: modpost: vmlinux: section mismatch in reference: 0x16fc (section: __ex_table) -> .LASF4984 (section: .debug_str)
> > ERROR: modpost: __ex_table+0x16fc references non-executable section '.debug_str'
> > WARNING: modpost: vmlinux: section mismatch in reference: 0x1704 (section: __ex_table) -> .LLST20 (section: .debug_loc)
> > ERROR: modpost: __ex_table+0x1704 references non-executable section '.debug_loc'
> > WARNING: modpost: vmlinux: section mismatch in reference: 0x1708 (section: __ex_table) -> .LLST22 (section: .debug_loc)
> > ERROR: modpost: __ex_table+0x1708 references non-executable section '.debug_loc'
> > WARNING: modpost: vmlinux: section mismatch in reference: 0x1710 (section: __ex_table) -> .LLST23 (section: .debug_loc)
> > ERROR: modpost: __ex_table+0x1710 references non-executable section '.debug_loc'
> > WARNING: modpost: vmlinux: section mismatch in reference: 0x1714 (section: __ex_table) -> .LASF4984 (section: .debug_str)
> > ERROR: modpost: __ex_table+0x1714 references non-executable section '.debug_str'
> > WARNING: modpost: vmlinux: section mismatch in reference: 0x171c (section: __ex_table) -> .LASF270 (section: .debug_str)
> > ERROR: modpost: __ex_table+0x171c references non-executable section '.debug_str'
> > WARNING: modpost: vmlinux: section mismatch in reference: 0x1720 (section: __ex_table) -> .LASF272 (section: .debug_str)
> > ERROR: modpost: __ex_table+0x1720 references non-executable section '.debug_str'
> > WARNING: modpost: vmlinux: section mismatch in reference: 0x174c (section: __ex_table) -> .LASF1801 (section: .debug_str)
> > ERROR: modpost: __ex_table+0x174c references non-executable section '.debug_str'
> > WARNING: modpost: vmlinux: section mismatch in reference: 0x1750 (section: __ex_table) -> .LASF1803 (section: .debug_str)
> > ERROR: modpost: __ex_table+0x1750 references non-executable section '.debug_str'
> > WARNING: modpost: vmlinux: section mismatch in reference: 0x1758 (section: __ex_table) -> .LASF1805 (section: .debug_str)
> > ERROR: modpost: __ex_table+0x1758 references non-executable section '.debug_str'
> > WARNING: modpost: vmlinux: section mismatch in reference: 0x175c (section: __ex_table) -> .LASF1807 (section: .debug_str)
> > ERROR: modpost: __ex_table+0x175c references non-executable section '.debug_str'
> > WARNING: modpost: vmlinux: section mismatch in reference: 0x1764 (section: __ex_table) -> .LASF1809 (section: .debug_str)
> > ERROR: modpost: __ex_table+0x1764 references non-executable section '.debug_str'
> > WARNING: modpost: vmlinux: section mismatch in reference: 0x1768 (section: __ex_table) -> .LASF1807 (section: .debug_str)
> > ERROR: modpost: __ex_table+0x1768 references non-executable section '.debug_str'
> >
> > --
> > 0-DAY CI Kernel Test Service
> > https://github.com/intel/lkp-tests/wiki
>
> --
> Aleksa Sarai
> Senior Software Engineer (Containers)
> SUSE Linux GmbH
> https://www.cyphar.com/
^ permalink raw reply
* Re: [PATCH v2 03/11] fsopen.2: document 'new' mount api
From: Aleksa Sarai @ 2025-08-07 19:39 UTC (permalink / raw)
To: Konstantin Ryabitsev
Cc: Alejandro Colomar, Michael T. Kerrisk, Alexander Viro, Jan Kara,
Askar Safin, G. Branden Robinson, linux-man, linux-api,
linux-fsdevel, linux-kernel, David Howells, Christian Brauner
In-Reply-To: <20250807-intelligent-amorphous-cuscus-1caae0@lemur>
[-- Attachment #1: Type: text/plain, Size: 777 bytes --]
On 2025-08-07, Konstantin Ryabitsev <konstantin@linuxfoundation.org> wrote:
> On Fri, Aug 08, 2025 at 12:26:48AM +1000, Aleksa Sarai wrote:
> > Konstantin, would you be interested in a patch to add --range-diff to
> > the trailing bits of cover letters? I would guess that b4 already has
> > all of the necessary metadata to reference the right commits.
> >
> > It seems like a fairly neat way of providing some more metadata about
> > changes between patchsets, for folks that care about that information.
>
> It's already there, just add ${range_diff} to your cover letter template.
Oh, my bad... Time to go re-read the b4 docs again.
> Cheers,
> -K
>
--
Aleksa Sarai
Senior Software Engineer (Containers)
SUSE Linux GmbH
https://www.cyphar.com/
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v2 03/11] fsopen.2: document 'new' mount api
From: Konstantin Ryabitsev @ 2025-08-07 19:27 UTC (permalink / raw)
To: Aleksa Sarai
Cc: Alejandro Colomar, Michael T. Kerrisk, Alexander Viro, Jan Kara,
Askar Safin, G. Branden Robinson, linux-man, linux-api,
linux-fsdevel, linux-kernel, David Howells, Christian Brauner
In-Reply-To: <2025-08-07.1754576582-puny-spade-blotchy-axiom-winking-overtone-AerGh5@cyphar.com>
On Fri, Aug 08, 2025 at 12:26:48AM +1000, Aleksa Sarai wrote:
> Konstantin, would you be interested in a patch to add --range-diff to
> the trailing bits of cover letters? I would guess that b4 already has
> all of the necessary metadata to reference the right commits.
>
> It seems like a fairly neat way of providing some more metadata about
> changes between patchsets, for folks that care about that information.
It's already there, just add ${range_diff} to your cover letter template.
Cheers,
-K
^ 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