* Re: [PATCH v10 04/30] ring-buffer: Add non-consuming read for ring-buffer remotes
From: Steven Rostedt @ 2026-01-29 0:26 UTC (permalink / raw)
To: Vincent Donnefort
Cc: mhiramat, mathieu.desnoyers, linux-trace-kernel, maz,
oliver.upton, joey.gouly, suzuki.poulose, yuzenghui, kvmarm,
linux-arm-kernel, jstultz, qperret, will, aneesh.kumar,
kernel-team, linux-kernel
In-Reply-To: <20260126104419.1649811-5-vdonnefort@google.com>
On Mon, 26 Jan 2026 10:43:53 +0000
Vincent Donnefort <vdonnefort@google.com> wrote:
> Hopefully, the remote will only swap pages on the kernel instruction (via
> the swap_reader_page() callback). This means we know at what point the
> ring-buffer geometry has changed. It is therefore possible to rearrange
> the kernel view of that ring-buffer to allow non-consuming read.
>
> Signed-off-by: Vincent Donnefort <vdonnefort@google.com>
Reviewed-by: Steven Rostedt (Google) <rostedt@goodmis.org>
-- Steve
^ permalink raw reply
* Re: [PATCH v10 06/30] tracing: Add reset to trace remotes
From: Steven Rostedt @ 2026-01-29 0:27 UTC (permalink / raw)
To: Vincent Donnefort
Cc: mhiramat, mathieu.desnoyers, linux-trace-kernel, maz,
oliver.upton, joey.gouly, suzuki.poulose, yuzenghui, kvmarm,
linux-arm-kernel, jstultz, qperret, will, aneesh.kumar,
kernel-team, linux-kernel
In-Reply-To: <20260126104419.1649811-7-vdonnefort@google.com>
On Mon, 26 Jan 2026 10:43:55 +0000
Vincent Donnefort <vdonnefort@google.com> wrote:
> Allow to reset the trace remote buffer by writing to the Tracefs "trace"
> file. This is similar to the regular Tracefs interface.
>
> Signed-off-by: Vincent Donnefort <vdonnefort@google.com>
Reviewed-by: Steven Rostedt (Google) <rostedt@goodmis.org>
-- Steve
^ permalink raw reply
* Re: [PATCH v10 08/30] tracing: Add init callback to trace remotes
From: Steven Rostedt @ 2026-01-29 0:27 UTC (permalink / raw)
To: Vincent Donnefort
Cc: mhiramat, mathieu.desnoyers, linux-trace-kernel, maz,
oliver.upton, joey.gouly, suzuki.poulose, yuzenghui, kvmarm,
linux-arm-kernel, jstultz, qperret, will, aneesh.kumar,
kernel-team, linux-kernel
In-Reply-To: <20260126104419.1649811-9-vdonnefort@google.com>
On Mon, 26 Jan 2026 10:43:57 +0000
Vincent Donnefort <vdonnefort@google.com> wrote:
> Add a .init call back so the trace remote callers can add entries to the
> tracefs directory.
>
> Signed-off-by: Vincent Donnefort <vdonnefort@google.com>
Reviewed-by: Steven Rostedt (Google) <rostedt@goodmis.org>
-- Steve
^ permalink raw reply
* Re: [PATCH v10 10/30] tracing: Add events/ root files to trace remotes
From: Steven Rostedt @ 2026-01-29 0:28 UTC (permalink / raw)
To: Vincent Donnefort
Cc: mhiramat, mathieu.desnoyers, linux-trace-kernel, maz,
oliver.upton, joey.gouly, suzuki.poulose, yuzenghui, kvmarm,
linux-arm-kernel, jstultz, qperret, will, aneesh.kumar,
kernel-team, linux-kernel
In-Reply-To: <20260126104419.1649811-11-vdonnefort@google.com>
On Mon, 26 Jan 2026 10:43:59 +0000
Vincent Donnefort <vdonnefort@google.com> wrote:
> Just like for the kernel events directory, add 'enable', 'header_page'
> and 'header_event' at the root of the trace remote events/ directory.
>
> Signed-off-by: Vincent Donnefort <vdonnefort@google.com>
Reviewed-by: Steven Rostedt (Google) <rostedt@goodmis.org>
-- Steve
^ permalink raw reply
* Re: [PATCH v10 11/30] tracing: Add helpers to create trace remote events
From: Steven Rostedt @ 2026-01-29 0:28 UTC (permalink / raw)
To: Vincent Donnefort
Cc: mhiramat, mathieu.desnoyers, linux-trace-kernel, maz,
oliver.upton, joey.gouly, suzuki.poulose, yuzenghui, kvmarm,
linux-arm-kernel, jstultz, qperret, will, aneesh.kumar,
kernel-team, linux-kernel
In-Reply-To: <20260126104419.1649811-12-vdonnefort@google.com>
On Mon, 26 Jan 2026 10:44:00 +0000
Vincent Donnefort <vdonnefort@google.com> wrote:
> Declaring remote events can be cumbersome let's add a set of macros to
> simplify developers life. The declaration of a remote event is very
> similar to kernel's events:
>
> REMOTE_EVENT(name, id,
> RE_STRUCT(
> re_field(u64 foo)
> ),
> RE_PRINTK("foo=%llu", __entry->foo)
> )
>
> Signed-off-by: Vincent Donnefort <vdonnefort@google.com>
Reviewed-by: Steven Rostedt (Google) <rostedt@goodmis.org>
-- Steve
^ permalink raw reply
* Re: [PATCH v10 12/30] ring-buffer: Export buffer_data_page and macros
From: Steven Rostedt @ 2026-01-29 0:28 UTC (permalink / raw)
To: Vincent Donnefort
Cc: mhiramat, mathieu.desnoyers, linux-trace-kernel, maz,
oliver.upton, joey.gouly, suzuki.poulose, yuzenghui, kvmarm,
linux-arm-kernel, jstultz, qperret, will, aneesh.kumar,
kernel-team, linux-kernel
In-Reply-To: <20260126104419.1649811-13-vdonnefort@google.com>
On Mon, 26 Jan 2026 10:44:01 +0000
Vincent Donnefort <vdonnefort@google.com> wrote:
> In preparation for allowing the writing of ring-buffer compliant pages
> outside of ring_buffer.c, move buffer_data_page and timestamps encoding
> macros into the publicly available ring_buffer_types.h.
>
> Signed-off-by: Vincent Donnefort <vdonnefort@google.com>
Reviewed-by: Steven Rostedt (Google) <rostedt@goodmis.org>
-- Steve
^ permalink raw reply
* Re: [PATCH v5 v5 1/3] docs: tracing/fprobe: Document list filters and :entry/:exit
From: Masami Hiramatsu @ 2026-01-29 0:35 UTC (permalink / raw)
To: Seokwoo Chung
Cc: Steven Rostedt, mhiramat, corbet, shuah, mathieu.desnoyers,
linux-kernel, linux-trace-kernel, linux-doc, linux-kselftest
In-Reply-To: <wqpijkdwziafpuci6js5mtfzro46bre4z7une547crcdzrlm67@kd4fgea5m6ov>
Hi Ryan,
On Sun, 25 Jan 2026 15:23:17 -0500
Seokwoo Chung <seokwoo.chung130@gmail.com> wrote:
> On Tue, Jan 20, 2026 at 03:53:40PM -0500, Steven Rostedt wrote:
> > On Sat, 17 Jan 2026 20:18:13 -0500
> > "Seokwoo Chung (Ryan)" <seokwoo.chung130@gmail.com> wrote:
> >
> > > Update fprobe event documentation to describe comma-separated symbol lists,
> > > exclusions, and explicit suffixes.
> >
> > Usually, the documentation updates comes *after* the changes.
> >
> > -- Steve
> >
> Thanks for the comment. As you noticed, I sent another patch since I forgot to
> put log. That said, please let me know if you want me to continue on this
> series. My apologies on the ordering. I noted after Masami mentioned but I
> misordered when sending. Thank you.
Sorry for replying so late,
Can you fix the kernel test robot's error? I think it is almost done.
Thank you,
>
> Best regards,
> Ryan Chung
> > >
> > > Signed-off-by: Seokwoo Chung (Ryan) <seokwoo.chung130@gmail.com>
> > > ---
> > > Documentation/trace/fprobetrace.rst | 17 ++++++++++++++---
> > > 1 file changed, 14 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/Documentation/trace/fprobetrace.rst b/Documentation/trace/fprobetrace.rst
> > > index b4c2ca3d02c1..bbcfd57f0005 100644
> > > --- a/Documentation/trace/fprobetrace.rst
> > > +++ b/Documentation/trace/fprobetrace.rst
> > > @@ -25,14 +25,18 @@ Synopsis of fprobe-events
> > > -------------------------
> > > ::
> > >
> > > - f[:[GRP1/][EVENT1]] SYM [FETCHARGS] : Probe on function entry
> > > - f[MAXACTIVE][:[GRP1/][EVENT1]] SYM%return [FETCHARGS] : Probe on function exit
> > > + f[:[GRP1/][EVENT1]] SYM[%return] [FETCHARGS] : Single function
> > > + f[:[GRP1/][EVENT1]] SYM[,[!]SYM[,...]][:entry|:exit] [FETCHARGS] :Multiple
> > > + function
> > > t[:[GRP2/][EVENT2]] TRACEPOINT [FETCHARGS] : Probe on tracepoint
> > >
> > > GRP1 : Group name for fprobe. If omitted, use "fprobes" for it.
> > > GRP2 : Group name for tprobe. If omitted, use "tracepoints" for it.
> > > EVENT1 : Event name for fprobe. If omitted, the event name is
> > > - "SYM__entry" or "SYM__exit".
> > > + - For a single literal symbol, the event name is
> > > + "SYM__entry" or "SYM__exit".
> > > + - For a *list or any wildcard*, an explicit [GRP1/][EVENT1] is
> > > + required; otherwise the parser rejects it.
> > > EVENT2 : Event name for tprobe. If omitted, the event name is
> > > the same as "TRACEPOINT", but if the "TRACEPOINT" starts
> > > with a digit character, "_TRACEPOINT" is used.
> > > @@ -40,6 +44,13 @@ Synopsis of fprobe-events
> > > can be probed simultaneously, or 0 for the default value
> > > as defined in Documentation/trace/fprobe.rst
> > >
> > > + SYM : Function name or comma-separated list of symbols.
> > > + - SYM prefixed with "!" are exclusions.
> > > + - ":entry" suffix means it probes entry of given symbols
> > > + (default)
> > > + - ":exit" suffix means it probes exit of given symbols.
> > > + - "%return" suffix means it probes exit of SYM (single
> > > + symbol).
> > > FETCHARGS : Arguments. Each probe can have up to 128 args.
> > > ARG : Fetch "ARG" function argument using BTF (only for function
> > > entry or tracepoint.) (\*1)
> >
--
Masami Hiramatsu (Google) <mhiramat@kernel.org>
^ permalink raw reply
* Re: [RFC PATCH v1 05/37] KVM: guest_memfd: Wire up kvm_get_memory_attributes() to per-gmem attributes
From: Jason Gunthorpe @ 2026-01-29 0:37 UTC (permalink / raw)
To: Ackerley Tng
Cc: Alexey Kardashevskiy, cgroups, kvm, linux-doc, linux-fsdevel,
linux-kernel, linux-kselftest, linux-mm, linux-trace-kernel, x86,
akpm, binbin.wu, bp, brauner, chao.p.peng, chenhuacai, corbet,
dave.hansen, dave.hansen, david, dmatlack, erdemaktas, fan.du,
fvdl, haibo1.xu, hannes, hch, hpa, hughd, ira.weiny,
isaku.yamahata, jack, james.morse, jarkko, jgowans, jhubbard,
jroedel, jthoughton, jun.miao, kai.huang, keirf, kent.overstreet,
liam.merwick, maciej.wieczor-retman, mail, maobibo,
mathieu.desnoyers, maz, mhiramat, mhocko, mic, michael.roth,
mingo, mlevitsk, mpe, muchun.song, nikunj, nsaenz, oliver.upton,
palmer, pankaj.gupta, paul.walmsley, pbonzini, peterx, pgonda,
prsampat, pvorel, qperret, richard.weiyang, rick.p.edgecombe,
rientjes, rostedt, roypat, rppt, seanjc, shakeel.butt, shuah,
steven.price, steven.sistare, suzuki.poulose, tabba, tglx,
thomas.lendacky, vannapurve, vbabka, viro, vkuznets, wei.w.wang,
will, willy, wyihan, xiaoyao.li, yan.y.zhao, yilun.xu, yuzenghui,
zhiquan1.li
In-Reply-To: <CAEvNRgEuez=JbArRf2SApLAL0usv5-Q6q=nBPOFMHrHGaKAtMw@mail.gmail.com>
On Wed, Jan 28, 2026 at 01:47:50PM -0800, Ackerley Tng wrote:
> Alexey Kardashevskiy <aik@amd.com> writes:
>
> >
> > [...snip...]
> >
> >
>
> Thanks for bringing this up!
>
> > I am trying to make it work with TEE-IO where fd of VFIO MMIO is a dmabuf fd while the rest (guest RAM) is gmemfd. The above suggests that if there is gmemfd - then the memory attributes are handled by gmemfd which is... expected?
> >
>
> I think this is not expected.
>
> IIUC MMIO guest physical addresses don't have an associated memslot, but
> if you managed to get to that line in kvm_gmem_get_memory_attributes(),
> then there is an associated memslot (slot != NULL)?
I think they should have a memslot, shouldn't they? I imagine creating
a memslot from a FD and the FD can be memfd, guestmemfd, dmabuf, etc,
etc ?
> Either way, guest_memfd shouldn't store attributes for guest physical
> addresses that don't belong to some guest_memfd memslot.
>
> I think we need a broader discussion for this on where to store memory
> attributes for MMIO addresses.
>
> I think we should at least have line of sight to storing memory
> attributes for MMIO addresses, in case we want to design something else,
> since we're putting vm_memory_attributes on a deprecation path with this
> series.
I don't know where you want to store them in KVM long term, but they
need to come from the dmabuf itself (probably via a struct
p2pdma_provider) and currently it is OK to assume all DMABUFs are
uncachable MMIO that is safe for the VM to convert into "write
combining" (eg Normal-NC on ARM)
Jason
^ permalink raw reply
* Re: [PATCH v4 5/5] blktrace: Make init_blk_tracer() asynchronous when trace_async_init set
From: Steven Rostedt @ 2026-01-29 0:41 UTC (permalink / raw)
To: Yaxiong Tian, axboe
Cc: mhiramat, mathieu.desnoyers, corbet, skhan, linux-trace-kernel,
linux-block, linux-kernel, linux-doc
In-Reply-To: <20260128125554.1717261-1-tianyaxiong@kylinos.cn>
Jens,
Can you give me an acked-by on this patch and I can take the series through
my tree.
Or perhaps this doesn't even need to test the trace_async_init flag and can
always do the work queue? Does blk_trace ever do tracing at boot up? That
is, before user space starts?
Thanks,
-- Steve
On Wed, 28 Jan 2026 20:55:54 +0800
Yaxiong Tian <tianyaxiong@kylinos.cn> wrote:
> The init_blk_tracer() function causes significant boot delay as it
> waits for the trace_event_sem lock held by trace_event_update_all().
> Specifically, its child function register_trace_event() requires
> this lock, which is occupied for an extended period during boot.
>
> To resolve this, when the trace_async_init parameter is enabled, the
> execution of primary init_blk_tracer() is moved to the trace_init_wq
> workqueue, allowing it to run asynchronously. and prevent blocking
> the main boot thread.
>
> Signed-off-by: Yaxiong Tian <tianyaxiong@kylinos.cn>
> ---
> kernel/trace/blktrace.c | 23 ++++++++++++++++++++++-
> 1 file changed, 22 insertions(+), 1 deletion(-)
>
> diff --git a/kernel/trace/blktrace.c b/kernel/trace/blktrace.c
> index d031c8d80be4..56c7270ec447 100644
> --- a/kernel/trace/blktrace.c
> +++ b/kernel/trace/blktrace.c
> @@ -1832,7 +1832,9 @@ static struct trace_event trace_blk_event = {
> .funcs = &trace_blk_event_funcs,
> };
>
> -static int __init init_blk_tracer(void)
> +static struct work_struct blktrace_works __initdata;
> +
> +static int __init __init_blk_tracer(void)
> {
> if (!register_trace_event(&trace_blk_event)) {
> pr_warn("Warning: could not register block events\n");
> @@ -1852,6 +1854,25 @@ static int __init init_blk_tracer(void)
> return 0;
> }
>
> +static void __init blktrace_works_func(struct work_struct *work)
> +{
> + __init_blk_tracer();
> +}
> +
> +static int __init init_blk_tracer(void)
> +{
> + int ret = 0;
> +
> + if (trace_init_wq && trace_async_init) {
> + INIT_WORK(&blktrace_works, blktrace_works_func);
> + queue_work(trace_init_wq, &blktrace_works);
> + } else {
> + ret = __init_blk_tracer();
> + }
> +
> + return ret;
> +}
> +
> device_initcall(init_blk_tracer);
>
> static int blk_trace_remove_queue(struct request_queue *q)
^ permalink raw reply
* Re: [PATCH v2] iommu: Fix NULL pointer deref when io_page_fault tracepoint fires
From: Steven Rostedt @ 2026-01-29 0:46 UTC (permalink / raw)
To: Daniel Thompson
Cc: Masami Hiramatsu, Mathieu Desnoyers, linux-kernel,
linux-trace-kernel, Will Deacon, Robin Murphy, linux-arm-kernel,
Joerg Roedel
In-Reply-To: <20260128-iommu-io_page_fault_null_fix-v2-1-de047be6dd3a@riscstar.com>
Note, event changes go through the maintainer's tree where the events are
used.
But from a tracing POV:
Reviewed-by: Steven Rostedt (Google) <rostedt@goodmis.org>
-- Steve
On Wed, 28 Jan 2026 15:48:01 +0000
Daniel Thompson <daniel@riscstar.com> wrote:
> The arm-smmu driver is unable to allocate the blame for a page fault to
> a specific device so it calls report_iommu_fault() with the dev argument
> set to NULL. Normally this doesn't cause anything catastrophic but on a
> system with the io_page_fault tracepoint enabled this results in a NULL
> pointer deref (resulting in a fairly spectacular crash on the hardware
> I'm currently working on).
>
> Fix this by adding logic to the tracepoint to safely propagate NULL.
>
> Fixes: f8f934c180f6 ("iommu/arm-smmu: Add support for driver IOMMU fault handlers")
> Signed-off-by: Daniel Thompson <daniel@riscstar.com>
> ---
> Changes in v2:
> - Add a Fixes:. It points to the earliest point I can find where it becomes
> possible for the tracepoint to be triggered with dev set to NULL.
> - Link to v1: https://lore.kernel.org/r/20260116-iommu-io_page_fault_null_fix-v1-1-6c20c2e62987@riscstar.com
> ---
> include/trace/events/iommu.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/include/trace/events/iommu.h b/include/trace/events/iommu.h
> index 373007e567cb827458a729b8200bbcc1b7d76912..1315193f13b8812ad4e29e6b0c0c66ca806ce08d 100644
> --- a/include/trace/events/iommu.h
> +++ b/include/trace/events/iommu.h
> @@ -131,8 +131,8 @@ DECLARE_EVENT_CLASS(iommu_error,
> TP_ARGS(dev, iova, flags),
>
> TP_STRUCT__entry(
> - __string(device, dev_name(dev))
> - __string(driver, dev_driver_string(dev))
> + __string(device, dev ? dev_name(dev) : NULL)
> + __string(driver, dev ? dev_driver_string(dev) : NULL)
> __field(u64, iova)
> __field(int, flags)
> ),
>
> ---
> base-commit: 0f61b1860cc3f52aef9036d7235ed1f017632193
> change-id: 20260116-iommu-io_page_fault_null_fix-f81b4e8b5423
>
> Best regards,
^ permalink raw reply
* Re: [PATCHv2 bpf-next 1/6] x86/fgraph: Fix return_to_handler regs.rsp value
From: Steven Rostedt @ 2026-01-29 0:49 UTC (permalink / raw)
To: Jiri Olsa
Cc: Masami Hiramatsu, Josh Poimboeuf, Peter Zijlstra, bpf,
linux-trace-kernel, x86, Yonghong Song, Song Liu, Andrii Nakryiko,
Mahe Tardy
In-Reply-To: <20260126211837.472802-2-jolsa@kernel.org>
On Mon, 26 Jan 2026 22:18:32 +0100
Jiri Olsa <jolsa@kernel.org> wrote:
> The previous change (Fixes commit) messed up the rsp register value,
> which is wrong because it's already adjusted with FRAME_SIZE, we need
> the original rsp value.
>
> This change does not affect fprobe current kernel unwind, the !perf_hw_regs
> path perf_callchain_kernel:
>
> if (perf_hw_regs(regs)) {
> if (perf_callchain_store(entry, regs->ip))
> return;
> unwind_start(&state, current, regs, NULL);
> } else {
> unwind_start(&state, current, NULL, (void *)regs->sp);
> }
>
> which uses pt_regs.sp as first_frame boundary (FRAME_SIZE shift makes
> no difference, unwind stil stops at the right frame).
>
> This change fixes the other path when we want to unwind directly from
> pt_regs sp/fp/ip state, which is coming in following change.
>
> Fixes: 20a0bc10272f ("x86/fgraph,bpf: Fix stack ORC unwind from kprobe_multi return probe")
> Signed-off-by: Jiri Olsa <jolsa@kernel.org>
Reviewed-by: Steven Rostedt (Google) <rostedt@goodmis.org>
(it passed all my tests too)
-- Steve
^ permalink raw reply
* Re: [PATCHv2 bpf-next 2/6] x86/fgraph,bpf: Switch kprobe_multi program stack unwind to hw_regs path
From: Steven Rostedt @ 2026-01-29 0:50 UTC (permalink / raw)
To: Jiri Olsa
Cc: Masami Hiramatsu, Josh Poimboeuf, Mahe Tardy, Peter Zijlstra, bpf,
linux-trace-kernel, x86, Yonghong Song, Song Liu, Andrii Nakryiko
In-Reply-To: <20260126211837.472802-3-jolsa@kernel.org>
On Mon, 26 Jan 2026 22:18:33 +0100
Jiri Olsa <jolsa@kernel.org> wrote:
> Mahe reported missing function from stack trace on top of kprobe
> multi program. The missing function is the very first one in the
> stacktrace, the one that the bpf program is attached to.
>
> # bpftrace -e 'kprobe:__x64_sys_newuname* { print(kstack)}'
> Attaching 1 probe...
>
> do_syscall_64+134
> entry_SYSCALL_64_after_hwframe+118
>
> ('*' is used for kprobe_multi attachment)
>
> The reason is that the previous change (the Fixes commit) fixed
> stack unwind for tracepoint, but removed attached function address
> from the stack trace on top of kprobe multi programs, which I also
> overlooked in the related test (check following patch).
>
> The tracepoint and kprobe_multi have different stack setup, but use
> same unwind path. I think it's better to keep the previous change,
> which fixed tracepoint unwind and instead change the kprobe multi
> unwind as explained below.
>
> The bpf program stack unwind calls perf_callchain_kernel for kernel
> portion and it follows two unwind paths based on X86_EFLAGS_FIXED
> bit in pt_regs.flags.
>
> When the bit set we unwind from stack represented by pt_regs argument,
> otherwise we unwind currently executed stack up to 'first_frame'
> boundary.
>
> The 'first_frame' value is taken from regs.rsp value, but ftrace_caller
> and ftrace_regs_caller (ftrace trampoline) functions set the regs.rsp
> to the previous stack frame, so we skip the attached function entry.
>
> If we switch kprobe_multi unwind to use the X86_EFLAGS_FIXED bit,
> we set the start of the unwind to the attached function address.
> As another benefit we also cut extra unwind cycles needed to reach
> the 'first_frame' boundary.
>
> The speedup can be measured with trigger bench for kprobe_multi
> program and stacktrace support.
>
> - trigger bench with stacktrace on current code:
>
> kprobe-multi : 0.810 ± 0.001M/s
> kretprobe-multi: 0.808 ± 0.001M/s
>
> - and with the fix:
>
> kprobe-multi : 1.264 ± 0.001M/s
> kretprobe-multi: 1.401 ± 0.002M/s
>
> With the fix, the entry probe stacktrace:
>
> # bpftrace -e 'kprobe:__x64_sys_newuname* { print(kstack)}'
> Attaching 1 probe...
>
> __x64_sys_newuname+9
> do_syscall_64+134
> entry_SYSCALL_64_after_hwframe+118
>
> The return probe skips the attached function, because it's no longer
> on the stack at the point of the unwind and this way is the same how
> standard kretprobe works.
>
> # bpftrace -e 'kretprobe:__x64_sys_newuname* { print(kstack)}'
> Attaching 1 probe...
>
> do_syscall_64+134
> entry_SYSCALL_64_after_hwframe+118
>
> Fixes: 6d08340d1e35 ("Revert "perf/x86: Always store regs->ip in perf_callchain_kernel()"")
> Reported-by: Mahe Tardy <mahe.tardy@gmail.com>
> Signed-off-by: Jiri Olsa <jolsa@kernel.org>
> ---
> arch/x86/include/asm/ftrace.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/x86/include/asm/ftrace.h b/arch/x86/include/asm/ftrace.h
> index b08c95872eed..c56e1e63b893 100644
> --- a/arch/x86/include/asm/ftrace.h
> +++ b/arch/x86/include/asm/ftrace.h
Acked-by: Steven Rostedt (Google) <rostedt@goodmis.org>
(it passed all my tests too)
-- Steve
^ permalink raw reply
* Re: [PATCH AUTOSEL 6.18] tracing: Avoid possible signed 64-bit truncation
From: Steven Rostedt @ 2026-01-29 0:59 UTC (permalink / raw)
To: Sasha Levin
Cc: patches, stable, Ian Rogers, Mathieu Desnoyers,
Masami Hiramatsu (Google), linux-kernel, linux-trace-kernel
In-Reply-To: <20260128223332.2806589-18-sashal@kernel.org>
On Wed, 28 Jan 2026 17:33:16 -0500
Sasha Levin <sashal@kernel.org> wrote:
> LLM Generated explanations, may be completely bogus:
>
> The original buggy code was introduced in v6.15 and later. It's only
> present in 6.15+ kernels.
Interesting self discussion from the LLM.
>
> ### 8. SUMMARY OF ANALYSIS
>
> **The Bug:**
> - The `cmp_mod_entry()` function uses subtraction of two `unsigned long`
> values and returns the result as `int`
> - On 64-bit systems, if addresses differ by more than 2^31 (~2GB), the
> truncation from 64-bit to 32-bit can flip the sign
> - This would cause `bsearch()` to make wrong decisions about search
> direction
> - Result: potentially incorrect module address lookups in trace data
>
> **The Fix:**
> - Replaces arithmetic subtraction with simple comparisons
> - Returns -1, 0, or 1 directly based on comparisons
> - No overflow or truncation possible with the new code
> - Logic is more readable and provably correct
>
> **Stable Criteria Evaluation:**
> 1. ✅ **Obviously correct and tested**: Simple logic, reviewed by
> maintainers
> 2. ✅ **Fixes a real bug**: Yes, a potential comparator correctness bug
> 3. ⚠️ **Important issue**: Moderate - unlikely to trigger (requires >2GB
> address separation) but could cause incorrect trace output
I purposely didn't add Cc: stable because there's basically no chance of
two modules being more than 2GB apart.
> 4. ✅ **Small and contained**: Only changes one function body (~6 lines)
> 5. ✅ **No new features**: Pure bug fix
> 6. ✅ **Applies cleanly**: Should apply to 6.15+ kernels where this code
> exists
>
> **Risk Assessment:**
> - Very low risk - the change is small and the new logic is simpler
> - The original code has a provable bug (integer overflow on truncation)
> - The new code has no such issues
>
> **Concerns:**
> - The code only exists in 6.15+ kernels (introduced March 2025)
> - The bug is "unlikely" per the author (requires addresses >2GB apart)
> - No known real-world reports of this actually causing issues
>
> ### DECISION
>
> This is a valid bug fix that:
> - Fixes a real (though unlikely to trigger) bug in the comparator
> function
> - Is very small and self-contained
> - Has been reviewed and acked by the tracing maintainers
> - Has near-zero regression risk
> - Applies to 6.15+ kernels only
>
> The fix is surgical, obviously correct, and addresses a potential
> correctness issue. While the bug is unlikely to trigger in practice
> (addresses must be >2GB apart), it could cause silent data corruption in
> trace output when it does trigger. The fix is trivial and risk-free.
>
> **YES**
But I see the bot considered the same thing, but because of the risk factor
it decided to take it.
I have no issue with backporting it (I did label it a "fix"). I was
actually wondering if the bot would notice likeliness of it not happening.
It did, but decided to take it for "correctness" reasons vs risk factor.
Nice,
-- Steve
^ permalink raw reply
* Re: [RFC PATCH v1 05/37] KVM: guest_memfd: Wire up kvm_get_memory_attributes() to per-gmem attributes
From: Sean Christopherson @ 2026-01-29 1:03 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Ackerley Tng, Alexey Kardashevskiy, cgroups, kvm, linux-doc,
linux-fsdevel, linux-kernel, linux-kselftest, linux-mm,
linux-trace-kernel, x86, akpm, binbin.wu, bp, brauner,
chao.p.peng, chenhuacai, corbet, dave.hansen, dave.hansen, david,
dmatlack, erdemaktas, fan.du, fvdl, haibo1.xu, hannes, hch, hpa,
hughd, ira.weiny, isaku.yamahata, jack, james.morse, jarkko,
jgowans, jhubbard, jroedel, jthoughton, jun.miao, kai.huang,
keirf, kent.overstreet, liam.merwick, maciej.wieczor-retman, mail,
maobibo, mathieu.desnoyers, maz, mhiramat, mhocko, mic,
michael.roth, mingo, mlevitsk, mpe, muchun.song, nikunj, nsaenz,
oliver.upton, palmer, pankaj.gupta, paul.walmsley, pbonzini,
peterx, pgonda, prsampat, pvorel, qperret, richard.weiyang,
rick.p.edgecombe, rientjes, rostedt, roypat, rppt, shakeel.butt,
shuah, steven.price, steven.sistare, suzuki.poulose, tabba, tglx,
thomas.lendacky, vannapurve, vbabka, viro, vkuznets, wei.w.wang,
will, willy, wyihan, xiaoyao.li, yan.y.zhao, yilun.xu, yuzenghui,
zhiquan1.li
In-Reply-To: <20260129003753.GZ1641016@ziepe.ca>
On Wed, Jan 28, 2026, Jason Gunthorpe wrote:
> On Wed, Jan 28, 2026 at 01:47:50PM -0800, Ackerley Tng wrote:
> > Alexey Kardashevskiy <aik@amd.com> writes:
> >
> > >
> > > [...snip...]
> > >
> > >
> >
> > Thanks for bringing this up!
> >
> > > I am trying to make it work with TEE-IO where fd of VFIO MMIO is a dmabuf
> > > fd while the rest (guest RAM) is gmemfd. The above suggests that if there
> > > is gmemfd - then the memory attributes are handled by gmemfd which is...
> > > expected?
> > >
> >
> > I think this is not expected.
> >
> > IIUC MMIO guest physical addresses don't have an associated memslot, but
> > if you managed to get to that line in kvm_gmem_get_memory_attributes(),
> > then there is an associated memslot (slot != NULL)?
>
> I think they should have a memslot, shouldn't they? I imagine creating
> a memslot from a FD and the FD can be memfd, guestmemfd, dmabuf, etc,
> etc ?
Yeah, there are two flavors of MMIO for KVM guests. Emulated MMIO, which is
what Ackerley is thinking of, and "host" MMIO (for lack of a better term), which
is what I assume "fd of VFIO MMIO" is referring to.
Emulated MMIO does NOT have memslots[*]. There are some wrinkles and technical
exceptions, e.g. read-only memslots for emulating option ROMs, but by and large,
lack of a memslot means Emulated MMIO.
Host MMIO isn't something KVM really cares about, in the sense that, for the most
part, it's "just another memslot". KVM x86 does need to identify host MMIO for
vendor specific reasons, e.g. to ensure UC memory stays UC when using EPT (MTRRs
are ignored), to create shared mappings when SME is enabled, and to mitigate the
lovely MMIO Stale Data vulnerability.
But those Host MMIO edge cases are almost entirely contained to make_spte() (see
the kvm_is_mmio_pfn() calls). And so the vast, vast majority of "MMIO" code in
KVM is dealing with Emulated MMIO, and when most people talk about MMIO in KVM,
they're also talking about Emulated MMIO.
> > Either way, guest_memfd shouldn't store attributes for guest physical
> > addresses that don't belong to some guest_memfd memslot.
> >
> > I think we need a broader discussion for this on where to store memory
> > attributes for MMIO addresses.
> >
> > I think we should at least have line of sight to storing memory
> > attributes for MMIO addresses, in case we want to design something else,
> > since we're putting vm_memory_attributes on a deprecation path with this
> > series.
>
> I don't know where you want to store them in KVM long term, but they
> need to come from the dmabuf itself (probably via a struct
> p2pdma_provider) and currently it is OK to assume all DMABUFs are
> uncachable MMIO that is safe for the VM to convert into "write
> combining" (eg Normal-NC on ARM)
+1. For guest_memfd, we initially defined per-VM memory attributes to track
private vs. shared. But as Ackerley noted, we are in the process of deprecating
that support, e.g. by making it incompatible with various guest_memfd features,
in favor of having each guest_memfd instance track the state of a given page.
The original guest_memfd design was that it would _only_ hold private pages, and
so tracking private vs. shared in guest_memfd didn't make any sense. As we've
pivoted to in-place conversion, tracking private vs. shared in the guest_memfd
has basically become mandatory. We could maaaaaybe make it work with per-VM
attributes, but it would be insanely complex.
For a dmabuf fd, the story is the same as guest_memfd. Unless private vs. shared
is all or nothing, and can never change, then the only entity that can track that
info is the owner of the dmabuf. And even if the private vs. shared attributes
are constant, tracking it external to KVM makes sense, because then the provider
can simply hardcode %true/%false.
As for _how_ to do that, no matter where the attributes are stored, we're going
to have to teach KVM to play nice with a non-guest_memfd provider of private
memory.
^ permalink raw reply
* [PATCH v2] tracing: trace_mmap.h: fix a kernel-doc warning
From: Randy Dunlap @ 2026-01-29 1:12 UTC (permalink / raw)
To: linux-kernel
Cc: Randy Dunlap, Masami Hiramatsu (Google), Steven Rostedt,
Mathieu Desnoyers, linux-trace-kernel
Add a description of struct reader to resolve a kernel-doc warning:
Warning: include/uapi/linux/trace_mmap.h:43 struct member 'reader' not described in 'trace_buffer_meta'
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Acked-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
---
v2: move @reader ahead of its struct members (Steven)
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Cc: linux-trace-kernel@vger.kernel.org
include/uapi/linux/trace_mmap.h | 1 +
1 file changed, 1 insertion(+)
--- linux-next-20260128.orig/include/uapi/linux/trace_mmap.h
+++ linux-next-20260128/include/uapi/linux/trace_mmap.h
@@ -10,6 +10,7 @@
* @meta_struct_len: Size of this structure.
* @subbuf_size: Size of each sub-buffer.
* @nr_subbufs: Number of subbfs in the ring-buffer, including the reader.
+ * @reader: The reader composite info structure
* @reader.lost_events: Number of events lost at the time of the reader swap.
* @reader.id: subbuf ID of the current reader. ID range [0 : @nr_subbufs - 1]
* @reader.read: Number of bytes read on the reader subbuf.
^ permalink raw reply
* Re: [RFC PATCH v1 05/37] KVM: guest_memfd: Wire up kvm_get_memory_attributes() to per-gmem attributes
From: Jason Gunthorpe @ 2026-01-29 1:16 UTC (permalink / raw)
To: Sean Christopherson
Cc: Ackerley Tng, Alexey Kardashevskiy, cgroups, kvm, linux-doc,
linux-fsdevel, linux-kernel, linux-kselftest, linux-mm,
linux-trace-kernel, x86, akpm, binbin.wu, bp, brauner,
chao.p.peng, chenhuacai, corbet, dave.hansen, dave.hansen, david,
dmatlack, erdemaktas, fan.du, fvdl, haibo1.xu, hannes, hch, hpa,
hughd, ira.weiny, isaku.yamahata, jack, james.morse, jarkko,
jgowans, jhubbard, jroedel, jthoughton, jun.miao, kai.huang,
keirf, kent.overstreet, liam.merwick, maciej.wieczor-retman, mail,
maobibo, mathieu.desnoyers, maz, mhiramat, mhocko, mic,
michael.roth, mingo, mlevitsk, mpe, muchun.song, nikunj, nsaenz,
oliver.upton, palmer, pankaj.gupta, paul.walmsley, pbonzini,
peterx, pgonda, prsampat, pvorel, qperret, richard.weiyang,
rick.p.edgecombe, rientjes, rostedt, roypat, rppt, shakeel.butt,
shuah, steven.price, steven.sistare, suzuki.poulose, tabba, tglx,
thomas.lendacky, vannapurve, vbabka, viro, vkuznets, wei.w.wang,
will, willy, wyihan, xiaoyao.li, yan.y.zhao, yilun.xu, yuzenghui,
zhiquan1.li
In-Reply-To: <aXqx3_eE0rNh6nP0@google.com>
On Wed, Jan 28, 2026 at 05:03:27PM -0800, Sean Christopherson wrote:
> For a dmabuf fd, the story is the same as guest_memfd. Unless private vs. shared
> is all or nothing, and can never change, then the only entity that can track that
> info is the owner of the dmabuf. And even if the private vs. shared attributes
> are constant, tracking it external to KVM makes sense, because then the provider
> can simply hardcode %true/%false.
Oh my I had not given that bit any thought. My remarks were just about
normal non-CC systems.
So MMIO starts out shared, and then converts to private when the guest
triggers it. It is not all or nothing, there are permanent shared
holes in the MMIO ranges too.
Beyond that I don't know what people are thinking.
Clearly VFIO has to revoke and disable the DMABUF once any of it
becomes private. VFIO will somehow have to know when it changes modes
from the TSM subsystem.
I guess we could have a special channel for KVM to learn the
shared/private page by page from VFIO as some kind of "aware of CC"
importer.
I suppose AMD needs to mangle the RMP when it changes, and KVM has to
do that.
I forget what ARM does, but I seem to recall there is a call to create
a vPCI function and that is what stuffs the S2? So maybe KVM isn't
even involved? (IIRC people were talking that something else would
call the vPCI function but I haven't seen patches)
No idea what x86 does beyond it has to unmap all the MMIO otherwise
the machine crashes :P
Oh man, what a horrible mess to even contemplate. I'm going to bed.
Jason
^ permalink raw reply
* [PATCH] tracing: Fix indentation of return statement in print_trace_fmt()
From: Haoyang LIU @ 2026-01-29 1:39 UTC (permalink / raw)
To: Steven Rostedt, Masami Hiramatsu, Mathieu Desnoyers,
open list:TRACING, open list:TRACING
Cc: tttturtleruss, open list:TRACING, open list:TRACING
The return statement inside the nested if block in print_trace_fmt()
is not properly indented, making the code structure unclear. This was
flagged by smatch as a warning.
Add proper indentation to the return statement to match the kernel
coding style and improve readability.
Signed-off-by: Haoyang LIU <tttturtleruss@gmail.com>
---
kernel/trace/trace.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index 8bd4ec08fb36..bf0ce2aac177 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -4286,7 +4286,7 @@ static enum print_line_t print_trace_fmt(struct trace_iterator *iter)
/* ftrace and system call events are still OK */
if ((event->type > __TRACE_LAST_TYPE) &&
!is_syscall_event(event))
- return print_event_fields(iter, event);
+ return print_event_fields(iter, event);
}
return event->funcs->trace(iter, sym_flags, event);
}
--
2.25.1
^ permalink raw reply related
* Re: [PATCH v4 5/5] blktrace: Make init_blk_tracer() asynchronous when trace_async_init set
From: Jens Axboe @ 2026-01-29 2:25 UTC (permalink / raw)
To: Steven Rostedt
Cc: Yaxiong Tian, mhiramat, mathieu.desnoyers, corbet, skhan,
linux-trace-kernel, linux-block, linux-kernel, linux-doc
In-Reply-To: <20260128194104.30051be1@gandalf.local.home>
On Jan 28, 2026, at 5:40 PM, Steven Rostedt <rostedt@goodmis.org> wrote:
>
>
> Jens,
>
> Can you give me an acked-by on this patch and I can take the series through
> my tree.
On phone, hope this works:
Acked-by: Jens Axboe <axboe@kernel.dk>
> Or perhaps this doesn't even need to test the trace_async_init flag and can
> always do the work queue? Does blk_trace ever do tracing at boot up? That
> is, before user space starts?
Not via the traditonal way of running blktrace.
^ permalink raw reply
* Re: [PATCH] tracing: Fix indentation of return statement in print_trace_fmt()
From: Masami Hiramatsu @ 2026-01-29 2:29 UTC (permalink / raw)
To: Haoyang LIU
Cc: Steven Rostedt, Mathieu Desnoyers, open list:TRACING,
open list:TRACING
In-Reply-To: <20260129013954.5325-1-tttturtleruss@gmail.com>
On Thu, 29 Jan 2026 09:39:54 +0800
Haoyang LIU <tttturtleruss@gmail.com> wrote:
> The return statement inside the nested if block in print_trace_fmt()
> is not properly indented, making the code structure unclear. This was
> flagged by smatch as a warning.
>
> Add proper indentation to the return statement to match the kernel
> coding style and improve readability.
>
> Signed-off-by: Haoyang LIU <tttturtleruss@gmail.com>
Looks good to me.
Acked-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
Thanks,
> ---
> kernel/trace/trace.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
> index 8bd4ec08fb36..bf0ce2aac177 100644
> --- a/kernel/trace/trace.c
> +++ b/kernel/trace/trace.c
> @@ -4286,7 +4286,7 @@ static enum print_line_t print_trace_fmt(struct trace_iterator *iter)
> /* ftrace and system call events are still OK */
> if ((event->type > __TRACE_LAST_TYPE) &&
> !is_syscall_event(event))
> - return print_event_fields(iter, event);
> + return print_event_fields(iter, event);
> }
> return event->funcs->trace(iter, sym_flags, event);
> }
> --
> 2.25.1
>
--
Masami Hiramatsu (Google) <mhiramat@kernel.org>
^ permalink raw reply
* Re: [PATCH v5 v5 2/3] tracing/fprobe: Support comma-separated symbols and :entry/:exit
From: Masami Hiramatsu @ 2026-01-29 4:24 UTC (permalink / raw)
To: Seokwoo Chung (Ryan)
Cc: rostedt, corbet, shuah, mathieu.desnoyers, linux-kernel,
linux-trace-kernel, linux-doc, linux-kselftest
In-Reply-To: <20260118011815.56516-3-seokwoo.chung130@gmail.com>
On Sat, 17 Jan 2026 20:18:14 -0500
"Seokwoo Chung (Ryan)" <seokwoo.chung130@gmail.com> wrote:
> - Update DEFINE_FREE to use standard __free()
> - Extend fprobe to support multiple symbols per event. Add parsing logic for
> lists, ! exclusions, and explicit suffixes. Update tracefs/README to reflect
> the new syntax
>
> Signed-off-by: Seokwoo Chung (Ryan) <seokwoo.chung130@gmail.com>
> ---
> kernel/trace/trace.c | 3 +-
> kernel/trace/trace_fprobe.c | 209 +++++++++++++++++++++++++++---------
> 2 files changed, 163 insertions(+), 49 deletions(-)
>
> diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
> index baec63134ab6..10cdcc7b194e 100644
> --- a/kernel/trace/trace.c
> +++ b/kernel/trace/trace.c
> @@ -5578,7 +5578,8 @@ static const char readme_msg[] =
> "\t r[maxactive][:[<group>/][<event>]] <place> [<args>]\n"
> #endif
> #ifdef CONFIG_FPROBE_EVENTS
> - "\t f[:[<group>/][<event>]] <func-name>[%return] [<args>]\n"
> + "\t f[:[<group>/][<event>]] <func-name>[:entry|:exit] [<args>]\n"
> + "\t (single symbols still accept %return)\n"
> "\t t[:[<group>/][<event>]] <tracepoint> [<args>]\n"
> #endif
> #ifdef CONFIG_HIST_TRIGGERS
> diff --git a/kernel/trace/trace_fprobe.c b/kernel/trace/trace_fprobe.c
> index 262c0556e4af..5a2a41eea603 100644
> --- a/kernel/trace/trace_fprobe.c
> +++ b/kernel/trace/trace_fprobe.c
> @@ -187,11 +187,14 @@ DEFINE_FREE(tuser_put, struct tracepoint_user *,
> */
> struct trace_fprobe {
> struct dyn_event devent;
> + char *filter;
> struct fprobe fp;
> + bool list_mode;
> + char *nofilter;
> const char *symbol;
> + struct trace_probe tp;
> bool tprobe;
> struct tracepoint_user *tuser;
> - struct trace_probe tp;
> };
>
> static bool is_trace_fprobe(struct dyn_event *ev)
> @@ -559,6 +562,8 @@ static void free_trace_fprobe(struct trace_fprobe *tf)
> trace_probe_cleanup(&tf->tp);
> if (tf->tuser)
> tracepoint_user_put(tf->tuser);
> + kfree(tf->filter);
> + kfree(tf->nofilter);
> kfree(tf->symbol);
> kfree(tf);
> }
> @@ -838,7 +843,12 @@ static int __register_trace_fprobe(struct trace_fprobe *tf)
> if (trace_fprobe_is_tracepoint(tf))
> return __regsiter_tracepoint_fprobe(tf);
>
> - /* TODO: handle filter, nofilter or symbol list */
> + /* Registration path:
> + * - list_mode: pass filter/nofilter
> + * - single: pass symbol only (legacy)
> + */
> + if (tf->list_mode)
> + return register_fprobe(&tf->fp, tf->filter, tf->nofilter);
> return register_fprobe(&tf->fp, tf->symbol, NULL);
> }
>
> @@ -1154,60 +1164,119 @@ static struct notifier_block tprobe_event_module_nb = {
> };
> #endif /* CONFIG_MODULES */
>
> -static int parse_symbol_and_return(int argc, const char *argv[],
> - char **symbol, bool *is_return,
> - bool is_tracepoint)
> +static bool has_wildcard(const char *s)
> {
> - char *tmp = strchr(argv[1], '%');
> - int i;
> + return s && (strchr(s, '*') || strchr(s, '?'));
> +}
>
> - if (tmp) {
> - int len = tmp - argv[1];
> +static int parse_fprobe_spec(const char *in, bool is_tracepoint,
> + char **base, bool *is_return, bool *list_mode,
> + char **filter, char **nofilter)
> +{
> + char *work __free(kfree) = NULL;
> + char *b __free(kfree) = NULL;
> + char *f __free(kfree) = NULL;
> + char *nf __free(kfree) = NULL;
> + bool legacy_ret = false;
> + bool list = false;
> + const char *p;
> + int ret = 0;
>
> - if (!is_tracepoint && !strcmp(tmp, "%return")) {
> - *is_return = true;
> - } else {
> - trace_probe_log_err(len, BAD_ADDR_SUFFIX);
> - return -EINVAL;
> - }
> - *symbol = kmemdup_nul(argv[1], len, GFP_KERNEL);
> - } else
> - *symbol = kstrdup(argv[1], GFP_KERNEL);
> - if (!*symbol)
> - return -ENOMEM;
> + if (!in || !base || !is_return || !list_mode || !filter || !nofilter)
> + return -EINVAL;
>
> - if (*is_return)
> - return 0;
> + *base = NULL; *filter = NULL; *nofilter = NULL;
> + *is_return = false; *list_mode = false;
>
> if (is_tracepoint) {
> - tmp = *symbol;
> - while (*tmp && (isalnum(*tmp) || *tmp == '_'))
> - tmp++;
> - if (*tmp) {
> - /* find a wrong character. */
> - trace_probe_log_err(tmp - *symbol, BAD_TP_NAME);
> - kfree(*symbol);
> - *symbol = NULL;
> + if (strchr(in, ',') || strchr(in, ':'))
> return -EINVAL;
> - }
> + if (strstr(in, "%return"))
> + return -EINVAL;
These checks look redundant. because below ensures there is no
',', '/' and '%'.
> + for (p = in; *p; p++)
> + if (!isalnum(*p) && *p != '_')
> + return -EINVAL;
Please report parse error via trace_probe_log_err() function so that
user can check what was wrong via tracefs/error_log file. E.g.
trace_probe_log_err(p - in, BAD_TP_NAME);
> + b = kstrdup(in, GFP_KERNEL);
> + if (!b)
> + return -ENOMEM;
Note: ENOMEM does not need to report via error_log.
> + *base = no_free_ptr(b);
> + return 0;
> }
>
> - /* If there is $retval, this should be a return fprobe. */
> - for (i = 2; i < argc; i++) {
> - tmp = strstr(argv[i], "$retval");
> - if (tmp && !isalnum(tmp[7]) && tmp[7] != '_') {
> - if (is_tracepoint) {
> - trace_probe_log_set_index(i);
> - trace_probe_log_err(tmp - argv[i], RETVAL_ON_PROBE);
> - kfree(*symbol);
> - *symbol = NULL;
> + work = kstrdup(in, GFP_KERNEL);
> + if (!work)
> + return -ENOMEM;
> +
> + p = strstr(work, "%return");
> + if (p && p[7] == '\0') {
> + *is_return = true;
> + legacy_ret = true;
> + *(char *)p = '\0';
> + } else {
> + /*
> + * If "symbol:entry" or "symbol:exit" is given, it is new
> + * style probe.
> + */
> + p = strrchr(work, ':');
> + if (p) {
> + if (!strcmp(p, ":exit")) {
> + *is_return = true;
> + *(char *)p = '\0';
> + } else if (!strcmp(p, ":entry")) {
> + *(char *)p = '\0';
> + } else {
> return -EINVAL;
> }
> - *is_return = true;
> - break;
> }
> }
> - return 0;
> +
> + list = !!strchr(work, ',');
> +
> + if (list && legacy_ret) {
> + return -EINVAL;
> + }
You don't need braces for the above block.
> +
> + if (legacy_ret)
> + *is_return = true;
> +
> + b = kstrdup(work, GFP_KERNEL);
> + if (!b)
> + return -ENOMEM;
> +
> + if (list) {
Could you make this block as an independent function?
> + char *tmp = b, *tok;
> + size_t fsz, nfsz;
> +
> + fsz = nfsz = strlen(b) + 1;
> +
> + f = kzalloc(fsz, GFP_KERNEL);
> + nf = kzalloc(nfsz, GFP_KERNEL);
> + if (!f || !nf)
> + return -ENOMEM;
> +
> + while ((tok = strsep(&tmp, ",")) != NULL) {
> + char *dst;
> + bool neg = (*tok == '!');
> +
> + if (*tok == '\0') {
> + trace_probe_log_err(tmp - b - 1, BAD_TP_NAME);
> + return -EINVAL;
You missed close brace '}' here. And that makes the build failure.
Can you fix it and run all tests under tools/testing/selftests/ftrace/
with your change?
Thank you,
> +
> + if (neg)
> + tok++;
> + dst = neg ? nf : f;
> + if (dst[0] != '\0')
> + strcat(dst, ",");
> + strcat(dst, tok);
> + }
> + *list_mode = true;
> + }
> +
> + *base = no_free_ptr(b);
> + *filter = no_free_ptr(f);
> + *nofilter = no_free_ptr(nf);
> +
> + return ret;
> }
>
> static int trace_fprobe_create_internal(int argc, const char *argv[],
> @@ -1241,6 +1310,8 @@ static int trace_fprobe_create_internal(int argc, const char *argv[],
> const char *event = NULL, *group = FPROBE_EVENT_SYSTEM;
> struct module *mod __free(module_put) = NULL;
> const char **new_argv __free(kfree) = NULL;
> + char *parsed_nofilter __free(kfree) = NULL;
> + char *parsed_filter __free(kfree) = NULL;
> char *symbol __free(kfree) = NULL;
> char *ebuf __free(kfree) = NULL;
> char *gbuf __free(kfree) = NULL;
> @@ -1249,6 +1320,7 @@ static int trace_fprobe_create_internal(int argc, const char *argv[],
> char *dbuf __free(kfree) = NULL;
> int i, new_argc = 0, ret = 0;
> bool is_tracepoint = false;
> + bool list_mode = false;
> bool is_return = false;
>
> if ((argv[0][0] != 'f' && argv[0][0] != 't') || argc < 2)
> @@ -1270,11 +1342,26 @@ static int trace_fprobe_create_internal(int argc, const char *argv[],
>
> trace_probe_log_set_index(1);
>
> - /* a symbol(or tracepoint) must be specified */
> - ret = parse_symbol_and_return(argc, argv, &symbol, &is_return, is_tracepoint);
> + /* Parse spec early (single vs list, suffix, base symbol) */
> + ret = parse_fprobe_spec(argv[1], is_tracepoint, &symbol, &is_return,
> + &list_mode, &parsed_filter, &parsed_nofilter);
> if (ret < 0)
> return -EINVAL;
>
> + for (i = 2; i < argc; i++) {
> + char *tmp = strstr(argv[i], "$retval");
> +
> + if (tmp && !isalnum(tmp[7]) && tmp[7] != '_') {
> + if (is_tracepoint) {
> + trace_probe_log_set_index(i);
> + trace_probe_log_err(tmp - argv[i], RETVAL_ON_PROBE);
> + return -EINVAL;
> + }
> + is_return = true;
> + break;
> + }
> + }
> +
> trace_probe_log_set_index(0);
> if (event) {
> gbuf = kmalloc(MAX_EVENT_NAME_LEN, GFP_KERNEL);
> @@ -1287,6 +1374,15 @@ static int trace_fprobe_create_internal(int argc, const char *argv[],
> }
>
> if (!event) {
> + /*
> + * Event name rules:
> + * - For list/wildcard: require explicit [GROUP/]EVENT
> + * - For single literal: autogenerate symbol__entry/symbol__exit
> + */
> + if (list_mode || has_wildcard(symbol)) {
> + trace_probe_log_err(0, NO_GROUP_NAME);
> + return -EINVAL;
> + }
> ebuf = kmalloc(MAX_EVENT_NAME_LEN, GFP_KERNEL);
> if (!ebuf)
> return -ENOMEM;
> @@ -1322,7 +1418,8 @@ static int trace_fprobe_create_internal(int argc, const char *argv[],
> NULL, NULL, NULL, sbuf);
> }
> }
> - if (!ctx->funcname)
> +
> + if (!list_mode && !has_wildcard(symbol) && !is_tracepoint)
> ctx->funcname = symbol;
>
> abuf = kmalloc(MAX_BTF_ARGS_LEN, GFP_KERNEL);
> @@ -1356,6 +1453,21 @@ static int trace_fprobe_create_internal(int argc, const char *argv[],
> return ret;
> }
>
> + /* carry list parsing result into tf */
> + if (!is_tracepoint) {
> + tf->list_mode = list_mode;
> + if (parsed_filter) {
> + tf->filter = kstrdup(parsed_filter, GFP_KERNEL);
> + if (!tf->filter)
> + return -ENOMEM;
> + }
> + if (parsed_nofilter) {
> + tf->nofilter = kstrdup(parsed_nofilter, GFP_KERNEL);
> + if (!tf->nofilter)
> + return -ENOMEM;
> + }
> + }
> +
> /* parse arguments */
> for (i = 0; i < argc; i++) {
> trace_probe_log_set_index(i + 2);
> @@ -1442,8 +1554,9 @@ static int trace_fprobe_show(struct seq_file *m, struct dyn_event *ev)
> seq_printf(m, ":%s/%s", trace_probe_group_name(&tf->tp),
> trace_probe_name(&tf->tp));
>
> - seq_printf(m, " %s%s", trace_fprobe_symbol(tf),
> - trace_fprobe_is_return(tf) ? "%return" : "");
> + seq_printf(m, " %s", trace_fprobe_symbol(tf));
> + if (!trace_fprobe_is_tracepoint(tf) && trace_fprobe_is_return(tf))
> + seq_puts(m, ":exit");
>
> for (i = 0; i < tf->tp.nr_args; i++)
> seq_printf(m, " %s=%s", tf->tp.args[i].name, tf->tp.args[i].comm);
> --
> 2.43.0
>
--
Masami Hiramatsu (Google) <mhiramat@kernel.org>
^ permalink raw reply
* [PATCH -next] cgroup: increase maximum subsystem count from 16 to 32
From: Chen Ridong @ 2026-01-29 6:31 UTC (permalink / raw)
To: tj, hannes, mkoutny, rostedt, mhiramat, mathieu.desnoyers,
inwardvessel, shakeel.butt
Cc: cgroups, linux-kernel, linux-trace-kernel, lujialin4, chenridong
From: Chen Ridong <chenridong@huawei.com>
The current cgroup subsystem limit of 16 is insufficient, as the number of
subsystems has already reached this maximum. Attempting to add new
subsystems beyond this limit results in boot failures.
This patch increases the maximum number of supported cgroup subsystems from
16 to 32, providing adequate headroom for future subsystem additions.
Signed-off-by: Chen Ridong <chenridong@huawei.com>
---
include/linux/cgroup-defs.h | 8 +++---
include/trace/events/cgroup.h | 2 +-
kernel/cgroup/cgroup-internal.h | 8 +++---
kernel/cgroup/cgroup-v1.c | 12 ++++-----
kernel/cgroup/cgroup.c | 46 ++++++++++++++++-----------------
kernel/cgroup/debug.c | 2 +-
6 files changed, 39 insertions(+), 39 deletions(-)
diff --git a/include/linux/cgroup-defs.h b/include/linux/cgroup-defs.h
index f7cc60de0058..bb92f5c169ca 100644
--- a/include/linux/cgroup-defs.h
+++ b/include/linux/cgroup-defs.h
@@ -535,10 +535,10 @@ struct cgroup {
* one which may have more subsystems enabled. Controller knobs
* are made available iff it's enabled in ->subtree_control.
*/
- u16 subtree_control;
- u16 subtree_ss_mask;
- u16 old_subtree_control;
- u16 old_subtree_ss_mask;
+ u32 subtree_control;
+ u32 subtree_ss_mask;
+ u32 old_subtree_control;
+ u32 old_subtree_ss_mask;
/* Private pointers for each registered subsystem */
struct cgroup_subsys_state __rcu *subsys[CGROUP_SUBSYS_COUNT];
diff --git a/include/trace/events/cgroup.h b/include/trace/events/cgroup.h
index ba9229af9a34..b736da06340a 100644
--- a/include/trace/events/cgroup.h
+++ b/include/trace/events/cgroup.h
@@ -16,7 +16,7 @@ DECLARE_EVENT_CLASS(cgroup_root,
TP_STRUCT__entry(
__field( int, root )
- __field( u16, ss_mask )
+ __field( u32, ss_mask )
__string( name, root->name )
),
diff --git a/kernel/cgroup/cgroup-internal.h b/kernel/cgroup/cgroup-internal.h
index 22051b4f1ccb..3bfe37693d68 100644
--- a/kernel/cgroup/cgroup-internal.h
+++ b/kernel/cgroup/cgroup-internal.h
@@ -52,7 +52,7 @@ struct cgroup_fs_context {
bool cpuset_clone_children;
bool none; /* User explicitly requested empty subsystem */
bool all_ss; /* Seen 'all' option */
- u16 subsys_mask; /* Selected subsystems */
+ u32 subsys_mask; /* Selected subsystems */
char *name; /* Hierarchy name */
char *release_agent; /* Path for release notifications */
};
@@ -146,7 +146,7 @@ struct cgroup_mgctx {
struct cgroup_taskset tset;
/* subsystems affected by migration */
- u16 ss_mask;
+ u32 ss_mask;
};
#define CGROUP_TASKSET_INIT(tset) \
@@ -235,8 +235,8 @@ int cgroup_path_ns_locked(struct cgroup *cgrp, char *buf, size_t buflen,
void cgroup_favor_dynmods(struct cgroup_root *root, bool favor);
void cgroup_free_root(struct cgroup_root *root);
void init_cgroup_root(struct cgroup_fs_context *ctx);
-int cgroup_setup_root(struct cgroup_root *root, u16 ss_mask);
-int rebind_subsystems(struct cgroup_root *dst_root, u16 ss_mask);
+int cgroup_setup_root(struct cgroup_root *root, u32 ss_mask);
+int rebind_subsystems(struct cgroup_root *dst_root, u32 ss_mask);
int cgroup_do_get_tree(struct fs_context *fc);
int cgroup_migrate_vet_dst(struct cgroup *dst_cgrp);
diff --git a/kernel/cgroup/cgroup-v1.c b/kernel/cgroup/cgroup-v1.c
index a9e029b570c8..724950c4b690 100644
--- a/kernel/cgroup/cgroup-v1.c
+++ b/kernel/cgroup/cgroup-v1.c
@@ -28,7 +28,7 @@
#define CGROUP_PIDLIST_DESTROY_DELAY HZ
/* Controllers blocked by the commandline in v1 */
-static u16 cgroup_no_v1_mask;
+static u32 cgroup_no_v1_mask;
/* disable named v1 mounts */
static bool cgroup_no_v1_named;
@@ -1037,13 +1037,13 @@ int cgroup1_parse_param(struct fs_context *fc, struct fs_parameter *param)
static int check_cgroupfs_options(struct fs_context *fc)
{
struct cgroup_fs_context *ctx = cgroup_fc2context(fc);
- u16 mask = U16_MAX;
- u16 enabled = 0;
+ u32 mask = U32_MAX;
+ u32 enabled = 0;
struct cgroup_subsys *ss;
int i;
#ifdef CONFIG_CPUSETS
- mask = ~((u16)1 << cpuset_cgrp_id);
+ mask = ~((u32)1 << cpuset_cgrp_id);
#endif
for_each_subsys(ss, i)
if (cgroup_ssid_enabled(i) && !cgroup1_ssid_disabled(i) &&
@@ -1095,7 +1095,7 @@ int cgroup1_reconfigure(struct fs_context *fc)
struct kernfs_root *kf_root = kernfs_root_from_sb(fc->root->d_sb);
struct cgroup_root *root = cgroup_root_from_kf(kf_root);
int ret = 0;
- u16 added_mask, removed_mask;
+ u32 added_mask, removed_mask;
cgroup_lock_and_drain_offline(&cgrp_dfl_root.cgrp);
@@ -1343,7 +1343,7 @@ static int __init cgroup_no_v1(char *str)
continue;
if (!strcmp(token, "all")) {
- cgroup_no_v1_mask = U16_MAX;
+ cgroup_no_v1_mask = U32_MAX;
continue;
}
diff --git a/kernel/cgroup/cgroup.c b/kernel/cgroup/cgroup.c
index 94788bd1fdf0..8af4351536cf 100644
--- a/kernel/cgroup/cgroup.c
+++ b/kernel/cgroup/cgroup.c
@@ -203,13 +203,13 @@ EXPORT_SYMBOL_GPL(cgrp_dfl_root);
bool cgrp_dfl_visible;
/* some controllers are not supported in the default hierarchy */
-static u16 cgrp_dfl_inhibit_ss_mask;
+static u32 cgrp_dfl_inhibit_ss_mask;
/* some controllers are implicitly enabled on the default hierarchy */
-static u16 cgrp_dfl_implicit_ss_mask;
+static u32 cgrp_dfl_implicit_ss_mask;
/* some controllers can be threaded on the default hierarchy */
-static u16 cgrp_dfl_threaded_ss_mask;
+static u32 cgrp_dfl_threaded_ss_mask;
/* The list of hierarchy roots */
LIST_HEAD(cgroup_roots);
@@ -231,10 +231,10 @@ static u64 css_serial_nr_next = 1;
* These bitmasks identify subsystems with specific features to avoid
* having to do iterative checks repeatedly.
*/
-static u16 have_fork_callback __read_mostly;
-static u16 have_exit_callback __read_mostly;
-static u16 have_release_callback __read_mostly;
-static u16 have_canfork_callback __read_mostly;
+static u32 have_fork_callback __read_mostly;
+static u32 have_exit_callback __read_mostly;
+static u32 have_release_callback __read_mostly;
+static u32 have_canfork_callback __read_mostly;
static bool have_favordynmods __ro_after_init = IS_ENABLED(CONFIG_CGROUP_FAVOR_DYNMODS);
@@ -472,13 +472,13 @@ static bool cgroup_is_valid_domain(struct cgroup *cgrp)
}
/* subsystems visibly enabled on a cgroup */
-static u16 cgroup_control(struct cgroup *cgrp)
+static u32 cgroup_control(struct cgroup *cgrp)
{
struct cgroup *parent = cgroup_parent(cgrp);
- u16 root_ss_mask = cgrp->root->subsys_mask;
+ u32 root_ss_mask = cgrp->root->subsys_mask;
if (parent) {
- u16 ss_mask = parent->subtree_control;
+ u32 ss_mask = parent->subtree_control;
/* threaded cgroups can only have threaded controllers */
if (cgroup_is_threaded(cgrp))
@@ -493,12 +493,12 @@ static u16 cgroup_control(struct cgroup *cgrp)
}
/* subsystems enabled on a cgroup */
-static u16 cgroup_ss_mask(struct cgroup *cgrp)
+static u32 cgroup_ss_mask(struct cgroup *cgrp)
{
struct cgroup *parent = cgroup_parent(cgrp);
if (parent) {
- u16 ss_mask = parent->subtree_ss_mask;
+ u32 ss_mask = parent->subtree_ss_mask;
/* threaded cgroups can only have threaded controllers */
if (cgroup_is_threaded(cgrp))
@@ -1633,9 +1633,9 @@ static umode_t cgroup_file_mode(const struct cftype *cft)
* This function calculates which subsystems need to be enabled if
* @subtree_control is to be applied while restricted to @this_ss_mask.
*/
-static u16 cgroup_calc_subtree_ss_mask(u16 subtree_control, u16 this_ss_mask)
+static u32 cgroup_calc_subtree_ss_mask(u32 subtree_control, u32 this_ss_mask)
{
- u16 cur_ss_mask = subtree_control;
+ u32 cur_ss_mask = subtree_control;
struct cgroup_subsys *ss;
int ssid;
@@ -1644,7 +1644,7 @@ static u16 cgroup_calc_subtree_ss_mask(u16 subtree_control, u16 this_ss_mask)
cur_ss_mask |= cgrp_dfl_implicit_ss_mask;
while (true) {
- u16 new_ss_mask = cur_ss_mask;
+ u32 new_ss_mask = cur_ss_mask;
do_each_subsys_mask(ss, ssid, cur_ss_mask) {
new_ss_mask |= ss->depends_on;
@@ -1848,12 +1848,12 @@ static int css_populate_dir(struct cgroup_subsys_state *css)
return ret;
}
-int rebind_subsystems(struct cgroup_root *dst_root, u16 ss_mask)
+int rebind_subsystems(struct cgroup_root *dst_root, u32 ss_mask)
{
struct cgroup *dcgrp = &dst_root->cgrp;
struct cgroup_subsys *ss;
int ssid, ret;
- u16 dfl_disable_ss_mask = 0;
+ u32 dfl_disable_ss_mask = 0;
lockdep_assert_held(&cgroup_mutex);
@@ -2149,7 +2149,7 @@ void init_cgroup_root(struct cgroup_fs_context *ctx)
set_bit(CGRP_CPUSET_CLONE_CHILDREN, &root->cgrp.flags);
}
-int cgroup_setup_root(struct cgroup_root *root, u16 ss_mask)
+int cgroup_setup_root(struct cgroup_root *root, u32 ss_mask)
{
LIST_HEAD(tmp_links);
struct cgroup *root_cgrp = &root->cgrp;
@@ -3131,7 +3131,7 @@ void cgroup_procs_write_finish(struct task_struct *task,
put_task_struct(task);
}
-static void cgroup_print_ss_mask(struct seq_file *seq, u16 ss_mask)
+static void cgroup_print_ss_mask(struct seq_file *seq, u32 ss_mask)
{
struct cgroup_subsys *ss;
bool printed = false;
@@ -3496,9 +3496,9 @@ static void cgroup_finalize_control(struct cgroup *cgrp, int ret)
cgroup_apply_control_disable(cgrp);
}
-static int cgroup_vet_subtree_control_enable(struct cgroup *cgrp, u16 enable)
+static int cgroup_vet_subtree_control_enable(struct cgroup *cgrp, u32 enable)
{
- u16 domain_enable = enable & ~cgrp_dfl_threaded_ss_mask;
+ u32 domain_enable = enable & ~cgrp_dfl_threaded_ss_mask;
/* if nothing is getting enabled, nothing to worry about */
if (!enable)
@@ -3541,7 +3541,7 @@ static ssize_t cgroup_subtree_control_write(struct kernfs_open_file *of,
char *buf, size_t nbytes,
loff_t off)
{
- u16 enable = 0, disable = 0;
+ u32 enable = 0, disable = 0;
struct cgroup *cgrp, *child;
struct cgroup_subsys *ss;
char *tok;
@@ -6347,7 +6347,7 @@ int __init cgroup_init(void)
struct cgroup_subsys *ss;
int ssid;
- BUILD_BUG_ON(CGROUP_SUBSYS_COUNT > 16);
+ BUILD_BUG_ON(CGROUP_SUBSYS_COUNT > 32);
BUG_ON(cgroup_init_cftypes(NULL, cgroup_base_files));
BUG_ON(cgroup_init_cftypes(NULL, cgroup_psi_files));
BUG_ON(cgroup_init_cftypes(NULL, cgroup1_base_files));
diff --git a/kernel/cgroup/debug.c b/kernel/cgroup/debug.c
index c1623d03137d..e5c7c56a0b68 100644
--- a/kernel/cgroup/debug.c
+++ b/kernel/cgroup/debug.c
@@ -230,7 +230,7 @@ static int cgroup_subsys_states_read(struct seq_file *seq, void *v)
}
static void cgroup_masks_read_one(struct seq_file *seq, const char *name,
- u16 mask)
+ u32 mask)
{
struct cgroup_subsys *ss;
int ssid;
--
2.34.1
^ permalink raw reply related
* Re: [PATCH -next] cgroup: increase maximum subsystem count from 16 to 32
From: Chen Ridong @ 2026-01-29 7:22 UTC (permalink / raw)
To: tj, hannes, mkoutny, rostedt, mhiramat, mathieu.desnoyers,
inwardvessel, shakeel.butt
Cc: cgroups, linux-kernel, linux-trace-kernel, lujialin4
In-Reply-To: <20260129063133.209874-1-chenridong@huaweicloud.com>
On 2026/1/29 14:31, Chen Ridong wrote:
> The current cgroup subsystem limit of 16 is insufficient, as the number of
> subsystems has already reached this maximum. Attempting to add new
> subsystems beyond this limit results in boot failures.
We found this issue because our product includes a subsystem not present in the
community version, causing the total number of subsystems to exceed 16. When all
subsystems are enabled, the system fails to boot.
--
Best regards,
Ridong
^ permalink raw reply
* Re: [PATCH -next] cgroup: increase maximum subsystem count from 16 to 32
From: Michal Koutný @ 2026-01-29 9:23 UTC (permalink / raw)
To: Chen Ridong
Cc: tj, hannes, rostedt, mhiramat, mathieu.desnoyers, inwardvessel,
shakeel.butt, cgroups, linux-kernel, linux-trace-kernel,
lujialin4
In-Reply-To: <20260129063133.209874-1-chenridong@huaweicloud.com>
[-- Attachment #1: Type: text/plain, Size: 1176 bytes --]
On Thu, Jan 29, 2026 at 06:31:33AM +0000, Chen Ridong <chenridong@huaweicloud.com> wrote:
> From: Chen Ridong <chenridong@huawei.com>
>
> The current cgroup subsystem limit of 16 is insufficient, as the number of
> subsystems has already reached this maximum.
Indeed. But some of them are legacy (and some novel). Do you really need
one kernel image with every subsys config enabled?
> Attempting to add new subsystems beyond this limit results in boot
> failures.
That sounds like BUILD_BUG_ON(CGROUP_SUBSYS_COUNT > 16) doesn't trigger
during build for you. Is the macro broken?
> This patch increases the maximum number of supported cgroup subsystems from
> 16 to 32, providing adequate headroom for future subsystem additions.
It may be needed one day but I'd suggest binding this change with
introduction of actual new controller.
(As we have some CONFIG_*_V1 options that default to N, I'm thinking
about switching config's default to N as well (like:
CONFIG_CGROUP_CPUACCT CONFIG_CGROUP_DEVICE CONFIG_CGROUP_FREEZER
CONFIG_CGROUP_DEBGU), arch/x86/configs/x86_64_defconfig is not exactly
pinnacle of freshness :-/)
Thanks,
Michal
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 265 bytes --]
^ permalink raw reply
* Re: [PATCH -next] cgroup: increase maximum subsystem count from 16 to 32
From: Chen Ridong @ 2026-01-29 9:51 UTC (permalink / raw)
To: Michal Koutný
Cc: tj, hannes, rostedt, mhiramat, mathieu.desnoyers, inwardvessel,
shakeel.butt, cgroups, linux-kernel, linux-trace-kernel,
lujialin4
In-Reply-To: <asryf3kk6c337l33faqpeznk7d4a3rxblzmqrawxffq7sfbaf7@5yfzzdroltjq>
On 2026/1/29 17:23, Michal Koutný wrote:
> On Thu, Jan 29, 2026 at 06:31:33AM +0000, Chen Ridong <chenridong@huaweicloud.com> wrote:
>> From: Chen Ridong <chenridong@huawei.com>
>>
>> The current cgroup subsystem limit of 16 is insufficient, as the number of
>> subsystems has already reached this maximum.
>
> Indeed. But some of them are legacy (and some novel). Do you really need
> one kernel image with every subsys config enabled?
>
We compiled with 'make allmodconfig'.
>> Attempting to add new subsystems beyond this limit results in boot
>> failures.
>
> That sounds like BUILD_BUG_ON(CGROUP_SUBSYS_COUNT > 16) doesn't trigger
> during build for you. Is the macro broken?
>
The BUILD_BUG_ON(CGROUP_SUBSYS_COUNT > 16) macro worked correctly. However, I
only modified the code to allow compilation to pass, and the system subsequently
failed to boot.
>> This patch increases the maximum number of supported cgroup subsystems from
>> 16 to 32, providing adequate headroom for future subsystem additions.
>
> It may be needed one day but I'd suggest binding this change with
> introduction of actual new controller.
> >
> (As we have some CONFIG_*_V1 options that default to N, I'm thinking
> about switching config's default to N as well (like:
> CONFIG_CGROUP_CPUACCT CONFIG_CGROUP_DEVICE CONFIG_CGROUP_FREEZER
> CONFIG_CGROUP_DEBGU), arch/x86/configs/x86_64_defconfig is not exactly
> pinnacle of freshness :-/)
>
>
Can I propose increasing the maximum number now? If we switch certain configs to
default N and then a new subsystem is added later, the default configuration may
work fine, but it will become a problem under allmodconfig — which some users
actually rely on.
Besides, this shouldn't be a major change, right?
--
Best regards,
Ridong
^ permalink raw reply
* Re: [RFC PATCH v1 05/37] KVM: guest_memfd: Wire up kvm_get_memory_attributes() to per-gmem attributes
From: Quentin Perret @ 2026-01-29 11:10 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Sean Christopherson, Ackerley Tng, Alexey Kardashevskiy, cgroups,
kvm, linux-doc, linux-fsdevel, linux-kernel, linux-kselftest,
linux-mm, linux-trace-kernel, x86, akpm, binbin.wu, bp, brauner,
chao.p.peng, chenhuacai, corbet, dave.hansen, dave.hansen, david,
dmatlack, erdemaktas, fan.du, fvdl, haibo1.xu, hannes, hch, hpa,
hughd, ira.weiny, isaku.yamahata, jack, james.morse, jarkko,
jgowans, jhubbard, jroedel, jthoughton, jun.miao, kai.huang,
keirf, kent.overstreet, liam.merwick, maciej.wieczor-retman, mail,
maobibo, mathieu.desnoyers, maz, mhiramat, mhocko, mic,
michael.roth, mingo, mlevitsk, mpe, muchun.song, nikunj, nsaenz,
oliver.upton, palmer, pankaj.gupta, paul.walmsley, pbonzini,
peterx, pgonda, prsampat, pvorel, richard.weiyang,
rick.p.edgecombe, rientjes, rostedt, roypat, rppt, shakeel.butt,
shuah, steven.price, steven.sistare, suzuki.poulose, tabba, tglx,
thomas.lendacky, vannapurve, vbabka, viro, vkuznets, wei.w.wang,
will, willy, wyihan, xiaoyao.li, yan.y.zhao, yilun.xu, yuzenghui,
zhiquan1.li
In-Reply-To: <20260129011618.GA2307128@ziepe.ca>
Hi all,
On Wednesday 28 Jan 2026 at 21:16:18 (-0400), Jason Gunthorpe wrote:
> On Wed, Jan 28, 2026 at 05:03:27PM -0800, Sean Christopherson wrote:
>
> > For a dmabuf fd, the story is the same as guest_memfd. Unless private vs. shared
> > is all or nothing, and can never change, then the only entity that can track that
> > info is the owner of the dmabuf. And even if the private vs. shared attributes
> > are constant, tracking it external to KVM makes sense, because then the provider
> > can simply hardcode %true/%false.
>
> Oh my I had not given that bit any thought. My remarks were just about
> normal non-CC systems.
>
> So MMIO starts out shared, and then converts to private when the guest
> triggers it. It is not all or nothing, there are permanent shared
> holes in the MMIO ranges too.
>
> Beyond that I don't know what people are thinking.
>
> Clearly VFIO has to revoke and disable the DMABUF once any of it
> becomes private. VFIO will somehow have to know when it changes modes
> from the TSM subsystem.
>
> I guess we could have a special channel for KVM to learn the
> shared/private page by page from VFIO as some kind of "aware of CC"
> importer.
Slightly out of my depth, but I figured I should jump in this discussion
nonetheless; turns out dmabuf vs CoCo is a hot topic for pKVM[*], so
please bear with me :)
It occurred to me that lazily faulting a dmabuf page by page into a
guest isn't particularly useful, because the entire dmabuf is 'paged in'
by construction on the host side (regardless of whether that dmabuf is
backed by memory or MMIO). There is a weird edge case where a memslot
may not cover an entire dmabuf, but perhaps we could simply say 'don't
do that'. Faulting-in the entire dmabuf in one go on the first guest
access would be good for performance, but it doesn't really solve any of
the problems you've listed above.
A not-fully-thought-through-and-possibly-ridiculous idea that crossed
my mind some time ago was to make KVM itself a proper dmabuf
importer. You'd essentially see a guest as a 'device' (probably with an
actual struct dev representing it), and the stage-2 MMU in front of it
as its IOMMU. That could potentially allow KVM to implement dma_map_ops
for that guest 'device' by mapping/unmapping pages into its stage-2 and
such. And in order to get KVM to import a dmabuf, host userspace would
have to pass a dmabuf fd to SET_USER_MEMORY_REGION2, a which point KVM
could check properties about the dmabuf before proceeding with the
import. We could set different expectations about the properties we
want for CoCo vs non-CoCo guests at that level (and yes this could
include having KVM use a special channel with the exporter to check
that).
That has the nice benefit of having a clear KVM-level API to transition
an entire dmabuf fd to 'private' in one go in the CoCo case. And in the
non-CoCo case, we avoid the unnecessary lazy faulting of the dmabuf.
It gets really funny when a CoCo guest decides to share back a subset of
that dmabuf with the host, and I'm still wrapping my head around how
we'd make that work, but at this point I'm ready to be told how all the
above already doesn't work and that I should go back to the peanut
gallery :-)
Cheers,
Quentin
[*] https://www.youtube.com/watch?v=zaBxoyRepzA&list=PLW3ep1uCIRfxwmllXTOA2txfDWN6vUOHp&index=35
^ 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