GNU bug report logs - #42686
Update to linux-libre 5.7

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 42686 in the body.
You can then email your comments to 42686 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Leo Famulari <leo <at> famulari.name>
To: guix-patches <at> gnu.org
Subject: Update to linux-libre 5.7
Date: Sun, 2 Aug 2020 18:43:56 -0400

[Message part 1 (text/plain, inline)]

The attached patch updates our default kernel to linux-libre 5.7.

Among other things, this will bring in-kernel WireGuard support,
multipath TCP, and USB4 (Thunderbolt).

I tested on x86_64 bare-metal and virtualized i686.

I'd like to push this as a "kernel-updates" branch and let Cuirass build
it. In the past, we always did this so that nobody had to build it
themselves. CI admins, can we do this? I don't have another way to test
for ARM platforms.

I have questions about some new features:

* Enable the compressed cache for swap pages by default? (ZSWAP_DEFAULT_ON)

Should we enable this? It seems useful and the compression algorithms
are known to be very fast. Are there any downsides?

* Enable the DMA-BUF userland memory heaps? This options creates per
heap chardevs in /dev/dma_heap/ which allows userspace to allocate
dma-bufs that can be shared between drivers. (DMABUF_HEAPS)

I don't really know what that means.

* Should USB4 (Thunderbolt) be built-in? Or a module?

[0001-gnu-linux-libre-Update-to-5.7.12.patch (text/plain, attachment)]

[signature.asc (application/pgp-signature, inline)]

Message #8 received at 42686 <at> debbugs.gnu.org (full text, mbox):

