From: David Howells <dhowells@redhat.com>
To: Stephen Rothwell <sfr@canb.auug.org.au>,
Masahiro Yamada <masahiroy@kernel.org>
Cc: dhowells@redhat.com, torvalds@linux-foundation.org,
linux-kbuild@vger.kernel.org,
Linux Next Mailing List <linux-next@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
"Jason A. Donenfeld" <Jason@zx2c4.com>
Subject: How should we handle a bool depending on a tristate?
Date: Mon, 18 May 2020 17:00:50 +0100 [thread overview]
Message-ID: <968394.1589817650@warthog.procyon.org.uk> (raw)
In-Reply-To: <20200518145723.65b89375@canb.auug.org.au>
Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> After merging the keys tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> x86_64-linux-gnu-ld: security/keys/big_key.o: in function `big_key_read':
> big_key.c:(.text+0x562): undefined reference to `chacha20poly1305_decrypt'
> x86_64-linux-gnu-ld: security/keys/big_key.o: in function `big_key_preparse':
> big_key.c:(.text+0x825): undefined reference to `chacha20poly1305_encrypt'
>
> Caused by commit
>
> e0a715753a88 ("security/keys: rewrite big_key crypto to use library interface")
>
> I have used the version from next-20200512 again tdoay.
Blech. Yeah. "depends on" doesn't work either. The problem actually lies
within the Kconfig framework. It doesn't know how to handle a bool depending
on a tristate.
So the issue is that with Jason's patch, we now have:
config BIG_KEYS
bool "Large payload keys"
depends on KEYS
depends on TMPFS
depends on CRYPTO_LIB_CHACHA20POLY1305
...
config CRYPTO_LIB_CHACHA20POLY1305
tristate "ChaCha20-Poly1305 AEAD support (8-byte nonce library version)"
depends on CRYPTO_ARCH_HAVE_LIB_CHACHA || !CRYPTO_ARCH_HAVE_LIB_CHACHA
depends on CRYPTO_ARCH_HAVE_LIB_POLY1305 || !CRYPTO_ARCH_HAVE_LIB_POLY1305
select CRYPTO_LIB_CHACHA
select CRYPTO_LIB_POLY1305
But you're allowed to set CONFIG_CRYPTO_LIB_CHACHA20POLY1305=m.
Using "select" instead can lead to warnings about circular dependencies and,
in any case, doesn't propagate the selection up the tree.
Also, in this case, having BIG_KEYS select everything isn't practical as
CRYPTO_LIB_CHACHA20POLY1305 has a logical-XOR in its depends on.
I think one or more of the following things need to happen:
(1) The configurator needs to give an error if it detects this.
(2) The configurator needs to propagate select rootwards.
(3) The configurator needs to propagate "=y" rootwards over depends on,
prohibiting "=m".
(4) The BIG_KEYS config needs to switch to a tristate.[*]
Do we have a preference?
David
[*] Note there have been situations where switching to a tristate isn't
technically an option because the dependency target was required during
boot (crypto used by module checking, for example), but we've just had to
work around it and hope whoever was configuring the kernel built
everything in.
next prev parent reply other threads:[~2020-05-18 16:01 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-18 4:57 linux-next: build failure after merge of the keys tree Stephen Rothwell
2020-05-18 16:00 ` David Howells [this message]
2020-05-18 16:49 ` How should we handle a bool depending on a tristate? Linus Torvalds
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=968394.1589817650@warthog.procyon.org.uk \
--to=dhowells@redhat.com \
--cc=Jason@zx2c4.com \
--cc=linux-kbuild@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-next@vger.kernel.org \
--cc=masahiroy@kernel.org \
--cc=sfr@canb.auug.org.au \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.