From: Lee Jones <lee@kernel.org>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Greg KH <gregkh@linuxfoundation.org>,
Vincent Donnefort <vdonnefort@google.com>,
stable@vger.kernel.org, mhiramat@kernel.org,
linux-trace-kernel@vger.kernel.org,
mathieu.desnoyers@efficios.com, kernel-team@android.com,
linux-kernel@vger.kernel.org
Subject: Re: STABLE REQ: [PATCH v5 06/10] tracing: Fix subbuf resize races with trace_pipe_raw readers
Date: Wed, 2 Sep 2026 17:22:46 +0100 [thread overview]
Message-ID: <20260902162246.GC2133376@google.com> (raw)
In-Reply-To: <20260902082550.4644fe91@gandalf.local.home>
On Wed, 02 Sep 2026, Steven Rostedt wrote:
> On Wed, 2 Sep 2026 08:21:41 -0400
> Steven Rostedt <rostedt@goodmis.org> wrote:
>
> > There's even been times that I *removed* a Cc to stable because I did not
> > think it was worth the backport. Of course, I still keep the Fixes tag,
> > which means it will likely be backported anyway. But that's up to the
> > stable maintainers to decide ;-)
Pretty sure this isn't the case anymore. RIP AUTOSEL.
> The big difference between a commit with the Fixes tag and a Cc to stable
> verses one with the Fixes tag without the Cc stable, is that the one with
> Cc stable will give me a "FAILED" message if it fails to apply. One with
> just the Fixes tag and no Cc stable, will not generate that message to me
> if it doesn't apply back to the version with the Fixes commit sha.
So what happens when you receive the FAILED message?
And why are you interested to know how far back a fix can be backported?
Personally, I'm _very_ interested in a _small_ number of patches, but
none of which usually emanate from subsystems I maintain.
> I do like to know what I marked as stable and fails to apply. Unfortunately
> I don't have the time to go fix them. But I keep them in a mail folder in
> case I need to do it one day.
We have have such wonderful aspirations. Maybe we can get around to
those jobs when AI starts doing our jobs for us! =;-)
--
Lee Jones
next prev parent reply other threads:[~2026-09-02 16:22 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-13 13:11 [PATCH v5 00/10] ring-buffer: Fixes for subbuf resizing and persistent buffers Vincent Donnefort
2026-08-13 13:11 ` [PATCH v5 01/10] ring-buffer: Free cpu_buffer::free_page with subbuf_order Vincent Donnefort
2026-08-13 13:54 ` sashiko-bot
2026-08-13 15:49 ` Masami Hiramatsu
2026-08-13 16:02 ` Vincent Donnefort
2026-08-13 16:03 ` Vincent Donnefort
2026-08-13 16:18 ` Masami Hiramatsu
2026-08-13 13:11 ` [PATCH v5 02/10] ring-buffer: Hold cpu_buffer::lock when resizing a subbuf Vincent Donnefort
2026-08-13 14:01 ` sashiko-bot
2026-08-13 13:11 ` [PATCH v5 03/10] ring-buffer: Make cpu_buffer::free_page a buffer_data_read_page Vincent Donnefort
2026-08-13 13:56 ` sashiko-bot
2026-08-14 1:04 ` Steven Rostedt
2026-08-13 13:11 ` [PATCH v5 04/10] ring-buffer: Fix subbuf resize race with ring buffer readers Vincent Donnefort
2026-08-13 13:51 ` sashiko-bot
2026-08-14 1:12 ` Steven Rostedt
2026-08-14 15:32 ` Masami Hiramatsu
2026-08-14 17:28 ` Steven Rostedt
2026-08-13 13:11 ` [PATCH v5 05/10] ring-buffer: Fix subbuf resize race with ring_buffer_alloc_read_page() Vincent Donnefort
2026-08-13 13:11 ` [PATCH v5 06/10] tracing: Fix subbuf resize races with trace_pipe_raw readers Vincent Donnefort
2026-08-13 13:53 ` sashiko-bot
2026-08-14 1:31 ` Steven Rostedt
2026-08-14 8:02 ` Vincent Donnefort
2026-09-01 12:34 ` STABLE REQ: " Lee Jones
2026-09-01 13:46 ` Steven Rostedt
2026-09-02 8:27 ` Lee Jones
2026-09-02 8:44 ` Greg KH
2026-09-02 9:57 ` Lee Jones
2026-09-02 11:38 ` Greg KH
2026-09-02 11:59 ` Lee Jones
2026-09-02 12:21 ` Steven Rostedt
2026-09-02 12:25 ` Steven Rostedt
2026-09-02 16:22 ` Lee Jones [this message]
2026-09-02 16:33 ` Steven Rostedt
2026-09-01 13:50 ` Vincent Donnefort
2026-09-02 22:14 ` Sasha Levin
2026-08-13 13:11 ` [PATCH v5 07/10] ring-buffer: Dynamically calculate max_data_size Vincent Donnefort
2026-08-14 1:34 ` Steven Rostedt
2026-08-14 7:59 ` Vincent Donnefort
2026-08-14 12:46 ` Steven Rostedt
2026-08-14 12:50 ` Vincent Donnefort
2026-08-13 13:11 ` [PATCH v5 08/10] ring-buffer: Remove trace_buffer::cpus Vincent Donnefort
2026-08-13 13:11 ` [PATCH v5 09/10] ring-buffer: Remove ring_buffer_per_cpu::mapped Vincent Donnefort
2026-08-13 13:11 ` [PATCH v5 10/10] ring-buffer: Make nr_pages unsigned int Vincent Donnefort
2026-08-13 13:55 ` sashiko-bot
2026-08-14 1:41 ` Steven Rostedt
2026-08-14 8:07 ` Vincent Donnefort
2026-08-14 12:37 ` Steven Rostedt
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=20260902162246.GC2133376@google.com \
--to=lee@kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=kernel-team@android.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=mathieu.desnoyers@efficios.com \
--cc=mhiramat@kernel.org \
--cc=rostedt@goodmis.org \
--cc=stable@vger.kernel.org \
--cc=vdonnefort@google.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.