linux-kernel - Re: linus-next: improving functional testing for to-be-merged pull requests

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]

Message-ID: <80e26ac9-2829-44c1-a562-d80ed9d559e0@paulmck-laptop>
Date: Fri, 25 Oct 2024 10:23:36 -0700
From: "Paul E. McKenney" <paulmck@...nel.org>
To: Steven Rostedt <rostedt@...dmis.org>
Cc: Guenter Roeck <linux@...ck-us.net>,
	Michael Ellerman <mpe@...erman.id.au>,
	Geert Uytterhoeven <geert@...ux-m68k.org>,
	Christoph Hellwig <hch@...radead.org>, Kees Cook <kees@...nel.org>,
	Sasha Levin <sashal@...nel.org>, torvalds@...ux-foundation.org,
	ksummit@...ts.linux.dev, linux-kernel@...r.kernel.org
Subject: Re: linus-next: improving functional testing for to-be-merged pull
 requests

On Thu, Oct 24, 2024 at 09:11:49PM -0400, Steven Rostedt wrote:
> On Thu, 24 Oct 2024 07:39:00 -0700
> Guenter Roeck <linux@...ck-us.net> wrote:

[ . . . ]

> > Note that I do collect known fixes in my 'fixes' and 'testing' branches,
> > primarily to have something clean available to keep testing. Linus even
> > pulled my fixes branch once directly because the responsible maintainers
> > didn't send pull requests to him for weeks.
> 
> Or are you saying that it's helpful to "fix" linux-next before fixing
> Linus's tree? That way others will have the fixes too?

It is a risk-management issue, and so the answer will vary depending on
the situation.

For one extreme, if the fix is a regression, but the bug is an odd corner
case that is unlikely to be triggered, then it is very helpful to run
it through 0day and -next before sending the pull request to Linus.
This is because the delay won't inconvenient many people, if any, and
0day and -next can help catch any bugs introduced by the fix.

At the other extreme, if the fix is for a regression that (say) bricks
50% of the systems out there, clearly speed is of the essence.  And let's
face it, in this case, Linus might well just apply your initial patch.
Which would expose it to both 0day and -next.

But!!!  In this case, I sure would hope that there would then be some
serious follow up to fix the bug in the validation, which clearly failed
to catch a very ugly bug.

							Thanx, Paul