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: <20241024211149.4f0b6138@rorschach.local.home>
Date: Thu, 24 Oct 2024 21:11:49 -0400
From: Steven Rostedt <rostedt@...dmis.org>
To: Guenter Roeck <linux@...ck-us.net>
Cc: 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 07:39:00 -0700
Guenter Roeck <linux@...ck-us.net> wrote:

> > 
> > Now I have to ask. What's the benefit of pushing to linux-next over
> > waiting for the zero-day bot?
> >   
> 
> I push my changes into the same branches that are checked by 0-day
> and pulled into linux-next. linux-next shows interference with other
> branches. Once in a while I do get a notification telling me that
> one or more of the patches interfere with other patches, so I know that
> something happened, and I can prepare for that for the next commit window.

Remember, this is about pushing to linux-next before sending fixes
after -rc1. Not for things that are going to land in the next merge
window. My fixes seldom ever interfere with others work as it's usually
much more focused on code that is already in Linus's tree. Like adding
a missing mutex_unlock() from an error path. How is it helpful to push
something like that to linux-next?

> 
> Testing-wise, I do run build and boot tests on linux-next (the same tests
> as those running on release candidates), so I do know what is wrong there
> and (which did happen a couple of times) if a patch in one of my trees
> is responsible.
> 
> Yes, that means that in many cases I do know ahead of time which problems
> are going to pop up in the mainline kernel. But I don't have the time
> tracking those down when seen in linux-next - there are just too many
> and, as already mentioned, that would be a full-time job on its own.
> Also, it happens a lot that they have been reported but the report was
> ignored or missed. On top of that I found that _if_ I am reporting them,
> the receiving side is at least sometimes either not responsive to almost
> abusive, so for the most part I gave up on it (and frankly I found that
> people tend to be _much_ more responsive if one Linus Torvalds is listed
> in Cc:).
> 
> 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?

-- Steve