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: <20241024211728.0e2304fd@rorschach.local.home>
Date: Thu, 24 Oct 2024 21:17:28 -0400
From: Steven Rostedt <rostedt@...dmis.org>
To: Luis Chamberlain <mcgrof@...nel.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, 24 Oct 2024 10:53:19 -0700
Luis Chamberlain <mcgrof@...nel.org> wrote:

> On Thu, Oct 24, 2024 at 02:49:28AM -0400, Steven Rostedt wrote:
> > Now I have to ask. What's the benefit of pushing to linux-next over
> > waiting for the zero-day bot?  
> 
> 0-day only does build tests by default, there are many places which have
> actual run time tests which *run* off of linux-next, those are both bots
> and human. Granted you can get your own run time tests out of your own
> branches but that's on each developer to set up and a developer's test
> exposure of just one branch is small compared to linux-next. For example
> I've seen obscure bugs creep up on linux-next for modules which only some
> odd arch or setup was able to capture before which no test we had during
> development was able to capture. So more exposure to system variability
> and test variability.

I have a test suite that takes 8 to 13 hours to run (depending on how
many commits I'm testing) that I run before sending to Linus or linux-next.

> 
> The other benefit is you get to see *way ahead of time* possible merge
> conflicts, and if you can coordinate with the respective maintainers
> which your code conflicts with, you can prepare so that this is smooth
> sailing upon pull request to Linus.
> 

Remember, this is talking about fixes after -rc1 not for things heading
to the merge window. I find linux-next extremely useful for that work.
But for fixes, what benefit is it to push to linux-next before sending
to Linus a fix that adds a missing mutex_unlock() in the error path?

-- Steve