linux-kernel - Re: Do we need a "DoNotBackPort" tag?

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: Thu, 4 Apr 2024 17:56:58 +0200
From: "Linux regression tracking (Thorsten Leemhuis)"
 <regressions@...mhuis.info>
To: Greg KH <gregkh@...uxfoundation.org>,
 Linux regressions mailing list <regressions@...ts.linux.dev>
Cc: Tejun Heo <tj@...nel.org>, Sasha Levin <sashal@...nel.org>,
 "stable@...r.kernel.org" <stable@...r.kernel.org>,
 LKML <linux-kernel@...r.kernel.org>
Subject: Re: Do we need a "DoNotBackPort" tag?

On 04.04.24 17:44, Greg KH wrote:
> On Thu, Apr 04, 2024 at 05:36:42PM +0200, Linux regression tracking (Thorsten Leemhuis) wrote:
>> 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@...r.kernel.org> # DoNotBackport
>>
>> Or something like this?
>>
>>   Cc: <stable@...r.kernel.org> # DoNotBackport - or only after 16 weeks
>> in mainline [but I don't care]
> 
> We do this today, with stuff like:
> 	Cc: stable <stable@...nel.org>	# wait for -rc3 to be out
> 
> So if people want to do that, they can, the documentation says that you
> can give us hints and the like in the # area, and usually we notice them :)

I know, as I wrote that (as you likely remember). ;-) But it seems it's
not well known; and maybe making it explicit that this can be used to
convey a "DoNotBackport" message is supported as well.

Guess I'll prepare a patch to do that then and we'll see how it goes
from there.

Ciao, Thorsten