From: Mathieu Othacehe <othacehe <at> gnu.org>
To: Leo Famulari <leo <at> famulari.name>
Cc: 42686 <at> debbugs.gnu.org
Subject: Re: [bug#42686] Update to linux-libre 5.7
Date: Mon, 03 Aug 2020 10:08:41 +0200

Hey Leo,

> The attached patch updates our default kernel to linux-libre 5.7.
>
> Among other things, this will bring in-kernel WireGuard support,
> multipath TCP, and USB4 (Thunderbolt).
>
> I tested on x86_64 bare-metal and virtualized i686.
>
> I'd like to push this as a "kernel-updates" branch and let Cuirass build
> it. In the past, we always did this so that nobody had to build it
> themselves. CI admins, can we do this? I don't have another way to test
> for ARM platforms.

Nice! Adding a new branch to the CI will only allow us to know if this
builds for armhf-linux and aarch64-linux architectures. You should be
able to do that on your machine with the following commands:

guix build -s armhf-linux linux-libre
guix build -s aarch64-linux linux-libre

but you need to setup qemu-binfmt first. It would also be nice to test
cross-compilation this way:

guix build -t arm-linux-gnueabihf linux-libre
guix build -t aarch64-linux-gnu linux-libre

> * Enable the compressed cache for swap pages by default? (ZSWAP_DEFAULT_ON)
>
> Should we enable this? It seems useful and the compression algorithms
> are known to be very fast. Are there any downsides?

There's at least Archlinux that is enabling it by default[1], but using LZ4
algorithm instead of the default LZO. No strong opinion otherwise.

> * Enable the DMA-BUF userland memory heaps? This options creates per
> heap chardevs in /dev/dma_heap/ which allows userspace to allocate
> dma-bufs that can be shared between drivers. (DMABUF_HEAPS)
>
> I don't really know what that means.

I think it's targeting embedded devices mainly, but it can't hurt to
enable it.

>
> * Should USB4 (Thunderbolt) be built-in? Or a module?

I would say a module, like most other device drivers.

Thanks,

Mathieu

[1]: https://github.com/archlinux/svntogit-packages/blob/packages/linux/trunk/config#L1044

Message #11 received at 42686 <at> debbugs.gnu.org (full text, mbox):

From: Leo Famulari <leo <at> famulari.name>
To: Mathieu Othacehe <othacehe <at> gnu.org>
Cc: 42686 <at> debbugs.gnu.org
Subject: Re: [bug#42686] Update to linux-libre 5.7
Date: Mon, 3 Aug 2020 13:42:00 -0400

On Mon, Aug 03, 2020 at 10:08:41AM +0200, Mathieu Othacehe wrote:
> Nice! Adding a new branch to the CI will only allow us to know if this
> builds for armhf-linux and aarch64-linux architectures. You should be
> able to do that on your machine with the following commands:
> 
> guix build -s armhf-linux linux-libre
> guix build -s aarch64-linux linux-libre
> 
> but you need to setup qemu-binfmt first. It would also be nice to test
> cross-compilation this way:

My workstation is not very powerful so I'd rather use the build farm.

> > * Enable the compressed cache for swap pages by default? (ZSWAP_DEFAULT_ON)
> >
> > Should we enable this? It seems useful and the compression algorithms
> > are known to be very fast. Are there any downsides?
> 
> There's at least Archlinux that is enabling it by default[1], but using LZ4
> algorithm instead of the default LZO. No strong opinion otherwise.

Good to know! I wonder if any other distros are...

> > * Enable the DMA-BUF userland memory heaps? This options creates per
> > heap chardevs in /dev/dma_heap/ which allows userspace to allocate
> > dma-bufs that can be shared between drivers. (DMABUF_HEAPS)
> >
> > I don't really know what that means.
> 
> I think it's targeting embedded devices mainly, but it can't hurt to
> enable it.

If that's the case, I would leave it disabled. Guix is not really
appropriate for embedded systems.

Message #14 received at 42686 <at> debbugs.gnu.org (full text, mbox):

From: Ricardo Wurmus <rekado <at> elephly.net>
To: Leo Famulari <leo <at> famulari.name>
Cc: 42686 <at> debbugs.gnu.org
Subject: Re: [bug#42686] Update to linux-libre 5.7
Date: Mon, 03 Aug 2020 23:00:32 +0200

Leo Famulari <leo <at> famulari.name> writes:

> I'd like to push this as a "kernel-updates" branch and let Cuirass build
> it. In the past, we always did this so that nobody had to build it
> themselves. CI admins, can we do this?

Sure!  Those with a valid client certificate can visit

   https://ci.guix.gnu.org/admin/specifications

and add “kernel-updates” to the specifications.

-- 
Ricardo

Message #17 received at 42686 <at> debbugs.gnu.org (full text, mbox):

From: Leo Famulari <leo <at> famulari.name>
To: Ricardo Wurmus <rekado <at> elephly.net>
Cc: 42686 <at> debbugs.gnu.org
Subject: Re: [bug#42686] Update to linux-libre 5.7
Date: Mon, 3 Aug 2020 17:55:29 -0400

On Mon, Aug 03, 2020 at 11:00:32PM +0200, Ricardo Wurmus wrote:
> 
> Leo Famulari <leo <at> famulari.name> writes:
> 
> > I'd like to push this as a "kernel-updates" branch and let Cuirass build
> > it. In the past, we always did this so that nobody had to build it
> > themselves. CI admins, can we do this?
> 
> Sure!  Those with a valid client certificate can visit
> 
>    https://ci.guix.gnu.org/admin/specifications
> 
> and add “kernel-updates” to the specifications.

Cool! I don't have a certificate or know who does.

Will somebody do this? Or should I create one for myself? If so, can you
give me some details about how to do that?

Message #20 received at 42686 <at> debbugs.gnu.org (full text, mbox):

From: Ricardo Wurmus <rekado <at> elephly.net>
To: Leo Famulari <leo <at> famulari.name>
Cc: 42686 <at> debbugs.gnu.org
Subject: Re: [bug#42686] Update to linux-libre 5.7
Date: Tue, 04 Aug 2020 12:04:56 +0200

Leo Famulari <leo <at> famulari.name> writes:

> On Mon, Aug 03, 2020 at 11:00:32PM +0200, Ricardo Wurmus wrote:
>> 
>> Leo Famulari <leo <at> famulari.name> writes:
>> 
>> > I'd like to push this as a "kernel-updates" branch and let Cuirass build
>> > it. In the past, we always did this so that nobody had to build it
>> > themselves. CI admins, can we do this?
>> 
>> Sure!  Those with a valid client certificate can visit
>> 
>>    https://ci.guix.gnu.org/admin/specifications
>> 
>> and add “kernel-updates” to the specifications.
>
> Cool! I don't have a certificate or know who does.

I do!  I just added “kernel-updates” to the specifications.

> Will somebody do this? Or should I create one for myself? If so, can you
> give me some details about how to do that?

All people with an account on ci.guix.gnu.org should be able to generate
a client certificate for themselves.  Documentation and scripts are in
the /root/maintenance directory.

-- 
Ricardo

Message #23 received at 42686 <at> debbugs.gnu.org (full text, mbox):

From: Danny Milosavljevic <dannym <at> scratchpost.org>
To: Leo Famulari <leo <at> famulari.name>
Cc: 42686 <at> debbugs.gnu.org
Subject: Re: [bug#42686] Update to linux-libre 5.7
Date: Tue, 4 Aug 2020 12:36:57 +0200

[Message part 1 (text/plain, inline)]

Hi Leo,

On Sun, 2 Aug 2020 18:43:56 -0400
Leo Famulari <leo <at> famulari.name> wrote:

> * Enable the DMA-BUF userland memory heaps? This options creates per
> heap chardevs in /dev/dma_heap/ which allows userspace to allocate
> dma-bufs that can be shared between drivers. (DMABUF_HEAPS)
> 
> I don't really know what that means.

DMA ("direct memory access") is a method to automatically have devices transfer
memory blocks to (and/or from) volatile memory without the involvement of the
CPU.

dma-bufs are buffers that can be used for DMA.  These are distinct from regular
buffers because DMA is done without the involvement of the CPU, so setting up
a DMA buffer, telling the device the buffer location, and then freeing (or
swapping out) the buffer would be very bad (the device wouldn't know that it
is freed and would just continue using it, bypassing all the usual kernel
access checks--because it doesn't use the CPU in the first place).

A dma-buf heap is an allocator for dma-buf buffers and some limits where it
can allocate.  That is needed because peripheral chips have all kinds of
weird limitations on where the dma-buf buffer can be in memory (for example
some GPUs require the dma-buf buffers to be in the first 256 MiB of memory),
so the allocator has to take into account that the later devices can actually
reach the buffers and give them a dma-buf buffer at some weird location,
aliged like the device likes it and size-padded so the device doesn't
scribble over something else while using potentially huge block transfers.

A dma-buf userland memory heap is a device file in directory /dev/dma_heap/
which is connected to one specific dma-buf heap allocator in the kernel.
A userspace program can then use a weird ioctl to request a dma-buf buffer,
which then will be allocated.  A file descriptor will be returned to the
userspace program.  This FD can be inherited by child processes etc--the
usual.

These dma-buf buffers are annoying in that you can't swap them out, free them
and reallocate them later--or anything else you would do with normal memory.
Also, when using them you need to use a memory fence in order to synchronize
accesses between the CPU and the other devices that are using the buffer.

That means allocating those dma-buf buffers without needing them is a great
way to exhaust all RAM, with the kernel not having any recourse in reclaiming
them.  So, require root.

If the heap allocator that is used for that has a device-specific limit,
that is much safer, though.

The thing is mostly used by Android.

[Message part 2 (application/pgp-signature, inline)]

Message #26 received at 42686 <at> debbugs.gnu.org (full text, mbox):

From: Leo Famulari <leo <at> famulari.name>
To: Danny Milosavljevic <dannym <at> scratchpost.org>
Cc: 42686 <at> debbugs.gnu.org
Subject: Re: [bug#42686] Update to linux-libre 5.7
Date: Wed, 5 Aug 2020 13:24:34 -0400

[Message part 1 (text/plain, inline)]

On Tue, Aug 04, 2020 at 12:36:57PM +0200, Danny Milosavljevic wrote:
> DMA ("direct memory access") is a method to automatically have devices transfer
> memory blocks to (and/or from) volatile memory without the involvement of the
> CPU.

Thanks for your detailed explanation! I decided not to enable this
feature since it seems less relevant to systems that can run Guix. Of
course, we can enable it if requested.

[signature.asc (application/pgp-signature, inline)]

Message #29 received at 42686 <at> debbugs.gnu.org (full text, mbox):

From: Leo Famulari <leo <at> famulari.name>
To: Ricardo Wurmus <rekado <at> elephly.net>
Cc: 42686 <at> debbugs.gnu.org
Subject: Re: [bug#42686] Update to linux-libre 5.7
Date: Wed, 5 Aug 2020 13:25:23 -0400

On Tue, Aug 04, 2020 at 12:04:56PM +0200, Ricardo Wurmus wrote:
> I do!  I just added “kernel-updates” to the specifications.

Thanks!

> All people with an account on ci.guix.gnu.org should be able to generate
> a client certificate for themselves.  Documentation and scripts are in
> the /root/maintenance directory.

Cool. I don't have an account on ci.guix.gnu.org. I don't think I need
one, since this kernel-updates job specification should keep working for
future kernel updates.

Message #34 received at 42686-done <at> debbugs.gnu.org (full text, mbox):

From: Leo Famulari <leo <at> famulari.name>
To: 42686-done <at> debbugs.gnu.org
Subject: Re: Update to linux-libre 5.7
Date: Wed, 5 Aug 2020 13:27:16 -0400

[Message part 1 (text/plain, inline)]

The CI server successfully built linux-libre 5.7 for x86_64, i686, and
aarch64:

http://ci.guix.gnu.org/search?query=spec%3Akernel-updates+linux-libre-5.7

I guess that it doesn't build kernels for armhf, since it appears that
nothing was attempted.

Anyways, I pushed the update as 843344273c6a587b8e6c84d8406500fd64d8908a

Please report any problems!

[signature.asc (application/pgp-signature, inline)]

Message #37 received at 42686 <at> debbugs.gnu.org (full text, mbox):

From: Mathieu Othacehe <othacehe <at> gnu.org>
To: 42686 <at> debbugs.gnu.org
Cc: leo <at> famulari.name
Subject: Re: bug#42686: Update to linux-libre 5.7
Date: Thu, 06 Aug 2020 09:35:05 +0200

Hey,

> I guess that it doesn't build kernels for armhf, since it appears that
> nothing was attempted.

They should be built too, the "omap2plus" arm variant has been built
successfully, see: https://ci.guix.gnu.org/build/3083232/details.

Anyway, looking good, thanks for the update :)

Mathieu

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.