linux-next.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* 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; 29+ 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] 29+ messages in thread

* Re: linux-next: build failure after merge of the keys tree
  2020-03-02  0:37 linux-next: build failure after merge of the keys tree Stephen Rothwell
@ 2020-03-02 15:23 ` Pavel Begunkov
  2020-05-04  3:25 ` Stephen Rothwell
  1 sibling, 0 replies; 29+ 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] 29+ messages in thread

* Re: linux-next: build failure after merge of the keys tree
  2020-03-02  0:37 linux-next: build failure after merge of the keys tree 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; 29+ 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] 29+ 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; 29+ 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] 29+ messages in thread

* linux-next: build failure after merge of the keys tree
@ 2020-12-11  4:50 Stephen Rothwell
  0 siblings, 0 replies; 29+ 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] 29+ messages in thread

* linux-next: build failure after merge of the keys tree
@ 2020-05-18  4:57 Stephen Rothwell
  0 siblings, 0 replies; 29+ 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] 29+ 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; 29+ 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] 29+ 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; 29+ 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] 29+ 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; 29+ 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] 29+ 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; 29+ 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] 29+ 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; 29+ 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] 29+ 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; 29+ 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] 29+ 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; 29+ 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] 29+ 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; 29+ 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] 29+ messages in thread

* linux-next: build failure after merge of the keys tree
@ 2020-01-16  1:36 Stephen Rothwell
  0 siblings, 0 replies; 29+ 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] 29+ 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; 29+ 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] 29+ 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; 29+ 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] 29+ 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; 29+ 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] 29+ 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; 29+ 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] 29+ 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; 29+ 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] 29+ 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; 29+ 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] 29+ 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; 29+ 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] 29+ 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; 29+ 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] 29+ 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; 29+ 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] 29+ 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; 29+ 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] 29+ messages in thread

* linux-next: build failure after merge of the keys tree
@ 2019-08-16  5:04 Stephen Rothwell
  0 siblings, 0 replies; 29+ 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] 29+ messages in thread

* Re: 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, 0 replies; 29+ messages in thread
From: David Howells @ 2017-11-13 11:21 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: dhowells, Linux-Next Mailing List, Linux Kernel Mailing List

I've dropped the keyrings ACL patches from the branch for now.  I'll revisit
them after the merge window.

David

^ permalink raw reply	[flat|nested] 29+ 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; 29+ 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] 29+ messages in thread

* linux-next: build failure after merge of the keys tree
@ 2017-04-04  3:39 Stephen Rothwell
  0 siblings, 0 replies; 29+ 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] 29+ messages in thread

end of thread, other threads:[~2020-12-11  4:59 UTC | newest]

Thread overview: 29+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-03-02  0:37 linux-next: build failure after merge of the keys tree Stephen Rothwell
2020-03-02 15:23 ` Pavel Begunkov
2020-05-04  3:25 ` Stephen Rothwell
2020-05-04  3:29   ` Stephen Rothwell
  -- strict thread matches above, loose matches on Subject: below --
2020-12-11  4:50 Stephen Rothwell
2020-05-18  4:57 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-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).