Received-SPF: pass (google.com: domain of linux-kernel+bounces-131738-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1;
Message-ID: <dfd87673-c581-4b4b-b37a-1cf5c817240d@leemhuis.info>
Date: Thu, 4 Apr 2024 17:36:42 +0200
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Do we need a "DoNotBackPort" tag? (was: Re: Hibernate stuck after
 recent kernel/workqueue.c changes in Stable 6.6.23)
To: Greg KH <gregkh@linuxfoundation.org>, Tejun Heo <tj@kernel.org>
Cc: Linux regressions mailing list <regressions@lists.linux.dev>,
 Sasha Levin <sashal@kernel.org>,
 "stable@vger.kernel.org" <stable@vger.kernel.org>,
 LKML <linux-kernel@vger.kernel.org>
References: <ce4c2f67-c298-48a0-87a3-f933d646c73b@leemhuis.info>
 <ZgylCe48FuOKNWtM@slm.duckdns.org>
 <b6cdb17f-206c-4dff-bb45-a60317e0a55e@leemhuis.info>
 <2024040328-surfacing-breezy-34c6@gregkh> <Zg10Keik4KORjXMh@slm.duckdns.org>
 <2024040319-doorbell-ecosystem-7d31@gregkh>
From: "Linux regression tracking (Thorsten Leemhuis)"
 <regressions@leemhuis.info>
Reply-To: Linux regressions mailing list <regressions@lists.linux.dev>
Content-Language: en-US, de-DE
In-Reply-To: <2024040319-doorbell-ecosystem-7d31@gregkh>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 03.04.24 18:10, Greg KH wrote:
> On Wed, Apr 03, 2024 at 05:22:17AM -1000, Tejun Heo wrote:
>> On Wed, Apr 03, 2024 at 07:11:04AM +0200, Greg KH wrote:
>>>> Side note: I have no idea why the stable team backported those patches
>>>> and no option on whether that was wise, just trying to help finding the best
>>>> solution forward from the current state of things.
>>>
>>> The Fixes: tag triggered it, that's why they were backported.

Yeah, this is what I assumed.

>>>>> which would
>>>>> be far too invasive for -stable, thus no Cc: stable.
>>>>>
>>>>> I didn't know a Fixes
>>>>> tag automatically triggers backport to -stable. I will keep that in mind for
>>>>> future.
>>>>
>>>> /me fears that more and more developers due to situations like this will
>>>> avoid Fixes: tags and wonders what consequences that might have for the
>>>> kernel as a whole
>>>
>>> The problem is that we have subsystems that only use Fixes: and not cc:
>>> stable which is why we need to pick these up as well.  Fixes: is great,
>>> but if everyone were to do this "properly" then we wouldn't need to pick
>>> these other ones up, but instead, it's about 1/3 of our volume :(

I'm also well aware of that and do not want to complain about it, as I
think I grasped why the stable team works like that -- and even think
given the circumstances it is round about the right approach. I also
understand that mistakes will always happen.

Nevertheless this thread and the Bluetooth thing we had earlier this
week[1] makes me fear that this approach could lead to developer
avoiding Fixes: tags. And funny thing, that's something that is already
happening, as I noticed by chance today: "'"A "Fixes" tag has been
deliberately omitted to avoid potential test failures and subsequent
regression issues that could arise from backporting."'"[2].

I wonder if that in the long term might be bad. But well, maybe it won't
matter much. Still made me wonder if we should have a different solution
for this kind of problem. Something like this?

  Cc: <stable@vger.kernel.org> # DoNotBackport

Or something like this?

  Cc: <stable@vger.kernel.org> # DoNotBackport - or only after 16 weeks
in mainline [but I don't care]

Whatever, mainly thinking aloud and do no need a reply to this. :-D

[1]
https://lore.kernel.org/all/84da1f26-0457-451c-b4fd-128cb9bd860d@leemhuis.info/

[2] saw that today here:
https://lore.kernel.org/all/cover.1712226175.git.antony.antony@secunet.com/

>>> I'll gladly revert the above series if they shouldn't have been
>>> backported to stable, but from reading them, it seemed like they were
>>> fixing an issue that was serious and should have been added to stable,
>>> which is why they were.
>> Oh, yeah, they're fixing an issue. It's just that the issue is relatively
>> confined peformance degradation and the fix is really invasive, so not a
>> great -stable candidate. At the very least, they'd need a log longer cooking
>> time in mainline before being considered for -stable backport.
> Ok, I'll go revert them all now.  I did some test builds here with them
> reverted and they seem sane.  I'll push out some -rcs with just the
> reverts to at least fix the regressions found in the 6.8.y tree now.

Great, thx for taking care of this!

Ciao, Thorsten