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: <a4d7222ddb039a03a337fcfb047f5e804bc541d4.camel@HansenPartnership.com>
Date: Tue, 22 Oct 2024 07:51:03 -0400
From: James Bottomley <James.Bottomley@...senPartnership.com>
To: 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 Tue, 2024-10-22 at 04:12 -0400, Steven Rostedt wrote:
> On Mon, 21 Oct 2024 23:48:34 -0700
> Christoph Hellwig <hch@...radead.org> wrote:
> 
> > > 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.
> 
> You mean have everything go into linux-next before going to Linus
> after -rc1?

I think that's a good goal, yes.  Most developers tend to send a fixes
pull around once a week (or less) after the merge window, which means
it could be soaked in -next.

> I'm one that doesn't do this. That's because my code in linux-next
> after -rc1 is for the next merge window, and the code I send to Linus
> is only fixes for code I sent before -rc1. I tend to keep an "urgent"
> and "core" branch. My "core" branch is everything I plan to send in
> the next merge window and goes into linux-next (via being pulled into
> my for-next branch). After I send my pull request to Linus, and he
> pulls it in the merge window, that "core" branch becomes my "urgent"
> branch.
> 
> But when I find a bug that's in Linus's tree, I put the fix on top of
> "urgent", run it through my test suite (takes 8 hours or so), then
> send a pull request to Linus. My "urgent" branch doesn't go into
> linux-next as it doesn't have changes that should affect others work,
> which is what I think linux-next is mostly for.

That's not necessarily a safe assumption.  The reason we put scsi-fixes
into -next is precisely to pick up if this happens.  I admit it happens
very rarely because of the compact and local nature of the fixes, but
the signal rate isn't zero.

>  I also find known bugs in Linus's tree to be high priority to be
> fixed (I stop what I'm doing to get the fix out ASAP).
> 
> Now, if there was better testing from linux-next, maybe it would be
> worth the time to push my urgent branch there for a bit. But so far I
> haven't seen the benefit of doing that.

It does at least get 0day running over it, although that can also be
configured for your branches separately as well.  It's also not unwise
to have some pause time before fixing and sending ... the fix you first
thought of isn't always the best one (or even sometimes an actual fix).

Regards,

James