+ tracing-add-__event_in_irq-helpers.patch added to mm-new branch

+ tracing-add-__event_in_irq-helpers.patch added to mm-new branch

[Andrew Morton]

The patch titled
     Subject: tracing: add __event_in_*irq() helpers
has been added to the -mm mm-new branch.  Its filename is
     tracing-add-__event_in_irq-helpers.patch

This patch will shortly appear at
     https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patches/tracing-add-__event_in_irq-helpers.patch

This patch will later appear in the mm-new branch at
    git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm

Note, mm-new is a provisional staging ground for work-in-progress
patches, and acceptance into mm-new is a notification for others take
notice and to finish up reviews.  Please do not hesitate to respond to
review feedback and post updated versions to replace or incrementally
fixup patches in mm-new.

The mm-new branch of mm.git is not included in linux-next

Before you just go and hit "reply", please:
   a) Consider who else should be cc'ed
   b) Prefer to cc a suitable mailing list as well
   c) Ideally: find the original patch on the mailing list and do a
      reply-to-all to that, adding suitable additional cc's

*** Remember to use Documentation/process/submit-checklist.rst when testing your code ***

The -mm tree is included into linux-next via various
branches at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
and is updated there most days

------------------------------------------------------
From: Steven Rostedt <rostedt@goodmis.org>
Subject: tracing: add __event_in_*irq() helpers
Date: Mon, 29 Dec 2025 16:35:15 -0500

Some trace events want to expose in their output if they were triggered in
an interrupt or softirq context.  Instead of recording this in the event
structure itself, as this information is stored in the flags portion of
the event header, add helper macros that can be used in the print format:

  TP_printk("val=%d %s", __entry->val, __entry_in_irq() ? "(in-irq)" : "")

This will output "(in-irq)" for the event in the trace data if the event
was triggered in hard or soft interrupt context.

Link: https://lore.kernel.org/all/20251229132942.31a2b583@gandalf.local.home/
Link: https://lkml.kernel.org/r/20251229163515.3d1b0bba@gandalf.local.home
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
Cc: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Axel Rasmussen <axelrasmussen@google.com>
Cc: Dave Chinner <david@fromorbit.com>
Cc: David Hildenbrand <david@kernel.org>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
Cc: Michal Hocko <mhocko@kernel.org>
Cc: Muchun Song <muchun.song@linux.dev>
Cc: Qi Zheng <zhengqi.arch@bytedance.com>
Cc: Roman Gushchin <roman.gushchin@linux.dev>
Cc: Shakeel Butt <shakeel.butt@linux.dev>
Cc: Thomas Ballasi <tballasi@linux.microsoft.com>
Cc: Wei Xu <weixugc@google.com>
Cc: Yuanchu Xie <yuanchu@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---

 include/trace/stages/stage3_trace_output.h |    8 ++++++++
 include/trace/stages/stage7_class_define.h |   19 +++++++++++++++++++
 2 files changed, 27 insertions(+)

--- a/include/trace/stages/stage3_trace_output.h~tracing-add-__event_in_irq-helpers
+++ a/include/trace/stages/stage3_trace_output.h
@@ -150,3 +150,11 @@
 
 #undef __get_buf
 #define __get_buf(len)		trace_seq_acquire(p, (len))
+
+#undef __event_in_hardirq
+#undef __event_in_softirq
+#undef __event_in_irq
+
+#define __event_in_hardirq()	(__entry->ent.flags & TRACE_FLAG_HARDIRQ)
+#define __event_in_softirq()	(__entry->ent.flags & TRACE_FLAG_SOFTIRQ)
+#define __event_in_irq()	(__entry->ent.flags & (TRACE_FLAG_HARDIRQ | TRACE_FLAG_SOFTIRQ))
--- a/include/trace/stages/stage7_class_define.h~tracing-add-__event_in_irq-helpers
+++ a/include/trace/stages/stage7_class_define.h
@@ -26,6 +26,25 @@
 #undef __print_hex_dump
 #undef __get_buf
 
