linux-trace-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Jason A. Donenfeld" <Jason@zx2c4.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Vlastimil Babka <vbabka@suse.cz>,
	Greg KH <gregkh@linuxfoundation.org>,
	"Paul E. McKenney" <paulmck@kernel.org>,
	Julia Lawall <Julia.Lawall@inria.fr>,
	kernel-janitors@vger.kernel.org,
	Masami Hiramatsu <mhiramat@kernel.org>,
	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
	linux-kernel@vger.kernel.org, linux-trace-kernel@vger.kernel.org,
	"workflows@vger.kernel.org" <workflows@vger.kernel.org>,
	Thorsten Leemhuis <linux@leemhuis.info>
Subject: Re: [PATCH 05/14] tracefs: replace call_rcu by kfree_rcu for simple kmem_cache_free callback
Date: Wed, 12 Jun 2024 16:09:40 +0200	[thread overview]
Message-ID: <ZmmsJFDmnbjngRNV@zx2c4.com> (raw)
In-Reply-To: <20240611101458.7fa78da8@gandalf.local.home>

On Tue, Jun 11, 2024 at 10:14:58AM -0400, Steven Rostedt wrote:
> On Tue, 11 Jun 2024 10:42:28 +0200
> Vlastimil Babka <vbabka@suse.cz> wrote:
> 
> > AFAICS that documented way is for a different situation? I assume you mean
> > this part:
> > 
> > * Specify any additional patch prerequisites for cherry picking::
> > 
> >     Cc: <stable@vger.kernel.org> # 3.3.x: a1f84a3: sched: Check for idle
> > 
> > But that would assume we actively want to backport this cleanup patch in the
> > first place. But as I understand Steven's intention, we want just to make
> > sure that if in the future this patch is backported (i.e. as a dependency of
> > something else) it won't be forgotten to also backport c9929f0e344a
> > ("mm/slob: remove CONFIG_SLOB"). How to express that without actively
> > marking this patch for backport at the same time?
> 
> Exactly! This isn't to be tagged as stable. It's just a way to say "if you
> need this patch for any reason, you also need patch X".
> 
> I think "Depends-on" is the way to go, as it is *not* a stable thing, and
> what is in stable rules is only about stable patches.

How does "Depends-on" not spiral out of control? There's a *lot* of
"Depends-on" relations one could express in commit series and such. Of
course a lot of git itself is designed to show some subset of these
relationships.

It seems like in most cases, the "Cc: stable@v.g.o # x.y.z+" notation
expresses the backporting safety correctly. What is the purpose of
saying, "if you need this patch for any reason, you also need patch X"?
Who is the intended audience, and are you sure they need this?

I ask these questions because I wind up doing a lot of work backporting
patches to stable and marking things properly for that or submitting
manually backported stable patches and so forth, and in general, patch
applicability for stable things is something I wind up devoting a lot of
time to. If I have to *additionally* start caring about the theoretical
possibility that somebody in the future, outside of the stable flow,
might not understand the context of a given patch and blindly apply it
to some random tree here or there, that sounds like a lot of extra brain
cycles to consider.

So, is this actually necessary, and how does it not spiral out of
control?

  reply	other threads:[~2024-06-12 14:09 UTC|newest]

