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: <ZxdKwtTd7LvpieLK@infradead.org>
Date: Mon, 21 Oct 2024 23:48:34 -0700
From: Christoph Hellwig <hch@...radead.org>
To: Kees Cook <kees@...nel.org>
Cc: 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 Mon, Oct 21, 2024 at 09:54:53PM -0700, Kees Cook wrote:
> >	1. Composed of pull requests sent directly to Linus
> >
> >	2. Contains branches destined for imminent inclusion by Linus
> 
> But this means hours or a day or 2 at most.

Yeah.

> 
> >	3. Higher code quality expectation (these are pull requests that
> >	maintainers expect Linus to pull)
> 
> Are people putting things in linux-next that they don't expect to send to Linus? That seems like the greater problem.

They shouldn't.  If they do we do indeed have a problem.

> >	4. Continuous tree (not daily tags like in linux-next),
> >	facilitating easier bisection
> 
> I'm not sure how useful that is given the very small time window to find bugs.

Same.

> >The linus-next tree aims to provide a more stable and testable
> >integration point compared to linux-next,
> 
> Why not just use linux-next? I don't understand how this is any
> different except that it provides very little time to do testing and
> will need manual conflict resolutions that have already been done in
> linux-next.

Exactly!

> How about this, instead: no one sends -rc1 PRs to Linus that didn't go
> through -next. Just have a bot that replies to all PRs with a health
> check, and Linus can pull it if he thinks it looks good. 

Not just -rc1, otherwise agreed.

> For example, for a given PR, the bot can report:
> 
> - Were the patches CCed to a mailing list?
> - A histogram of how long the patches were in next (to show bake times)
> - Are any patches associated with test failures? (0day and many other
> CIs are already running tests against -next; parse those reports)
> 
> We could have a real pre-submit checker! :)

That would be very useful.  Items 1 and 2 should be trivial, 3 would
require a bit of work but would still be very useful.