* Re: [PATCH] kprobes: Replace __ASSEMBLY__ with __ASSEMBLER__ in header file
From: Masami Hiramatsu @ 2026-06-21 13:27 UTC (permalink / raw)
To: Thomas Huth
Cc: Naveen N Rao, David S. Miller, linux-kernel, linux-trace-kernel,
linux-arch
In-Reply-To: <20260619161434.88270-1-thuth@redhat.com>
On Fri, 19 Jun 2026 18:14:34 +0200
Thomas Huth <thuth@redhat.com> wrote:
> From: Thomas Huth <thuth@redhat.com>
>
> While the GCC and Clang compilers already define __ASSEMBLER__
> automatically when compiling assembly code, __ASSEMBLY__ is a
> macro that only gets defined by the Makefiles in the kernel.
> This can be very confusing when switching between userspace
> and kernelspace coding, or when dealing with uapi headers that
> rather should use __ASSEMBLER__ instead. So let's standardize now
> on the __ASSEMBLER__ macro that is provided by the compilers.
>
Oops, good catch!
Let me pick it.
Thanks!
> Signed-off-by: Thomas Huth <thuth@redhat.com>
> ---
> Note: This patch has been split from an earlier bigger patch of
> mine to ease reviewing.
>
> include/asm-generic/kprobes.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/include/asm-generic/kprobes.h b/include/asm-generic/kprobes.h
> index 5290a2b2e15a0..16f16963d503d 100644
> --- a/include/asm-generic/kprobes.h
> +++ b/include/asm-generic/kprobes.h
> @@ -2,7 +2,7 @@
> #ifndef _ASM_GENERIC_KPROBES_H
> #define _ASM_GENERIC_KPROBES_H
>
> -#if defined(__KERNEL__) && !defined(__ASSEMBLY__)
> +#if defined(__KERNEL__) && !defined(__ASSEMBLER__)
> #ifdef CONFIG_KPROBES
> /*
> * Blacklist ganerating macro. Specify functions which is not probed
> @@ -21,6 +21,6 @@ static unsigned long __used \
> # define __kprobes
> # define nokprobe_inline inline
> #endif
> -#endif /* defined(__KERNEL__) && !defined(__ASSEMBLY__) */
> +#endif /* defined(__KERNEL__) && !defined(__ASSEMBLER__) */
>
> #endif /* _ASM_GENERIC_KPROBES_H */
> --
> 2.54.0
>
--
Masami Hiramatsu (Google) <mhiramat@kernel.org>
^ permalink raw reply
* Re: [PATCH] riscv: entry: Fixup do_trap_break from kernel side
From: Guo Ren @ 2026-06-21 6:52 UTC (permalink / raw)
To: Kees Cook
Cc: arnd, palmer, tglx, peterz, luto, conor.dooley, heiko, jszhang,
lazyparser, falcon, chenhuacai, apatel, atishp, mark.rutland,
bjorn, palmer, bjorn, daniel.thompson, linux-arch, linux-kernel,
linux-riscv, stable, Guo Ren
In-Reply-To: <202606191652.38297DE51@keescook>
On Fri, Jun 19, 2026 at 04:54:53PM -0700, Kees Cook wrote:
> *thread encromancy*
>
> On Sat, Jul 01, 2023 at 10:57:07PM -0400, guoren@kernel.org wrote:
> > From: Guo Ren <guoren@linux.alibaba.com>
> >
> > The irqentry_nmi_enter/exit would force the current context into in_interrupt.
> > That would trigger the kernel to dead panic, but the kdb still needs "ebreak" to
> > debug the kernel.
> >
> > Move irqentry_nmi_enter/exit to exception_enter/exit could correct handle_break
> > of the kernel side.
> >
> > Before the fixup:
> > $echo BUG > /sys/kernel/debug/provoke-crash/DIRECT
> > lkdtm: Performing direct entry BUG
> > ------------[ cut here ]------------
> > kernel BUG at drivers/misc/lkdtm/bugs.c:78!
> > [...]
> > Kernel panic - not syncing: Aiee, killing interrupt handler!
>
> This appears to still be unfixed. What's the blocker? The solutions in
> this thread seem to work...
>
> I'd like to be exercising an Oops path via KUnit (for KCFI), and riscv
> just instantly falls over instead of thread-killing on the exception.
Thanks for reviving this thread. At the time I didn’t fully understand
Peter’s point. We should only use the NMI path when the trap occurs with
interrupts disabled.
Here’s the updated fix:
do_trap_break(struct pt_regs *regs)
...
irqentry_exit_to_user_mode(regs);
} else {
- irqentry_state_t state = irqentry_nmi_enter(regs);
+ if (regs->status & SR_IE) {
+ enum ctx_state prev_state = exception_enter();
- handle_break(regs);
+ handle_break(regs);
- irqentry_nmi_exit(regs, state);
+ exception_exit(prev_state);
+ } else {
+ irqentry_state_t state = irqentry_nmi_enter(regs);
+
+ handle_break(regs);
+
+ irqentry_nmi_exit(regs, state);
+ }
}
}
If you & Peter have no objection, I’ll post a v2.
Best Regards
GUO Ren
^ permalink raw reply
* Re: [PATCH] init/main: Expose built-in initcalls and blacklist status via debugfs
From: Aaron Tomlin @ 2026-06-20 23:11 UTC (permalink / raw)
To: Petr Pavlu
Cc: arnd, mcgrof, da.gomez, samitolvanen, neelx, sean, chjohnst,
steve, mproche, nick.lane, linux-arch, linux-modules,
linux-kernel
In-Reply-To: <79ace94f-31d3-4a5e-9a47-3fad69304fe5@suse.com>
[-- Attachment #1: Type: text/plain, Size: 2757 bytes --]
On Wed, Jun 17, 2026 at 02:39:53PM +0200, Petr Pavlu wrote:
> On 5/10/26 8:13 AM, Aaron Tomlin wrote:
> > At present, identifying the correct function name to supply to the
> > "initcall_blacklist=" kernel command-line parameter requires manual
> > inspection of the source code or kernel symbol tables. Furthermore,
> > administrators lack a reliable runtime mechanism to verify whether a
> > specified built-in module has been successfully blacklisted.
>
> My understanding is that initcall_blacklist is primarily a debugging
> facility. This is documented in
> Documentation/admin-guide/kernel-parameters.txt [1] and also outlined in
> the initial commit 7b0b73d76651 ("init/main.c: add initcall_blacklist
> kernel parameter") [2]. It is expected that to use it, one must inspect
> the kernel source code.
>
> If the goal is to allow specific built-in modules to be blacklisted,
> I wonder whether extending module_blacklist to also cover built-in
> modules might be a better option. Module names are more appropriate for
> administrators to use, while initcall names should remain internal to
> the kernel. Additionally, initcalls are typically "static" and therefore
> are not guaranteed to have unique names + using module names avoids
> a dependency on CONFIG_KALLSYMS=y.
>
> [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/admin-guide/kernel-parameters.txt?h=v7.1#n2408
> [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7b0b73d76651e5f88c88b76efa18d719f832bf6f
Hi Petr,
Thank you for your review and the excellent historical context.
Your points regarding static function name collisions and the
unnecessary kallsyms dependency are correct.
Extending the module blacklist parameter to intercept built in modules
makes far more architectural sense. It provides a consistent interface for
administrators and aligns perfectly with existing kernel conventions.
For the forthcoming v2 patchset, I have completely dropped the original
approach. Instead, I am implementing a parallel metadata section. By
updating the core initcall macros, the compiler will emit the module name
string into a custom ELF section directly alongside the function pointer.
The core boot code can then evaluate this mapping against the module
blacklist before executing the initialisation function.
This new architecture performs all the mapping at compile time. It entirely
avoids the kallsyms dependency you highlighted, perfectly preserves the
original function names for debugging purposes, and resides securely within
the initialisation data so the memory is freed completely immediately after
boot.
Kind regards,
--
Aaron Tomlin
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v3] coredump: exit_files() in coredump_wait() if MMF_DUMP_MAPPED_SHARED is not set
From: Xin Zhao @ 2026-06-20 3:04 UTC (permalink / raw)
To: mjguzik
Cc: alex.aring, allen.lkml, arnd, brauner, chuck.lever, ebiederm,
j.granados, jack, jackzxcui1989, jlayton, keescook, linux-arch,
linux-fsdevel, linux-kernel, mcgrof, pfalcato, viro
In-Reply-To: <jt7glnz6scdbnbzzl7l3slvnu4vtr2uzlbwe74znxp3sxeqdtc@dhrwwjhhn6md>
On Fri, 19 Jun 2026 19:33:16 +0200 Mateusz Guzik <mjguzik@gmail.com> wrote:
> The claim is the coredump takes "some time" without specifying what kind
> of window is it (seconds, minutes?), nor where said time is spent.
>
> For example it is known that a big mmapped areas are slow to dump even
> if they are sparsely populated.
>
> So I would suggest profiling what exactly happens in this case. It is
> virtually guaranteed the time can be shortened, but it is plausible even
> with fixups it will be too long.
I test it by running the first testflock, wait until it output
'get flock success' and then run the second testflock.
testflock will send signal 6 to trigger coredump to the first testflock.
The second flock wait 11 seconds to get the flock. (it may wait less time
if I do not polling get the flock--add sleep in the while loop, as the two
testflock function is run by ssh, and they share the same cpu), but still
wait a long time(about 5 seconds).
./testflock
get flock success!
Aborted (core dumped)
./testflock
get flock fail!
lock_pid=8724
get flock success!
waitms=11443
The testflock program（the test program only use 500MB heap memory, the
memory used by other business processes will exceed this value）:
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
#include <fcntl.h>
#include <sys/file.h>
#include <errno.h>
#include <time.h>
#include <signal.h>
#include <sys/syscall.h>
static inline long get_msec(void)
{
struct timespec ts;
clock_gettime(CLOCK_MONOTONIC, &ts);
return ts.tv_sec * 1000 + ts.tv_nsec / 1000000;
}
#ifndef F_GETFD_EX
#define F_GETFD_EX 18
#endif
#ifndef F_SETFD_EX
#define F_SETFD_EX 19
#endif
#define FD_CLOBCOR 2
int main(int argc, char *argv[])
{
size_t size_mb = 512;
size_t size, i;
long start = 0, stop;
int mode = 1;
const char *dir = "/map/zhaoxin/flock_tmp";
int fd;
int ret;
char *buf;
if (argc == 2 && strcmp(argv[1], "0") == 0) {
printf("Do not send signal when fail!\n");
mode = 0;
}
size = size_mb * 1024 * 1024;
buf = (char*)malloc(size);
if (!buf) {
perror("malloc 失败");
return 1;
}
for (i = 0; i < size; i++) {
buf[i] = (char)i;
}
/* 打开目录，需要读权限 */
fd = open(dir, O_CREAT | O_RDWR, 0777);
if (fd < 0) {
perror("open");
exit(EXIT_FAILURE);
}
int setfd_ex_ret = fcntl(fd, F_SETFD_EX, FD_CLOBCOR);
struct flock fl;
fl.l_type = F_WRLCK;
fl.l_whence = SEEK_SET;
fl.l_start = 0;
fl.l_len = 0;
bool brunonce = false;
int lastresult;
int lock_pid = 0;
while (1) {
int result = fcntl(fd, F_SETLK, &fl);
if (errno == EBADF || errno == EINVAL) {
printf("errno=%d\n", errno);
return -1;
}
if (!brunonce) {
brunonce = true;
// let lastresult differ from result
lastresult = result + 1;
}
if (lastresult != result) {
if (result == 0) {
printf("get flock success!\n");
if (start) {
stop = get_msec();
printf("waitms=%ld\n", stop - start);
}
while (1) {
sleep(1000);
}
}
lastresult = result;
if (errno == EAGAIN || errno == EACCES) {
printf("get flock fail!\n");
struct flock lock;
(void)memset(&lock, 0, sizeof(lock));
lock.l_type = F_WRLCK;
lock.l_whence = SEEK_SET;
lock.l_start = 0;
lock.l_len = 0;
if (fcntl(fd, F_GETLK, &lock) == 0) {
if (lock.l_type != F_UNLCK) {
lock_pid = lock.l_pid;
start = get_msec();
if (mode) {
int ret = syscall(SYS_tgkill, lock_pid, lock_pid, SIGABRT);
}
}
printf("lock_pid=%d\n", lock_pid);
}
}
}
}
return 0;
}
Thanks
Xin Zhao
^ permalink raw reply
* Re: [PATCH v3] coredump: exit_files() in coredump_wait() if MMF_DUMP_MAPPED_SHARED is not set
From: Xin Zhao @ 2026-06-20 2:42 UTC (permalink / raw)
To: brauner
Cc: alex.aring, allen.lkml, arnd, chuck.lever, ebiederm, j.granados,
jack, jackzxcui1989, jlayton, keescook, linux-arch, linux-fsdevel,
linux-kernel, mcgrof, pfalcato, viro
In-Reply-To: <178187726633.350634.1366346571707417413.b4-review@b4>
On Fri, 19 Jun 2026 15:54:26 +0200 Christian Brauner <brauner@kernel.org> wrote:
> > + /*
> > + * Early unlocking a flock on a file allows other processes
> > + * to lock and modify the mapped data protected by the flock.
> > + */
> > + if (!mm_flags_test(MMF_DUMP_MAPPED_SHARED, tsk->mm))
> > + exit_files(tsk);
>
> This doesn't work - at least not unconditionally. Tools like
> systemd-coredump or apport go through the fds. Specifically
> systemd-coredump does:
>
> 1) /proc/[pid]/fd/ — opendir() then, per entry, readlinkat() to get the symlink target.
> 2) /proc/[pid]/fdinfo/ — for each fd it reads the fdinfo text lines
>
> The blob is attached to the journal record as the COREDUMP_OPEN_FDS=
> field. So the open-fd list is recorded as metadata, retrievable later
> (e.g. coredumpctl info shows it).
>
> Also, irc some clever implementations use pidfd_getfd() to preserve the
> files from a coredumping process to preserve them.
>
> So you break all that - and only in some of the cases which is really
> opaque to userspace. That's not acceptable. If you only care about the
> case where you dump to a file then either special-case it to the legacy
> file coredump format or if it's generally useful make it an optional
> argument that can be passed to the coredump pipe and a new flag
> extension to the coredump socket that makes the coredumping process shed
> it's file descriptors.
Thank you for providing such useful information. I’ve also learned about
the useful pidfd_getfd() interface. Returning to the issue, I really want
to find a suitable method to resolve it. Now I know how to proceed, and I
will modify a version; I would appreciate it if you could take a look at
it later.
Thanks
Xin Zhao
^ permalink raw reply
* Re: [PATCH] riscv: entry: Fixup do_trap_break from kernel side
From: Kees Cook @ 2026-06-19 23:54 UTC (permalink / raw)
To: guoren
Cc: arnd, palmer, tglx, peterz, luto, conor.dooley, heiko, jszhang,
lazyparser, falcon, chenhuacai, apatel, atishp, mark.rutland,
bjorn, palmer, bjorn, daniel.thompson, linux-arch, linux-kernel,
linux-riscv, stable, Guo Ren
In-Reply-To: <20230702025708.784106-1-guoren@kernel.org>
*thread encromancy*
On Sat, Jul 01, 2023 at 10:57:07PM -0400, guoren@kernel.org wrote:
> From: Guo Ren <guoren@linux.alibaba.com>
>
> The irqentry_nmi_enter/exit would force the current context into in_interrupt.
> That would trigger the kernel to dead panic, but the kdb still needs "ebreak" to
> debug the kernel.
>
> Move irqentry_nmi_enter/exit to exception_enter/exit could correct handle_break
> of the kernel side.
>
> Before the fixup:
> $echo BUG > /sys/kernel/debug/provoke-crash/DIRECT
> lkdtm: Performing direct entry BUG
> ------------[ cut here ]------------
> kernel BUG at drivers/misc/lkdtm/bugs.c:78!
> [...]
> Kernel panic - not syncing: Aiee, killing interrupt handler!
This appears to still be unfixed. What's the blocker? The solutions in
this thread seem to work...
I'd like to be exercising an Oops path via KUnit (for KCFI), and riscv
just instantly falls over instead of thread-killing on the exception.
Thanks!
-Kees
--
Kees Cook
^ permalink raw reply
* Re: [PATCH v3] coredump: exit_files() in coredump_wait() if MMF_DUMP_MAPPED_SHARED is not set
From: Mateusz Guzik @ 2026-06-19 17:33 UTC (permalink / raw)
To: Christian Brauner
Cc: Xin Zhao, pfalcato, ebiederm, viro, jack, jlayton, chuck.lever,
alex.aring, arnd, keescook, mcgrof, j.granados, allen.lkml,
linux-fsdevel, linux-kernel, linux-arch
In-Reply-To: <178187726633.350634.1366346571707417413.b4-review@b4>
On Fri, Jun 19, 2026 at 03:54:26PM +0200, Christian Brauner wrote:
> > A coredump typically takes some time to complete. If we happen to hold a
> > write lock with flock just before triggering the coredump, that write lock
> > will not be released during the entire coredump process. As a result,
> > other processes attempting to acquire the same write lock may experience
> > significant delays.
> >
> > To address this, call exit_files() in the end of coredump_wait(), if
> > MMF_DUMP_MAPPED_SHARED is not set. Note that early unlocking a flock on a
> > file allows other processes to lock and modify the mapped data protected
> > by the flock.
> >
> > Signed-off-by: Xin Zhao <jackzxcui1989@163.com>
> >
> > diff --git a/fs/coredump.c b/fs/coredump.c
> > index bb6fdb1f458e..70698d06ec9d 100644
> > --- a/fs/coredump.c
> > +++ b/fs/coredump.c
> > @@ -548,6 +548,13 @@ static int coredump_wait(int exit_code, struct core_state *core_state)
> > }
> > }
> >
> > + /*
> > + * Early unlocking a flock on a file allows other processes
> > + * to lock and modify the mapped data protected by the flock.
> > + */
> > + if (!mm_flags_test(MMF_DUMP_MAPPED_SHARED, tsk->mm))
> > + exit_files(tsk);
>
> This doesn't work - at least not unconditionally. Tools like
> systemd-coredump or apport go through the fds. Specifically
> systemd-coredump does:
>
> 1) /proc/[pid]/fd/ — opendir() then, per entry, readlinkat() to get the symlink target.
> 2) /proc/[pid]/fdinfo/ — for each fd it reads the fdinfo text lines
>
> The blob is attached to the journal record as the COREDUMP_OPEN_FDS=
> field. So the open-fd list is recorded as metadata, retrievable later
> (e.g. coredumpctl info shows it).
>
> Also, irc some clever implementations use pidfd_getfd() to preserve the
> files from a coredumping process to preserve them.
>
> So you break all that - and only in some of the cases which is really
> opaque to userspace. That's not acceptable. If you only care about the
> case where you dump to a file then either special-case it to the legacy
> file coredump format or if it's generally useful make it an optional
> argument that can be passed to the coredump pipe and a new flag
> extension to the coredump socket that makes the coredumping process shed
> it's file descriptors.
>
The claim is the coredump takes "some time" without specifying what kind
of window is it (seconds, minutes?), nor where said time is spent.
For example it is known that a big mmapped areas are slow to dump even
if they are sparsely populated.
So I would suggest profiling what exactly happens in this case. It is
virtually guaranteed the time can be shortened, but it is plausible even
with fixups it will be too long.
Which brings me to the next point: the issue is not strictly any
particular file is still referenced by the target process, but that the
lock is held on it. Perhaps it would be perfectly fine to walk the fd
table and release these here instead of much later?
^ permalink raw reply
* [PATCH] kprobes: Replace __ASSEMBLY__ with __ASSEMBLER__ in header file
From: Thomas Huth @ 2026-06-19 16:14 UTC (permalink / raw)
To: Naveen N Rao, David S. Miller, Masami Hiramatsu
Cc: linux-kernel, linux-trace-kernel, linux-arch
From: Thomas Huth <thuth@redhat.com>
While the GCC and Clang compilers already define __ASSEMBLER__
automatically when compiling assembly code, __ASSEMBLY__ is a
macro that only gets defined by the Makefiles in the kernel.
This can be very confusing when switching between userspace
and kernelspace coding, or when dealing with uapi headers that
rather should use __ASSEMBLER__ instead. So let's standardize now
on the __ASSEMBLER__ macro that is provided by the compilers.
Signed-off-by: Thomas Huth <thuth@redhat.com>
---
Note: This patch has been split from an earlier bigger patch of
mine to ease reviewing.
include/asm-generic/kprobes.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/asm-generic/kprobes.h b/include/asm-generic/kprobes.h
index 5290a2b2e15a0..16f16963d503d 100644
--- a/include/asm-generic/kprobes.h
+++ b/include/asm-generic/kprobes.h
@@ -2,7 +2,7 @@
#ifndef _ASM_GENERIC_KPROBES_H
#define _ASM_GENERIC_KPROBES_H
-#if defined(__KERNEL__) && !defined(__ASSEMBLY__)
+#if defined(__KERNEL__) && !defined(__ASSEMBLER__)
#ifdef CONFIG_KPROBES
/*
* Blacklist ganerating macro. Specify functions which is not probed
@@ -21,6 +21,6 @@ static unsigned long __used \
# define __kprobes
# define nokprobe_inline inline
#endif
-#endif /* defined(__KERNEL__) && !defined(__ASSEMBLY__) */
+#endif /* defined(__KERNEL__) && !defined(__ASSEMBLER__) */
#endif /* _ASM_GENERIC_KPROBES_H */
--
2.54.0
^ permalink raw reply related
* Re: [PATCH v3] coredump: exit_files() in coredump_wait() if MMF_DUMP_MAPPED_SHARED is not set
From: Christian Brauner @ 2026-06-19 13:54 UTC (permalink / raw)
To: Xin Zhao
Cc: pfalcato, brauner, ebiederm, viro, jack, jlayton, chuck.lever,
alex.aring, arnd, keescook, mcgrof, j.granados, allen.lkml,
linux-fsdevel, linux-kernel, linux-arch
In-Reply-To: <20260619122419.3954581-1-jackzxcui1989@163.com>
> A coredump typically takes some time to complete. If we happen to hold a
> write lock with flock just before triggering the coredump, that write lock
> will not be released during the entire coredump process. As a result,
> other processes attempting to acquire the same write lock may experience
> significant delays.
>
> To address this, call exit_files() in the end of coredump_wait(), if
> MMF_DUMP_MAPPED_SHARED is not set. Note that early unlocking a flock on a
> file allows other processes to lock and modify the mapped data protected
> by the flock.
>
> Signed-off-by: Xin Zhao <jackzxcui1989@163.com>
>
> diff --git a/fs/coredump.c b/fs/coredump.c
> index bb6fdb1f458e..70698d06ec9d 100644
> --- a/fs/coredump.c
> +++ b/fs/coredump.c
> @@ -548,6 +548,13 @@ static int coredump_wait(int exit_code, struct core_state *core_state)
> }
> }
>
> + /*
> + * Early unlocking a flock on a file allows other processes
> + * to lock and modify the mapped data protected by the flock.
> + */
> + if (!mm_flags_test(MMF_DUMP_MAPPED_SHARED, tsk->mm))
> + exit_files(tsk);
This doesn't work - at least not unconditionally. Tools like
systemd-coredump or apport go through the fds. Specifically
systemd-coredump does:
1) /proc/[pid]/fd/ — opendir() then, per entry, readlinkat() to get the symlink target.
2) /proc/[pid]/fdinfo/ — for each fd it reads the fdinfo text lines
The blob is attached to the journal record as the COREDUMP_OPEN_FDS=
field. So the open-fd list is recorded as metadata, retrievable later
(e.g. coredumpctl info shows it).
Also, irc some clever implementations use pidfd_getfd() to preserve the
files from a coredumping process to preserve them.
So you break all that - and only in some of the cases which is really
opaque to userspace. That's not acceptable. If you only care about the
case where you dump to a file then either special-case it to the legacy
file coredump format or if it's generally useful make it an optional
argument that can be passed to the coredump pipe and a new flag
extension to the coredump socket that makes the coredumping process shed
it's file descriptors.
--
Christian Brauner <brauner@kernel.org>
^ permalink raw reply
* [PATCH] mm: Replace __ASSEMBLY__ with __ASSEMBLER__ in memory management header files
From: Thomas Huth @ 2026-06-19 13:18 UTC (permalink / raw)
To: Andrew Morton, David Hildenbrand
Cc: Lorenzo Stoakes, Vlastimil Babka, Liam R. Howlett, Mike Rapoport,
Suren Baghdasaryan, Michal Hocko, Kairui Song, Qi Zheng,
Shakeel Butt, Barry Song, Axel Rasmussen, Yuanchu Xie, Wei Xu,
linux-arch, linux-kernel, linux-mm
From: Thomas Huth <thuth@redhat.com>
While the GCC and Clang compilers already define __ASSEMBLER__
automatically when compiling assembly code, __ASSEMBLY__ is a
macro that only gets defined by the Makefiles in the kernel.
This can be very confusing when switching between userspace
and kernelspace coding, or when dealing with uapi headers that
rather should use __ASSEMBLER__ instead. So let's standardize now
on the __ASSEMBLER__ macro that is provided by the compilers.
This is a completely mechanical patch (done with a simple "sed -i"
statement).
Signed-off-by: Thomas Huth <thuth@redhat.com>
---
Note: This patch has been split from an earlier patch of mine
to ease reviewing.
include/asm-generic/fixmap.h | 4 ++--
include/asm-generic/getorder.h | 4 ++--
include/asm-generic/memory_model.h | 4 ++--
include/asm-generic/mmu.h | 2 +-
include/asm-generic/pgtable-nop4d.h | 4 ++--
include/asm-generic/pgtable-nopmd.h | 4 ++--
include/asm-generic/pgtable-nopud.h | 4 ++--
include/linux/mmzone.h | 4 ++--
include/linux/pfn.h | 2 +-
include/linux/pgtable.h | 4 ++--
10 files changed, 18 insertions(+), 18 deletions(-)
diff --git a/include/asm-generic/fixmap.h b/include/asm-generic/fixmap.h
index 29cab7947980a..3ff832ebcea50 100644
--- a/include/asm-generic/fixmap.h
+++ b/include/asm-generic/fixmap.h
@@ -21,7 +21,7 @@
#define __fix_to_virt(x) (FIXADDR_TOP - ((x) << PAGE_SHIFT))
#define __virt_to_fix(x) ((FIXADDR_TOP - ((x)&PAGE_MASK)) >> PAGE_SHIFT)
-#ifndef __ASSEMBLY__
+#ifndef __ASSEMBLER__
/*
* 'index to address' translation. If anyone tries to use the idx
* directly without translation, we catch the bug with a NULL-deference
@@ -97,5 +97,5 @@ static inline unsigned long virt_to_fix(const unsigned long vaddr)
#define set_fixmap_io(idx, phys) \
__set_fixmap(idx, phys, FIXMAP_PAGE_IO)
-#endif /* __ASSEMBLY__ */
+#endif /* __ASSEMBLER__ */
#endif /* __ASM_GENERIC_FIXMAP_H */
diff --git a/include/asm-generic/getorder.h b/include/asm-generic/getorder.h
index f2979e3a96b60..875ccae196832 100644
--- a/include/asm-generic/getorder.h
+++ b/include/asm-generic/getorder.h
@@ -2,7 +2,7 @@
#ifndef __ASM_GENERIC_GETORDER_H
#define __ASM_GENERIC_GETORDER_H
-#ifndef __ASSEMBLY__
+#ifndef __ASSEMBLER__
#include <linux/compiler.h>
#include <linux/log2.h>
@@ -47,6 +47,6 @@ static __always_inline __attribute_const__ int get_order(unsigned long size)
#endif
}
-#endif /* __ASSEMBLY__ */
+#endif /* __ASSEMBLER__ */
#endif /* __ASM_GENERIC_GETORDER_H */
diff --git a/include/asm-generic/memory_model.h b/include/asm-generic/memory_model.h
index efa6610acbc79..fd74de50b0540 100644
--- a/include/asm-generic/memory_model.h
+++ b/include/asm-generic/memory_model.h
@@ -4,7 +4,7 @@
#include <linux/pfn.h>
-#ifndef __ASSEMBLY__
+#ifndef __ASSEMBLER__
/*
* supports 3 memory models.
@@ -86,6 +86,6 @@ static inline int pfn_valid(unsigned long pfn)
#endif /* CONFIG_DEBUG_VIRTUAL */
#define phys_to_page(phys) pfn_to_page(PHYS_PFN(phys))
-#endif /* __ASSEMBLY__ */
+#endif /* __ASSEMBLER__ */
#endif
diff --git a/include/asm-generic/mmu.h b/include/asm-generic/mmu.h
index 0618380375429..5f78971e3ac2c 100644
--- a/include/asm-generic/mmu.h
+++ b/include/asm-generic/mmu.h
@@ -6,7 +6,7 @@
* This is the mmu.h header for nommu implementations.
* Architectures with an MMU need something more complex.
*/
-#ifndef __ASSEMBLY__
+#ifndef __ASSEMBLER__
typedef struct {
unsigned long end_brk;
diff --git a/include/asm-generic/pgtable-nop4d.h b/include/asm-generic/pgtable-nop4d.h
index 03b7dae47dd43..89c21f84cffbe 100644
--- a/include/asm-generic/pgtable-nop4d.h
+++ b/include/asm-generic/pgtable-nop4d.h
@@ -2,7 +2,7 @@
#ifndef _PGTABLE_NOP4D_H
#define _PGTABLE_NOP4D_H
-#ifndef __ASSEMBLY__
+#ifndef __ASSEMBLER__
#define __PAGETABLE_P4D_FOLDED 1
@@ -54,5 +54,5 @@ static inline p4d_t *p4d_offset(pgd_t *pgd, unsigned long address)
#undef p4d_addr_end
#define p4d_addr_end(addr, end) (end)
-#endif /* __ASSEMBLY__ */
+#endif /* __ASSEMBLER__ */
#endif /* _PGTABLE_NOP4D_H */
diff --git a/include/asm-generic/pgtable-nopmd.h b/include/asm-generic/pgtable-nopmd.h
index 8ffd64e7a24cb..36b6490ed1808 100644
--- a/include/asm-generic/pgtable-nopmd.h
+++ b/include/asm-generic/pgtable-nopmd.h
@@ -2,7 +2,7 @@
#ifndef _PGTABLE_NOPMD_H
#define _PGTABLE_NOPMD_H
-#ifndef __ASSEMBLY__
+#ifndef __ASSEMBLER__
#include <asm-generic/pgtable-nopud.h>
@@ -68,6 +68,6 @@ static inline void pmd_free(struct mm_struct *mm, pmd_t *pmd)
#undef pmd_addr_end
#define pmd_addr_end(addr, end) (end)
-#endif /* __ASSEMBLY__ */
+#endif /* __ASSEMBLER__ */
#endif /* _PGTABLE_NOPMD_H */
diff --git a/include/asm-generic/pgtable-nopud.h b/include/asm-generic/pgtable-nopud.h
index eb70c6d7ceff2..356cbfbaab247 100644
--- a/include/asm-generic/pgtable-nopud.h
+++ b/include/asm-generic/pgtable-nopud.h
@@ -2,7 +2,7 @@
#ifndef _PGTABLE_NOPUD_H
#define _PGTABLE_NOPUD_H
-#ifndef __ASSEMBLY__
+#ifndef __ASSEMBLER__
#include <asm-generic/pgtable-nop4d.h>
@@ -62,5 +62,5 @@ static inline pud_t *pud_offset(p4d_t *p4d, unsigned long address)
#undef pud_addr_end
#define pud_addr_end(addr, end) (end)
-#endif /* __ASSEMBLY__ */
+#endif /* __ASSEMBLER__ */
#endif /* _PGTABLE_NOPUD_H */
diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
index 9adb2ad21da59..d0cf5c697548d 100644
--- a/include/linux/mmzone.h
+++ b/include/linux/mmzone.h
@@ -2,7 +2,7 @@
#ifndef _LINUX_MMZONE_H
#define _LINUX_MMZONE_H
-#ifndef __ASSEMBLY__
+#ifndef __ASSEMBLER__
#ifndef __GENERATING_BOUNDS_H
#include <linux/spinlock.h>
@@ -2400,5 +2400,5 @@ static inline unsigned long next_present_section_nr(unsigned long section_nr)
#endif
#endif /* !__GENERATING_BOUNDS.H */
-#endif /* !__ASSEMBLY__ */
+#endif /* !__ASSEMBLER__ */
#endif /* _LINUX_MMZONE_H */
diff --git a/include/linux/pfn.h b/include/linux/pfn.h
index b90ca0b6c331e..cfedf0f61bb3c 100644
--- a/include/linux/pfn.h
+++ b/include/linux/pfn.h
@@ -2,7 +2,7 @@
#ifndef _LINUX_PFN_H_
#define _LINUX_PFN_H_
-#ifndef __ASSEMBLY__
+#ifndef __ASSEMBLER__
#include <linux/types.h>
#endif
diff --git a/include/linux/pgtable.h b/include/linux/pgtable.h
index 2981e386da7b3..dc804296d78f7 100644
--- a/include/linux/pgtable.h
+++ b/include/linux/pgtable.h
@@ -8,7 +8,7 @@
#define PMD_ORDER (PMD_SHIFT - PAGE_SHIFT)
#define PUD_ORDER (PUD_SHIFT - PAGE_SHIFT)
-#ifndef __ASSEMBLY__
+#ifndef __ASSEMBLER__
#ifdef CONFIG_MMU
#include <linux/mm_types.h>
@@ -2320,7 +2320,7 @@ static inline const char *pgtable_level_to_str(enum pgtable_level level)
}
}
-#endif /* !__ASSEMBLY__ */
+#endif /* !__ASSEMBLER__ */
#if !defined(MAX_POSSIBLE_PHYSMEM_BITS) && !defined(CONFIG_64BIT)
#ifdef CONFIG_PHYS_ADDR_T_64BIT
--
2.54.0
^ permalink raw reply related
* [PATCH v3] coredump: exit_files() in coredump_wait() if MMF_DUMP_MAPPED_SHARED is not set
From: Xin Zhao @ 2026-06-19 12:24 UTC (permalink / raw)
To: pfalcato, brauner, ebiederm, viro, jack, jlayton, chuck.lever,
alex.aring, arnd, keescook, mcgrof, j.granados, allen.lkml
Cc: linux-fsdevel, linux-kernel, linux-arch, Xin Zhao
A coredump typically takes some time to complete. If we happen to hold a
write lock with flock just before triggering the coredump, that write lock
will not be released during the entire coredump process. As a result,
other processes attempting to acquire the same write lock may experience
significant delays.
To address this, call exit_files() in the end of coredump_wait(), if
MMF_DUMP_MAPPED_SHARED is not set. Note that early unlocking a flock on a
file allows other processes to lock and modify the mapped data protected
by the flock.
Signed-off-by: Xin Zhao <jackzxcui1989@163.com>
---
Change in v3:
- Add comment and commit-log to explain why do the MMF_DUMP_MAPPED_SHARED
mm_flags_test() check, note that memory mapped files keep their own
separate references to the files. The case to work around is that early
unlocking a flock on a file allows other processes to lock and modify
the mapped data protected by the flock,
as suggested by Pedro Falcato.
Change in v2:
- Get rid of the implement of adding new fcntl API, the issue does not
worth inflicting the cost on everyone,
as suggested by Al Viro.
- Call exit_files() in coredump_wait(),
as suggested by Eric W. Biederman.
Add MMF_DUMP_MAPPED_SHARED mm_flags_test() check to filter cases that
need to dump file-backed shared memory.
- Link to v2: https://lore.kernel.org/lkml/20260618150301.3226517-1-jackzxcui1989@163.com/
v1:
- Link to v1: https://lore.kernel.org/all/20260618030700.2511668-1-jackzxcui1989@163.com/
---
fs/coredump.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/fs/coredump.c b/fs/coredump.c
index bb6fdb1f4..70698d06e 100644
--- a/fs/coredump.c
+++ b/fs/coredump.c
@@ -548,6 +548,13 @@ static int coredump_wait(int exit_code, struct core_state *core_state)
}
}
+ /*
+ * Early unlocking a flock on a file allows other processes
+ * to lock and modify the mapped data protected by the flock.
+ */
+ if (!mm_flags_test(MMF_DUMP_MAPPED_SHARED, tsk->mm))
+ exit_files(tsk);
+
return core_waiters;
}
--
2.34.1
^ permalink raw reply related
* Re: [PATCH] coredump/fcntl: Add FD_CLOBCOR flag to close fd before dumping core
From: Xin Zhao @ 2026-06-19 11:27 UTC (permalink / raw)
To: brauner
Cc: alex.aring, allen.lkml, arnd, chuck.lever, ebiederm, j.granados,
jack, jackzxcui1989, jlayton, keescook, linux-arch, linux-fsdevel,
linux-kernel, mcgrof, viro
In-Reply-To: <20260619-hiervon-kopfsache-rechen-efbdf4463544@brauner>
On Fri, 19 Jun 2026 09:23:30 +0200 Christian Brauner <brauner@kernel.org> wrote:
> On Thu, Jun 18, 2026 at 11:07:00AM +0800, Xin Zhao wrote:
> > A coredump typically takes some time to complete. If we happen to hold a
> > write lock with flock just before triggering the coredump, that write lock
> > will not be released during the entire coredump process. As a result,
> > other processes attempting to acquire the same write lock may experience
> > significant delays.
> >
> > To address this, we introduce the F_[GET|SET]FD_EX fcntl operation and the
> > FD_CLOBCOR flag, allowing coredump_wait() to release any file descriptors
> > marked with FD_CLOBCOR. We can also assign the FD_CLOBCOR flag to specific
> > shared memory segments, preventing the coredump from including shared
> > memory that we are not interested in, thereby reducing both the coredump
> > duration and the size of the core file.
> >
> > We actually considered using signals that generate coredumps to perform
> > the actions we wanted in user space. However, since other threads within
> > the process are not frozen when handling these signals, indiscriminately
> > closing an fd can lead to concurrency issues. For example, if the thread
> > that triggered the coredump closes the fd in the signal handler while
> > other threads are using the resources associated with that fd, it could
> > cause secondary corruption of the coredump state.
> >
> > Signed-off-by: Xin Zhao <jackzxcui1989@163.com>
> > ---
>
> Eew, NAK. No way we're doing this.
> I can see a point in filtering memory that one isn't interested in but
> that has to be built on top of the coredump socket protoctol by
> extending it.
Thank you for your suggestion. Now, besides knowing about MADV_DONTDUMP to
filter out uninteresting memory, I also learned about the new method you
mentioned: the coredump socket protocol.
In addition to the need to filter out uninteresting memory during a core
dump, what I really hope to address is the issue of the flock lock being
held for a long time during the core dump process. I have completely
given up on adding a new fcntl interface to solve this problem. In the v2
version I sent, I called exit_files in coredump_wait to address this
issue. Please let me know if you have any comments on my v2 version.
Link: https://lore.kernel.org/lkml/20260619003900.3546571-1-jackzxcui1989@163.com/
Thanks
Xin Zhao
^ permalink raw reply
* [PATCH] vdso: Replace __ASSEMBLY__ with __ASSEMBLER__ in header files
From: Thomas Huth @ 2026-06-19 10:06 UTC (permalink / raw)
To: Andy Lutomirski, Thomas Gleixner, Vincenzo Frascino, linux-kernel
Cc: linux-arch
From: Thomas Huth <thuth@redhat.com>
While the GCC and Clang compilers already define __ASSEMBLER__
automatically when compiling assembly code, __ASSEMBLY__ is a
macro that only gets defined by the Makefiles in the kernel.
This can be very confusing when switching between userspace
and kernelspace coding, or when dealing with uapi headers that
rather should use __ASSEMBLER__ instead. So let's standardize now
on the __ASSEMBLER__ macro that is provided by the compilers.
This is a completely mechanical patch (done with a simple "sed -i"
statement).
Signed-off-by: Thomas Huth <thuth@redhat.com>
---
Note: This patch has been split from an earlier bigger patch of mine
to ease reviewing.
include/asm-generic/vdso/vsyscall.h | 4 ++--
include/vdso/datapage.h | 6 +++---
include/vdso/helpers.h | 4 ++--
include/vdso/processor.h | 4 ++--
include/vdso/vsyscall.h | 4 ++--
5 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/include/asm-generic/vdso/vsyscall.h b/include/asm-generic/vdso/vsyscall.h
index 5c6d9799f4e74..a6b03cfba0e24 100644
--- a/include/asm-generic/vdso/vsyscall.h
+++ b/include/asm-generic/vdso/vsyscall.h
@@ -2,7 +2,7 @@
#ifndef __ASM_GENERIC_VSYSCALL_H
#define __ASM_GENERIC_VSYSCALL_H
-#ifndef __ASSEMBLY__
+#ifndef __ASSEMBLER__
#ifndef __arch_get_vdso_u_time_data
static __always_inline const struct vdso_time_data *__arch_get_vdso_u_time_data(void)
@@ -30,6 +30,6 @@ static __always_inline void __arch_sync_vdso_time_data(struct vdso_time_data *vd
}
#endif /* __arch_sync_vdso_time_data */
-#endif /* !__ASSEMBLY__ */
+#endif /* !__ASSEMBLER__ */
#endif /* __ASM_GENERIC_VSYSCALL_H */
diff --git a/include/vdso/datapage.h b/include/vdso/datapage.h
index 5977723fb3b5d..09897f76ae07a 100644
--- a/include/vdso/datapage.h
+++ b/include/vdso/datapage.h
@@ -2,7 +2,7 @@
#ifndef __VDSO_DATAPAGE_H
#define __VDSO_DATAPAGE_H
-#ifndef __ASSEMBLY__
+#ifndef __ASSEMBLER__
#include <linux/types.h>
@@ -176,7 +176,7 @@ enum vdso_pages {
VDSO_NR_PAGES
};
-#else /* !__ASSEMBLY__ */
+#else /* !__ASSEMBLER__ */
#ifdef CONFIG_VDSO_GETRANDOM
#define __vdso_u_rng_data PROVIDE(vdso_u_rng_data = vdso_u_data + 2 * PAGE_SIZE);
@@ -197,6 +197,6 @@ enum vdso_pages {
__vdso_u_arch_data \
-#endif /* !__ASSEMBLY__ */
+#endif /* !__ASSEMBLER__ */
#endif /* __VDSO_DATAPAGE_H */
diff --git a/include/vdso/helpers.h b/include/vdso/helpers.h
index a3bf4f1c0d37d..65151b681c4f5 100644
--- a/include/vdso/helpers.h
+++ b/include/vdso/helpers.h
@@ -2,7 +2,7 @@
#ifndef __VDSO_HELPERS_H
#define __VDSO_HELPERS_H
-#ifndef __ASSEMBLY__
+#ifndef __ASSEMBLER__
#include <asm/barrier.h>
#include <vdso/datapage.h>
@@ -111,6 +111,6 @@ static __always_inline void vdso_write_end(struct vdso_time_data *vd)
vdso_write_seq_end(&vc[CS_RAW]);
}
-#endif /* !__ASSEMBLY__ */
+#endif /* !__ASSEMBLER__ */
#endif /* __VDSO_HELPERS_H */
diff --git a/include/vdso/processor.h b/include/vdso/processor.h
index fbe8265ea3c49..cc781912a696e 100644
--- a/include/vdso/processor.h
+++ b/include/vdso/processor.h
@@ -5,10 +5,10 @@
#ifndef __VDSO_PROCESSOR_H
#define __VDSO_PROCESSOR_H
-#ifndef __ASSEMBLY__
+#ifndef __ASSEMBLER__
#include <asm/vdso/processor.h>
-#endif /* __ASSEMBLY__ */
+#endif /* __ASSEMBLER__ */
#endif /* __VDSO_PROCESSOR_H */
diff --git a/include/vdso/vsyscall.h b/include/vdso/vsyscall.h
index b0fdc9c6bf439..c5c2a2c078571 100644
--- a/include/vdso/vsyscall.h
+++ b/include/vdso/vsyscall.h
@@ -2,13 +2,13 @@
#ifndef __VDSO_VSYSCALL_H
#define __VDSO_VSYSCALL_H
-#ifndef __ASSEMBLY__
+#ifndef __ASSEMBLER__
#include <asm/vdso/vsyscall.h>
unsigned long vdso_update_begin(void);
void vdso_update_end(unsigned long flags);
-#endif /* !__ASSEMBLY__ */
+#endif /* !__ASSEMBLER__ */
#endif /* __VDSO_VSYSCALL_H */
--
2.54.0
^ permalink raw reply related
* Re: [PATCH] coredump/fcntl: Add FD_CLOBCOR flag to close fd before dumping core
From: Christian Brauner @ 2026-06-19 7:23 UTC (permalink / raw)
To: Xin Zhao
Cc: viro, jack, jlayton, chuck.lever, alex.aring, arnd, ebiederm,
keescook, mcgrof, j.granados, allen.lkml, linux-fsdevel,
linux-kernel, linux-arch
In-Reply-To: <20260618030700.2511668-1-jackzxcui1989@163.com>
On Thu, Jun 18, 2026 at 11:07:00AM +0800, Xin Zhao wrote:
> A coredump typically takes some time to complete. If we happen to hold a
> write lock with flock just before triggering the coredump, that write lock
> will not be released during the entire coredump process. As a result,
> other processes attempting to acquire the same write lock may experience
> significant delays.
>
> To address this, we introduce the F_[GET|SET]FD_EX fcntl operation and the
> FD_CLOBCOR flag, allowing coredump_wait() to release any file descriptors
> marked with FD_CLOBCOR. We can also assign the FD_CLOBCOR flag to specific
> shared memory segments, preventing the coredump from including shared
> memory that we are not interested in, thereby reducing both the coredump
> duration and the size of the core file.
>
> We actually considered using signals that generate coredumps to perform
> the actions we wanted in user space. However, since other threads within
> the process are not frozen when handling these signals, indiscriminately
> closing an fd can lead to concurrency issues. For example, if the thread
> that triggered the coredump closes the fd in the signal handler while
> other threads are using the resources associated with that fd, it could
> cause secondary corruption of the coredump state.
>
> Signed-off-by: Xin Zhao <jackzxcui1989@163.com>
> ---
Eew, NAK. No way we're doing this.
I can see a point in filtering memory that one isn't interested in but
that has to be built on top of the coredump socket protoctol by
extending it.
^ permalink raw reply
* Re: [PATCH v2] coredump: exit_files() in coredump_wait() if MMF_DUMP_MAPPED_SHARED is not set
From: Xin Zhao @ 2026-06-19 0:39 UTC (permalink / raw)
To: pfalcato
Cc: alex.aring, allen.lkml, arnd, brauner, chuck.lever, ebiederm,
j.granados, jack, jackzxcui1989, jlayton, keescook, linux-arch,
linux-fsdevel, linux-kernel, mcgrof, viro
In-Reply-To: <ajQoFeTyIqh6tMVv@pedro-suse>
On Thu, 18 Jun 2026 18:19:16 +0100 Pedro Falcato <pfalcato@suse.de> wrote:
> > > + if (!mm_flags_test(MMF_DUMP_MAPPED_SHARED, tsk->mm))
> > > + exit_files(tsk);
> >
> > Memory mapped files keep their own separate references to the files
> > (in struct vm_area_struct::vm_file), so there is no need to attempt to
> > work around this. Unless I'm misunderstanding what you're attempting
> > to work around.
>
> Waiit, I think I get it - you have a flock on a file, and you're scared
> that if you unlock early, some other process can lock it and modify some other
> file we have mapped? If so, that does make some sense. Please add that as
> a comment and/or into the git log, because it feels very much non-obvious
> to me.
I did forget that mmap also increases the reference count, but the case
you mentioned is one we also want to work around. I will add this
information to both the commit log and the comments as below:
Early unlocking a flock on a file allows other processes to lock and
modify the mapped data protected by the flock.
Thanks
Xin Zhao
^ permalink raw reply
* RE: [RFC PATCH 5/6] arm64: hyperv: Route hypercalls through RSI host call in CCA Realms
From: Michael Kelley @ 2026-06-18 17:46 UTC (permalink / raw)
To: Kameron Carr, kys@microsoft.com, haiyangz@microsoft.com,
wei.liu@kernel.org, decui@microsoft.com, longli@microsoft.com
Cc: catalin.marinas@arm.com, will@kernel.org, mark.rutland@arm.com,
lpieralisi@kernel.org, sudeep.holla@kernel.org, arnd@arndb.de,
thuth@redhat.com, linux-hyperv@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org,
Michael Kelley
In-Reply-To: <20260609181030.2378391-6-kameroncarr@linux.microsoft.com>
From: Kameron Carr <kameroncarr@linux.microsoft.com> Sent: Tuesday, June 9, 2026 11:10 AM
>
> Modify the five hypercall wrapper functions to check is_realm_world()
> and use the per-CPU rsi_host_call structure when inside a Realm.
>
> Signed-off-by: Kameron Carr <kameroncarr@linux.microsoft.com>
> ---
> arch/arm64/hyperv/hv_core.c | 175 +++++++++++++++++++++++++++++-------
> 1 file changed, 141 insertions(+), 34 deletions(-)
>
> diff --git a/arch/arm64/hyperv/hv_core.c b/arch/arm64/hyperv/hv_core.c
> index e33a9e3c366a1..1759998ef2667 100644
> --- a/arch/arm64/hyperv/hv_core.c
> +++ b/arch/arm64/hyperv/hv_core.c
> @@ -16,6 +16,7 @@
> #include <asm-generic/bug.h>
> #include <hyperv/hvhdk.h>
> #include <asm/mshyperv.h>
> +#include <asm/rsi.h>
>
> /*
> * hv_do_hypercall- Invoke the specified hypercall
> @@ -25,12 +26,32 @@ u64 hv_do_hypercall(u64 control, void *input, void *output)
> struct arm_smccc_res res;
> u64 input_address;
> u64 output_address;
> + struct rsi_host_call *hostcall;
> + unsigned long flags;
> + u64 ret;
>
> input_address = input ? virt_to_phys(input) : 0;
> output_address = output ? virt_to_phys(output) : 0;
>
> - arm_smccc_1_1_hvc(HV_FUNC_ID, control,
> - input_address, output_address, &res);
> + if (is_realm_world()) {
> + local_irq_save(flags);
> + hostcall = *this_cpu_ptr(hyperv_pcpu_hostcall_struct);
> + memset(hostcall, 0, sizeof(*hostcall));
> + hostcall->gprs[0] = HV_FUNC_ID;
> + hostcall->gprs[1] = control;
> + hostcall->gprs[2] = input_address;
> + hostcall->gprs[3] = output_address;
> +
> + if (rsi_host_call(virt_to_phys(hostcall)) == RSI_SUCCESS)
> + ret = hostcall->gprs[0];
> + else
> + ret = HV_STATUS_INVALID_HYPERCALL_INPUT;
> + local_irq_restore(flags);
> + return ret;
This code sequence for handling the realm case is almost exactly
duplicated for the three hypercall variants. The only difference is
how gprs[2] and gprs[3] are populated. So I think the code
sequence could go into a helper routine with the appropriate
values for gprs[2] and gprs[3] passed in.
> + }
> +
> + arm_smccc_1_1_hvc(HV_FUNC_ID, control, input_address,
> + output_address, &res);
> return res.a0;
> }
> EXPORT_SYMBOL_GPL(hv_do_hypercall);
> @@ -45,9 +66,28 @@ u64 hv_do_fast_hypercall8(u16 code, u64 input)
> {
> struct arm_smccc_res res;
> u64 control;
> + struct rsi_host_call *hostcall;
> + unsigned long flags;
> + u64 ret;
>
> control = (u64)code | HV_HYPERCALL_FAST_BIT;
>
> + if (is_realm_world()) {
> + local_irq_save(flags);
> + hostcall = *this_cpu_ptr(hyperv_pcpu_hostcall_struct);
> + memset(hostcall, 0, sizeof(*hostcall));
> + hostcall->gprs[0] = HV_FUNC_ID;
> + hostcall->gprs[1] = control;
> + hostcall->gprs[2] = input;
> +
> + if (rsi_host_call(virt_to_phys(hostcall)) == RSI_SUCCESS)
> + ret = hostcall->gprs[0];
> + else
> + ret = HV_STATUS_INVALID_HYPERCALL_INPUT;
> + local_irq_restore(flags);
> + return ret;
> + }
> +
> arm_smccc_1_1_hvc(HV_FUNC_ID, control, input, &res);
> return res.a0;
> }
> @@ -62,9 +102,29 @@ u64 hv_do_fast_hypercall16(u16 code, u64 input1, u64 input2)
> {
> struct arm_smccc_res res;
> u64 control;
> + struct rsi_host_call *hostcall;
> + unsigned long flags;
> + u64 ret;
>
> control = (u64)code | HV_HYPERCALL_FAST_BIT;
>
> + if (is_realm_world()) {
> + local_irq_save(flags);
> + hostcall = *this_cpu_ptr(hyperv_pcpu_hostcall_struct);
> + memset(hostcall, 0, sizeof(*hostcall));
> + hostcall->gprs[0] = HV_FUNC_ID;
> + hostcall->gprs[1] = control;
> + hostcall->gprs[2] = input1;
> + hostcall->gprs[3] = input2;
> +
> + if (rsi_host_call(virt_to_phys(hostcall)) == RSI_SUCCESS)
> + ret = hostcall->gprs[0];
> + else
> + ret = HV_STATUS_INVALID_HYPERCALL_INPUT;
> + local_irq_restore(flags);
> + return ret;
> + }
> +
> arm_smccc_1_1_hvc(HV_FUNC_ID, control, input1, input2, &res);
> return res.a0;
> }
> @@ -76,24 +136,44 @@ EXPORT_SYMBOL_GPL(hv_do_fast_hypercall16);
> void hv_set_vpreg(u32 msr, u64 value)
> {
> struct arm_smccc_res res;
> + struct rsi_host_call *hostcall;
> + unsigned long flags;
> + u64 status;
> +
> + if (is_realm_world()) {
> + local_irq_save(flags);
> + hostcall = *this_cpu_ptr(hyperv_pcpu_hostcall_struct);
> + memset(hostcall, 0, sizeof(*hostcall));
> + hostcall->gprs[0] = HV_FUNC_ID;
> + hostcall->gprs[1] = HVCALL_SET_VP_REGISTERS |
> + HV_HYPERCALL_FAST_BIT |
> + HV_HYPERCALL_REP_COMP_1;
> + hostcall->gprs[2] = HV_PARTITION_ID_SELF;
> + hostcall->gprs[3] = HV_VP_INDEX_SELF;
> + hostcall->gprs[4] = msr;
> + hostcall->gprs[6] = value;
>
> - arm_smccc_1_1_hvc(HV_FUNC_ID,
> - HVCALL_SET_VP_REGISTERS | HV_HYPERCALL_FAST_BIT |
> - HV_HYPERCALL_REP_COMP_1,
> - HV_PARTITION_ID_SELF,
> - HV_VP_INDEX_SELF,
> - msr,
> - 0,
> - value,
> - 0,
> - &res);
> + if (rsi_host_call(virt_to_phys(hostcall)) == RSI_SUCCESS)
> + status = hostcall->gprs[0];
> + else
> + status = HV_STATUS_INVALID_HYPERCALL_INPUT;
> + local_irq_restore(flags);
> + } else {
> + arm_smccc_1_1_hvc(HV_FUNC_ID,
> + HVCALL_SET_VP_REGISTERS |
> + HV_HYPERCALL_FAST_BIT |
> + HV_HYPERCALL_REP_COMP_1,
> + HV_PARTITION_ID_SELF, HV_VP_INDEX_SELF, msr,
> + 0, value, 0, &res);
> + status = res.a0;
> + }
>
> /*
> - * Something is fundamentally broken in the hypervisor if
> - * setting a VP register fails. There's really no way to
> - * continue as a guest VM, so panic.
> + * Something is fundamentally broken in the hypervisor (or, in a
> + * Realm, the RMM denied the host call) if setting a VP register
> + * fails. There's really no way to continue as a guest VM, so panic.
> */
> - BUG_ON(!hv_result_success(res.a0));
> + BUG_ON(!hv_result_success(status));
> }
> EXPORT_SYMBOL_GPL(hv_set_vpreg);
>
> @@ -108,29 +188,56 @@ void hv_get_vpreg_128(u32 msr, struct
> hv_get_vp_registers_output *result)
> {
> struct arm_smccc_1_2_regs args;
> struct arm_smccc_1_2_regs res;
> + struct rsi_host_call *hostcall;
> + u64 status;
>
> - args.a0 = HV_FUNC_ID;
> - args.a1 = HVCALL_GET_VP_REGISTERS | HV_HYPERCALL_FAST_BIT |
> - HV_HYPERCALL_REP_COMP_1;
> - args.a2 = HV_PARTITION_ID_SELF;
> - args.a3 = HV_VP_INDEX_SELF;
> - args.a4 = msr;
> + if (is_realm_world()) {
> + unsigned long flags;
>
> - /*
> - * Use the SMCCC 1.2 interface because the results are in registers
> - * beyond X0-X3.
> - */
> - arm_smccc_1_2_hvc(&args, &res);
> + local_irq_save(flags);
> + hostcall = *this_cpu_ptr(hyperv_pcpu_hostcall_struct);
> + memset(hostcall, 0, sizeof(*hostcall));
> +
> + hostcall->gprs[0] = HV_FUNC_ID;
> + hostcall->gprs[1] = HVCALL_GET_VP_REGISTERS |
> + HV_HYPERCALL_FAST_BIT |
> + HV_HYPERCALL_REP_COMP_1;
> + hostcall->gprs[2] = HV_PARTITION_ID_SELF;
> + hostcall->gprs[3] = HV_VP_INDEX_SELF;
> + hostcall->gprs[4] = msr;
> +
> + if (rsi_host_call(virt_to_phys(hostcall)) == RSI_SUCCESS) {
> + status = hostcall->gprs[0];
> + result->as64.low = hostcall->gprs[6];
> + result->as64.high = hostcall->gprs[7];
> + } else {
> + status = HV_STATUS_INVALID_HYPERCALL_INPUT;
> + }
> + local_irq_restore(flags);
> + } else {
> + args.a0 = HV_FUNC_ID;
> + args.a1 = HVCALL_GET_VP_REGISTERS | HV_HYPERCALL_FAST_BIT |
> + HV_HYPERCALL_REP_COMP_1;
> + args.a2 = HV_PARTITION_ID_SELF;
> + args.a3 = HV_VP_INDEX_SELF;
> + args.a4 = msr;
> +
> + /*
> + * Use the SMCCC 1.2 interface because the results are in
> + * registers beyond X0-X3.
> + */
> + arm_smccc_1_2_hvc(&args, &res);
> + status = res.a0;
> + result->as64.low = res.a6;
> + result->as64.high = res.a7;
> + }
>
> /*
> - * Something is fundamentally broken in the hypervisor if
> - * getting a VP register fails. There's really no way to
> - * continue as a guest VM, so panic.
> + * Something is fundamentally broken in the hypervisor (or, in a
> + * Realm, the RMM denied the host call) if getting a VP register
> + * fails. There's really no way to continue as a guest VM, so panic.
> */
> - BUG_ON(!hv_result_success(res.a0));
> -
> - result->as64.low = res.a6;
> - result->as64.high = res.a7;
> + BUG_ON(!hv_result_success(status));
> }
> EXPORT_SYMBOL_GPL(hv_get_vpreg_128);
>
> --
> 2.45.4
>
^ permalink raw reply
* RE: [RFC PATCH 3/6] arm64: hyperv: Add per-CPU RSI host call infrastructure for CCA Realms
From: Michael Kelley @ 2026-06-18 17:46 UTC (permalink / raw)
To: Kameron Carr, kys@microsoft.com, haiyangz@microsoft.com,
wei.liu@kernel.org, decui@microsoft.com, longli@microsoft.com
Cc: catalin.marinas@arm.com, will@kernel.org, mark.rutland@arm.com,
lpieralisi@kernel.org, sudeep.holla@kernel.org, arnd@arndb.de,
thuth@redhat.com, linux-hyperv@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org,
Michael Kelley
In-Reply-To: <20260609181030.2378391-4-kameroncarr@linux.microsoft.com>
From: Kameron Carr <kameroncarr@linux.microsoft.com> Sent: Tuesday, June 9, 2026 11:10 AM
>
> Arm CCA Realms cannot issue Hyper-V hypercalls via HVC; the guest must
> route them through the RSI_HOST_CALL interface, which takes the IPA of a
> per-CPU rsi_host_call structure as its argument.
>
> Add hyperv_pcpu_hostcall_struct as a per-CPU pointer to that buffer and
> allocate it for the boot CPU during hyperv_init() and for each secondary
> CPU in hv_cpu_init(). The allocation is gated on is_realm_world() so
> non-Realm arm64 Hyper-V guests pay no memory cost.
I wonder if there's a simpler approach here. What about calculating the
total size of struct rsi_host_call needed for all CPUs, then doing a single
dynamic allocation to effectively create an array of entries? Each CPU
would just index into the array with its processor ID. You could still have
a per-cpu pointer that points to the correct array entry to avoid the need
to get the processor ID, but I wonder if even that is worth the trouble. Since
struct rsi_host_call size is a power of 2, the indexing is just a simple shift.
The hyperv_pcpu_input_page is allocated the way it is because it's much
bigger. But 16 struct rsi_host_call fit into a single 4 KiB, so there's no
danger of hitting a memory allocation limit at boot time. Even with 8192
CPUs the allocation is only 2 MiB.
Michael
>
> Signed-off-by: Kameron Carr <kameroncarr@linux.microsoft.com>
> ---
> arch/arm64/hyperv/mshyperv.c | 78 ++++++++++++++++++++++++++++++-
> arch/arm64/include/asm/mshyperv.h | 3 ++
> 2 files changed, 79 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/hyperv/mshyperv.c b/arch/arm64/hyperv/mshyperv.c
> index 4fdc26ade1d74..08fec82691683 100644
> --- a/arch/arm64/hyperv/mshyperv.c
> +++ b/arch/arm64/hyperv/mshyperv.c
> @@ -15,10 +15,16 @@
> #include <linux/errno.h>
> #include <linux/version.h>
> #include <linux/cpuhotplug.h>
> +#include <linux/slab.h>
> +#include <linux/percpu.h>
> #include <asm/mshyperv.h>
> +#include <asm/rsi.h>
>
> static bool hyperv_initialized;
>
> +void * __percpu *hyperv_pcpu_hostcall_struct;
> +EXPORT_SYMBOL_GPL(hyperv_pcpu_hostcall_struct);
> +
> int hv_get_hypervisor_version(union hv_hypervisor_version_info *info)
> {
> hv_get_vpreg_128(HV_REGISTER_HYPERVISOR_VERSION,
> @@ -60,6 +66,46 @@ static bool __init hyperv_detect_via_acpi(void)
>
> #endif
>
> +static void hv_hostcall_free(void)
> +{
> + int cpu;
> +
> + if (!hyperv_pcpu_hostcall_struct)
> + return;
> +
> + for_each_possible_cpu(cpu)
> + kfree(*per_cpu_ptr(hyperv_pcpu_hostcall_struct, cpu));
> + free_percpu(hyperv_pcpu_hostcall_struct);
> + hyperv_pcpu_hostcall_struct = NULL;
> +}
> +
> +static int hv_cpu_init(unsigned int cpu)
> +{
> + void **hostcall_struct;
> + gfp_t flags;
> + void *mem;
> +
> + if (hyperv_pcpu_hostcall_struct) {
> + /* hv_cpu_init() can be called with IRQs disabled from hv_resume() */
> + flags = irqs_disabled() ? GFP_ATOMIC : GFP_KERNEL;
> +
> + hostcall_struct = (void **)this_cpu_ptr(hyperv_pcpu_hostcall_struct);
> + /*
> + * The hostcall_struct memory is not freed when the CPU
> + * goes offline. If a previously offlined CPU is brought
> + * back online, the memory is reused here.
> + */
> + if (!*hostcall_struct) {
> + mem = kzalloc_obj(struct rsi_host_call, flags);
> + if (!mem)
> + return -ENOMEM;
> + *hostcall_struct = mem;
> + }
> + }
> +
> + return hv_common_cpu_init(cpu);
> +}
> +
> static bool __init hyperv_detect_via_smccc(void)
> {
> uuid_t hyperv_uuid = UUID_INIT(
> @@ -73,6 +119,8 @@ static bool __init hyperv_detect_via_smccc(void)
> static int __init hyperv_init(void)
> {
> struct hv_get_vp_registers_output result;
> + void **hostcall_struct;
> + void *mem;
> u64 guest_id;
> int ret;
>
> @@ -85,6 +133,27 @@ static int __init hyperv_init(void)
> if (!hyperv_detect_via_acpi() && !hyperv_detect_via_smccc())
> return 0;
>
> + /*
> + * The RSI host-call buffer is only ever used when
> + * is_realm_world() is true. Skip the per-CPU allocation on
> + * non-Realm guests.
> + */
> + if (is_realm_world()) {
> + hyperv_pcpu_hostcall_struct = alloc_percpu(void *);
> + if (!hyperv_pcpu_hostcall_struct)
> + return -ENOMEM;
> +
> + hostcall_struct = (void **)this_cpu_ptr(hyperv_pcpu_hostcall_struct);
> + if (!*hostcall_struct) {
> + mem = kzalloc_obj(struct rsi_host_call);
> + if (!mem) {
> + ret = -ENOMEM;
> + goto free_hostcall_mem;
> + }
> + *hostcall_struct = mem;
> + }
> + }
> +
> /* Setup the guest ID */
> guest_id = hv_generate_guest_id(LINUX_VERSION_CODE);
> hv_set_vpreg(HV_REGISTER_GUEST_OS_ID, guest_id);
> @@ -106,12 +175,13 @@ static int __init hyperv_init(void)
>
> ret = hv_common_init();
> if (ret)
> - return ret;
> + goto free_hostcall_mem;
>
> ret = cpuhp_setup_state(CPUHP_AP_HYPERV_ONLINE,
> "arm64/hyperv_init:online",
> - hv_common_cpu_init, hv_common_cpu_die);
> + hv_cpu_init, hv_common_cpu_die);
> if (ret < 0) {
> hv_common_free();
> + hv_hostcall_free();
> return ret;
> }
>
> @@ -125,6 +195,10 @@ static int __init hyperv_init(void)
>
> hyperv_initialized = true;
> return 0;
> +
> +free_hostcall_mem:
> + hv_hostcall_free();
> + return ret;
> }
>
> early_initcall(hyperv_init);
> diff --git a/arch/arm64/include/asm/mshyperv.h b/arch/arm64/include/asm/mshyperv.h
> index b721d3134ab66..65a00bd14c6cb 100644
> --- a/arch/arm64/include/asm/mshyperv.h
> +++ b/arch/arm64/include/asm/mshyperv.h
> @@ -63,4 +63,7 @@ static inline u64 hv_get_non_nested_msr(unsigned int reg)
>
> #include <asm-generic/mshyperv.h>
>
> +/* Per-CPU RSI host call structure for CCA Realms */
> +extern void *__percpu *hyperv_pcpu_hostcall_struct;
> +
> #endif
> --
> 2.45.4
>
^ permalink raw reply
* RE: [RFC PATCH 2/6] firmware: smccc: Detect hypervisor via RSI host call in CCA Realms
From: Michael Kelley @ 2026-06-18 17:45 UTC (permalink / raw)
To: Kameron Carr, kys@microsoft.com, haiyangz@microsoft.com,
wei.liu@kernel.org, decui@microsoft.com, longli@microsoft.com
Cc: catalin.marinas@arm.com, will@kernel.org, mark.rutland@arm.com,
lpieralisi@kernel.org, sudeep.holla@kernel.org, arnd@arndb.de,
thuth@redhat.com, linux-hyperv@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org,
Michael Kelley
In-Reply-To: <20260609181030.2378391-3-kameroncarr@linux.microsoft.com>
From: Kameron Carr <kameroncarr@linux.microsoft.com> Sent: Tuesday, June 9, 2026 11:10 AM
>
> Modify arm_smccc_hypervisor_has_uuid() to check is_realm_world() and
> use rsi_host_call() to query the hypervisor vendor UUID when inside a
> Realm. The realm path is factored into a helper,
> arm_smccc_realm_get_hypervisor_uuid(), that owns a file-static
> rsi_host_call buffer (uuid_hc) serialized by a spinlock.
>
> The RSI-specific includes, file-static state and helper are guarded
> with CONFIG_ARM64 because <asm/rsi.h> does not exist on 32-bit ARM.
>
> For non-Realm environments, the existing arm_smccc_1_1_invoke() path
> is unchanged.
>
> Signed-off-by: Kameron Carr <kameroncarr@linux.microsoft.com>
> ---
> drivers/firmware/smccc/smccc.c | 41 +++++++++++++++++++++++++++++++++-
> 1 file changed, 40 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/firmware/smccc/smccc.c b/drivers/firmware/smccc/smccc.c
> index bdee057db2fd3..6b465e65472b0 100644
> --- a/drivers/firmware/smccc/smccc.c
> +++ b/drivers/firmware/smccc/smccc.c
> @@ -12,6 +12,12 @@
> #include <linux/platform_device.h>
> #include <asm/archrandom.h>
>
> +#ifdef CONFIG_ARM64
> +#include <linux/cleanup.h>
> +#include <linux/spinlock.h>
> +#include <asm/rsi.h>
> +#endif
> +
> static u32 smccc_version = ARM_SMCCC_VERSION_1_0;
> static enum arm_smccc_conduit smccc_conduit = SMCCC_CONDUIT_NONE;
>
> @@ -67,12 +73,45 @@ s32 arm_smccc_get_soc_id_revision(void)
> }
> EXPORT_SYMBOL_GPL(arm_smccc_get_soc_id_revision);
>
> +#ifdef CONFIG_ARM64
> +static struct rsi_host_call uuid_hc;
> +static DEFINE_SPINLOCK(uuid_hc_lock);
So evidently Sashiko is wrong in saying that struct rsi_host_call must be
in decrypted memory?
>
> +/*
> + * Helper function to get the hypervisor UUID via an RsiHostCall.
> + */
> +static bool arm_smccc_realm_get_hypervisor_uuid(struct arm_smccc_res *res)
> +{
> + guard(spinlock_irqsave)(&uuid_hc_lock);
> +
> + memset(&uuid_hc, 0, sizeof(uuid_hc));
> + uuid_hc.gprs[0] = ARM_SMCCC_VENDOR_HYP_CALL_UID_FUNC_ID;
> +
> + if (rsi_host_call(__pa_symbol(&uuid_hc)) != RSI_SUCCESS)
> + return false;
Rather than having this function return a boolean upon failure,
couldn't it just set res->a0 to SMCCC_RET_NOT_SUPPORTED like
arm_smcc_1_1_invoke()? Then arm_smccc_hypervisor_has_uuid()
could process both paths exactly the same way.
> +
> + res->a0 = uuid_hc.gprs[0];
> + res->a1 = uuid_hc.gprs[1];
> + res->a2 = uuid_hc.gprs[2];
> + res->a3 = uuid_hc.gprs[3];
> + return true;
> +}
> +#endif
> +
> bool arm_smccc_hypervisor_has_uuid(const uuid_t *hyp_uuid)
> {
> struct arm_smccc_res res = {};
> uuid_t uuid;
>
> - arm_smccc_1_1_invoke(ARM_SMCCC_VENDOR_HYP_CALL_UID_FUNC_ID, &res);
> +#ifdef CONFIG_ARM64
> + if (is_realm_world()) {
> + if (!arm_smccc_realm_get_hypervisor_uuid(&res))
> + return false;
> + } else
> +#endif
> +
> arm_smccc_1_1_invoke(ARM_SMCCC_VENDOR_HYP_CALL_UID_FUNC_ID,
> + &res);
> +
> if (res.a0 == SMCCC_RET_NOT_SUPPORTED)
> return false;
>
> --
> 2.45.4
>
^ permalink raw reply
* RE: [RFC PATCH 1/6] arm64: rsi: Add RSI host call structure and helper function
From: Michael Kelley @ 2026-06-18 17:45 UTC (permalink / raw)
To: Kameron Carr, kys@microsoft.com, haiyangz@microsoft.com,
wei.liu@kernel.org, decui@microsoft.com, longli@microsoft.com
Cc: catalin.marinas@arm.com, will@kernel.org, mark.rutland@arm.com,
lpieralisi@kernel.org, sudeep.holla@kernel.org, arnd@arndb.de,
thuth@redhat.com, linux-hyperv@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org,
Michael Kelley
In-Reply-To: <20260609181030.2378391-2-kameroncarr@linux.microsoft.com>
From: Kameron Carr <kameroncarr@linux.microsoft.com> Sent: Tuesday, June 9, 2026 11:10 AM
>
> Add struct rsi_host_call to rsi_smc.h, which represents the host call
> data structure used by the Realm Management Monitor (RMM) for the
> RSI_HOST_CALL interface. The structure contains a 16-bit immediate field
> and 31 general-purpose register values, aligned to 256 bytes as required
> by the CCA RMM specification.
>
> Add rsi_host_call() static inline wrapper in rsi_cmds.h that invokes
> SMC_RSI_HOST_CALL with the physical address of the host call structure.
> This will be used by Hyper-V guest code to route hypercalls through the
> RSI interface when running inside an Arm CCA Realm.
>
> Signed-off-by: Kameron Carr <kameroncarr@linux.microsoft.com>
> ---
> arch/arm64/include/asm/rsi_cmds.h | 9 +++++++++
> arch/arm64/include/asm/rsi_smc.h | 6 ++++++
> 2 files changed, 15 insertions(+)
>
> diff --git a/arch/arm64/include/asm/rsi_cmds.h b/arch/arm64/include/asm/rsi_cmds.h
> index 2c8763876dfb7..83b4b1f598454 100644
> --- a/arch/arm64/include/asm/rsi_cmds.h
> +++ b/arch/arm64/include/asm/rsi_cmds.h
> @@ -159,4 +159,13 @@ static inline unsigned long
> rsi_attestation_token_continue(phys_addr_t granule,
> return res.a0;
> }
>
> +static inline long rsi_host_call(phys_addr_t host_call_struct)
> +{
> + struct arm_smccc_res res;
> +
> + arm_smccc_smc(SMC_RSI_HOST_CALL, host_call_struct, 0, 0, 0, 0, 0, 0,
> + &res);
> + return res.a0;
> +}
For consistent grouping, it seems like this inline function should
be placed after rsi_set_addr_range_state() since it follows the
same pattern. It's a bit different from the token functions.
> +
> #endif /* __ASM_RSI_CMDS_H */
> diff --git a/arch/arm64/include/asm/rsi_smc.h b/arch/arm64/include/asm/rsi_smc.h
> index e19253f96c940..ffea93340ed7f 100644
> --- a/arch/arm64/include/asm/rsi_smc.h
> +++ b/arch/arm64/include/asm/rsi_smc.h
> @@ -142,6 +142,12 @@ struct realm_config {
> */
> } __aligned(0x1000);
>
> +struct rsi_host_call {
> + u16 immediate;
I don't see the "immediate" used anywhere in this patch set.
Is it always zero for the Hyper-V use cases? Just curious ...
> + u64 gprs[31];
> +} __aligned(256);
> +static_assert(sizeof(struct rsi_host_call) == 256);
This struct defines an ABI with the RMM layer, so I'd suggest
adding explicit padding of 6 bytes after the immediate so there's
no implicit dependency on the compiler adding the padding.
Sashiko had the same comment ....
Michael
> +
> #endif /* __ASSEMBLER__ */
>
> /*
> --
> 2.45.4
>
^ permalink raw reply
* Re: [PATCH v2] coredump: exit_files() in coredump_wait() if MMF_DUMP_MAPPED_SHARED is not set
From: Pedro Falcato @ 2026-06-18 17:19 UTC (permalink / raw)
To: Xin Zhao
Cc: viro, brauner, jack, jlayton, chuck.lever, alex.aring, arnd,
ebiederm, keescook, mcgrof, j.granados, allen.lkml, linux-fsdevel,
linux-kernel, linux-arch
In-Reply-To: <ajQXNRT5PnBgh48M@pedro-suse>
On Thu, Jun 18, 2026 at 05:07:56PM +0100, Pedro Falcato wrote:
> On Thu, Jun 18, 2026 at 11:03:01PM +0800, Xin Zhao wrote:
> > A coredump typically takes some time to complete. If we happen to hold a
> > write lock with flock just before triggering the coredump, that write lock
> > will not be released during the entire coredump process. As a result,
> > other processes attempting to acquire the same write lock may experience
> > significant delays.
> >
> > To address this, call exit_files() in the end of coredump_wait(), if
> > MMF_DUMP_MAPPED_SHARED is not set.
> >
> > Signed-off-by: Xin Zhao <jackzxcui1989@163.com>
> > ---
> >
> > Change in v2:
> > - Get rid of the implement of adding new fcntl API, the issue does not
> > worth inflicting the cost on everyone,
> > as suggested by Al Viro.
> > - Call exit_files() in coredump_wait(),
> > as suggested by Eric W. Biederman.
> > Add MMF_DUMP_MAPPED_SHARED mm_flags_test() check to filter cases that
> > need to dump file-backed shared memory.
> >
> > v1:
> > - Link to v1: https://lore.kernel.org/all/20260618030700.2511668-1-jackzxcui1989@163.com/
> > ---
> > fs/coredump.c | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/fs/coredump.c b/fs/coredump.c
> > index bb6fdb1f4..e20baf44f 100644
> > --- a/fs/coredump.c
> > +++ b/fs/coredump.c
> > @@ -548,6 +548,9 @@ static int coredump_wait(int exit_code, struct core_state *core_state)
> > }
> > }
> >
> > + if (!mm_flags_test(MMF_DUMP_MAPPED_SHARED, tsk->mm))
> > + exit_files(tsk);
>
> Memory mapped files keep their own separate references to the files
> (in struct vm_area_struct::vm_file), so there is no need to attempt to
> work around this. Unless I'm misunderstanding what you're attempting
> to work around.
Waiit, I think I get it - you have a flock on a file, and you're scared
that if you unlock early, some other process can lock it and modify some other
file we have mapped? If so, that does make some sense. Please add that as
a comment and/or into the git log, because it feels very much non-obvious
to me.
--
Pedro
^ permalink raw reply
* Re: [PATCH v2] coredump: exit_files() in coredump_wait() if MMF_DUMP_MAPPED_SHARED is not set
From: Pedro Falcato @ 2026-06-18 16:07 UTC (permalink / raw)
To: Xin Zhao
Cc: viro, brauner, jack, jlayton, chuck.lever, alex.aring, arnd,
ebiederm, keescook, mcgrof, j.granados, allen.lkml, linux-fsdevel,
linux-kernel, linux-arch
In-Reply-To: <20260618150301.3226517-1-jackzxcui1989@163.com>
On Thu, Jun 18, 2026 at 11:03:01PM +0800, Xin Zhao wrote:
> A coredump typically takes some time to complete. If we happen to hold a
> write lock with flock just before triggering the coredump, that write lock
> will not be released during the entire coredump process. As a result,
> other processes attempting to acquire the same write lock may experience
> significant delays.
>
> To address this, call exit_files() in the end of coredump_wait(), if
> MMF_DUMP_MAPPED_SHARED is not set.
>
> Signed-off-by: Xin Zhao <jackzxcui1989@163.com>
> ---
>
> Change in v2:
> - Get rid of the implement of adding new fcntl API, the issue does not
> worth inflicting the cost on everyone,
> as suggested by Al Viro.
> - Call exit_files() in coredump_wait(),
> as suggested by Eric W. Biederman.
> Add MMF_DUMP_MAPPED_SHARED mm_flags_test() check to filter cases that
> need to dump file-backed shared memory.
>
> v1:
> - Link to v1: https://lore.kernel.org/all/20260618030700.2511668-1-jackzxcui1989@163.com/
> ---
> fs/coredump.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/fs/coredump.c b/fs/coredump.c
> index bb6fdb1f4..e20baf44f 100644
> --- a/fs/coredump.c
> +++ b/fs/coredump.c
> @@ -548,6 +548,9 @@ static int coredump_wait(int exit_code, struct core_state *core_state)
> }
> }
>
> + if (!mm_flags_test(MMF_DUMP_MAPPED_SHARED, tsk->mm))
> + exit_files(tsk);
Memory mapped files keep their own separate references to the files
(in struct vm_area_struct::vm_file), so there is no need to attempt to
work around this. Unless I'm misunderstanding what you're attempting
to work around.
--
Pedro
^ permalink raw reply
* [PATCH v2] coredump: exit_files() in coredump_wait() if MMF_DUMP_MAPPED_SHARED is not set
From: Xin Zhao @ 2026-06-18 15:03 UTC (permalink / raw)
To: viro, brauner, jack, jlayton, chuck.lever, alex.aring, arnd,
ebiederm, keescook, mcgrof, j.granados, allen.lkml
Cc: linux-fsdevel, linux-kernel, linux-arch, Xin Zhao
A coredump typically takes some time to complete. If we happen to hold a
write lock with flock just before triggering the coredump, that write lock
will not be released during the entire coredump process. As a result,
other processes attempting to acquire the same write lock may experience
significant delays.
To address this, call exit_files() in the end of coredump_wait(), if
MMF_DUMP_MAPPED_SHARED is not set.
Signed-off-by: Xin Zhao <jackzxcui1989@163.com>
---
Change in v2:
- Get rid of the implement of adding new fcntl API, the issue does not
worth inflicting the cost on everyone,
as suggested by Al Viro.
- Call exit_files() in coredump_wait(),
as suggested by Eric W. Biederman.
Add MMF_DUMP_MAPPED_SHARED mm_flags_test() check to filter cases that
need to dump file-backed shared memory.
v1:
- Link to v1: https://lore.kernel.org/all/20260618030700.2511668-1-jackzxcui1989@163.com/
---
fs/coredump.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/fs/coredump.c b/fs/coredump.c
index bb6fdb1f4..e20baf44f 100644
--- a/fs/coredump.c
+++ b/fs/coredump.c
@@ -548,6 +548,9 @@ static int coredump_wait(int exit_code, struct core_state *core_state)
}
}
+ if (!mm_flags_test(MMF_DUMP_MAPPED_SHARED, tsk->mm))
+ exit_files(tsk);
+
return core_waiters;
}
--
2.34.1
^ permalink raw reply related
* Re: [PATCH] coredump/fcntl: Add FD_CLOBCOR flag to close fd before dumping core
From: Xin Zhao @ 2026-06-18 6:48 UTC (permalink / raw)
To: ebiederm
Cc: alex.aring, allen.lkml, arnd, brauner, chuck.lever, j.granados,
jack, jackzxcui1989, jlayton, keescook, linux-arch, linux-fsdevel,
linux-kernel, mcgrof, viro
In-Reply-To: <87zf0se7qi.fsf@email.froward.int.ebiederm.org>
On Thu, 18 Jun 2026 00:29:57 -0500 "Eric W. Biederman" <ebiederm@xmission.com> wrote:
> > A coredump typically takes some time to complete. If we happen to hold a
> > write lock with flock just before triggering the coredump, that write lock
> > will not be released during the entire coredump process. As a result,
> > other processes attempting to acquire the same write lock may experience
> > significant delays.
>
> You are talking about giant processes writing to slow backing store?
>
> I suspect you would be better off quickly writing the coredump to a pipe,
> and then writing it to disk.
>
> Unless your machine is badly balanced that should take perhaps a second.
>
> That said I don't see why you need elaborate machinery to do something
> about these file descriptors. Unless I am mistaken no file descriptors
> are placed into a coredump. In which case it should be possible to just
> call exit_files early.
Thank you for your suggestion. Are you suggesting modifying the coredump
path to a location like /tmp and then copying the files from /tmp to the
final storage location? That would indeed be faster, but our tasks
sometimes consume a considerable amount of memory, and the dump time might
still be significant even when using a pipe. For our higher-level code,
even 100 ms might be a bit too long. Additionally, while directly calling
exit_files() in coredump_wait can cover most scenarios, if the
coredump_filter includes (bit 3) file-backed shared memory, it may not be
appropriate to release all files.
I actually prefer to dynamically create the bitmap for determining
close_before_core on demand. If the task hasn't set this attribute, then
we wouldn't create the bitmap, which would also save time on memory
allocation when this feature is not used.
> > To address this, we introduce the F_[GET|SET]FD_EX fcntl operation and the
> > FD_CLOBCOR flag, allowing coredump_wait() to release any file descriptors
> > marked with FD_CLOBCOR. We can also assign the FD_CLOBCOR flag to specific
> > shared memory segments, preventing the coredump from including shared
> > memory that we are not interested in, thereby reducing both the coredump
> > duration and the size of the core file.
>
> Please look at vma_dump_size. There are plenty of ways already to
> skip dumping a memory area. Using file backed shared memory,
> and madvise(MADV_DONTDUMP) are two easy ones that already exist.
>
> My point is that there are cleaner ways to solve your problem than
> the solutions you have proposed.
This requirement can indeed be addressed with the MADV_DONTDUMP you
mentioned, thank you for your suggestion. But what troubles me is the
scenario mentioned above.
Thanks
Xin Zhao
^ permalink raw reply
* [syzbot ci] Re: coredump/fcntl: Add FD_CLOBCOR flag to close fd before dumping core
From: syzbot ci @ 2026-06-18 6:40 UTC (permalink / raw)
To: alex.aring, allen.lkml, arnd, brauner, chuck.lever, ebiederm,
j.granados, jack, jackzxcui1989, jlayton, keescook, linux-arch,
linux-fsdevel, linux-kernel, mcgrof, viro
Cc: syzbot, syzkaller-bugs
In-Reply-To: <20260618030700.2511668-1-jackzxcui1989@163.com>
syzbot ci has tested the following series
[v1] coredump/fcntl: Add FD_CLOBCOR flag to close fd before dumping core
https://lore.kernel.org/all/20260618030700.2511668-1-jackzxcui1989@163.com
* [PATCH] coredump/fcntl: Add FD_CLOBCOR flag to close fd before dumping core
and found the following issue:
WARNING: suspicious RCU usage in exit_files_before_core
Full report is available here:
https://ci.syzbot.org/series/bda032a0-64d8-4226-8ad1-6a4c99514d61
***
WARNING: suspicious RCU usage in exit_files_before_core
tree: torvalds
URL: https://kernel.googlesource.com/pub/scm/linux/kernel/git/torvalds/linux
base: 2a706d98d50a28dd635b3d028531d839c1f5f19a
arch: amd64
compiler: Debian clang version 21.1.8 (++20251221033036+2078da43e25a-1~exp1~20251221153213.50), Debian LLD 21.1.8
config: https://ci.syzbot.org/builds/e0dd4cce-02a0-415c-9720-8816ca17346d/config
=============================
WARNING: suspicious RCU usage
syzkaller #0 Not tainted
-----------------------------
./include/linux/fdtable.h:104 suspicious rcu_dereference_check() usage!
other info that might help us debug this:
rcu_scheduler_active = 2, debug_locks = 1
no locks held by syz.2.65/5687.
stack backtrace:
CPU: 0 UID: 0 PID: 5687 Comm: syz.2.65 Not tainted syzkaller #0 PREEMPT(full)
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 04/01/2014
Call Trace:
<TASK>
dump_stack_lvl+0xe8/0x150
lockdep_rcu_suspicious+0x13f/0x1d0
exit_files_before_core+0x35a/0x410
vfs_coredump+0xa52/0x4550
get_signal+0x1107/0x1330
arch_do_signal_or_restart+0xbc/0x830
irqentry_exit+0x2a4/0x860
asm_exc_page_fault+0x26/0x30
RIP: 0033:0x0
Code: Unable to access opcode bytes at 0xffffffffffffffd6.
RSP: 002b:0000200000000008 EFLAGS: 00010217
RAX: 0000000000000000 RBX: 00007f3125415fa0 RCX: 00007f312519ce59
RDX: 0000200000000000 RSI: 0000200000000000 RDI: 0000000000000000
RBP: 00007f3125232d6f R08: 0000200000000000 R09: 0000000000000000
R10: 0000200000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007f3125415fac R14: 00007f3125415fa0 R15: 00007f3125415fa0
</TASK>
***
If these findings have caused you to resend the series or submit a
separate fix, please add the following tag to your commit message:
Tested-by: syzbot@syzkaller.appspotmail.com
---
This report is generated by a bot. It may contain errors.
syzbot ci engineers can be reached at syzkaller@googlegroups.com.
To test a patch for this bug, please reply with `#syz test`
(should be on a separate line).
The patch should be attached to the email.
Note: arguments like custom git repos and branches are not supported.
^ permalink raw reply
* Re: [PATCH] coredump/fcntl: Add FD_CLOBCOR flag to close fd before dumping core
From: Eric W. Biederman @ 2026-06-18 5:29 UTC (permalink / raw)
To: Xin Zhao
Cc: viro, brauner, jack, jlayton, chuck.lever, alex.aring, arnd,
keescook, mcgrof, j.granados, allen.lkml, linux-fsdevel,
linux-kernel, linux-arch
In-Reply-To: <20260618030700.2511668-1-jackzxcui1989@163.com>
Xin Zhao <jackzxcui1989@163.com> writes:
> A coredump typically takes some time to complete. If we happen to hold a
> write lock with flock just before triggering the coredump, that write lock
> will not be released during the entire coredump process. As a result,
> other processes attempting to acquire the same write lock may experience
> significant delays.
You are talking about giant processes writing to slow backing store?
I suspect you would be better off quickly writing the coredump to a pipe,
and then writing it to disk.
Unless your machine is badly balanced that should take perhaps a second.
That said I don't see why you need elaborate machinery to do something
about these file descriptors. Unless I am mistaken no file descriptors
are placed into a coredump. In which case it should be possible to just
call exit_files early.
> To address this, we introduce the F_[GET|SET]FD_EX fcntl operation and the
> FD_CLOBCOR flag, allowing coredump_wait() to release any file descriptors
> marked with FD_CLOBCOR. We can also assign the FD_CLOBCOR flag to specific
> shared memory segments, preventing the coredump from including shared
> memory that we are not interested in, thereby reducing both the coredump
> duration and the size of the core file.
Please look at vma_dump_size. There are plenty of ways already to
skip dumping a memory area. Using file backed shared memory,
and madvise(MADV_DONTDUMP) are two easy ones that already exist.
My point is that there are cleaner ways to solve your problem than
the solutions you have proposed.
Eric
^ 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