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] [day] [month] [year] [list]
Message-ID: <aXHcZu0EK4THCix-@horms.kernel.org>
Date: Thu, 22 Jan 2026 08:14:30 +0000
From: Simon Horman <horms@...nel.org>
To: Jakub Kicinski <kuba@...nel.org>
Cc: Geert Uytterhoeven <geert@...ux-m68k.org>,
	"David S. Miller" <davem@...emloft.net>,
	David Ahern <dsahern@...nel.org>,
	Eric Dumazet <edumazet@...gle.com>, Paolo Abeni <pabeni@...hat.com>,
	netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH net-next v2] net/tcp_sigpool: Enable compile-testing

On Wed, Jan 21, 2026 at 05:28:28PM -0800, Jakub Kicinski wrote:
> On Wed, 21 Jan 2026 19:55:38 +0000 Simon Horman wrote:
> > On Mon, Jan 19, 2026 at 05:26:37PM +0100, Geert Uytterhoeven wrote:
> > > > this code cannot be used today. If this code regresses and someone
> > > > wants to start using it on 32b they'll have to fix it.
> > > >
> > > > Please LMK if I'm misunderstanding or there's another argument (not
> > > > mentioned in the commit message).  
> > > 
> > > In general, we want to be able to test-compile as much code as possible
> > > on all platforms, but not bother everyone who configures and builds a
> > > kernel for his system.  Until commit 37a183d3b7cdb873, that included
> > > the tcp_sigpool code, and any build regressions would be caught soon,
> > > and fixed (presumably).  Of course that still doesn't guarantee the
> > > code would actually work on 32-bit, but successful compilation is a
> > > first step...
> > > 
> > > As the maintainer, the decision is yours, though.  
> > 
> > Thanks Geert,
> > 
> > In my understanding COMPILE_TEST is about expanding compile-test coverage,
> > and that is what this patch does.
> 
> Mine is that the goal of COMPILE_TEST is to make hard to reach but
> *reachable* configurations. Canonical example a driver which can
> only be useful on a single SOC may be hiding under that SOCs configs
> but we don't want allconfig to miss it. Or randconfig to struggle
> to each it.
> 
> If we change a core API we want to be able to build all the drivers
> that it may break.
> 
> Here the situation is different, this code is already reachable by
> allmodconfig. The patch makes it also build for what I referred to
> as very unusual and Geert as "on't be dead for at least a decade"
> platforms.. But crucially the code currently _never_ builds for 
> those platforms.
> 
> Please don't repost this.

Let us agree to disagree on the intention of COMPILE_TEST.
And let this thread rest.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