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: <0cf2898d-da29-470d-9b26-ff5f85ccd437@leemhuis.info>
Date: Wed, 23 Oct 2024 12:18:28 +0200
From: Thorsten Leemhuis <linux@...mhuis.info>
To: Vlastimil Babka <vbabka@...e.cz>, Steven Rostedt <rostedt@...dmis.org>,
 Christoph Hellwig <hch@...radead.org>
Cc: 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 23.10.24 11:32, Vlastimil Babka wrote:
> On 10/23/24 10:20, Steven Rostedt wrote:
>> To put it this way. The bugs I'm fixing was for code in linux-next
>> where the bugs were never found. They only appeared when they went into
>> Linus's tree. So why put the fixes in linux-next, if it didn't catch
>> the bugs I fixed in the first place?
> 
> The fix might be in a different part of the code, one that's stressed by
> -next testing even if the code with the original bug wasn't. So I don't
> think you can always assume that -next not catching the original bug means
> it can't catch a bug in the fix?

+1 to this and the "compile failures on obscure architectures or
configs" from Geert.

A -fixes branch in -next also makes a few things easier for regression
tracking:

* I only have to check *one* place instead of one or two hundred to see
if a regression fix is heading towards mainline or stuck somewhere.

* I can see if people accidentally queued regression fix for the current
or the next cycle when it should be the former (some subsystems make
this hard or impossible).

Ciao, Thorsten

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