Thread overview: 77+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-09  8:27 [PATCH 00/14] replace call_rcu by kfree_rcu for simple kmem_cache_free callback Julia Lawall
2024-06-09  8:27 ` [PATCH 05/14] tracefs: " Julia Lawall
2024-06-10 15:22   ` Steven Rostedt
2024-06-10 15:46     ` Paul E. McKenney
2024-06-10 20:36       ` Steven Rostedt
2024-06-10 21:40         ` Vlastimil Babka
2024-06-11  6:23           ` Greg KH
2024-06-11  8:42             ` Vlastimil Babka
2024-06-11  9:05               ` Thorsten Leemhuis
2024-06-11 14:14               ` Steven Rostedt
2024-06-12 14:09                 ` Jason A. Donenfeld [this message]
2024-06-12 16:04                   ` Steven Rostedt
2024-06-11 14:12             ` Steven Rostedt
2024-06-10 20:42       ` Vlastimil Babka
2024-06-10 21:18         ` Steven Rostedt
2024-06-12 21:33 ` [PATCH 00/14] " Jakub Kicinski
2024-06-12 22:37   ` Paul E. McKenney
2024-06-12 22:46     ` Jakub Kicinski
2024-06-12 22:52     ` Jens Axboe
2024-06-12 23:04       ` Paul E. McKenney
2024-06-12 23:31     ` Jason A. Donenfeld
2024-06-13  0:31       ` Jason A. Donenfeld
2024-06-13  3:38         ` Paul E. McKenney
2024-06-13 12:22           ` Jason A. Donenfeld
2024-06-13 12:46             ` Paul E. McKenney
2024-06-13 14:11               ` Jason A. Donenfeld
2024-06-13 15:12                 ` Paul E. McKenney
2024-06-17 15:10             ` Vlastimil Babka
2024-06-17 16:12               ` Paul E. McKenney
2024-06-17 17:23                 ` Vlastimil Babka
2024-06-17 18:42                   ` Uladzislau Rezki
2024-06-17 21:08                     ` Vlastimil Babka
2024-06-18  9:31                       ` Uladzislau Rezki
2024-06-18 16:48                         ` Paul E. McKenney
2024-06-18 17:21                           ` Vlastimil Babka
2024-06-18 17:53                             ` Paul E. McKenney
2024-06-19  9:28                               ` Vlastimil Babka
2024-06-19 16:46                                 ` Paul E. McKenney
2024-06-21  9:32                                 ` Uladzislau Rezki
2024-07-15 20:39                                   ` Vlastimil Babka
2024-07-24 13:53                                     ` Paul E. McKenney
2024-07-24 14:40                                       ` Vlastimil Babka
2024-10-08 16:41                                       ` Vlastimil Babka
2024-10-08 20:02                                         ` Paul E. McKenney
2024-10-09 17:08                                           ` Julia Lawall
2024-10-09 21:02                                             ` Paul E. McKenney
2024-06-19  9:51                           ` Uladzislau Rezki
2024-06-19  9:56                             ` Vlastimil Babka
2024-06-19 11:22                               ` Uladzislau Rezki
2024-06-17 18:54                   ` Paul E. McKenney
2024-06-17 21:34                     ` Vlastimil Babka
2024-06-13 14:17           ` Jakub Kicinski
2024-06-13 14:53             ` Paul E. McKenney
2024-06-13 11:58     ` Jason A. Donenfeld
2024-06-13 12:47       ` Paul E. McKenney
2024-06-13 13:06         ` Uladzislau Rezki
2024-06-13 15:06           ` Paul E. McKenney
2024-06-13 17:38             ` Uladzislau Rezki
2024-06-13 17:45               ` Paul E. McKenney
2024-06-13 17:58                 ` Uladzislau Rezki
2024-06-13 18:13                   ` Paul E. McKenney
2024-06-14 12:35                     ` Uladzislau Rezki
2024-06-14 14:17                       ` Paul E. McKenney
2024-06-14 14:50                         ` Uladzislau Rezki
2024-06-14 19:33                       ` Jason A. Donenfeld
2024-06-17 13:50                         ` Uladzislau Rezki
2024-06-17 14:56                           ` Jason A. Donenfeld
2024-06-17 16:30                             ` Uladzislau Rezki
2024-06-17 16:33                               ` Jason A. Donenfeld
2024-06-17 16:38                                 ` Vlastimil Babka
2024-06-17 17:04                                   ` Jason A. Donenfeld
2024-06-17 21:19                                     ` Vlastimil Babka
2024-06-17 16:42                                 ` Uladzislau Rezki
2024-06-17 16:57                                   ` Jason A. Donenfeld
2024-06-17 17:19                                     ` Uladzislau Rezki
2024-06-17 14:37                         ` Vlastimil Babka
2024-10-08 16:36 ` Vlastimil Babka

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZmmsJFDmnbjngRNV@zx2c4.com \
    --to=jason@zx2c4.com \
    --cc=Julia.Lawall@inria.fr \
    --cc=gregkh@linuxfoundation.org \
    --cc=kernel-janitors@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-trace-kernel@vger.kernel.org \
    --cc=linux@leemhuis.info \
    --cc=mathieu.desnoyers@efficios.com \
    --cc=mhiramat@kernel.org \
    --cc=paulmck@kernel.org \
    --cc=rostedt@goodmis.org \
    --cc=vbabka@suse.cz \
    --cc=workflows@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).