* linux-next: build failure after merge of the keys tree
@ 2020-05-18 4:57 Stephen Rothwell
2020-05-18 16:00 ` How should we handle a bool depending on a tristate? David Howells
0 siblings, 1 reply; 31+ messages in thread
From: Stephen Rothwell @ 2020-05-18 4:57 UTC (permalink / raw)
To: David Howells
Cc: Linux Next Mailing List, Linux Kernel Mailing List, Jason A. Donenfeld
[-- Attachment #1: Type: text/plain, Size: 613 bytes --]
Hi all,
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.
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 31+ messages in thread* How should we handle a bool depending on a tristate?
2020-05-18 4:57 linux-next: build failure after merge of the keys tree Stephen Rothwell
@ 2020-05-18 16:00 ` David Howells
2020-05-18 16:49 ` Linus Torvalds
0 siblings, 1 reply; 31+ messages in thread
From: David Howells @ 2020-05-18 16:00 UTC (permalink / raw)
To: Stephen Rothwell, Masahiro Yamada
Cc: dhowells, torvalds, linux-kbuild, Linux Next Mailing List,
Linux Kernel Mailing List, Jason A. Donenfeld
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.
^ permalink raw reply [flat|nested] 31+ messages in thread* Re: How should we handle a bool depending on a tristate?
2020-05-18 16:00 ` How should we handle a bool depending on a tristate? David Howells
@ 2020-05-18 16:49 ` Linus Torvalds
0 siblings, 0 replies; 31+ messages in thread
From: Linus Torvalds @ 2020-05-18 16:49 UTC (permalink / raw)
To: David Howells
Cc: Stephen Rothwell, Masahiro Yamada, Linux Kbuild mailing list,
Linux Next Mailing List, Linux Kernel Mailing List,
Jason A. Donenfeld
On Mon, May 18, 2020 at 9:01 AM David Howells <dhowells@redhat.com> wrote:
>
>
> 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.
No problem with Kconfig. It knows exactly how to let a bool depend on
a tristate.
It's just that there are two different kinds of dependencies.
For example, the dependency can be a hard and absolute dependency
(linking doesn't work, or whatever), and then obviously built-in code
cannot be enabled if the thing it depends on is a loadable module.
But the dependency can also be a conceptual one: "This option doesn't
make sense unless that option is set". Then a bool can make sense even
if the other config is a modular one.
And Kconfig can deal with either situation just fine.
Do
depends on XYZ = y
or
depends on XYZ != n
to clarify the choice. One requires a hard dependency, the other
requires that the option just be enabled.
Now, if you just do "depends on XYZ", it allows a bool to be enabled
even for just a module (ie that second case). That makes sense for a
lot of "allow this feature in the module" kind of options, where it
would be pointless to even ask about a boolean feature if the parent
module isn't even enabled.
But that "depends on XYZ=y" is not uncommon. It basically says "this
option makes sense only when built in". Either because it requires it
for linking, or just because it doesn't work or make sense without it.
Linus
^ permalink raw reply [flat|nested] 31+ messages in thread
* linux-next: build failure after merge of the keys tree
@ 2020-12-11 4:50 Stephen Rothwell
0 siblings, 0 replies; 31+ messages in thread
From: Stephen Rothwell @ 2020-12-11 4:50 UTC (permalink / raw)
To: David Howells; +Cc: Linux Kernel Mailing List, Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 3073 bytes --]
Hi all,
After merging the keys tree, today's linux-next build (x86_64
allmodconfig) failed like this:
In file included from include/linux/cred.h:13,
from security/integrity/ima/ima_mok.c:12:
security/integrity/ima/ima_mok.c: In function 'ima_mok_init':
include/linux/key.h:292:29: warning: passing argument 7 of 'keyring_alloc' makes pointer from integer without a cast [-Wint-conversion]
292 | #define KEY_ALLOC_SET_KEEP 0x0020 /* Set the KEEP flag on the key/keyring */
| ^~~~~~
| |
| int
security/integrity/ima/ima_mok.c:42:5: note: in expansion of macro 'KEY_ALLOC_SET_KEEP'
42 | KEY_ALLOC_SET_KEEP,
| ^~~~~~~~~~~~~~~~~~
include/linux/key.h:410:30: note: expected 'struct key_restriction *' but argument is of type 'int'
410 | struct key_restriction *restrict_link,
| ~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~
security/integrity/ima/ima_mok.c:43:5: error: passing argument 8 of 'keyring_alloc' from incompatible pointer type [-Werror=incompatible-pointer-types]
43 | restriction, NULL);
| ^~~~~~~~~~~
| |
| struct key_restriction *
In file included from include/linux/cred.h:13,
from security/integrity/ima/ima_mok.c:12:
include/linux/key.h:411:18: note: expected 'struct key *' but argument is of type 'struct key_restriction *'
411 | struct key *dest);
| ~~~~~~~~~~~~^~~~
security/integrity/ima/ima_mok.c:36:26: error: too many arguments to function 'keyring_alloc'
36 | ima_blacklist_keyring = keyring_alloc(".ima_blacklist",
| ^~~~~~~~~~~~~
In file included from include/linux/cred.h:13,
from security/integrity/ima/ima_mok.c:12:
include/linux/key.h:406:20: note: declared here
406 | extern struct key *keyring_alloc(const char *description, kuid_t uid, kgid_t gid,
| ^~~~~~~~~~~~~
Caused by commit
33c36b2053de ("certs: Fix blacklist flag type confusion")
I have applied the following fix patch for today:
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Fri, 11 Dec 2020 15:46:09 +1100
Subject: [PATCH] fixup for "certs: Fix blacklist flag type confusion"
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
security/integrity/ima/ima_mok.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/security/integrity/ima/ima_mok.c b/security/integrity/ima/ima_mok.c
index ce8871d96f12..5594dd38ab04 100644
--- a/security/integrity/ima/ima_mok.c
+++ b/security/integrity/ima/ima_mok.c
@@ -38,8 +38,7 @@ __init int ima_mok_init(void)
(KEY_POS_ALL & ~KEY_POS_SETATTR) |
KEY_USR_VIEW | KEY_USR_READ |
KEY_USR_WRITE | KEY_USR_SEARCH,
- KEY_ALLOC_NOT_IN_QUOTA,
- KEY_ALLOC_SET_KEEP,
+ KEY_ALLOC_NOT_IN_QUOTA | KEY_ALLOC_SET_KEEP,
restriction, NULL);
if (IS_ERR(ima_blacklist_keyring))
--
2.29.2
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply related [flat|nested] 31+ messages in thread* linux-next: build failure after merge of the keys tree
@ 2020-05-14 4:30 Stephen Rothwell
2020-05-14 4:46 ` Jason A. Donenfeld
2020-05-14 12:11 ` David Howells
0 siblings, 2 replies; 31+ messages in thread
From: Stephen Rothwell @ 2020-05-14 4:30 UTC (permalink / raw)
To: David Howells
Cc: Linux Next Mailing List, Linux Kernel Mailing List, Jason A. Donenfeld
[-- Attachment #1: Type: text/plain, Size: 5914 bytes --]
Hi all,
After merging the keys tree, today's linux-next build (x86_64
allmodconfig) failed like this:
WARNING: unmet direct dependencies detected for CRYPTO_LIB_CHACHA20POLY1305
Depends on [m]: CRYPTO [=y] && (CRYPTO_ARCH_HAVE_LIB_CHACHA [=m] || !CRYPTO_ARCH_HAVE_LIB_CHACHA [=m]) && (CRYPTO_ARCH_HAVE_LIB_POLY1305 [=m] || !CRYPTO_ARCH_HAVE_LIB_POLY1305 [=m])
Selected by [y]:
- BIG_KEYS [=y] && KEYS [=y] && TMPFS [=y]
Selected by [m]:
- WIREGUARD [=m] && NETDEVICES [=y] && NET_CORE [=y] && NET [=y] && INET [=y] && (IPV6 [=y] || !IPV6 [=y])
WARNING: unmet direct dependencies detected for CRYPTO_LIB_CHACHA20POLY1305
Depends on [m]: CRYPTO [=y] && (CRYPTO_ARCH_HAVE_LIB_CHACHA [=m] || !CRYPTO_ARCH_HAVE_LIB_CHACHA [=m]) && (CRYPTO_ARCH_HAVE_LIB_POLY1305 [=m] || !CRYPTO_ARCH_HAVE_LIB_POLY1305 [=m])
Selected by [y]:
- BIG_KEYS [=y] && KEYS [=y] && TMPFS [=y]
Selected by [m]:
- WIREGUARD [=m] && NETDEVICES [=y] && NET_CORE [=y] && NET [=y] && INET [=y] && (IPV6 [=y] || !IPV6 [=y])
WARNING: unmet direct dependencies detected for CRYPTO_LIB_CHACHA20POLY1305
Depends on [m]: CRYPTO [=y] && (CRYPTO_ARCH_HAVE_LIB_CHACHA [=m] || !CRYPTO_ARCH_HAVE_LIB_CHACHA [=m]) && (CRYPTO_ARCH_HAVE_LIB_POLY1305 [=m] || !CRYPTO_ARCH_HAVE_LIB_POLY1305 [=m])
Selected by [y]:
- BIG_KEYS [=y] && KEYS [=y] && TMPFS [=y]
Selected by [m]:
- WIREGUARD [=m] && NETDEVICES [=y] && NET_CORE [=y] && NET [=y] && INET [=y] && (IPV6 [=y] || !IPV6 [=y])
x86_64-linux-gnu-ld: lib/crypto/chacha20poly1305.o: in function `xchacha_init':
chacha20poly1305.c:(.text+0x12d): undefined reference to `chacha_init_arch'
x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0x13d): undefined reference to `hchacha_block_arch'
x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0x14b): undefined reference to `chacha_init_arch'
x86_64-linux-gnu-ld: lib/crypto/chacha20poly1305.o: in function `__chacha20poly1305_encrypt':
chacha20poly1305.c:(.text+0x2ab): undefined reference to `chacha_crypt_arch'
x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0x2bd): undefined reference to `poly1305_init_arch'
x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0x2d6): undefined reference to `poly1305_update_arch'
x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0x317): undefined reference to `chacha_crypt_arch'
x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0x32d): undefined reference to `poly1305_update_arch'
x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0x379): undefined reference to `poly1305_update_arch'
x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0x385): undefined reference to `poly1305_final_arch'
x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0x413): undefined reference to `poly1305_update_arch'
x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0x434): undefined reference to `poly1305_update_arch'
x86_64-linux-gnu-ld: lib/crypto/chacha20poly1305.o: in function `chacha20poly1305_encrypt':
(.text+0x59d): undefined reference to `chacha_init_arch'
x86_64-linux-gnu-ld: lib/crypto/chacha20poly1305.o: in function `__chacha20poly1305_decrypt':
chacha20poly1305.c:(.text+0x847): undefined reference to `chacha_crypt_arch'
x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0x859): undefined reference to `poly1305_init_arch'
x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0x86d): undefined reference to `poly1305_update_arch'
x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0x8a7): undefined reference to `poly1305_update_arch'
x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0x8f1): undefined reference to `poly1305_update_arch'
x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0x8fc): undefined reference to `poly1305_final_arch'
x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0x94f): undefined reference to `chacha_crypt_arch'
x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0x9d9): undefined reference to `poly1305_update_arch'
x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0x9f9): undefined reference to `poly1305_update_arch'
x86_64-linux-gnu-ld: lib/crypto/chacha20poly1305.o: in function `chacha20poly1305_decrypt':
(.text+0xb78): undefined reference to `chacha_init_arch'
x86_64-linux-gnu-ld: lib/crypto/chacha20poly1305.o: in function `chacha20poly1305_crypt_sg_inplace':
chacha20poly1305.c:(.text+0xf16): undefined reference to `chacha_init_arch'
x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0xf3b): undefined reference to `chacha_crypt_arch'
x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0xf50): undefined reference to `poly1305_init_arch'
x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0x1094): undefined reference to `chacha_crypt_arch'
x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0x1155): undefined reference to `poly1305_update_arch'
x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0x117b): undefined reference to `poly1305_update_arch'
x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0x11da): undefined reference to `poly1305_update_arch'
x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0x1223): undefined reference to `poly1305_final_arch'
x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0x1321): undefined reference to `chacha_crypt_arch'
x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0x1401): undefined reference to `poly1305_final_arch'
x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0x14a3): undefined reference to `poly1305_update_arch'
x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0x14d6): undefined reference to `poly1305_update_arch'
x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0x1507): undefined reference to `poly1305_update_arch'
x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0x1573): undefined reference to `poly1305_update_arch'
x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0x15aa): undefined reference to `poly1305_final_arch'
Caused by commit
f22998a0de8a ("security/keys: rewrite big_key crypto to use library interface")
I have used the keys tree from next-20200512 for today.
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 31+ messages in thread* Re: linux-next: build failure after merge of the keys tree
2020-05-14 4:30 Stephen Rothwell
@ 2020-05-14 4:46 ` Jason A. Donenfeld
2020-05-14 12:11 ` David Howells
1 sibling, 0 replies; 31+ messages in thread
From: Jason A. Donenfeld @ 2020-05-14 4:46 UTC (permalink / raw)
To: Stephen Rothwell, Masahiro Yamada
Cc: David Howells, Linux Next Mailing List, Linux Kernel Mailing List
Hey Masahiro,
Your touch might be helpful here. CRYPTO_LIB_CHACHA20POLY1305 is a
tristate and depends on as well as selects other things that are
tristates.
Meanwhile BIG_KEYS is a bool, which needs to select
CRYPTO_LIB_CHACHA20POLY1305. However, it gets antsy if the the symbol
its selecting has =m items in its hierarchy.
Any suggestions? The ideal thing to happen would be that the select of
CRYPTO_LIB_CHACHA20POLY1305 in BIG_KEYS causes all of the descendants
to become =y too.
Jason
On Wed, May 13, 2020 at 10:31 PM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Hi all,
>
> After merging the keys tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> WARNING: unmet direct dependencies detected for CRYPTO_LIB_CHACHA20POLY1305
> Depends on [m]: CRYPTO [=y] && (CRYPTO_ARCH_HAVE_LIB_CHACHA [=m] || !CRYPTO_ARCH_HAVE_LIB_CHACHA [=m]) && (CRYPTO_ARCH_HAVE_LIB_POLY1305 [=m] || !CRYPTO_ARCH_HAVE_LIB_POLY1305 [=m])
> Selected by [y]:
> - BIG_KEYS [=y] && KEYS [=y] && TMPFS [=y]
> Selected by [m]:
> - WIREGUARD [=m] && NETDEVICES [=y] && NET_CORE [=y] && NET [=y] && INET [=y] && (IPV6 [=y] || !IPV6 [=y])
>
> WARNING: unmet direct dependencies detected for CRYPTO_LIB_CHACHA20POLY1305
> Depends on [m]: CRYPTO [=y] && (CRYPTO_ARCH_HAVE_LIB_CHACHA [=m] || !CRYPTO_ARCH_HAVE_LIB_CHACHA [=m]) && (CRYPTO_ARCH_HAVE_LIB_POLY1305 [=m] || !CRYPTO_ARCH_HAVE_LIB_POLY1305 [=m])
> Selected by [y]:
> - BIG_KEYS [=y] && KEYS [=y] && TMPFS [=y]
> Selected by [m]:
> - WIREGUARD [=m] && NETDEVICES [=y] && NET_CORE [=y] && NET [=y] && INET [=y] && (IPV6 [=y] || !IPV6 [=y])
>
> WARNING: unmet direct dependencies detected for CRYPTO_LIB_CHACHA20POLY1305
> Depends on [m]: CRYPTO [=y] && (CRYPTO_ARCH_HAVE_LIB_CHACHA [=m] || !CRYPTO_ARCH_HAVE_LIB_CHACHA [=m]) && (CRYPTO_ARCH_HAVE_LIB_POLY1305 [=m] || !CRYPTO_ARCH_HAVE_LIB_POLY1305 [=m])
> Selected by [y]:
> - BIG_KEYS [=y] && KEYS [=y] && TMPFS [=y]
> Selected by [m]:
> - WIREGUARD [=m] && NETDEVICES [=y] && NET_CORE [=y] && NET [=y] && INET [=y] && (IPV6 [=y] || !IPV6 [=y])
> x86_64-linux-gnu-ld: lib/crypto/chacha20poly1305.o: in function `xchacha_init':
> chacha20poly1305.c:(.text+0x12d): undefined reference to `chacha_init_arch'
> x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0x13d): undefined reference to `hchacha_block_arch'
> x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0x14b): undefined reference to `chacha_init_arch'
> x86_64-linux-gnu-ld: lib/crypto/chacha20poly1305.o: in function `__chacha20poly1305_encrypt':
> chacha20poly1305.c:(.text+0x2ab): undefined reference to `chacha_crypt_arch'
> x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0x2bd): undefined reference to `poly1305_init_arch'
> x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0x2d6): undefined reference to `poly1305_update_arch'
> x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0x317): undefined reference to `chacha_crypt_arch'
> x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0x32d): undefined reference to `poly1305_update_arch'
> x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0x379): undefined reference to `poly1305_update_arch'
> x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0x385): undefined reference to `poly1305_final_arch'
> x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0x413): undefined reference to `poly1305_update_arch'
> x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0x434): undefined reference to `poly1305_update_arch'
> x86_64-linux-gnu-ld: lib/crypto/chacha20poly1305.o: in function `chacha20poly1305_encrypt':
> (.text+0x59d): undefined reference to `chacha_init_arch'
> x86_64-linux-gnu-ld: lib/crypto/chacha20poly1305.o: in function `__chacha20poly1305_decrypt':
> chacha20poly1305.c:(.text+0x847): undefined reference to `chacha_crypt_arch'
> x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0x859): undefined reference to `poly1305_init_arch'
> x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0x86d): undefined reference to `poly1305_update_arch'
> x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0x8a7): undefined reference to `poly1305_update_arch'
> x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0x8f1): undefined reference to `poly1305_update_arch'
> x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0x8fc): undefined reference to `poly1305_final_arch'
> x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0x94f): undefined reference to `chacha_crypt_arch'
> x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0x9d9): undefined reference to `poly1305_update_arch'
> x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0x9f9): undefined reference to `poly1305_update_arch'
> x86_64-linux-gnu-ld: lib/crypto/chacha20poly1305.o: in function `chacha20poly1305_decrypt':
> (.text+0xb78): undefined reference to `chacha_init_arch'
> x86_64-linux-gnu-ld: lib/crypto/chacha20poly1305.o: in function `chacha20poly1305_crypt_sg_inplace':
> chacha20poly1305.c:(.text+0xf16): undefined reference to `chacha_init_arch'
> x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0xf3b): undefined reference to `chacha_crypt_arch'
> x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0xf50): undefined reference to `poly1305_init_arch'
> x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0x1094): undefined reference to `chacha_crypt_arch'
> x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0x1155): undefined reference to `poly1305_update_arch'
> x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0x117b): undefined reference to `poly1305_update_arch'
> x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0x11da): undefined reference to `poly1305_update_arch'
> x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0x1223): undefined reference to `poly1305_final_arch'
> x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0x1321): undefined reference to `chacha_crypt_arch'
> x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0x1401): undefined reference to `poly1305_final_arch'
> x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0x14a3): undefined reference to `poly1305_update_arch'
> x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0x14d6): undefined reference to `poly1305_update_arch'
> x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0x1507): undefined reference to `poly1305_update_arch'
> x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0x1573): undefined reference to `poly1305_update_arch'
> x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0x15aa): undefined reference to `poly1305_final_arch'
>
> Caused by commit
>
> f22998a0de8a ("security/keys: rewrite big_key crypto to use library interface")
>
> I have used the keys tree from next-20200512 for today.
>
> --
> Cheers,
> Stephen Rothwell
^ permalink raw reply [flat|nested] 31+ messages in thread* Re: linux-next: build failure after merge of the keys tree
2020-05-14 4:30 Stephen Rothwell
2020-05-14 4:46 ` Jason A. Donenfeld
@ 2020-05-14 12:11 ` David Howells
2020-05-14 12:34 ` Masahiro Yamada
1 sibling, 1 reply; 31+ messages in thread
From: David Howells @ 2020-05-14 12:11 UTC (permalink / raw)
To: Jason A. Donenfeld
Cc: dhowells, Stephen Rothwell, Masahiro Yamada,
Linux Next Mailing List, Linux Kernel Mailing List
Jason A. Donenfeld <Jason@zx2c4.com> wrote:
> Your touch might be helpful here. CRYPTO_LIB_CHACHA20POLY1305 is a
> tristate and depends on as well as selects other things that are
> tristates.
>
> Meanwhile BIG_KEYS is a bool, which needs to select
> CRYPTO_LIB_CHACHA20POLY1305. However, it gets antsy if the the symbol
> its selecting has =m items in its hierarchy.
>
> Any suggestions? The ideal thing to happen would be that the select of
> CRYPTO_LIB_CHACHA20POLY1305 in BIG_KEYS causes all of the descendants
> to become =y too.
I think that select is broken in its behaviour - it doesn't propagate the
selection enforcement up the tree. You could try changing it to a depends on
or you could put in a select for every dependency. I'm not sure there are any
other options - unless we turn big_key into a module and institute autoloading
of keytypes on demand.
David
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: linux-next: build failure after merge of the keys tree
2020-05-14 12:11 ` David Howells
@ 2020-05-14 12:34 ` Masahiro Yamada
2020-05-14 23:25 ` Jason A. Donenfeld
0 siblings, 1 reply; 31+ messages in thread
From: Masahiro Yamada @ 2020-05-14 12:34 UTC (permalink / raw)
To: David Howells
Cc: Jason A. Donenfeld, Stephen Rothwell, Linux Next Mailing List,
Linux Kernel Mailing List
On Thu, May 14, 2020 at 9:11 PM David Howells <dhowells@redhat.com> wrote:
>
> Jason A. Donenfeld <Jason@zx2c4.com> wrote:
>
> > Your touch might be helpful here. CRYPTO_LIB_CHACHA20POLY1305 is a
> > tristate and depends on as well as selects other things that are
> > tristates.
> >
> > Meanwhile BIG_KEYS is a bool, which needs to select
> > CRYPTO_LIB_CHACHA20POLY1305. However, it gets antsy if the the symbol
> > its selecting has =m items in its hierarchy.
> >
> > Any suggestions? The ideal thing to happen would be that the select of
> > CRYPTO_LIB_CHACHA20POLY1305 in BIG_KEYS causes all of the descendants
> > to become =y too.
>
> I think that select is broken in its behaviour - it doesn't propagate the
> selection enforcement up the tree. You could try changing it to a depends on
> or you could put in a select for every dependency.
I agree.
'depends on' will be cleaner.
> I'm not sure there are any
> other options - unless we turn big_key into a module and institute autoloading
> of keytypes on demand.
>
> David
>
--
Best Regards
Masahiro Yamada
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: linux-next: build failure after merge of the keys tree
2020-05-14 12:34 ` Masahiro Yamada
@ 2020-05-14 23:25 ` Jason A. Donenfeld
0 siblings, 0 replies; 31+ messages in thread
From: Jason A. Donenfeld @ 2020-05-14 23:25 UTC (permalink / raw)
To: Masahiro Yamada
Cc: David Howells, Stephen Rothwell, Linux Next Mailing List,
Linux Kernel Mailing List
On Thu, May 14, 2020 at 6:35 AM Masahiro Yamada <masahiroy@kernel.org> wrote:
>
> On Thu, May 14, 2020 at 9:11 PM David Howells <dhowells@redhat.com> wrote:
> >
> > Jason A. Donenfeld <Jason@zx2c4.com> wrote:
> >
> > > Your touch might be helpful here. CRYPTO_LIB_CHACHA20POLY1305 is a
> > > tristate and depends on as well as selects other things that are
> > > tristates.
> > >
> > > Meanwhile BIG_KEYS is a bool, which needs to select
> > > CRYPTO_LIB_CHACHA20POLY1305. However, it gets antsy if the the symbol
> > > its selecting has =m items in its hierarchy.
> > >
> > > Any suggestions? The ideal thing to happen would be that the select of
> > > CRYPTO_LIB_CHACHA20POLY1305 in BIG_KEYS causes all of the descendants
> > > to become =y too.
> >
> > I think that select is broken in its behaviour - it doesn't propagate the
> > selection enforcement up the tree. You could try changing it to a depends on
> > or you could put in a select for every dependency.
>
> I agree.
> 'depends on' will be cleaner.
That's fine, but also makes it more annoying for people to select
big_keys, and I don't know how David feels in that regard.
Seems like it'd be useful to have something that means "select X and
all the things X needs to not be broken", though satisfiability
problems like that can get really complicated quite fast.
^ permalink raw reply [flat|nested] 31+ messages in thread
* linux-next: build failure after merge of the keys tree
@ 2020-03-02 0:37 Stephen Rothwell
2020-03-02 15:23 ` Pavel Begunkov
2020-05-04 3:25 ` Stephen Rothwell
0 siblings, 2 replies; 31+ messages in thread
From: Stephen Rothwell @ 2020-03-02 0:37 UTC (permalink / raw)
To: David Howells, Jens Axboe
Cc: Linux Next Mailing List, Linux Kernel Mailing List, Pavel Begunkov
[-- Attachment #1: Type: text/plain, Size: 1877 bytes --]
Hi all,
After merging the keys tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:
fs/io_uring.c: In function 'io_splice_punt':
fs/io_uring.c:2473:6: error: too few arguments to function 'get_pipe_info'
2473 | if (get_pipe_info(file))
| ^~~~~~~~~~~~~
In file included from include/linux/splice.h:12,
from include/linux/skbuff.h:36,
from include/linux/if_ether.h:19,
from include/uapi/linux/ethtool.h:19,
from include/linux/ethtool.h:18,
from include/linux/netdevice.h:37,
from include/net/sock.h:46,
from fs/io_uring.c:64:
include/linux/pipe_fs_i.h:267:25: note: declared here
267 | struct pipe_inode_info *get_pipe_info(struct file *file, bool for_splice);
| ^~~~~~~~~~~~~
Caused by commit
549d46d3827d ("pipe: Add general notification queue support")
interacting with commit
52b31bc9aabc ("io_uring: add splice(2) support")
from the block tree.
I have added the following merge fix patch.
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 2 Mar 2020 11:27:27 +1100
Subject: [PATCH] io_uring: fix up for get_pipe_info() API change
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
fs/io_uring.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/io_uring.c b/fs/io_uring.c
index fb8fe0bd5e18..8cdd3870cd4e 100644
--- a/fs/io_uring.c
+++ b/fs/io_uring.c
@@ -2470,7 +2470,7 @@ static int io_splice_prep(struct io_kiocb *req, const struct io_uring_sqe *sqe)
static bool io_splice_punt(struct file *file)
{
- if (get_pipe_info(file))
+ if (get_pipe_info(file, true))
return false;
if (!io_file_supports_async(file))
return true;
--
2.25.0
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply related [flat|nested] 31+ messages in thread* Re: linux-next: build failure after merge of the keys tree
2020-03-02 0:37 Stephen Rothwell
@ 2020-03-02 15:23 ` Pavel Begunkov
2020-05-04 3:25 ` Stephen Rothwell
1 sibling, 0 replies; 31+ messages in thread
From: Pavel Begunkov @ 2020-03-02 15:23 UTC (permalink / raw)
To: Stephen Rothwell, David Howells, Jens Axboe
Cc: Linux Next Mailing List, Linux Kernel Mailing List
On 3/2/2020 3:37 AM, Stephen Rothwell wrote:
> Hi all,
>
> After merging the keys tree, today's linux-next build (arm
> multi_v7_defconfig) failed like this:
Acked-by: Pavel Begunkov <asml.silence@gmail.com>
Thanks
> fs/io_uring.c: In function 'io_splice_punt':
> fs/io_uring.c:2473:6: error: too few arguments to function 'get_pipe_info'
> 2473 | if (get_pipe_info(file))
> | ^~~~~~~~~~~~~
> In file included from include/linux/splice.h:12,
> from include/linux/skbuff.h:36,
> from include/linux/if_ether.h:19,
> from include/uapi/linux/ethtool.h:19,
> from include/linux/ethtool.h:18,
> from include/linux/netdevice.h:37,
> from include/net/sock.h:46,
> from fs/io_uring.c:64:
> include/linux/pipe_fs_i.h:267:25: note: declared here
> 267 | struct pipe_inode_info *get_pipe_info(struct file *file, bool for_splice);
> | ^~~~~~~~~~~~~
>
> Caused by commit
>
> 549d46d3827d ("pipe: Add general notification queue support")
>
> interacting with commit
>
> 52b31bc9aabc ("io_uring: add splice(2) support")
>
> from the block tree.
>
> I have added the following merge fix patch.
>
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Mon, 2 Mar 2020 11:27:27 +1100
> Subject: [PATCH] io_uring: fix up for get_pipe_info() API change
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
> fs/io_uring.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/fs/io_uring.c b/fs/io_uring.c
> index fb8fe0bd5e18..8cdd3870cd4e 100644
> --- a/fs/io_uring.c
> +++ b/fs/io_uring.c
> @@ -2470,7 +2470,7 @@ static int io_splice_prep(struct io_kiocb *req, const struct io_uring_sqe *sqe)
>
> static bool io_splice_punt(struct file *file)
> {
> - if (get_pipe_info(file))
> + if (get_pipe_info(file, true))
> return false;
> if (!io_file_supports_async(file))
> return true;
>
--
Pavel Begunkov
^ permalink raw reply [flat|nested] 31+ messages in thread* Re: linux-next: build failure after merge of the keys tree
2020-03-02 0:37 Stephen Rothwell
2020-03-02 15:23 ` Pavel Begunkov
@ 2020-05-04 3:25 ` Stephen Rothwell
2020-05-04 3:29 ` Stephen Rothwell
1 sibling, 1 reply; 31+ messages in thread
From: Stephen Rothwell @ 2020-05-04 3:25 UTC (permalink / raw)
To: David Howells, Jens Axboe
Cc: Linux Next Mailing List, Linux Kernel Mailing List, Pavel Begunkov
[-- Attachment #1: Type: text/plain, Size: 2148 bytes --]
Hi all,
On Mon, 2 Mar 2020 11:37:37 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> After merging the keys tree, today's linux-next build (arm
> multi_v7_defconfig) failed like this:
>
> fs/io_uring.c: In function 'io_splice_punt':
> fs/io_uring.c:2473:6: error: too few arguments to function 'get_pipe_info'
> 2473 | if (get_pipe_info(file))
> | ^~~~~~~~~~~~~
> In file included from include/linux/splice.h:12,
> from include/linux/skbuff.h:36,
> from include/linux/if_ether.h:19,
> from include/uapi/linux/ethtool.h:19,
> from include/linux/ethtool.h:18,
> from include/linux/netdevice.h:37,
> from include/net/sock.h:46,
> from fs/io_uring.c:64:
> include/linux/pipe_fs_i.h:267:25: note: declared here
> 267 | struct pipe_inode_info *get_pipe_info(struct file *file, bool for_splice);
> | ^~~~~~~~~~~~~
>
> Caused by commit
>
> 549d46d3827d ("pipe: Add general notification queue support")
>
> interacting with commit
>
> 52b31bc9aabc ("io_uring: add splice(2) support")
>
> from the block tree.
>
> I have added the following merge fix patch.
>
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Mon, 2 Mar 2020 11:27:27 +1100
> Subject: [PATCH] io_uring: fix up for get_pipe_info() API change
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
> fs/io_uring.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/fs/io_uring.c b/fs/io_uring.c
> index fb8fe0bd5e18..8cdd3870cd4e 100644
> --- a/fs/io_uring.c
> +++ b/fs/io_uring.c
> @@ -2470,7 +2470,7 @@ static int io_splice_prep(struct io_kiocb *req, const struct io_uring_sqe *sqe)
>
> static bool io_splice_punt(struct file *file)
> {
> - if (get_pipe_info(file))
> + if (get_pipe_info(file, true))
> return false;
> if (!io_file_supports_async(file))
> return true;
Due to further changes in Linus' tree over the weekend, this fixup is
not linger needed.
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 31+ messages in thread* Re: linux-next: build failure after merge of the keys tree
2020-05-04 3:25 ` Stephen Rothwell
@ 2020-05-04 3:29 ` Stephen Rothwell
0 siblings, 0 replies; 31+ messages in thread
From: Stephen Rothwell @ 2020-05-04 3:29 UTC (permalink / raw)
To: David Howells, Jens Axboe
Cc: Linux Next Mailing List, Linux Kernel Mailing List, Pavel Begunkov
[-- Attachment #1: Type: text/plain, Size: 255 bytes --]
Hi all,
On Mon, 4 May 2020 13:25:29 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Due to further changes in Linus' tree over the weekend, this fixup is
> not linger needed.
"no longer" (Monday's ...)
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 31+ messages in thread
* linux-next: build failure after merge of the keys tree
@ 2020-02-09 23:05 Stephen Rothwell
2020-02-09 23:07 ` Stephen Rothwell
0 siblings, 1 reply; 31+ messages in thread
From: Stephen Rothwell @ 2020-02-09 23:05 UTC (permalink / raw)
To: David Howells, Linus Torvalds
Cc: Linux Next Mailing List, Linux Kernel Mailing List
[-- Attachment #1: Type: text/plain, Size: 460 bytes --]
Hi all,
After merging the keys tree, today's linux-next build (x86_64
allmodconfig) failed like this:
Caused by commits in the keys tree interacting with commit
0ddad21d3e99 ("pipe: use exclusive waits when reading or writing")
from Linus' tree.
Given that I haven't seen a pull request for the keys tree yet, it seems
that this work will not be in v5.6, so I have just dropped the keys tree
for today.
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 31+ messages in thread* Re: linux-next: build failure after merge of the keys tree
2020-02-09 23:05 Stephen Rothwell
@ 2020-02-09 23:07 ` Stephen Rothwell
2020-02-11 23:23 ` Stephen Rothwell
0 siblings, 1 reply; 31+ messages in thread
From: Stephen Rothwell @ 2020-02-09 23:07 UTC (permalink / raw)
To: David Howells, Linus Torvalds
Cc: Linux Next Mailing List, Linux Kernel Mailing List
[-- Attachment #1: Type: text/plain, Size: 1881 bytes --]
Hi all,
On Mon, 10 Feb 2020 10:05:55 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Hi all,
>
> After merging the keys tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
kernel/watch_queue.c: In function 'post_one_notification':
kernel/watch_queue.c:89:21: error: 'struct pipe_inode_info' has no member named 'wait'
89 | spin_lock_irq(&pipe->wait.lock);
| ^~
kernel/watch_queue.c:122:24: error: 'struct pipe_inode_info' has no member named 'wait'
122 | spin_unlock_irq(&pipe->wait.lock);
| ^~
In file included from include/linux/mmzone.h:10,
from include/linux/gfp.h:6,
from include/linux/umh.h:4,
from include/linux/kmod.h:9,
from include/linux/module.h:16,
from kernel/watch_queue.c:11:
kernel/watch_queue.c:125:46: error: 'struct pipe_inode_info' has no member named 'wait'
125 | wake_up_interruptible_sync_poll_locked(&pipe->wait, EPOLLIN | EPOLLRDNORM);
| ^~
include/linux/wait.h:234:29: note: in definition of macro 'wake_up_interruptible_sync_poll_locked'
234 | __wake_up_locked_sync_key((x), TASK_INTERRUPTIBLE, poll_to_key(m))
| ^
kernel/watch_queue.c:129:23: error: 'struct pipe_inode_info' has no member named 'wait'
129 | spin_unlock_irq(&pipe->wait.lock);
| ^~
> Caused by commit(s) in the keys tree interacting with commit
>
> 0ddad21d3e99 ("pipe: use exclusive waits when reading or writing")
>
> from Linus' tree.
>
> Given that I haven't seen a pull request for the keys tree yet, it seems
> that this work will not be in v5.6, so I have just dropped the keys tree
> for today.
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 31+ messages in thread* Re: linux-next: build failure after merge of the keys tree
2020-02-09 23:07 ` Stephen Rothwell
@ 2020-02-11 23:23 ` Stephen Rothwell
0 siblings, 0 replies; 31+ messages in thread
From: Stephen Rothwell @ 2020-02-11 23:23 UTC (permalink / raw)
To: David Howells, Linus Torvalds
Cc: Linux Next Mailing List, Linux Kernel Mailing List
[-- Attachment #1: Type: text/plain, Size: 2203 bytes --]
Hi all,
On Mon, 10 Feb 2020 10:07:43 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> On Mon, 10 Feb 2020 10:05:55 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > After merging the keys tree, today's linux-next build (x86_64
> > allmodconfig) failed like this:
>
> kernel/watch_queue.c: In function 'post_one_notification':
> kernel/watch_queue.c:89:21: error: 'struct pipe_inode_info' has no member named 'wait'
> 89 | spin_lock_irq(&pipe->wait.lock);
> | ^~
> kernel/watch_queue.c:122:24: error: 'struct pipe_inode_info' has no member named 'wait'
> 122 | spin_unlock_irq(&pipe->wait.lock);
> | ^~
> In file included from include/linux/mmzone.h:10,
> from include/linux/gfp.h:6,
> from include/linux/umh.h:4,
> from include/linux/kmod.h:9,
> from include/linux/module.h:16,
> from kernel/watch_queue.c:11:
> kernel/watch_queue.c:125:46: error: 'struct pipe_inode_info' has no member named 'wait'
> 125 | wake_up_interruptible_sync_poll_locked(&pipe->wait, EPOLLIN | EPOLLRDNORM);
> | ^~
> include/linux/wait.h:234:29: note: in definition of macro 'wake_up_interruptible_sync_poll_locked'
> 234 | __wake_up_locked_sync_key((x), TASK_INTERRUPTIBLE, poll_to_key(m))
> | ^
> kernel/watch_queue.c:129:23: error: 'struct pipe_inode_info' has no member named 'wait'
> 129 | spin_unlock_irq(&pipe->wait.lock);
> | ^~
>
> > Caused by commit(s) in the keys tree interacting with commit
> >
> > 0ddad21d3e99 ("pipe: use exclusive waits when reading or writing")
> >
> > from Linus' tree.
> >
> > Given that I haven't seen a pull request for the keys tree yet, it seems
> > that this work will not be in v5.6, so I have just dropped the keys tree
> > for today.
From today, I have just disabled CONFIG_WATCH_QUEUE instead of dropping
the keys tree completely. Please let me know when it has been fixed up
in case I don't notice.
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 31+ messages in thread
* linux-next: build failure after merge of the keys tree
@ 2020-01-16 1:36 Stephen Rothwell
0 siblings, 0 replies; 31+ messages in thread
From: Stephen Rothwell @ 2020-01-16 1:36 UTC (permalink / raw)
To: David Howells; +Cc: Linux Next Mailing List, Linux Kernel Mailing List
[-- Attachment #1: Type: text/plain, Size: 6985 bytes --]
Hi all,
After merging the keys tree, today's linux-next build (x86_64
allmodconfig) failed like this:
In file included from include/linux/keyctl.h:11,
from include/linux/key.h:35,
from include/linux/cred.h:13,
from fs/verity/signature.c:10:
fs/verity/signature.c: In function 'fsverity_init_signature':
include/uapi/linux/keyctl.h:52:24: warning: passing argument 5 of 'keyring_alloc' makes pointer from integer without a cast [-Wint-conversion]
52 | #define KEY_POS_SEARCH 0x08000000 /* possessor can find a key in search / search a keyring */
| ^
| |
| int
fs/verity/signature.c:140:25: note: in expansion of macro 'KEY_POS_SEARCH'
140 | current_cred(), KEY_POS_SEARCH |
| ^~~~~~~~~~~~~~
In file included from include/linux/cred.h:13,
from fs/verity/signature.c:10:
include/linux/key.h:390:20: note: expected 'struct key_acl *' but argument is of type 'int'
390 | extern struct key *keyring_alloc(const char *description, kuid_t uid, kgid_t gid,
| ^~~~~~~~~~~~~
fs/crypto/keysetup_v1.c: In function 'find_and_lock_process_key':
fs/crypto/keysetup_v1.c:107:8: error: too few arguments to function 'request_key'
107 | key = request_key(&key_type_logon, description, NULL);
| ^~~~~~~~~~~
In file included from include/keys/user-type.h:11,
from fs/crypto/keysetup_v1.c:25:
include/linux/key.h:321:27: note: declared here
321 | static inline struct key *request_key(struct key_type *type,
| ^~~~~~~~~~~
In file included from include/linux/keyctl.h:11,
from include/linux/key.h:35,
from include/linux/key-type.h:11,
from fs/crypto/keyring.c:22:
fs/crypto/keyring.c: In function 'allocate_filesystem_keyring':
include/uapi/linux/keyctl.h:52:24: warning: passing argument 5 of 'keyring_alloc' makes pointer from integer without a cast [-Wint-conversion]
52 | #define KEY_POS_SEARCH 0x08000000 /* possessor can find a key in search / search a keyring */
| ^
| |
| int
fs/crypto/keyring.c:208:21: note: in expansion of macro 'KEY_POS_SEARCH'
208 | current_cred(), KEY_POS_SEARCH |
| ^~~~~~~~~~~~~~
In file included from include/linux/key-type.h:11,
from fs/crypto/keyring.c:22:
include/linux/key.h:390:20: note: expected 'struct key_acl *' but argument is of type 'int'
390 | extern struct key *keyring_alloc(const char *description, kuid_t uid, kgid_t gid,
| ^~~~~~~~~~~~~
In file included from include/linux/keyctl.h:11,
from include/linux/key.h:35,
from include/linux/key-type.h:11,
from fs/crypto/keyring.c:22:
fs/crypto/keyring.c: In function 'allocate_master_key_users_keyring':
include/uapi/linux/keyctl.h:52:24: warning: passing argument 5 of 'keyring_alloc' makes pointer from integer without a cast [-Wint-conversion]
52 | #define KEY_POS_SEARCH 0x08000000 /* possessor can find a key in search / search a keyring */
| ^
| |
| int
fs/crypto/keyring.c:252:21: note: in expansion of macro 'KEY_POS_SEARCH'
252 | current_cred(), KEY_POS_SEARCH |
| ^~~~~~~~~~~~~~
In file included from include/linux/key-type.h:11,
from fs/crypto/keyring.c:22:
include/linux/key.h:390:20: note: expected 'struct key_acl *' but argument is of type 'int'
390 | extern struct key *keyring_alloc(const char *description, kuid_t uid, kgid_t gid,
| ^~~~~~~~~~~~~
In file included from include/linux/keyctl.h:11,
from include/linux/key.h:35,
from include/linux/key-type.h:11,
from fs/crypto/keyring.c:22:
fs/crypto/keyring.c: In function 'add_master_key_user':
include/uapi/linux/keyctl.h:52:24: warning: passing argument 6 of 'key_alloc' makes pointer from integer without a cast [-Wint-conversion]
52 | #define KEY_POS_SEARCH 0x08000000 /* possessor can find a key in search / search a keyring */
| ^
| |
| int
fs/crypto/keyring.c:290:8: note: in expansion of macro 'KEY_POS_SEARCH'
290 | KEY_POS_SEARCH | KEY_USR_VIEW, 0, NULL);
| ^~~~~~~~~~~~~~
In file included from include/linux/key-type.h:11,
from fs/crypto/keyring.c:22:
include/linux/key.h:256:20: note: expected 'struct key_acl *' but argument is of type 'int'
256 | extern struct key *key_alloc(struct key_type *type,
| ^~~~~~~~~
In file included from include/linux/keyctl.h:11,
from include/linux/key.h:35,
from include/linux/key-type.h:11,
from fs/crypto/keyring.c:22:
fs/crypto/keyring.c: In function 'add_new_master_key':
include/uapi/linux/keyctl.h:52:24: warning: passing argument 6 of 'key_alloc' makes pointer from integer without a cast [-Wint-conversion]
52 | #define KEY_POS_SEARCH 0x08000000 /* possessor can find a key in search / search a keyring */
| ^
| |
| int
fs/crypto/keyring.c:362:4: note: in expansion of macro 'KEY_POS_SEARCH'
362 | KEY_POS_SEARCH | KEY_USR_SEARCH | KEY_USR_VIEW,
| ^~~~~~~~~~~~~~
In file included from include/linux/key-type.h:11,
from fs/crypto/keyring.c:22:
include/linux/key.h:256:20: note: expected 'struct key_acl *' but argument is of type 'int'
256 | extern struct key *key_alloc(struct key_type *type,
| ^~~~~~~~~
drivers/md/dm-verity-verify-sig.c: In function 'verity_verify_get_sig_from_key':
drivers/md/dm-verity-verify-sig.c:38:8: error: too few arguments to function 'request_key'
38 | key = request_key(&key_type_user,
| ^~~~~~~~~~~
In file included from include/keys/user-type.h:11,
from drivers/md/dm-verity-verify-sig.c:10:
include/linux/key.h:321:27: note: declared here
321 | static inline struct key *request_key(struct key_type *type,
| ^~~~~~~~~~~
Caused by API updates in the keys tree without fixups of their uses.
The keys tree is now based on v5.5-rc3 ...
The callis to keyring_alloc() in fs/verity/signature.c and
fs/crypto/keyring.c were added in v5.4-rc1. As were the calls to
request_key() in fs/crypto/keysetup_v1.c and
drivers/md/dm-verity-verify-sig.c.
I have used the keys tree from next-20191211 again today.
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 31+ messages in thread* linux-next: build failure after merge of the keys tree
@ 2019-08-29 5:31 Stephen Rothwell
2019-09-02 6:19 ` Stephen Rothwell
2019-09-02 16:01 ` David Howells
0 siblings, 2 replies; 31+ messages in thread
From: Stephen Rothwell @ 2019-08-29 5:31 UTC (permalink / raw)
To: David Howells
Cc: Linux Next Mailing List, Linux Kernel Mailing List,
Greg Kroah-Hartman, Linux USB Mailing List
[-- Attachment #1: Type: text/plain, Size: 325 bytes --]
Hi all,
After merging the keys tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:
Caused by commit
ef9cc255c953 ("usb: Add USB subsystem notifications")
# CONFIG_USB_NOTIFICATIONS is not set
I have used the keys tree from next-20190828 for today.
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 31+ messages in thread* Re: linux-next: build failure after merge of the keys tree
2019-08-29 5:31 Stephen Rothwell
@ 2019-09-02 6:19 ` Stephen Rothwell
2019-09-02 16:01 ` David Howells
1 sibling, 0 replies; 31+ messages in thread
From: Stephen Rothwell @ 2019-09-02 6:19 UTC (permalink / raw)
To: David Howells
Cc: Linux Next Mailing List, Linux Kernel Mailing List,
Greg Kroah-Hartman, Linux USB Mailing List
[-- Attachment #1: Type: text/plain, Size: 2699 bytes --]
Hi all,
On Thu, 29 Aug 2019 15:31:16 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> After merging the keys tree, today's linux-next build (arm
> multi_v7_defconfig) failed like this:
>
>
> Caused by commit
>
> ef9cc255c953 ("usb: Add USB subsystem notifications")
>
> # CONFIG_USB_NOTIFICATIONS is not set
>
> I have used the keys tree from next-20190828 for today.
I only realised this morning that I forgot to include the error log
(sorry):
In file included from include/linux/usb/phy.h:15,
from include/linux/usb/otg.h:14,
from include/linux/usb/tegra_usb_phy.h:21,
from arch/arm/mach-tegra/tegra.c:27:
include/linux/usb.h:2026:34: error: parameter 2 ('subtype') has incomplete type
2026 | enum usb_notification_type subtype,
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~
include/linux/usb.h:2025:20: error: function declaration isn't a prototype [-Werror=strict-prototypes]
2025 | static inline void post_usb_device_notification(const struct usb_device *udev,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
include/linux/usb.h:2029:38: error: parameter 2 ('subtype') has incomplete type
2029 | enum usb_notification_type subtype,
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~
include/linux/usb.h:2028:20: error: function declaration isn't a prototype [-Werror=strict-prototypes]
2028 | static inline void post_usb_bus_notification(const struct usb_bus *ubus,
| ^~~~~~~~~~~~~~~~~~~~~~~~~
(several more like this)
Today I have included the following fix patch:
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 2 Sep 2019 16:01:59 +1000
Subject: [PATCH] usb: include watch_queue.h for needed enum
The forward declararion doesn't seem to work (at laste for the
!CONFIG_USB_NOTIFICATIONS case.
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
include/linux/usb.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/usb.h b/include/linux/usb.h
index a7d5fce46569..11438058f4fa 100644
--- a/include/linux/usb.h
+++ b/include/linux/usb.h
@@ -4,6 +4,7 @@
#include <linux/mod_devicetable.h>
#include <linux/usb/ch9.h>
+#include <linux/watch_queue.h>
#define USB_MAJOR 180
#define USB_DEVICE_MAJOR 189
@@ -26,7 +27,6 @@
struct usb_device;
struct usb_driver;
struct wusb_dev;
-enum usb_notification_type;
/*-------------------------------------------------------------------------*/
--
2.23.0.rc1
I then discovered that I needed to install libkeyutils-dev :-( but it
built OK after that.
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply related [flat|nested] 31+ messages in thread* Re: linux-next: build failure after merge of the keys tree
2019-08-29 5:31 Stephen Rothwell
2019-09-02 6:19 ` Stephen Rothwell
@ 2019-09-02 16:01 ` David Howells
2019-09-02 23:07 ` Stephen Rothwell
2019-09-02 23:20 ` David Howells
1 sibling, 2 replies; 31+ messages in thread
From: David Howells @ 2019-09-02 16:01 UTC (permalink / raw)
To: Stephen Rothwell
Cc: dhowells, Linux Next Mailing List, Linux Kernel Mailing List,
Greg Kroah-Hartman, Linux USB Mailing List
Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> The forward declararion doesn't seem to work (at laste for the
> !CONFIG_USB_NOTIFICATIONS case.
In the !CONFIG_USB_NOTIFICATIONS case, the argument is to a stub inline
function. Even though the argument isn't actually used, it can't be an
undefined type - and, I'm guessing, an undefined size, meaning the compiler
doesn't know how many registers/how much stack space it would occupy before
getting to the error argument.
I have a fix for this in my tree that just makes it an unsigned int in the
disabled case:
static inline void post_usb_device_notification(const struct usb_device *udev,
unsigned int subtype, u32 error) {}
> +#include <linux/watch_queue.h>
I was trying to avoid that if I could to avoid introducing the possibility of
circular deps, but that might not be a problem in this case.
> I then discovered that I needed to install libkeyutils-dev :-( but it
> built OK after that.
? The kernel shouldn't require that to build.
David
^ permalink raw reply [flat|nested] 31+ messages in thread* Re: linux-next: build failure after merge of the keys tree
2019-09-02 16:01 ` David Howells
@ 2019-09-02 23:07 ` Stephen Rothwell
2019-09-02 23:21 ` Stephen Rothwell
2019-09-02 23:53 ` David Howells
2019-09-02 23:20 ` David Howells
1 sibling, 2 replies; 31+ messages in thread
From: Stephen Rothwell @ 2019-09-02 23:07 UTC (permalink / raw)
To: David Howells
Cc: Linux Next Mailing List, Linux Kernel Mailing List,
Greg Kroah-Hartman, Linux USB Mailing List
[-- Attachment #1: Type: text/plain, Size: 1388 bytes --]
Hi David,
On Mon, 02 Sep 2019 17:01:19 +0100 David Howells <dhowells@redhat.com> wrote:
>
> Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> > The forward declararion doesn't seem to work (at laste for the
> > !CONFIG_USB_NOTIFICATIONS case.
>
> In the !CONFIG_USB_NOTIFICATIONS case, the argument is to a stub inline
> function. Even though the argument isn't actually used, it can't be an
> undefined type - and, I'm guessing, an undefined size, meaning the compiler
> doesn't know how many registers/how much stack space it would occupy before
> getting to the error argument.
>
> I have a fix for this in my tree that just makes it an unsigned int in the
> disabled case:
>
> static inline void post_usb_device_notification(const struct usb_device *udev,
> unsigned int subtype, u32 error) {}
But not published, yet?
> > +#include <linux/watch_queue.h>
>
> I was trying to avoid that if I could to avoid introducing the possibility of
> circular deps, but that might not be a problem in this case.
Seems to be OK for x86_64 allmodconfig at least.
>
> > I then discovered that I needed to install libkeyutils-dev :-( but it
> > built OK after that.
>
> ? The kernel shouldn't require that to build.
I was doing an x86_64 allmodconfig build which seems to build (all of?)
the samples.
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 31+ messages in thread* Re: linux-next: build failure after merge of the keys tree
2019-09-02 23:07 ` Stephen Rothwell
@ 2019-09-02 23:21 ` Stephen Rothwell
2019-09-02 23:53 ` David Howells
1 sibling, 0 replies; 31+ messages in thread
From: Stephen Rothwell @ 2019-09-02 23:21 UTC (permalink / raw)
To: David Howells
Cc: Linux Next Mailing List, Linux Kernel Mailing List,
Greg Kroah-Hartman, Linux USB Mailing List
[-- Attachment #1: Type: text/plain, Size: 514 bytes --]
Hi David,
On Tue, 3 Sep 2019 09:07:22 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> > > I then discovered that I needed to install libkeyutils-dev :-( but it
> > > built OK after that.
> >
> > ? The kernel shouldn't require that to build.
>
> I was doing an x86_64 allmodconfig build which seems to build (all of?)
> the samples.
Of course, this breaks our crossbuilds :-(
e.g. S390 allyesconfig build:
/usr/bin/ld: cannot find -lkeyutils
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: linux-next: build failure after merge of the keys tree
2019-09-02 23:07 ` Stephen Rothwell
2019-09-02 23:21 ` Stephen Rothwell
@ 2019-09-02 23:53 ` David Howells
2019-09-03 0:29 ` Stephen Rothwell
1 sibling, 1 reply; 31+ messages in thread
From: David Howells @ 2019-09-02 23:53 UTC (permalink / raw)
To: Stephen Rothwell
Cc: dhowells, Linux Next Mailing List, Linux Kernel Mailing List,
Greg Kroah-Hartman, Linux USB Mailing List
Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > I was doing an x86_64 allmodconfig build which seems to build (all of?)
> > the samples.
>
> Of course, this breaks our crossbuilds :-(
>
> e.g. S390 allyesconfig build:
>
> /usr/bin/ld: cannot find -lkeyutils
Is it a requirement that stuff in samples/ should be able to build without
resorting to external userspace headers? Or, at least, those outside of the C
library?
David
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: linux-next: build failure after merge of the keys tree
2019-09-02 23:53 ` David Howells
@ 2019-09-03 0:29 ` Stephen Rothwell
0 siblings, 0 replies; 31+ messages in thread
From: Stephen Rothwell @ 2019-09-03 0:29 UTC (permalink / raw)
To: David Howells
Cc: Linux Next Mailing List, Linux Kernel Mailing List,
Greg Kroah-Hartman, Linux USB Mailing List
[-- Attachment #1: Type: text/plain, Size: 671 bytes --]
Hi David,
On Tue, 03 Sep 2019 00:53:14 +0100 David Howells <dhowells@redhat.com> wrote:
>
> Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> > > I was doing an x86_64 allmodconfig build which seems to build (all of?)
> > > the samples.
> >
> > Of course, this breaks our crossbuilds :-(
> >
> > e.g. S390 allyesconfig build:
> >
> > /usr/bin/ld: cannot find -lkeyutils
>
> Is it a requirement that stuff in samples/ should be able to build without
> resorting to external userspace headers? Or, at least, those outside of the C
> library?
Well, this is the only samples failure in the current build ...
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: linux-next: build failure after merge of the keys tree
2019-09-02 16:01 ` David Howells
2019-09-02 23:07 ` Stephen Rothwell
@ 2019-09-02 23:20 ` David Howells
2019-09-02 23:39 ` Stephen Rothwell
2019-09-02 23:51 ` David Howells
1 sibling, 2 replies; 31+ messages in thread
From: David Howells @ 2019-09-02 23:20 UTC (permalink / raw)
To: Stephen Rothwell
Cc: dhowells, Linux Next Mailing List, Linux Kernel Mailing List,
Greg Kroah-Hartman, Linux USB Mailing List
Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > static inline void post_usb_device_notification(const struct usb_device *udev,
> > unsigned int subtype, u32 error) {}
>
> But not published, yet?
I was hoping to get the smack patch reviewed by Casey first, but I can
publish anyway.
> > > I then discovered that I needed to install libkeyutils-dev :-( but it
> > > built OK after that.
> >
> > ? The kernel shouldn't require that to build.
>
> I was doing an x86_64 allmodconfig build which seems to build (all of?)
> the samples.
Ah, yes - the sample demonstrates the key/keyring notifications as well as USB
and block notifications and requires a constant from the keyutils-devel
package. Maybe I should get it from the kernel UAPI headers instead, but that
risks generating a collision.
David
^ permalink raw reply [flat|nested] 31+ messages in thread* Re: linux-next: build failure after merge of the keys tree
2019-09-02 23:20 ` David Howells
@ 2019-09-02 23:39 ` Stephen Rothwell
2019-09-02 23:51 ` David Howells
1 sibling, 0 replies; 31+ messages in thread
From: Stephen Rothwell @ 2019-09-02 23:39 UTC (permalink / raw)
To: David Howells
Cc: Linux Next Mailing List, Linux Kernel Mailing List,
Greg Kroah-Hartman, Linux USB Mailing List
[-- Attachment #1: Type: text/plain, Size: 426 bytes --]
Hi David,
On Tue, 03 Sep 2019 00:20:08 +0100 David Howells <dhowells@redhat.com> wrote:
>
> Ah, yes - the sample demonstrates the key/keyring notifications as well as USB
> and block notifications and requires a constant from the keyutils-devel
> package. Maybe I should get it from the kernel UAPI headers instead, but that
> risks generating a collision.
What sort of collision?
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: linux-next: build failure after merge of the keys tree
2019-09-02 23:20 ` David Howells
2019-09-02 23:39 ` Stephen Rothwell
@ 2019-09-02 23:51 ` David Howells
1 sibling, 0 replies; 31+ messages in thread
From: David Howells @ 2019-09-02 23:51 UTC (permalink / raw)
To: Stephen Rothwell
Cc: dhowells, Linux Next Mailing List, Linux Kernel Mailing List,
Greg Kroah-Hartman, Linux USB Mailing List
Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > Ah, yes - the sample demonstrates the key/keyring notifications as well as
> > USB and block notifications and requires a constant from the
> > keyutils-devel package. Maybe I should get it from the kernel UAPI
> > headers instead, but that risks generating a collision.
>
> What sort of collision?
Accidentally including both a userspace header file and a kernel UAPI header
file with the constants colliding.
Anyway, I've pushed a new version of keys-next and also keyutils if you're
employing the testsuite from that at all.
David
^ permalink raw reply [flat|nested] 31+ messages in thread
* linux-next: build failure after merge of the keys tree
@ 2019-08-16 5:04 Stephen Rothwell
0 siblings, 0 replies; 31+ messages in thread
From: Stephen Rothwell @ 2019-08-16 5:04 UTC (permalink / raw)
To: David Howells, Alasdair G Kergon, Mike Snitzer
Cc: Linux Next Mailing List, Linux Kernel Mailing List, Jaskaran Khurana
[-- Attachment #1: Type: text/plain, Size: 1737 bytes --]
Hi all,
After merging the keys tree, today's linux-next build (x86_64
allmodconfig) failed like this:
drivers/md/dm-verity-verify-sig.c: In function 'verity_verify_get_sig_from_key':
drivers/md/dm-verity-verify-sig.c:38:8: error: too few arguments to function 'request_key'
key = request_key(&key_type_user,
^~~~~~~~~~~
In file included from include/keys/user-type.h:11,
from drivers/md/dm-verity-verify-sig.c:10:
include/linux/key.h:318:27: note: declared here
static inline struct key *request_key(struct key_type *type,
^~~~~~~~~~~
Caused by commit
f802f2b3a991 ("keys: Replace uid/gid/perm permissions checking with an ACL")
interacting with commit
644332ceab35 ("dm verity: add root hash pkcs#7 signature verification")
from the device-mapper tree.
I applied the following merge resolution patch.
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Fri, 16 Aug 2019 15:00:15 +1000
Subject: [PATCH] dm verity: merge fix for "keys: Replace uid/gid/perm
permissions checking with an ACL"
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
drivers/md/dm-verity-verify-sig.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/md/dm-verity-verify-sig.c b/drivers/md/dm-verity-verify-sig.c
index 614e43db93aa..2ca162d43fe6 100644
--- a/drivers/md/dm-verity-verify-sig.c
+++ b/drivers/md/dm-verity-verify-sig.c
@@ -36,7 +36,7 @@ static int verity_verify_get_sig_from_key(const char *key_desc,
int ret = 0;
key = request_key(&key_type_user,
- key_desc, NULL);
+ key_desc, NULL, NULL);
if (IS_ERR(key))
return PTR_ERR(key);
--
2.20.1
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply related [flat|nested] 31+ messages in thread* linux-next: build failure after merge of the keys tree
@ 2017-11-13 2:08 Stephen Rothwell
2017-11-13 11:21 ` David Howells
0 siblings, 1 reply; 31+ messages in thread
From: Stephen Rothwell @ 2017-11-13 2:08 UTC (permalink / raw)
To: David Howells; +Cc: Linux-Next Mailing List, Linux Kernel Mailing List
Hi David,
After merging the keys tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:
drivers/md/dm-crypt.c: In function 'crypt_set_keyring_key':
drivers/md/dm-crypt.c:2022:8: error: too few arguments to function 'request_key'
key = request_key(key_string[0] == 'l' ? &key_type_logon : &key_type_user,
^
In file included from drivers/md/dm-crypt.c:15:0:
include/linux/key.h:268:20: note: declared here
extern struct key *request_key(struct key_type *type,
^
Caused by commit
b059d2a56c53 ("KEYS: Replace uid/gid/perm permissions checking with an ACL")
I have used the keys tree from next-20171110 for today.
--
Cheers,
Stephen Rothwell
^ permalink raw reply [flat|nested] 31+ messages in thread* linux-next: build failure after merge of the keys tree
@ 2017-04-04 3:39 Stephen Rothwell
0 siblings, 0 replies; 31+ messages in thread
From: Stephen Rothwell @ 2017-04-04 3:39 UTC (permalink / raw)
To: David Howells
Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Mat Martineau
Hi David,
After merging the keys tree, today's linux-next build (x86_64
allmodconfig) failed like this:
security/integrity/digsig.c: In function 'integrity_init_keyring':
security/integrity/digsig.c:46:30: error: passing argument 7 of 'keyring_alloc' from incompatible pointer type [-Werror=incompatible-pointer-types]
#define restrict_link_to_ima restrict_link_by_builtin_and_secondary_trusted
^
security/integrity/digsig.c:95:9: note: in expansion of macro 'restrict_link_to_ima'
restrict_link_to_ima, NULL);
^
In file included from include/linux/cred.h:17:0,
from security/integrity/digsig.c:18:
include/linux/key.h:311:20: note: expected 'struct key_restriction *' but argument is of type 'int (*)(struct key *, const struct key_type *, const union key_payload *, struct key *)'
extern struct key *keyring_alloc(const char *description, kuid_t uid, kgid_t gid,
^
Caused by commits
aaf66c883813 ("KEYS: Split role of the keyring pointer for keyring restrict functions")
c5faca6b4a58 ("KEYS: Use structure to capture key restriction function and data")
I have used the version from next-20170403 for today.
--
Cheers,
Stephen Rothwell
^ permalink raw reply [flat|nested] 31+ messages in thread
end of thread, other threads:[~2020-12-11 4:59 UTC | newest]
Thread overview: 31+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-05-18 4:57 linux-next: build failure after merge of the keys tree Stephen Rothwell
2020-05-18 16:00 ` How should we handle a bool depending on a tristate? David Howells
2020-05-18 16:49 ` Linus Torvalds
-- strict thread matches above, loose matches on Subject: below --
2020-12-11 4:50 linux-next: build failure after merge of the keys tree Stephen Rothwell
2020-05-14 4:30 Stephen Rothwell
2020-05-14 4:46 ` Jason A. Donenfeld
2020-05-14 12:11 ` David Howells
2020-05-14 12:34 ` Masahiro Yamada
2020-05-14 23:25 ` Jason A. Donenfeld
2020-03-02 0:37 Stephen Rothwell
2020-03-02 15:23 ` Pavel Begunkov
2020-05-04 3:25 ` Stephen Rothwell
2020-05-04 3:29 ` Stephen Rothwell
2020-02-09 23:05 Stephen Rothwell
2020-02-09 23:07 ` Stephen Rothwell
2020-02-11 23:23 ` Stephen Rothwell
2020-01-16 1:36 Stephen Rothwell
2019-08-29 5:31 Stephen Rothwell
2019-09-02 6:19 ` Stephen Rothwell
2019-09-02 16:01 ` David Howells
2019-09-02 23:07 ` Stephen Rothwell
2019-09-02 23:21 ` Stephen Rothwell
2019-09-02 23:53 ` David Howells
2019-09-03 0:29 ` Stephen Rothwell
2019-09-02 23:20 ` David Howells
2019-09-02 23:39 ` Stephen Rothwell
2019-09-02 23:51 ` David Howells
2019-08-16 5:04 Stephen Rothwell
2017-11-13 2:08 Stephen Rothwell
2017-11-13 11:21 ` David Howells
2017-04-04 3:39 Stephen Rothwell
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).