Since commit 37a183d3b7cdb873 ("tcp: Convert tcp-md5 to use MD5 library
instead of crypto_ahash"), TCP_SIGPOOL is only selected by TCP_AO.
However, the latter depends on 64BIT, so tcp_sigpool can no longer be
built on 32-bit platforms at all.

Improve compile coverage on 32-bit by allowing the user to enable
TCP_SIGPOOL when compile-testing.  Add a dependency on CRYPTO, which is
always fulfilled when selected by TCP_AO.

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Simon Horman <horms@kernel.org>
---
One remaining oddity is that TCP_SIGPOOL has always been a tristate
symbol, while all users that select it have always been boolean symbols.
I kept that as-is, as it builds fine as a module.

v2:
  - Add Reviewed-by.
---
 net/ipv4/Kconfig | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/net/ipv4/Kconfig b/net/ipv4/Kconfig
index b71c22475c515ffc..7280d1b1dae1ba53 100644
--- a/net/ipv4/Kconfig
+++ b/net/ipv4/Kconfig
@@ -743,7 +743,8 @@ config DEFAULT_TCP_CONG
 	default "cubic"
 
 config TCP_SIGPOOL
-	tristate
+	tristate "TCP: Per-CPU pool of crypto requests" if COMPILE_TEST
+	depends on CRYPTO
 
 config TCP_AO
 	bool "TCP: Authentication Option (RFC5925)"
-- 
2.43.0

On Thu, 15 Jan 2026 15:27:26 +0100 Geert Uytterhoeven wrote:
> Since commit 37a183d3b7cdb873 ("tcp: Convert tcp-md5 to use MD5 library
> instead of crypto_ahash"), TCP_SIGPOOL is only selected by TCP_AO.
> However, the latter depends on 64BIT, so tcp_sigpool can no longer be
> built on 32-bit platforms at all.
> 
> Improve compile coverage on 32-bit by allowing the user to enable
> TCP_SIGPOOL when compile-testing.  Add a dependency on CRYPTO, which is
> always fulfilled when selected by TCP_AO.

I don't see why we'd care. I understand COMPILE_TEST when the symbol
is narrowed down to a very unusual platform. But this is doing the
opposite, it's _adding_ a very unusual platform on which, as you say,
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).
-- 
pw-bot: cr

Hi Jakub,

On Sun, 18 Jan 2026 at 01:33, Jakub Kicinski <kuba@kernel.org> wrote:
> On Thu, 15 Jan 2026 15:27:26 +0100 Geert Uytterhoeven wrote:
> > Since commit 37a183d3b7cdb873 ("tcp: Convert tcp-md5 to use MD5 library
> > instead of crypto_ahash"), TCP_SIGPOOL is only selected by TCP_AO.
> > However, the latter depends on 64BIT, so tcp_sigpool can no longer be
> > built on 32-bit platforms at all.
> >
> > Improve compile coverage on 32-bit by allowing the user to enable
> > TCP_SIGPOOL when compile-testing.  Add a dependency on CRYPTO, which is
> > always fulfilled when selected by TCP_AO.
>
> I don't see why we'd care. I understand COMPILE_TEST when the symbol
> is narrowed down to a very unusual platform. But this is doing the
> opposite, it's _adding_ a very unusual platform on which, as you say,

(I wouldn't claim it is a "very unusual platform". 32-bit won't be dead
 for at least a decade ;-)

> 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.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

On Mon, Jan 19, 2026 at 05:26:37PM +0100, Geert Uytterhoeven wrote:
> Hi Jakub,
> 
> On Sun, 18 Jan 2026 at 01:33, Jakub Kicinski <kuba@kernel.org> wrote:
> > On Thu, 15 Jan 2026 15:27:26 +0100 Geert Uytterhoeven wrote:
> > > Since commit 37a183d3b7cdb873 ("tcp: Convert tcp-md5 to use MD5 library
> > > instead of crypto_ahash"), TCP_SIGPOOL is only selected by TCP_AO.
> > > However, the latter depends on 64BIT, so tcp_sigpool can no longer be
> > > built on 32-bit platforms at all.
> > >
> > > Improve compile coverage on 32-bit by allowing the user to enable
> > > TCP_SIGPOOL when compile-testing.  Add a dependency on CRYPTO, which is
> > > always fulfilled when selected by TCP_AO.
> >
> > I don't see why we'd care. I understand COMPILE_TEST when the symbol
> > is narrowed down to a very unusual platform. But this is doing the
> > opposite, it's _adding_ a very unusual platform on which, as you say,
> 
> (I wouldn't claim it is a "very unusual platform". 32-bit won't be dead
>  for at least a decade ;-)
> 
> > 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.

Reviewed-by: Simon Horman <horms@kernel.org>

I do notice this patch has been marked as Changes Requested in patchwork.
So maybe repost to re-activate it?

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.

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.