* 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
* Re: linux-next: build failure after merge of the keys tree
2019-08-29 5:31 linux-next: build failure after merge of the keys tree 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
* Re: linux-next: build failure after merge of the keys tree
2019-08-29 5:31 linux-next: build failure after merge of the keys tree 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-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-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 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: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 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 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: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
* 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
* 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-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
* 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 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 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
* 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 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 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-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
* 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
* 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
* 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
* 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
* 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 --
2019-08-29 5:31 linux-next: build failure after merge of the keys tree 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
-- 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-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-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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.