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: <61e62ab7-50d4-40a3-8230-9c5e6814829a@roeck-us.net>
Date: Wed, 23 Oct 2024 11:05:48 -0700
From: Guenter Roeck <linux@...ck-us.net>
To: paulmck@...nel.org, Christoph Hellwig <hch@...radead.org>
Cc: Sasha Levin <sashal@...nel.org>, Kees Cook <kees@...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 10/23/24 10:47, Paul E. McKenney wrote:
> On Tue, Oct 22, 2024 at 10:50:04PM -0700, Christoph Hellwig wrote:
>> On Tue, Oct 22, 2024 at 05:37:38AM -0400, Sasha Levin wrote:
>>> We could add a report for the above, but:
>>>
>>> 1. Linus consistently pulls patches that haven't seen the light of day.
>>> 2. Linus explicitly objected to making a linux-next a must have.
>>>
>>> So unless these results would be actually used, what's the point in
>>> writing all of that?
>>
>> Yes, without Linus caring we're not going to get our process worked out.
>> Not sure how a tree that probably won't have much better latency than
>> linux-next is going to fix that, though.
> 
> If I recall correctly, one thing Linus asked us to do earlier this year
> (ARM Summit) is to CC him on -next failures.  I have been failing to do
> this, so I will post myself a note or something to remind me.
> 
> After all, if Linus doesn't know of a problem with a set of commits,
> how does he know not to pull it?
> 

As of right now:

Build results:
	total: 158 pass: 144 fail: 14
Failed builds:
	arm:axm55xx_defconfig
	csky:defconfig
	i386:allyesconfig
	i386:allmodconfig
	microblaze:defconfig
	mips:allmodconfig
	mips:mtx1_defconfig
	mips:db1xxx_defconfig
	openrisc:allmodconfig
	parisc:allmodconfig
	parisc64:generic-64bit_defconfig
	sh:defconfig
	sh:shx3_defconfig
	xtensa:allmodconfig
Qemu test results:
	total: 556 pass: 528 fail: 28
Unit test results:
	pass: 463943 fail: 0

And that is a good day. Sometimes dozens of builds and hundreds
of boot tests fail. Analyzing those failures would be a full-time job.
Who do you expect would or should do that ?

Guenter