+#undef __event_in_hardirq
+#undef __event_in_softirq
+#undef __event_in_irq
+
+/*
+ * The TRACE_FLAG_* are enums. Instead of using TRACE_DEFINE_ENUM(),
+ * use their hardcoded values. These values are parsed by user space
+ * tooling elsewhere so they will never change.
+ *
+ * See "enum trace_flag_type" in linux/trace_events.h:
+ *   TRACE_FLAG_HARDIRQ
+ *   TRACE_FLAG_SOFTIRQ
+ */
+
+/* This is what is displayed in the format files */
+#define __event_in_hardirq()	(REC->common_flags & 0x8)
+#define __event_in_softirq()	(REC->common_flags & 0x10)
+#define __event_in_irq()	(REC->common_flags & 0x18)
+
 /*
  * The below is not executed in the kernel. It is only what is
  * displayed in the print format for userspace to parse.
_

Patches currently in -mm which might be from rostedt@goodmis.org are

tracing-add-__event_in_irq-helpers.patch

Re: + tracing-add-__event_in_irq-helpers.patch added to mm-new branch

[Lorenzo Stoakes]

Hi All,

This results in (yet another) case of mm-new not compiling. I was trying to
do some other work and (yet again) ran into the compile failing.

I bisected the issue to this patch, enclose error message below.

Andrew - I am still confused as to how mm-new works, this patch looks
unreviewed (+ doesn't compile) but you took it, a related series that also
didn't compile and had review push-back was taken to mm-new, but other
series without review are rejected for not having review?

Be good to get some clarity as to what mm-new is for?

Thanks, Lorenzo

  AR      arch/x86/entry/built-in.a
In file included from ./include/trace/define_trace.h:132,
                 from ./include/trace/events/vmscan.h:554,
                 from mm/vmscan.c:73:
./include/trace/events/vmscan.h: In function ‘do_trace_event_raw_event_mm_shrink_slab_start’:
./include/trace/events/vmscan.h:238:68: error: invalid use of undefined type ‘struct mem_cgroup’
  238 |                 __entry->memcg_id = sc->memcg ? cgroup_id(sc->memcg->css.cgroup) : 0;
      |                                                                    ^~
./include/trace/trace_events.h:427:11: note: in definition of macro ‘__DECLARE_EVENT_CLASS’
  427 |         { assign; }                                                     \
      |           ^~~~~~
./include/trace/trace_events.h:435:23: note: in expansion of macro ‘PARAMS’
  435 |                       PARAMS(assign), PARAMS(print))                    \
      |                       ^~~~~~
./include/trace/trace_events.h:40:9: note: in expansion of macro ‘DECLARE_EVENT_CLASS’
   40 |         DECLARE_EVENT_CLASS(name,                              \
      |         ^~~~~~~~~~~~~~~~~~~
./include/trace/trace_events.h:44:30: note: in expansion of macro ‘PARAMS’
   44 |                              PARAMS(assign),                   \
      |                              ^~~~~~
./include/trace/events/vmscan.h:206:1: note: in expansion of macro ‘TRACE_EVENT’
  206 | TRACE_EVENT(mm_shrink_slab_start,
      | ^~~~~~~~~~~
./include/trace/events/vmscan.h:228:9: note: in expansion of macro ‘TP_fast_assign’
  228 |         TP_fast_assign(
      |         ^~~~~~~~~~~~~~
./include/trace/events/vmscan.h: In function ‘do_trace_event_raw_event_mm_shrink_slab_end’:
./include/trace/events/vmscan.h:280:56: error: invalid use of undefined type ‘struct mem_cgroup’
  280 |                 __entry->memcg_id = cgroup_id(sc->memcg->css.cgroup);
      |                                                        ^~
./include/trace/trace_events.h:427:11: note: in definition of macro ‘__DECLARE_EVENT_CLASS’
  427 |         { assign; }                                                     \
      |           ^~~~~~
./include/trace/trace_events.h:435:23: note: in expansion of macro ‘PARAMS’
  435 |                       PARAMS(assign), PARAMS(print))                    \
      |                       ^~~~~~
./include/trace/trace_events.h:40:9: note: in expansion of macro ‘DECLARE_EVENT_CLASS’
   40 |         DECLARE_EVENT_CLASS(name,                              \
      |         ^~~~~~~~~~~~~~~~~~~
./include/trace/trace_events.h:44:30: note: in expansion of macro ‘PARAMS’
   44 |                              PARAMS(assign),                   \
      |                              ^~~~~~
./include/trace/events/vmscan.h:254:1: note: in expansion of macro ‘TRACE_EVENT’
  254 | TRACE_EVENT(mm_shrink_slab_end,
      | ^~~~~~~~~~~
./include/trace/events/vmscan.h:272:9: note: in expansion of macro ‘TP_fast_assign’
  272 |         TP_fast_assign(
      |         ^~~~~~~~~~~~~~
In file included from ./include/trace/define_trace.h:133:
./include/trace/events/vmscan.h: In function ‘do_perf_trace_mm_shrink_slab_start’:
./include/trace/events/vmscan.h:238:68: error: invalid use of undefined type ‘struct mem_cgroup’
  238 |                 __entry->memcg_id = sc->memcg ? cgroup_id(sc->memcg->css.cgroup) : 0;
      |                                                                    ^~
./include/trace/perf.h:51:11: note: in definition of macro ‘__DECLARE_EVENT_CLASS’
   51 |         { assign; }                                                     \
      |           ^~~~~~
./include/trace/perf.h:67:23: note: in expansion of macro ‘PARAMS’
   67 |                       PARAMS(assign), PARAMS(print))                    \
      |                       ^~~~~~
./include/trace/trace_events.h:40:9: note: in expansion of macro ‘DECLARE_EVENT_CLASS’
   40 |         DECLARE_EVENT_CLASS(name,                              \
      |         ^~~~~~~~~~~~~~~~~~~
./include/trace/trace_events.h:44:30: note: in expansion of macro ‘PARAMS’
   44 |                              PARAMS(assign),                   \
      |                              ^~~~~~
./include/trace/events/vmscan.h:206:1: note: in expansion of macro ‘TRACE_EVENT’
  206 | TRACE_EVENT(mm_shrink_slab_start,
      | ^~~~~~~~~~~
./include/trace/events/vmscan.h:228:9: note: in expansion of macro ‘TP_fast_assign’
  228 |         TP_fast_assign(
      |         ^~~~~~~~~~~~~~
./include/trace/events/vmscan.h: In function ‘do_perf_trace_mm_shrink_slab_end’:
./include/trace/events/vmscan.h:280:56: error: invalid use of undefined type ‘struct mem_cgroup’
  280 |                 __entry->memcg_id = cgroup_id(sc->memcg->css.cgroup);
      |                                                        ^~
./include/trace/perf.h:51:11: note: in definition of macro ‘__DECLARE_EVENT_CLASS’
   51 |         { assign; }                                                     \
      |           ^~~~~~
./include/trace/perf.h:67:23: note: in expansion of macro ‘PARAMS’
   67 |                       PARAMS(assign), PARAMS(print))                    \
      |                       ^~~~~~
./include/trace/trace_events.h:40:9: note: in expansion of macro ‘DECLARE_EVENT_CLASS’
   40 |         DECLARE_EVENT_CLASS(name,                              \
      |         ^~~~~~~~~~~~~~~~~~~
./include/trace/trace_events.h:44:30: note: in expansion of macro ‘PARAMS’
   44 |                              PARAMS(assign),                   \
      |                              ^~~~~~
./include/trace/events/vmscan.h:254:1: note: in expansion of macro ‘TRACE_EVENT’
  254 | TRACE_EVENT(mm_shrink_slab_end,
      | ^~~~~~~~~~~
./include/trace/events/vmscan.h:272:9: note: in expansion of macro ‘TP_fast_assign’
  272 |         TP_fast_assign(
      |         ^~~~~~~~~~~~~~
make[3]: *** [scripts/Makefile.build:287: mm/vmscan.o] Error 1

On Mon, Jan 05, 2026 at 07:38:41PM -0800, Andrew Morton wrote:
>
> The patch titled
>      Subject: tracing: add __event_in_*irq() helpers
> has been added to the -mm mm-new branch.  Its filename is
>      tracing-add-__event_in_irq-helpers.patch
>
> This patch will shortly appear at
>      https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patches/tracing-add-__event_in_irq-helpers.patch
>
> This patch will later appear in the mm-new branch at
>     git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
>
> Note, mm-new is a provisional staging ground for work-in-progress
> patches, and acceptance into mm-new is a notification for others take
> notice and to finish up reviews.  Please do not hesitate to respond to
> review feedback and post updated versions to replace or incrementally
> fixup patches in mm-new.
>
> The mm-new branch of mm.git is not included in linux-next
>
> Before you just go and hit "reply", please:
>    a) Consider who else should be cc'ed
>    b) Prefer to cc a suitable mailing list as well
>    c) Ideally: find the original patch on the mailing list and do a
>       reply-to-all to that, adding suitable additional cc's
>
> *** Remember to use Documentation/process/submit-checklist.rst when testing your code ***
>
> The -mm tree is included into linux-next via various
> branches at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
> and is updated there most days
>
> ------------------------------------------------------
> From: Steven Rostedt <rostedt@goodmis.org>
> Subject: tracing: add __event_in_*irq() helpers
> Date: Mon, 29 Dec 2025 16:35:15 -0500
>
> Some trace events want to expose in their output if they were triggered in
> an interrupt or softirq context.  Instead of recording this in the event
> structure itself, as this information is stored in the flags portion of
> the event header, add helper macros that can be used in the print format:
>
>   TP_printk("val=%d %s", __entry->val, __entry_in_irq() ? "(in-irq)" : "")
>
> This will output "(in-irq)" for the event in the trace data if the event
> was triggered in hard or soft interrupt context.
>
> Link: https://lore.kernel.org/all/20251229132942.31a2b583@gandalf.local.home/
> Link: https://lkml.kernel.org/r/20251229163515.3d1b0bba@gandalf.local.home
> Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
> Cc: Masami Hiramatsu <mhiramat@kernel.org>
> Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
> Cc: Steven Rostedt <rostedt@goodmis.org>
> Cc: Axel Rasmussen <axelrasmussen@google.com>
> Cc: Dave Chinner <david@fromorbit.com>
> Cc: David Hildenbrand <david@kernel.org>
> Cc: Johannes Weiner <hannes@cmpxchg.org>
> Cc: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
> Cc: Michal Hocko <mhocko@kernel.org>
> Cc: Muchun Song <muchun.song@linux.dev>
> Cc: Qi Zheng <zhengqi.arch@bytedance.com>
> Cc: Roman Gushchin <roman.gushchin@linux.dev>
> Cc: Shakeel Butt <shakeel.butt@linux.dev>
> Cc: Thomas Ballasi <tballasi@linux.microsoft.com>
> Cc: Wei Xu <weixugc@google.com>
> Cc: Yuanchu Xie <yuanchu@google.com>
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
> ---
>
>  include/trace/stages/stage3_trace_output.h |    8 ++++++++
>  include/trace/stages/stage7_class_define.h |   19 +++++++++++++++++++
>  2 files changed, 27 insertions(+)
>
> --- a/include/trace/stages/stage3_trace_output.h~tracing-add-__event_in_irq-helpers
> +++ a/include/trace/stages/stage3_trace_output.h
> @@ -150,3 +150,11 @@
>
>  #undef __get_buf
>  #define __get_buf(len)		trace_seq_acquire(p, (len))
> +
> +#undef __event_in_hardirq
> +#undef __event_in_softirq
> +#undef __event_in_irq
> +
> +#define __event_in_hardirq()	(__entry->ent.flags & TRACE_FLAG_HARDIRQ)
> +#define __event_in_softirq()	(__entry->ent.flags & TRACE_FLAG_SOFTIRQ)
> +#define __event_in_irq()	(__entry->ent.flags & (TRACE_FLAG_HARDIRQ | TRACE_FLAG_SOFTIRQ))
> --- a/include/trace/stages/stage7_class_define.h~tracing-add-__event_in_irq-helpers
> +++ a/include/trace/stages/stage7_class_define.h
> @@ -26,6 +26,25 @@
>  #undef __print_hex_dump
>  #undef __get_buf
>
> +#undef __event_in_hardirq
> +#undef __event_in_softirq
> +#undef __event_in_irq
> +
> +/*
> + * The TRACE_FLAG_* are enums. Instead of using TRACE_DEFINE_ENUM(),
> + * use their hardcoded values. These values are parsed by user space
> + * tooling elsewhere so they will never change.
> + *
> + * See "enum trace_flag_type" in linux/trace_events.h:
> + *   TRACE_FLAG_HARDIRQ
> + *   TRACE_FLAG_SOFTIRQ
> + */
> +
> +/* This is what is displayed in the format files */
> +#define __event_in_hardirq()	(REC->common_flags & 0x8)
> +#define __event_in_softirq()	(REC->common_flags & 0x10)
> +#define __event_in_irq()	(REC->common_flags & 0x18)
> +
>  /*
>   * The below is not executed in the kernel. It is only what is
>   * displayed in the print format for userspace to parse.
> _
>
> Patches currently in -mm which might be from rostedt@goodmis.org are
>
> tracing-add-__event_in_irq-helpers.patch
>

Re: + tracing-add-__event_in_irq-helpers.patch added to mm-new branch

[Andrew Morton]

On Tue, 6 Jan 2026 17:30:32 +0000 Lorenzo Stoakes <lorenzo.stoakes@oracle.com> wrote:

> This results in (yet another) case of mm-new not compiling. I was trying to
> do some other work and (yet again) ran into the compile failing.
> 
> I bisected the issue to this patch, enclose error message below.

It worked for me, and presumably for Stephen.  Please tell us how to
reproduce this.

> Andrew - I am still confused as to how mm-new works, this patch looks
> unreviewed

It was written by the tracing maintainer.

> (+ doesn't compile) but you took it, a related series that also
> didn't compile and had review push-back was taken to mm-new, but other
> series without review are rejected for not having review?
> 
> Be good to get some clarity as to what mm-new is for?
> 

The email you replied to had (courtesy of David):

: Note, mm-new is a provisional staging ground for work-in-progress
: patches, and acceptance into mm-new is a notification for others take
: notice and to finish up reviews.  Please do not hesitate to respond to
: review feedback and post updated versions to replace or incrementally
: fixup patches in mm-new.
: 
: The mm-new branch of mm.git is not included in linux-next

Re: + tracing-add-__event_in_irq-helpers.patch added to mm-new branch

[Lorenzo Stoakes]

On Tue, Jan 06, 2026 at 12:49:30PM -0800, Andrew Morton wrote:
> On Tue, 6 Jan 2026 17:30:32 +0000 Lorenzo Stoakes <lorenzo.stoakes@oracle.com> wrote:
>
> > This results in (yet another) case of mm-new not compiling. I was trying to
> > do some other work and (yet again) ran into the compile failing.
> >
> > I bisected the issue to this patch, enclose error message below.
>
> It worked for me, and presumably for Stephen.  Please tell us how to
> reproduce this.

!CONFIG_MEMCG.

I'll let you guys investigate, I'm done reporting mm-new issues.

>
> > Andrew - I am still confused as to how mm-new works, this patch looks
> > unreviewed
>
> It was written by the tracing maintainer.

OK well that's at least reasonable.

>
> > (+ doesn't compile) but you took it, a related series that also
> > didn't compile and had review push-back was taken to mm-new, but other
> > series without review are rejected for not having review?
> >
> > Be good to get some clarity as to what mm-new is for?
> >
>
> The email you replied to had (courtesy of David):
>
> : Note, mm-new is a provisional staging ground for work-in-progress
> : patches, and acceptance into mm-new is a notification for others take
> : notice and to finish up reviews.  Please do not hesitate to respond to
> : review feedback and post updated versions to replace or incrementally
> : fixup patches in mm-new.
> :
> : The mm-new branch of mm.git is not included in linux-next
>

This provides no information about why/how things land in mm-new. At the
moment it seems entirely random.

Anyway, never mind I'm giving up on mm-new altogether at this point.

I'll let linux-next bots catch things from now on.

Please assume all future series I send are based on mm-unstable.

Thanks, Lorenzo

Re: + tracing-add-__event_in_irq-helpers.patch added to mm-new branch

[Steven Rostedt]

On Wed, 7 Jan 2026 12:12:23 +0000
Lorenzo Stoakes <lorenzo.stoakes@oracle.com> wrote:

> > It worked for me, and presumably for Stephen.  Please tell us how to
> > reproduce this.  
> 
> !CONFIG_MEMCG.
> 
> I'll let you guys investigate, I'm done reporting mm-new issues.
> 
> >  
> > > Andrew - I am still confused as to how mm-new works, this patch looks
> > > unreviewed  
> >
> > It was written by the tracing maintainer.  
> 
> OK well that's at least reasonable.

Hmm, the patch I wrote should not have any dependency on the MEMCG.

I'll have to go and investigate why that was. :-/

-- Steve

Re: + tracing-add-__event_in_irq-helpers.patch added to mm-new branch

[David Hildenbrand (Red Hat)]

>>
>> The email you replied to had (courtesy of David):

I think it was courtesy of Mike :)

>>
>> : Note, mm-new is a provisional staging ground for work-in-progress
>> : patches, and acceptance into mm-new is a notification for others take
>> : notice and to finish up reviews.  Please do not hesitate to respond to
>> : review feedback and post updated versions to replace or incrementally
>> : fixup patches in mm-new.
>> :
>> : The mm-new branch of mm.git is not included in linux-next
>>
> 
> This provides no information about why/how things land in mm-new. At the
> moment it seems entirely random.

Yeah, I am also still a bit unclear on some details of mm-new. So the 
summary mostly captures the idea of mm-new from a submitter 
point-of-view: if it's in mm-new that doesn't mean that your job as a 
submitter is done. That's a great start, but obviously lacks some details.

One point I see, also related to another mm-new-related discussion 
Lorenzo raised: If we want to use mm-new to find issues before they hit 
mm-unstable->next [1], then we should make sure that some known-broken 
patches/tests don't stay in there making it harder to test other patches 
that get put in there afterwards.

For the time being, I assume that everybody should develop against 
mm-unstable, and mm-new should mostly be a target for build bots etc. 
But then, if everybody would develop+test against mm-new, we could 
actually find more issues earlier (IOW, before mm-unstable -> next).

Hm.

[1] we have 0day now running and reporting problems mostly private to 
me, I just didn't have the time yet to closely look into the results 
I've been getting because there seem to be some false positive test 
failures in some unrelated tests.

-- 
Cheers

David

Re: + tracing-add-__event_in_irq-helpers.patch added to mm-new branch

[Lorenzo Stoakes]

On Wed, Jan 07, 2026 at 11:30:58PM +0100, David Hildenbrand (Red Hat) wrote:
> > >
> > > The email you replied to had (courtesy of David):
>
> I think it was courtesy of Mike :)
>
> > >
> > > : Note, mm-new is a provisional staging ground for work-in-progress
> > > : patches, and acceptance into mm-new is a notification for others take
> > > : notice and to finish up reviews.  Please do not hesitate to respond to
> > > : review feedback and post updated versions to replace or incrementally
> > > : fixup patches in mm-new.
> > > :
> > > : The mm-new branch of mm.git is not included in linux-next
> > >
> >
> > This provides no information about why/how things land in mm-new. At the
> > moment it seems entirely random.
>
> Yeah, I am also still a bit unclear on some details of mm-new. So the
> summary mostly captures the idea of mm-new from a submitter point-of-view:
> if it's in mm-new that doesn't mean that your job as a submitter is done.
> That's a great start, but obviously lacks some details.

The key one being - how does anything end up in mm-new?

Before it was generally the case that things went to mm-new prior to review
unless glaring issues or somebody already pushed back on it significantly.

Now it's ???.

Also there's no clarity on timelines of how things go from mm-new to
mm-unstable.

I've been using mm-new as a base since it was added (and encouraging others
to do so in order that I can a. make sure I take into account other series
and avoid conflicts and b. pick up on problems early.

>
> One point I see, also related to another mm-new-related discussion Lorenzo
> raised: If we want to use mm-new to find issues before they hit
> mm-unstable->next [1], then we should make sure that some known-broken
> patches/tests don't stay in there making it harder to test other patches
> that get put in there afterwards.

They generally don't stay in there, but it seems like it's mostly been me
who's been reporting this stuff to catch it early before we break
linux-next or things get merged.

As I said in the mail replying to this, I'm simply no longer going to be
doing this.

It's quite personally disappointing honestly to ask simple questions and to
be ignored on a thread where an issue _I_ personally took quite some time +
significant bisecting to report has been addressed.

And given I appear to be one of the few people to be reporting build/test
issues on mm-new, the fact that my no longer doing this was considered so
unimportant that it can also be ignored is also on a personal level really
rather disappointing to me.

>
> For the time being, I assume that everybody should develop against
> mm-unstable, and mm-new should mostly be a target for build bots etc. But
> then, if everybody would develop+test against mm-new, we could actually find
> more issues earlier (IOW, before mm-unstable -> next).

If everybody bases on mm-unstable the mm-new branch becomes totally
pointless honestly, unless it's simply a place to set the bots on things
which would make more sense.

But we _still_ need clear criteria as to what goes there.

If we have long delays from mm-new to mm-unstable - given our 'default
merge' policy + the huge amount of incoming series the mm list gets (I
personally am cc'd on ~100 mails a day) - we are inevitably going to run
into merge conflicts, one series breaking another, etc.

Refusing to send series there for arbitrary reasons just means we delay bot
reports etc.

This is why we need _clear_ criteria and timelines.

It doesn't feel like Andrew is too open to my point of view here but FWIW
here's an e.g.:

	mm patch timeline:

	1. (within a day) Unless significant pushback, added to mm-new.
	2. (within a few days) If no build bots pick up issues, added to mm-unstable.

	If at any time reviewers clearly reject the series, it will be
	dropped from both trees. This will not happen if the review is
	simply incremental.

	< ... stuff about merging to Linus (after M signoff) >

Right now it's:

	1. ??? maybe gets merged to mm-new or maybe not, no/few bots
	   running no build testing.
	2. After ??? days merged to mm-unstable or maybe not.
	3. With ??? criteria added to mm-stable and sent to Linus.

Which isn't really useful and causes stress for reviewers, maintainers and
submitters.

>
> Hm.
>
> [1] we have 0day now running and reporting problems mostly private to me, I
> just didn't have the time yet to closely look into the results I've been
> getting because there seem to be some false positive test failures in some
> unrelated tests.

I've not seen bot reports from mm-new at all, so this is news to me.

>
> --
> Cheers
>
> David

Thanks, Lorenzo

Re: + tracing-add-__event_in_irq-helpers.patch added to mm-new branch

[David Hildenbrand (Red Hat)]

Nothing to add to the above :)

>>
>> Hm.
>>
>> [1] we have 0day now running and reporting problems mostly private to me, I
>> just didn't have the time yet to closely look into the results I've been
>> getting because there seem to be some false positive test failures in some
>> unrelated tests.
> 
> I've not seen bot reports from mm-new at all, so this is news to me.

So far the reports only go to me while we are experimenting with how 
helpful it is and how stable the results are.

I skimmed over some results today, and apparently it found that the new 
memory-failure selftests are a bit shaky (fail in some environments).

-- 
Cheers

David

Re: + tracing-add-__event_in_irq-helpers.patch added to mm-new branch

[Lorenzo Stoakes]

On Fri, Jan 09, 2026 at 02:59:38PM +0100, David Hildenbrand (Red Hat) wrote:
>
> Nothing to add to the above :)
>
> > >
> > > Hm.
> > >
> > > [1] we have 0day now running and reporting problems mostly private to me, I
> > > just didn't have the time yet to closely look into the results I've been
> > > getting because there seem to be some false positive test failures in some
> > > unrelated tests.
> >
> > I've not seen bot reports from mm-new at all, so this is news to me.
>
> So far the reports only go to me while we are experimenting with how helpful
> it is and how stable the results are.
>
> I skimmed over some results today, and apparently it found that the new
> memory-failure selftests are a bit shaky (fail in some environments).

I guess this is why Andrew isn't bothered about me no longer checking the
branch then, you're taking over that role somewhat :)

Did you not have the bot running for this patch? Or did it happen to not
generate a config with !CONFIG_MEMCG?

I mean I ask again (>/dev/null) - why are we not putting patches into
mm-new randomly this cycle (I mean also previous cycles but on fewer
occasions)?

Surely even if something hasn't had review yet we want to test it no?

And with no information on the process for moving to mm-unstable, I guess
we are relying on some privately sent reports being flagged and you taking
the time to ping people.

This all seems pretty broken, and you're busy enough as it is.

To be constructive, FWIW, here's what I propose:

	I think we should rename mm-new to mm-early-testing, base stuff on
	mm-unstable, and have a clear indication as to how things flow
	through.

	We should then use the testing to determine stability, drop
	anything that's broken, and move stuff to mm-unstable after a
	certain _set_ time period where we'd expect bots to pick up any
	issue.

	Then stuff in mm-unstable goes to Linus if it has a sub-maintainer
	tag on it, if not it doesn't.

As of this cycle - mm-new is totally worthless - and if we don't move to
something sensible like the above we should just drop it.

Nobody outside of a handful of people in mm even know it's a thing, aside
from those I encouraged to use it prior to this cycle.

Overall I'm very uncomfortable with the way these processes are pushing
work down onto people with no regard as to the volume of the work or the
stress it induces with seemingly no say in how the processes are done.

Which is why I'm personally opting out of reporting mm-new issues and
significantly reducing my review work until there is some movement towards
sane processes that reflect the needs of the community and importantly -
those who do the review.

>
> --
> Cheers
>
> David

Cheers, Lorenzo

Re: + tracing-add-__event_in_irq-helpers.patch added to mm-new branch

[David Hildenbrand (Red Hat)]

On 1/9/26 15:17, Lorenzo Stoakes wrote:
> On Fri, Jan 09, 2026 at 02:59:38PM +0100, David Hildenbrand (Red Hat) wrote:
>>
>> Nothing to add to the above :)
>>
>>>>
>>>> Hm.
>>>>
>>>> [1] we have 0day now running and reporting problems mostly private to me, I
>>>> just didn't have the time yet to closely look into the results I've been
>>>> getting because there seem to be some false positive test failures in some
>>>> unrelated tests.
>>>
>>> I've not seen bot reports from mm-new at all, so this is news to me.
>>
>> So far the reports only go to me while we are experimenting with how helpful
>> it is and how stable the results are.
>>
>> I skimmed over some results today, and apparently it found that the new
>> memory-failure selftests are a bit shaky (fail in some environments).
> 
> I guess this is why Andrew isn't bothered about me no longer checking the
> branch then, you're taking over that role somewhat :)

I consider it just another attempt to catch more issues earlier, before 
patches reach mm-unstable and end up in -next.

The build-bots + tests can only catch some stuff. For example, 0day 
runtime-testing is x86 only and only tests some basic stuff (and 
apparently some unstable tests in their ...).

So I don't consider it any replacement for manual testing like you do.

> 
> Did you not have the bot running for this patch? Or did it happen to not
> generate a config with !CONFIG_MEMCG?

0day keeps reporting some issues against mm-new, but given I am on PTO I 
did not get to check all of them yet.

Skimming over the reports, it found one issue reported on January 06:

https://lkml.kernel.org/r/202601070517.0yxdw4WK-lkp@intel.com

At least I think that's the same thing from a quick look.

> 
> I mean I ask again (>/dev/null) - why are we not putting patches into
> mm-new randomly this cycle (I mean also previous cycles but on fewer
> occasions)?
> 
> Surely even if something hasn't had review yet we want to test it no?
> 
> And with no information on the process for moving to mm-unstable, I guess
> we are relying on some privately sent reports being flagged and you taking
> the time to ping people.
> 
> This all seems pretty broken, and you're busy enough as it is.
> 
> To be constructive, FWIW, here's what I propose:
> 
> 	I think we should rename mm-new to mm-early-testing, base stuff on
> 	mm-unstable, and have a clear indication as to how things flow
> 	through.
> 
> 	We should then use the testing to determine stability, drop
> 	anything that's broken, and move stuff to mm-unstable after a
> 	certain _set_ time period where we'd expect bots to pick up any
> 	issue.
> 
> 	Then stuff in mm-unstable goes to Linus if it has a sub-maintainer
> 	tag on it, if not it doesn't.
> 
> As of this cycle - mm-new is totally worthless - and if we don't move to
> something sensible like the above we should just drop it.
> 
> Nobody outside of a handful of people in mm even know it's a thing, aside
> from those I encouraged to use it prior to this cycle.
> 
> Overall I'm very uncomfortable with the way these processes are pushing
> work down onto people with no regard as to the volume of the work or the
> stress it induces with seemingly no say in how the processes are done.

Again, nothing to add from my side :(

> 
> Which is why I'm personally opting out of reporting mm-new issues and
> significantly reducing my review work until there is some movement towards
> sane processes that reflect the needs of the community and importantly -
> those who do the review.

Shame :( But I'm afraid there is nothing I can do and I can perfectly 
understand your position.

-- 
Cheers

David

Re: + tracing-add-__event_in_irq-helpers.patch added to mm-new branch

[Lorenzo Stoakes]

On Fri, Jan 09, 2026 at 03:29:11PM +0100, David Hildenbrand (Red Hat) wrote:
> On 1/9/26 15:17, Lorenzo Stoakes wrote:
> > On Fri, Jan 09, 2026 at 02:59:38PM +0100, David Hildenbrand (Red Hat) wrote:
> > >
> > > Nothing to add to the above :)
> > >
> > > > >
> > > > > Hm.
> > > > >
> > > > > [1] we have 0day now running and reporting problems mostly private to me, I
> > > > > just didn't have the time yet to closely look into the results I've been
> > > > > getting because there seem to be some false positive test failures in some
> > > > > unrelated tests.
> > > >
> > > > I've not seen bot reports from mm-new at all, so this is news to me.
> > >
> > > So far the reports only go to me while we are experimenting with how helpful
> > > it is and how stable the results are.
> > >
> > > I skimmed over some results today, and apparently it found that the new
> > > memory-failure selftests are a bit shaky (fail in some environments).
> >
> > I guess this is why Andrew isn't bothered about me no longer checking the
> > branch then, you're taking over that role somewhat :)
>
> I consider it just another attempt to catch more issues earlier, before
> patches reach mm-unstable and end up in -next.
>
> The build-bots + tests can only catch some stuff. For example, 0day
> runtime-testing is x86 only and only tests some basic stuff (and apparently
> some unstable tests in their ...).
>
> So I don't consider it any replacement for manual testing like you do.

*did :)

>
> >
> > Did you not have the bot running for this patch? Or did it happen to not
> > generate a config with !CONFIG_MEMCG?
>
> 0day keeps reporting some issues against mm-new, but given I am on PTO I did
> not get to check all of them yet.

I'm very sorry you're forced into working duing your leave period to keep
all of this going :/

That really is a sad indictment of the gap between Andrew's claims that
processes 'work' and the reality of _how_ they work.

I hope this adds some emphasis to why we need change.

>
> Skimming over the reports, it found one issue reported on January 06:
>
> https://lkml.kernel.org/r/202601070517.0yxdw4WK-lkp@intel.com
>
> At least I think that's the same thing from a quick look.

Yeah looks right.

I mean I'd say with the proposal I make below this could make mm-new
(renamed to something like mm-early-testing) quite useful.

I think that's a sensible way to go.

>
> >
> > I mean I ask again (>/dev/null) - why are we not putting patches into
> > mm-new randomly this cycle (I mean also previous cycles but on fewer
> > occasions)?
> >
> > Surely even if something hasn't had review yet we want to test it no?
> >
> > And with no information on the process for moving to mm-unstable, I guess
> > we are relying on some privately sent reports being flagged and you taking
> > the time to ping people.
> >
> > This all seems pretty broken, and you're busy enough as it is.
> >
> > To be constructive, FWIW, here's what I propose:
> >
> > 	I think we should rename mm-new to mm-early-testing, base stuff on
> > 	mm-unstable, and have a clear indication as to how things flow
> > 	through.
> >
> > 	We should then use the testing to determine stability, drop
> > 	anything that's broken, and move stuff to mm-unstable after a
> > 	certain _set_ time period where we'd expect bots to pick up any
> > 	issue.
> >
> > 	Then stuff in mm-unstable goes to Linus if it has a sub-maintainer
> > 	tag on it, if not it doesn't.
> >
> > As of this cycle - mm-new is totally worthless - and if we don't move to
> > something sensible like the above we should just drop it.
> >
> > Nobody outside of a handful of people in mm even know it's a thing, aside
> > from those I encouraged to use it prior to this cycle.
> >
> > Overall I'm very uncomfortable with the way these processes are pushing
> > work down onto people with no regard as to the volume of the work or the
> > stress it induces with seemingly no say in how the processes are done.
>
> Again, nothing to add from my side :(

:(

>
> >
> > Which is why I'm personally opting out of reporting mm-new issues and
> > significantly reducing my review work until there is some movement towards
> > sane processes that reflect the needs of the community and importantly -
> > those who do the review.
>
> Shame :( But I'm afraid there is nothing I can do and I can perfectly
> understand your position.

Yes, apologies if I'm adding any more workload to you during your PTO.

Do let me know if the workload gets too much and we can split things up in
THP at least. While I object to the current state of affairs, I take my
role as maintainer seriously.

I for one at least can say thank you for all you do! :)

>
> --
> Cheers
>
> David

Cheers, Lorenzo

Re: + tracing-add-__event_in_irq-helpers.patch added to mm-new branch

[Andrew Morton]

On Fri, 9 Jan 2026 14:17:19 +0000 Lorenzo Stoakes <lorenzo.stoakes@oracle.com> wrote:

> On Fri, Jan 09, 2026 at 02:59:38PM +0100, David Hildenbrand (Red Hat) wrote:
> >
> > Nothing to add to the above :)
> >
> > > >
> > > > Hm.
> > > >
> > > > [1] we have 0day now running and reporting problems mostly private to me, I
> > > > just didn't have the time yet to closely look into the results I've been
> > > > getting because there seem to be some false positive test failures in some
> > > > unrelated tests.
> > >
> > > I've not seen bot reports from mm-new at all, so this is news to me.
> >
> > So far the reports only go to me while we are experimenting with how helpful
> > it is and how stable the results are.
> >
> > I skimmed over some results today, and apparently it found that the new
> > memory-failure selftests are a bit shaky (fail in some environments).
> 
> I guess this is why Andrew isn't bothered about me no longer checking the
> branch then, you're taking over that role somewhat :)

These are serious matters and they merit serious consideration.  This
takes time and I shall not be making half-baked statements.  Please be
patient.

I've seen some buildbot/fuzzbot reports for mm-new but they seem to
have stopped.  It would be good to get this all going again but I never
know who to poke.

> To be constructive, FWIW, here's what I propose:
> 
> 	I think we should rename mm-new to mm-early-testing, base stuff on
> 	mm-unstable, and have a clear indication as to how things flow
> 	through.

Yes, let's not base changes on mm-new.  If an mm-unstable patch needs
work to integrate into mm-new (unlikely) then I'll take care of that.

I'm working on documentation for this and much more.  Hopefully I'll be
progressing that significantly this weekend.

> 	We should then use the testing to determine stability, drop
> 	anything that's broken, and move stuff to mm-unstable after a
> 	certain _set_ time period where we'd expect bots to pick up any
> 	issue.

I like to move things up after 2-3 days - it's all about protecting
linux-next from too much damage.  I've perhaps been a bit slow with
that lately, holidays and all.

> 	Then stuff in mm-unstable goes to Linus if it has a sub-maintainer
> 	tag on it, if not it doesn't.

Sounds easy if you say it quickly ;) There are complications.

Much more to say when I'm ready.

Re: + tracing-add-__event_in_irq-helpers.patch added to mm-new branch

[Lorenzo Stoakes]

On Fri, Jan 09, 2026 at 11:00:28AM -0800, Andrew Morton wrote:
> On Fri, 9 Jan 2026 14:17:19 +0000 Lorenzo Stoakes <lorenzo.stoakes@oracle.com> wrote:
>
> > On Fri, Jan 09, 2026 at 02:59:38PM +0100, David Hildenbrand (Red Hat) wrote:
> > >
> > > Nothing to add to the above :)
> > >
> > > > >
> > > > > Hm.
> > > > >
> > > > > [1] we have 0day now running and reporting problems mostly private to me, I
> > > > > just didn't have the time yet to closely look into the results I've been
> > > > > getting because there seem to be some false positive test failures in some
> > > > > unrelated tests.
> > > >
> > > > I've not seen bot reports from mm-new at all, so this is news to me.
> > >
> > > So far the reports only go to me while we are experimenting with how helpful
> > > it is and how stable the results are.
> > >
> > > I skimmed over some results today, and apparently it found that the new
> > > memory-failure selftests are a bit shaky (fail in some environments).
> >
> > I guess this is why Andrew isn't bothered about me no longer checking the
> > branch then, you're taking over that role somewhat :)
>
> These are serious matters and they merit serious consideration.  This
> takes time and I shall not be making half-baked statements.  Please be
> patient.

Thanks

>
> I've seen some buildbot/fuzzbot reports for mm-new but they seem to
> have stopped.  It would be good to get this all going again but I never
> know who to poke.

That's something we can try to dig into - David how did you get what's set up
already going, or did you just have the URL?

>
> > To be constructive, FWIW, here's what I propose:
> >
> > 	I think we should rename mm-new to mm-early-testing, base stuff on
> > 	mm-unstable, and have a clear indication as to how things flow
> > 	through.
>
> Yes, let's not base changes on mm-new.  If an mm-unstable patch needs
> work to integrate into mm-new (unlikely) then I'll take care of that.

OK thanks that makes sense. I wonder if a rename is in order then to highlight
it's testing, but that's a trivial thing obviously + doesn't matter too much.

>
> I'm working on documentation for this and much more.  Hopefully I'll be
> progressing that significantly this weekend.

Thanks

>
> > 	We should then use the testing to determine stability, drop
> > 	anything that's broken, and move stuff to mm-unstable after a
> > 	certain _set_ time period where we'd expect bots to pick up any
> > 	issue.
>
> I like to move things up after 2-3 days - it's all about protecting
> linux-next from too much damage.  I've perhaps been a bit slow with
> that lately, holidays and all.

I think with mm-new/whatever-we-call-it acting as a testing buffer zone that
makes sense. It then very simply becomes a place for checking stuff pre-next
visibility.

>
> > 	Then stuff in mm-unstable goes to Linus if it has a sub-maintainer
> > 	tag on it, if not it doesn't.
>
> Sounds easy if you say it quickly ;) There are complications.
>
> Much more to say when I'm ready.

Sure, devil's always in the details.

Thanks, Lorenzo

Re: + tracing-add-__event_in_irq-helpers.patch added to mm-new branch

[SeongJae Park]

On Fri, 9 Jan 2026 11:00:28 -0800 Andrew Morton <akpm@linux-foundation.org> wrote:

> On Fri, 9 Jan 2026 14:17:19 +0000 Lorenzo Stoakes <lorenzo.stoakes@oracle.com> wrote:
> 
> > On Fri, Jan 09, 2026 at 02:59:38PM +0100, David Hildenbrand (Red Hat) wrote:
> > >
> > > Nothing to add to the above :)
> > >
> > > > >
> > > > > Hm.
> > > > >
> > > > > [1] we have 0day now running and reporting problems mostly private to me, I
> > > > > just didn't have the time yet to closely look into the results I've been
> > > > > getting because there seem to be some false positive test failures in some
> > > > > unrelated tests.
> > > >
> > > > I've not seen bot reports from mm-new at all, so this is news to me.
> > >
> > > So far the reports only go to me while we are experimenting with how helpful
> > > it is and how stable the results are.
> > >
> > > I skimmed over some results today, and apparently it found that the new
> > > memory-failure selftests are a bit shaky (fail in some environments).
> > 
> > I guess this is why Andrew isn't bothered about me no longer checking the
> > branch then, you're taking over that role somewhat :)
> 
> These are serious matters and they merit serious consideration.  This
> takes time and I shall not be making half-baked statements.  Please be
> patient.
> 
> I've seen some buildbot/fuzzbot reports for mm-new but they seem to
> have stopped.  It would be good to get this all going again but I never
> know who to poke.

Seems at least some build tests for mm-new are still actively ongoing.  We got
wo reports today (2026-01-09 UTC):
https://lore.kernel.org/oe-kbuild-all/?q=mm-new

> 
> > To be constructive, FWIW, here's what I propose:
> > 
> > 	I think we should rename mm-new to mm-early-testing, base stuff on
> > 	mm-unstable, and have a clear indication as to how things flow
> > 	through.
> 
> Yes, let's not base changes on mm-new.  If an mm-unstable patch needs
> work to integrate into mm-new (unlikely) then I'll take care of that.
> 
> I'm working on documentation for this and much more.  Hopefully I'll be
> progressing that significantly this weekend.

I was actually thinking it would be nice to have a document that describing the
current process, becasue the nwe can make an alignment on the current status,
and further discuss possible improvements.  I was actually about to share the
idea today, and start writing an RFC patch that adds the documentation based on
my best understanding, as MM's maintainer profile [1].  It's good to hear you
are doing the documentation.  I'm not sure your documentation will be somewhat
I was planning to make, but I sure that will be helpful.  So I will wait for
your documentation.

[1] https://docs.kernel.org/maintainer/maintainer-entry-profile.html


Thanks,
SJ

[...]

Re: + tracing-add-__event_in_irq-helpers.patch added to mm-new branch

[Andrew Morton]

On Fri,  9 Jan 2026 16:32:32 -0800 SeongJae Park <sj@kernel.org> wrote:

> > I'm working on documentation for this and much more.  Hopefully I'll be
> > progressing that significantly this weekend.
> 
> I was actually thinking it would be nice to have a document that describing the
> current process, becasue the nwe can make an alignment on the current status,
> and further discuss possible improvements.  I was actually about to share the
> idea today, and start writing an RFC patch that adds the documentation based on
> my best understanding, as MM's maintainer profile [1].  It's good to hear you
> are doing the documentation.  I'm not sure your documentation will be somewhat
> I was planning to make, but I sure that will be helpful.  So I will wait for
> your documentation.

Thanks.  What I plan to do is, roughly,

- A whole bunch of changes to the mm.git series file
  (https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/pc/devel-series),
  which is the repository of all status

- Add some words to all those added-to-mm emails directing people to
  this file so they can look at the current status of all the patches

- Add a glossary of terms to the series file.  Decoding akpm notes-to-self.

- Explain what all the branches do, how material moves between them

- High level description of how mm-unstable works.  It's a
  development tree, not a patch repository!

- Explain my decision-making process, if such is possible

- Anything else I think of.

The series file is a strange place to do some of this - we can of
course move content somewhere else sometime.

Re: + tracing-add-__event_in_irq-helpers.patch added to mm-new branch

[Lorenzo Stoakes]

On Fri, Jan 09, 2026 at 05:15:21PM -0800, Andrew Morton wrote:
> On Fri,  9 Jan 2026 16:32:32 -0800 SeongJae Park <sj@kernel.org> wrote:
>
> > > I'm working on documentation for this and much more.  Hopefully I'll be
> > > progressing that significantly this weekend.
> >
> > I was actually thinking it would be nice to have a document that describing the
> > current process, becasue the nwe can make an alignment on the current status,
> > and further discuss possible improvements.  I was actually about to share the
> > idea today, and start writing an RFC patch that adds the documentation based on
> > my best understanding, as MM's maintainer profile [1].  It's good to hear you
> > are doing the documentation.  I'm not sure your documentation will be somewhat
> > I was planning to make, but I sure that will be helpful.  So I will wait for
> > your documentation.
>
> Thanks.  What I plan to do is, roughly,
>
> - A whole bunch of changes to the mm.git series file
>   (https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/pc/devel-series),
>   which is the repository of all status
>
> - Add some words to all those added-to-mm emails directing people to
>   this file so they can look at the current status of all the patches
>
> - Add a glossary of terms to the series file.  Decoding akpm notes-to-self.
>
> - Explain what all the branches do, how material moves between them
>
> - High level description of how mm-unstable works.  It's a
>   development tree, not a patch repository!
>
> - Explain my decision-making process, if such is possible
>
> - Anything else I think of.
>
> The series file is a strange place to do some of this - we can of
> course move content somewhere else sometime.

While I thank you for efforts to document the current process, the situation is
that merge-by-default is burning maintainers out.

Documentation is nice, discussions of details are nice, but they're essentially
immaterial in comparison to this primary issue.

I wouldn't normally be this direct, esp. publicly - but things have reached a
point where we truly do need to change this default.

David is working through his entire leave period as a result of it, which is a
sign of things being very broken, and work being pushed down on to others.

While the current process seems inscrutible and having it be less so is
definitely a win, scrutible or not, we truly must change this default. It solves
90% of the problems and is easily achievable with no change to your workflow
(e.g. simply note in the quilt file whether an M tag was received yet or not).

I know there's some 'devil in the detail' here, which I'm more than happy to
discuss, but any problems that might arise will be small in comparison to the
issues merge-by-default cause.

In order to give you time to properly respond, I'll await your larger responses,
and delay taking further action to opt-out of this process, in hopes that we'll
see change on this.

Please note that none of this is meant to be disrespectful, rather simply being
direct and clear in raising a very real issue that is having genuine impact on
maintainers.

Thanks, Lorenzo

Re: + tracing-add-__event_in_irq-helpers.patch added to mm-new branch

[Steven Rostedt]

On Tue, 6 Jan 2026 17:30:32 +0000
Lorenzo Stoakes <lorenzo.stoakes@oracle.com> wrote:

>   AR      arch/x86/entry/built-in.a
> In file included from ./include/trace/define_trace.h:132,
>                  from ./include/trace/events/vmscan.h:554,
>                  from mm/vmscan.c:73:
> ./include/trace/events/vmscan.h: In function ‘do_trace_event_raw_event_mm_shrink_slab_start’:
> ./include/trace/events/vmscan.h:238:68: error: invalid use of undefined type ‘struct mem_cgroup’
>   238 |                 __entry->memcg_id = sc->memcg ? cgroup_id(sc->memcg->css.cgroup) : 0;
>       |                                                                    ^~
> ./include/trace/trace_events.h:427:11: note: in definition of macro ‘__DECLARE_EVENT_CLASS’

OK, the bug isn't the patch I wrote. It's with the patch that was added on
top of it.

   https://lore.kernel.org/all/20260105160423.23708-2-tballasi@linux.microsoft.com/

Which added:

@@ -208,31 +215,34 @@ TRACE_EVENT(mm_shrink_slab_start,
 	TP_STRUCT__entry(
 		__field(struct shrinker *, shr)
 		__field(void *, shrink)
-		__field(int, nid)
 		__field(long, nr_objects_to_shrink)
 		__field(unsigned long, gfp_flags)
 		__field(unsigned long, cache_items)
 		__field(unsigned long long, delta)
 		__field(unsigned long, total_scan)
 		__field(int, priority)
+		__field(int, nid)
+		__field(unsigned short, memcg_id)
 	),
 
 	TP_fast_assign(
 		__entry->shr = shr;
 		__entry->shrink = shr->scan_objects;
-		__entry->nid = sc->nid;
 		__entry->nr_objects_to_shrink = nr_objects_to_shrink;
 		__entry->gfp_flags = (__force unsigned long)sc->gfp_mask;
 		__entry->cache_items = cache_items;
 		__entry->delta = delta;
 		__entry->total_scan = total_scan;
 		__entry->priority = priority;
+		__entry->nid = sc->nid;
+		__entry->memcg_id = sc->memcg ? cgroup_id(sc->memcg->css.cgroup) : 0;
 	),
 
-	TP_printk("%pS %p: nid: %d objects to shrink %ld gfp_flags %s cache items %ld delta %lld total_scan %ld priority %d",
+	TP_printk("%pS %p: nid: %d memcg_id: %u objects to shrink %ld gfp_flags %s cache items %ld delta %lld total_scan %ld priority %d",
 		__entry->shrink,
 		__entry->shr,
 		__entry->nid,
+		__entry->memcg_id,
 		__entry->nr_objects_to_shrink,
 		show_gfp_flags(__entry->gfp_flags),
 		__entry->cache_items,


Appears that the dereferencing of sc->memcg that was added is dependent on CONFIG_MEMCG.

Thus, not my fault ;-)

-- Steve

Re: + tracing-add-__event_in_irq-helpers.patch added to mm-new branch

[Andrew Morton]

On Wed, 7 Jan 2026 11:27:00 -0500 Steven Rostedt <rostedt@goodmis.org> wrote:

> On Tue, 6 Jan 2026 17:30:32 +0000
> Lorenzo Stoakes <lorenzo.stoakes@oracle.com> wrote:
> 
> >   AR      arch/x86/entry/built-in.a
> > In file included from ./include/trace/define_trace.h:132,
> >                  from ./include/trace/events/vmscan.h:554,
> >                  from mm/vmscan.c:73:
> > ./include/trace/events/vmscan.h: In function ‘do_trace_event_raw_event_mm_shrink_slab_start’:
> > ./include/trace/events/vmscan.h:238:68: error: invalid use of undefined type ‘struct mem_cgroup’
> >   238 |                 __entry->memcg_id = sc->memcg ? cgroup_id(sc->memcg->css.cgroup) : 0;
> >       |                                                                    ^~
> > ./include/trace/trace_events.h:427:11: note: in definition of macro ‘__DECLARE_EVENT_CLASS’
> 
> OK, the bug isn't the patch I wrote. It's with the patch that was added on
> top of it.
> 
>    https://lore.kernel.org/all/20260105160423.23708-2-tballasi@linux.microsoft.com/

Yep, thanks, Thomas is presumably working on a new version.

Thomas, please include Stephen's patch in that series (don't forget to
add your own signoff to it).

>
> Thus, not my fault ;-)
> 

Please don't deprive us of the joy of blaming you for stuff.

Re: + tracing-add-__event_in_irq-helpers.patch added to mm-new branch

[Steven Rostedt]

On Wed, 7 Jan 2026 08:35:52 -0800
Andrew Morton <akpm@linux-foundation.org> wrote:

> > OK, the bug isn't the patch I wrote. It's with the patch that was added on
> > top of it.
> > 
> >    https://lore.kernel.org/all/20260105160423.23708-2-tballasi@linux.microsoft.com/  
> 
> Yep, thanks, Thomas is presumably working on a new version.
> 
> Thomas, please include Stephen's patch in that series (don't forget to
> add your own signoff to it).

Who's this "Stephen" you keep referring to?

> 
> >
> > Thus, not my fault ;-)
> >   
> 
> Please don't deprive us of the joy of blaming you for stuff.

That's what I'm here for. Heck for several years the topic of the #linux-rt
IRC channel in OFTC was "Blame rostedt".

-- Steve

+ tracing-add-__event_in_irq-helpers.patch added to mm-new branch

[Andrew Morton]

The patch titled
     Subject: tracing: add __event_in_*irq() helpers
has been added to the -mm mm-new branch.  Its filename is
     tracing-add-__event_in_irq-helpers.patch

This patch will shortly appear at
     https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patches/tracing-add-__event_in_irq-helpers.patch

This patch will later appear in the mm-new branch at
    git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm

Note, mm-new is a provisional staging ground for work-in-progress
patches, and acceptance into mm-new is a notification for others take
notice and to finish up reviews.  Please do not hesitate to respond to
review feedback and post updated versions to replace or incrementally
fixup patches in mm-new.

The mm-new branch of mm.git is not included in linux-next

Before you just go and hit "reply", please:
   a) Consider who else should be cc'ed
   b) Prefer to cc a suitable mailing list as well
   c) Ideally: find the original patch on the mailing list and do a
      reply-to-all to that, adding suitable additional cc's

*** Remember to use Documentation/process/submit-checklist.rst when testing your code ***

The -mm tree is included into linux-next via various
branches at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
and is updated there most days

------------------------------------------------------
From: Steven Rostedt <rostedt@goodmis.org>
Subject: tracing: add __event_in_*irq() helpers
Date: Mon, 23 Feb 2026 09:15:42 -0800

Patch series "mm: vmscan: add PID and cgroup ID to vmscan tracepoints",
v7.


This patch (of 3):

Some trace events want to expose in their output if they were triggered in
an interrupt or softirq context.  Instead of recording this in the event
structure itself, as this information is stored in the flags portion of
the event header, add helper macros that can be used in the print format:

  TP_printk("val=%d %s", __entry->val, __event_in_irq() ? "(in-irq)" : "")

This will output "(in-irq)" for the event in the trace data if the event
was triggered in hard or soft interrupt context.

Link: https://lkml.kernel.org/r/20260223171544.4750-1-tballasi@linux.microsoft.com
Link: https://lore.kernel.org/all/20251229132942.31a2b583@gandalf.local.home/
Link: https://lkml.kernel.org/r/20260223171544.4750-2-tballasi@linux.microsoft.com
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
Signed-off-by: Thomas Ballasi <tballasi@linux.microsoft.com>
Cc: Axel Rasmussen <axelrasmussen@google.com>
Cc: David Hildenbrand <david@kernel.org>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
Cc: "Masami Hiramatsu (Google)" <mhiramat@kernel.org>
Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Cc: Michal Hocko <mhocko@kernel.org>
Cc: Qi Zheng <zhengqi.arch@bytedance.com>
Cc: Shakeel Butt <shakeel.butt@linux.dev>
Cc: Wei Xu <weixugc@google.com>
Cc: Yuanchu Xie <yuanchu@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---

 include/trace/stages/stage3_trace_output.h |    8 ++++++++
 include/trace/stages/stage7_class_define.h |   19 +++++++++++++++++++
 2 files changed, 27 insertions(+)

--- a/include/trace/stages/stage3_trace_output.h~tracing-add-__event_in_irq-helpers
+++ a/include/trace/stages/stage3_trace_output.h
@@ -150,3 +150,11 @@
 
 #undef __get_buf
 #define __get_buf(len)		trace_seq_acquire(p, (len))
+
+#undef __event_in_hardirq
+#undef __event_in_softirq
+#undef __event_in_irq
+
+#define __event_in_hardirq()	(__entry->ent.flags & TRACE_FLAG_HARDIRQ)
+#define __event_in_softirq()	(__entry->ent.flags & TRACE_FLAG_SOFTIRQ)
+#define __event_in_irq()	(__entry->ent.flags & (TRACE_FLAG_HARDIRQ | TRACE_FLAG_SOFTIRQ))
--- a/include/trace/stages/stage7_class_define.h~tracing-add-__event_in_irq-helpers
+++ a/include/trace/stages/stage7_class_define.h
@@ -26,6 +26,25 @@
 #undef __print_hex_dump
 #undef __get_buf
 
+#undef __event_in_hardirq
+#undef __event_in_softirq
+#undef __event_in_irq
+
+/*
+ * The TRACE_FLAG_* are enums. Instead of using TRACE_DEFINE_ENUM(),
+ * use their hardcoded values. These values are parsed by user space
+ * tooling elsewhere so they will never change.
+ *
+ * See "enum trace_flag_type" in linux/trace_events.h:
+ *   TRACE_FLAG_HARDIRQ
+ *   TRACE_FLAG_SOFTIRQ
+ */
+
+/* This is what is displayed in the format files */
+#define __event_in_hardirq()	(REC->common_flags & 0x8)
+#define __event_in_softirq()	(REC->common_flags & 0x10)
+#define __event_in_irq()	(REC->common_flags & 0x18)
+
 /*
  * The below is not executed in the kernel. It is only what is
  * displayed in the print format for userspace to parse.
_

Patches currently in -mm which might be from rostedt@goodmis.org are

tracing-add-__event_in_irq-helpers.patch