From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Mike Isely at pobox <isely@pobox.com>
Cc: mike.isely@cobaltdigital.com, Daniel Scally <djrscally@gmail.com>,
Heikki Krogerus <heikki.krogerus@linux.intel.com>,
Sakari Ailus <sakari.ailus@linux.intel.com>,
linux-acpi@vger.kernel.org,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 0/1] software node: Use-after-free fix in drivers/base/swnode.c
Date: Wed, 25 Feb 2026 22:05:57 +0200 [thread overview]
Message-ID: <aZ9WJX2otnpgk6wR@smile.fi.intel.com> (raw)
In-Reply-To: <80ccd17f-9265-f304-fae0-1250c2caedba@isely.net>
On Wed, Feb 25, 2026 at 01:48:04PM -0600, Mike Isely wrote:
> On Wed, 25 Feb 2026, Andy Shevchenko wrote:
> > On Wed, Feb 25, 2026 at 12:59:56PM -0600, Mike Isely wrote:
> > > On Wed, 25 Feb 2026, Andy Shevchenko wrote:
> > > > On Tue, Feb 24, 2026 at 01:19:21PM -0600, mike.isely@cobaltdigital.com wrote:
...
> > > > > This was detected in kernel 6.12, verified also in kernel 6.6. Visual
> > > > > inspection in 6.19.3 source (the latest as of right now) shows the
> > > >
> > > > The latest is v7.0-rc1 as of time of the topic message.
> > >
> > > I actually meant the latest release. Guess I should have checked the
> > > latest release candidate on the off-chance that it might have been
> > > addressed.
> >
> > It is probably not, but the idea to check against latest tag in the vanilla
> > repository. v6.19.3 is not even vanilla, it's stable kernel.
>
> I tend to stick with the latest kernel that is NOT a release candidate
> when building random things here regardless of the term used and that's
> still 6.19.3. But for verifying a patch, yes I should have at least
> taken a closer look at 7.0-rc1.
The logical requirement for a new contribution is to build changes against
current or next cycle. Hence only two kernels have interest to us:
- latest tag in vanilla (v7.0-rc1 as of today)
- latest tag in Linux Next (whatever day it is)
> > > > > same issue. The nearly trivial fix was verified in 6.12. While this
> > > > > patches against 6.19.3, IMHO this is a candidate for all LTS kernels.
> > > >
> > > > Thanks for the contribution, usually for a single patch there is no need
> > > > in cover letter. The comment block can handle this (the place after cutter
> > > > '---' line in the message with a patch).
> > >
> > > Yeah, a separate cover letter is overkill, but I was just following a
> > > process here.
> >
> > What process? I think we have that somewhere in the documentation that cover
> > letter for a single patch is not needed...
>
> Documentation/process/submitting-patches.rst in the kernel sources, or
> https://docs.kernel.org/process/submitting-patches.html
Yes, it maybe not so clear but it actually tells you to choose between two:
- vanilla (latest tag), OR
- dedicated tree "for-next" (most use this, but some use other name for
the branch for the next cycle).
--
With Best Regards,
Andy Shevchenko
prev parent reply other threads:[~2026-02-25 20:06 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-24 19:19 [PATCH 0/1] software node: Use-after-free fix in drivers/base/swnode.c mike.isely
2026-02-24 19:19 ` [PATCH 1/1] sofware node: Only the managing device can unreference managed software node mike.isely
2026-02-25 11:22 ` Andy Shevchenko
2026-02-25 19:42 ` Mike Isely
2026-02-25 20:01 ` Andy Shevchenko
2026-02-25 20:16 ` Mike Isely
2026-02-26 7:16 ` Andy Shevchenko
2026-02-26 19:06 ` Mike Isely
2026-02-26 20:42 ` Andy Shevchenko
2026-02-27 17:55 ` Mike Isely
2026-02-28 11:02 ` Andy Shevchenko
2026-02-28 16:34 ` Mike Isely
2026-02-25 9:46 ` [PATCH 0/1] software node: Use-after-free fix in drivers/base/swnode.c Andy Shevchenko
2026-02-25 18:59 ` Mike Isely
2026-02-25 19:17 ` Andy Shevchenko
2026-02-25 19:48 ` Mike Isely
2026-02-25 20:05 ` Andy Shevchenko [this message]
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=aZ9WJX2otnpgk6wR@smile.fi.intel.com \
--to=andriy.shevchenko@linux.intel.com \
--cc=djrscally@gmail.com \
--cc=heikki.krogerus@linux.intel.com \
--cc=isely@pobox.com \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mike.isely@cobaltdigital.com \
--cc=sakari.ailus@linux.intel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox