mainline build failure due to 8bdc2a190105 ("crypto: poly1305 - cleanup stray CRYPTO_LIB_POLY1305_RSIZE")

Hi All,

The latest mainline kernel branch fails to build for:

arm: imx_v6_v7_defconfig and multi_v7_defconfig
mips: decstation_64_defconfig, decstation_defconfig, decstation_r4k_defconfig

with errors like:

In file included from crypto/chacha20poly1305.c:13:
./include/crypto/poly1305.h:56:46: error: 'CONFIG_CRYPTO_LIB_POLY1305_RSIZE' undeclared here (not in a function); did you mean 'CONFIG_CRYPTO_POLY1305_MODULE'?

   56 |                 struct poly1305_key opaque_r[CONFIG_CRYPTO_LIB_POLY1305_RSIZE];
      |                                              ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

git bisect pointed to 8bdc2a190105 ("crypto: poly1305 - cleanup stray CRYPTO_LIB_POLY1305_RSIZE")

I have checked .config to confirm that it contains:

CONFIG_CRYPTO_CHACHA20POLY1305=m
# CONFIG_CRYPTO_LIB_POLY1305 is not set

so, CONFIG_CRYPTO_LIB_POLY1305_RSIZE will not be defined as it now depends on CONFIG_CRYPTO_LIB_POLY1305.

--
Regards
Sudip

Hi Sudip,

Indeed. There's this v2:
https://lore.kernel.org/all/[email protected]/

I'll send a v1/v2 interdiff shortly.

Jason

Hi again,

Actually, I think 8bdc2a190105 should just be reverted wholesale. There are too many headers that depend on it (e.g. caam) even if there's no .o that winds up using it. I could try to enumerate them all in kconfig language, but that doesn't seem much cleaner.

[Aside: note that none of this was a problem with my proposed "zinc" patchset from a few years ago, which cleaned up all this crypto layer stuff. The frankenstein that landed instead is just a never ending source of annoying bugs like this one. Until there are larger changes, I think a lot of the woes of crypto/ are terminally hopeless. :-\]

Jason

This reverts commit 8bdc2a190105e862dfe7a4033f2fd385b7e58ae8.

It got merged a bit prematurely and shortly after the kernel test robot and Sudip pointed out build failures.

We could attempt to fix this by listing the dependencies piecemeal, but it's not as obvious as it looks: drivers like caam use this macro in headers even if there's no .o compiled in that makes use of it. So actually fixing this might require a bit more of a comprehensive approach, rather than whack-a-mole with hunting down which drivers use which headers which use this macro.

Therefore, this commit just reverts the change, and maybe the problem can be visited on the next rainy day.

---
 lib/crypto/Kconfig | 1 -
 1 file changed, 1 deletion(-)

index a143ddf9279a..9856e291f414 100644
@@ -85,7 +85,6 @@ config CRYPTO_LIB_POLY1305_RSIZE
 	default 11 if X86_64
 	default 9 if ARM || ARM64
 	default 1
-	depends on CRYPTO_LIB_POLY1305
 
 config CRYPTO_ARCH_HAVE_LIB_POLY1305
 	tristate

2.35.1