linux-kernel - Re: [PATCH 05/14] tracefs: replace call_rcu by kfree_rcu for simple kmem_cache

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Wed, 12 Jun 2024 12:04:57 -0400
From: Steven Rostedt <rostedt@...dmis.org>
To: "Jason A. Donenfeld" <Jason@...c4.com>
Cc: Vlastimil Babka <vbabka@...e.cz>, Greg KH <gregkh@...uxfoundation.org>,
 "Paul E. McKenney" <paulmck@...nel.org>, Julia Lawall
 <Julia.Lawall@...ia.fr>, kernel-janitors@...r.kernel.org, Masami Hiramatsu
 <mhiramat@...nel.org>, Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
 linux-kernel@...r.kernel.org, linux-trace-kernel@...r.kernel.org,
 "workflows@...r.kernel.org" <workflows@...r.kernel.org>, Thorsten Leemhuis
 <linux@...mhuis.info>
Subject: Re: [PATCH 05/14] tracefs: replace call_rcu by kfree_rcu for simple
 kmem_cache_free callback

On Wed, 12 Jun 2024 16:09:40 +0200
"Jason A. Donenfeld" <Jason@...c4.com> wrote:
> > 
> > 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.

If a change occurs because a recent change happened that allows the
current change to work, then I think a Depends-on is appropriate.

Like in this example. I thought this change was broken, and it would
have been except for a recent change. Having the dependency listed is
useful, especially if the dependency is subtle (doesn't break the build
and may not show the bug immediately).

> 
> It seems like in most cases, the "Cc: stable@....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?

The intended audience is someone backporting features and not fixes.

> 
> 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?

How would you see it going out of control? And "Depends-on" would only
be used for non stable relationships. If stable backports, we can keep
with the current method.

-- Steve