linux-kernel - Re: [Ksummit-2013-discuss] When to push bug fixes to mainline

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] [day] [month] [year] [list]

Date:	Fri, 19 Jul 2013 12:13:30 +0200
From:	Ingo Molnar <mingo@...nel.org>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	"Luck, Tony" <tony.luck@...el.com>,
	Mark Brown <broonie@...nel.org>, Takashi Iwai <tiwai@...e.de>,
	David Lang <david@...g.hm>,
	"ksummit-2013-discuss@...ts.linux-foundation.org" 
	<ksummit-2013-discuss@...ts.linux-foundation.org>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"stable@...r.kernel.org" <stable@...r.kernel.org>,
	Willy Tarreau <w@....eu>
Subject: Re: [Ksummit-2013-discuss] When to push bug fixes to mainline


* Linus Torvalds <torvalds@...ux-foundation.org> wrote:

> [...]
> 
> Anyway, the point I'm making is that Q&A is limited and often even 
> actively misleading ("Hey, I have three tested-by's, so it must be 
> fine"), and we might actually want to have a new class of "non-critical 
> patch that might be worth backporting to stable, but only do so after 
> it's been in a release for some time". Because while it might be an 
> "obvious" fix, maybe it's not critical enough that it needs to be 
> backported _now_ - maybe it could wait a month or two, and get wider 
> testing.

The way I typically mark those kinds of fixes is that I don't add a 
stable@...r.kernel.org tag to the commit and wait for explicit complaints 
to come up. I also sometimes remove -stable backport tags from fix 
submissions.

Requests for backports will arrive with a time delay (if at all), which 
gives the perfect opportunity to review its upstream status (whether there 
are followup problems with the patch, etc.) and forward the commit to 
-stable, at which point it's already been upstream for a couple of weeks, 
sometimes months.

I don't think this scenario needs to be or can be automated via a special 
tag: the main problem is that when the fix is applied we rarely know how 
widely users care about it. I think dealing with them 'statistically' 
(i.e. waiting for a backport request) measures that property pretty 
accurately.

The nice thing about it is that it all self-balances if people just add 
-stable backport tags more judiciously.

Thanks,

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/