Update to linux-libre 5.7

  • Done
  • quality assurance status badge
Details
4 participants
  • Danny Milosavljevic
  • Leo Famulari
  • Mathieu Othacehe
  • Ricardo Wurmus
Owner
unassigned
Submitted by
Leo Famulari
Severity
normal
L
L
Leo Famulari wrote on 3 Aug 2020 00:43
(address . guix-patches@gnu.org)
20200802224356.GA4714@jasmine.lan
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?
Attachment: 0001-gnu-linux-libre-Update-to-5.7.12.patch
-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEEsFFZSPHn08G5gDigJkb6MLrKfwgFAl8nQakACgkQJkb6MLrK
fwiKhw/9HXSlSHfP+urPB2N2LMDt91Sr9A+I5rHJisHOKp0lYBHInFcb6HcPFt0l
Nou8geYznoD28fJNjE1chT3STP5N3msfz4wfHH/74mCiXHkmD9ohQHyiiWzs3gk4
HxELZFnNFg/AsaZ0L4KeAt4kP1tdWEuhxx9AW72JcO+VoemKUWJjBFxUN3VpPkcf
0cSsehnPoCVpFefpmX2poeGZroGulu+jRF7v4PJS3icyS4MltvcK3QyjEAZWcXDn
8cAgBk5Nd9U+vEwfy46KyGbKepl8p2xY/62rzJ/bbqciOy+gPEI9XtLXXYSK16aM
ZjckmSXMPfKhj3djoF8T9Q2Jz1Swpx458bcfRBbGwvRGbjkBBEwvzbLwiR1G5VOF
weg6YSaHk+DC+53ZIZpG+4cSt0MGnS1Zu0S5TTynGoZzulMeQOlZCNHqT3nOUliC
Pr8XlBneGiWj8Fa7hv73gtf4ivhbkyM8/iavsv4PbVaIakptPsgGLF0swMnOSz+F
iazu5oZUHibYJQcK3g4cO3mjWe1AuyQZdO4NwlirSrNLTYDohlzp4Yfqz6qNtOIc
FFhroY0cPfeklLIdx2Z55Cbo4yRbOpx9yltneqjS6jW5QX3JcmuJ5pgDl1013obo
shT9gbSTxA85LJhj1pNZezsPDiJm/F13LRmqbHFYJeqqRoxXgOA=
=C08k
-----END PGP SIGNATURE-----


M
M
Mathieu Othacehe wrote on 3 Aug 2020 10:08
(name . Leo Famulari)(address . leo@famulari.name)(address . 42686@debbugs.gnu.org)
878sewup6e.fsf@gnu.org
Hey Leo,

Toggle quote (12 lines)
> 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

Toggle quote (5 lines)
> * 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.

Toggle quote (6 lines)
> * 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.

Toggle quote (3 lines)
>
> * Should USB4 (Thunderbolt) be built-in? Or a module?

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

Thanks,

Mathieu

L
L
Leo Famulari wrote on 3 Aug 2020 19:42
(name . Mathieu Othacehe)(address . othacehe@gnu.org)(address . 42686@debbugs.gnu.org)
20200803174200.GA16760@jasmine.lan
On Mon, Aug 03, 2020 at 10:08:41AM +0200, Mathieu Othacehe wrote:
Toggle quote (10 lines)
> 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.

Toggle quote (8 lines)
> > * 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...

Toggle quote (9 lines)
> > * 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.
R
R
Ricardo Wurmus wrote on 3 Aug 2020 23:00
(name . Leo Famulari)(address . leo@famulari.name)(address . 42686@debbugs.gnu.org)
87tuxjfnrj.fsf@elephly.net
Leo Famulari <leo@famulari.name> writes:

Toggle quote (4 lines)
> 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


and add “kernel-updates” to the specifications.

--
Ricardo
L
L
Leo Famulari wrote on 3 Aug 2020 23:55
(name . Ricardo Wurmus)(address . rekado@elephly.net)(address . 42686@debbugs.gnu.org)
20200803215529.GA16925@jasmine.lan
On Mon, Aug 03, 2020 at 11:00:32PM +0200, Ricardo Wurmus wrote:
Toggle quote (13 lines)
>
> Leo Famulari <leo@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?
R
R
Ricardo Wurmus wrote on 4 Aug 2020 12:04
(name . Leo Famulari)(address . leo@famulari.name)(address . 42686@debbugs.gnu.org)
87o8nqg20n.fsf@elephly.net
Leo Famulari <leo@famulari.name> writes:

Toggle quote (16 lines)
> On Mon, Aug 03, 2020 at 11:00:32PM +0200, Ricardo Wurmus wrote:
>>
>> Leo Famulari <leo@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.

Toggle quote (3 lines)
> 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
D
D
Danny Milosavljevic wrote on 4 Aug 2020 12:36
(name . Leo Famulari)(address . leo@famulari.name)(address . 42686@debbugs.gnu.org)
20200804123657.67daa48e@scratchpost.org
Hi Leo,

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

Toggle quote (6 lines)
> * 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.
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCgAdFiEEds7GsXJ0tGXALbPZ5xo1VCwwuqUFAl8pOkkACgkQ5xo1VCww
uqVx3Qf/TEKS5+TG14ryOB6Tt66E4SUg7/yyTnE+PK1GFo/M6bkS1s+sXGuL0z74
+PB16P+zlfFYcDyF4HDwrIFjk9t22foutfbIJkEdTq0osKdPIt/hbIqVLM5qrhdI
n+EYdjMf/lYbPnNZVkJPdk73CUDTWXptU6aWyN2j39l3GJxcRUA58kWY34lF+jCc
V0uRMeMVdzCNALZrcz9zY/Hb9gFQE2z4DKd8lVSltJs1aec3Qlu1eaIJC9g0O55f
45pVJffSPuyIgbuedxQch6UuIBkwndGO8xw4H9o9sqoc0F30jx2Hg+BfnAb/fa2z
FEcjb51wHQiCp4R6ZdkHmHXnolHZ2g==
=/j25
-----END PGP SIGNATURE-----


L
L
Leo Famulari wrote on 5 Aug 2020 19:24
(name . Danny Milosavljevic)(address . dannym@scratchpost.org)(address . 42686@debbugs.gnu.org)
20200805172434.GA8394@jasmine.lan
On Tue, Aug 04, 2020 at 12:36:57PM +0200, Danny Milosavljevic wrote:
Toggle quote (4 lines)
> 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.
-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEEsFFZSPHn08G5gDigJkb6MLrKfwgFAl8q61IACgkQJkb6MLrK
fwizIw//YItHR22Br5VyxyQUVA4RDwOZIx3ApfyQR9RXyDsAJpeej++xX58dyBTL
XwAYsEHiymM1ia9pgXl7ZlhEJYO5LXjMBYC2d1OgkzQzbzck7fK+4DcYEK8Dbl+3
hORH2RVgoatTBxZ2jql3MIb0vTEn7loty+lZtMy9C3Jh+MoexzBE/mRhNoCliBIW
4pp0dL/j2uXLEkBCNy3dYEaA0i2ytT8oFtZ0Kb9QOCAxfeANbCIoSAeUJhtJGvPA
xAMIqXB/xF/b/oPpkiPv8ADQHNHlxY8QtARp3nP8ymg9qB1CARGI4UUeTkOQuOMd
zQ8Mpuad6SsO1PLZc/LA7V9myoEbQdI0mePkHPFGMIwWI3wK/0O7WR/nS+4WUK/k
IffJF4l/LwkYjqDFtH5Ep2ARIKUl8MvBt2xYAGRzimyB2BtAadS2jAmRhBISSzKu
uIRv6oteGXCj40evajm4Jkqr7EFLhzB0UT2Ylkt9jsM0ykumpiwr8IVPs9N9XSw7
4iHhiGWqAEB6jCCqgoSP/zgrbZP29nN1YBggx+tsD7m9nWgREgtOsPh4d5omOJMy
NXAfdLEuBa9Y4SbCQ4EkZI8Hk8i9hhHHd4IxKKlxV+ifVlH+7jq6bocSaZEEm5O5
LrIwmJgUP6kWD7NcOF7+hDQWeTLjaPqESaKY9BGOJ8Ubo5kK554=
=kmtd
-----END PGP SIGNATURE-----


L
L
Leo Famulari wrote on 5 Aug 2020 19:25
(name . Ricardo Wurmus)(address . rekado@elephly.net)(address . 42686@debbugs.gnu.org)
20200805172523.GB8394@jasmine.lan
On Tue, Aug 04, 2020 at 12:04:56PM +0200, Ricardo Wurmus wrote:
Toggle quote (2 lines)
> I do! I just added “kernel-updates” to the specifications.

Thanks!

Toggle quote (4 lines)
> 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.
L
L
Leo Famulari wrote on 5 Aug 2020 19:27
Re: Update to linux-libre 5.7
(address . 42686-done@debbugs.gnu.org)
20200805172716.GA8526@jasmine.lan
The CI server successfully built linux-libre 5.7 for x86_64, i686, and
aarch64:


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!
-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEEsFFZSPHn08G5gDigJkb6MLrKfwgFAl8q6/QACgkQJkb6MLrK
fwhGGg//XOoTqoDj3A+WSy+cqfvpfWKmxcnnfwMEV+4rp4NcUR/O+pTjrpR4trwz
hlQ5DTPp1/kP2fTmYwpS2CGVT4Pkm2oRliXmVoF5sNwB2jwl5CHkUnDJQKC4TAmh
rkcHy1se98345CntDXNHbaMn5dY7iMXh/+MMFKayviqT1ok2RZXModXtB53OCOPx
jCK9A8OzLANxY0wmw2bPtaD9fFv1w44a3YWw+7wKt7tSRVpCbBFpCsHf0c3Rn1P3
qvXz4N24NP3wo+vfB8rbujrgaQujKDNt44gSBai7CseELuGtwXLjfE0f14mcCJo+
h1eDwQnkH8YgaD4svz2fbiQ3+sI2qGY0IOPa6aBxtgK3ncbWnPnXaGgQGRU0Lu5m
cNj5NwnybvEEH8qpavAftjnHYjQW0PSOP0HZgdK+M1jxWysk4jTwSZ0VcvIPo+JR
27lvormHGBBB4k7d3y2rXH93IBl5Gy4xKzI/GkSIRClOVqPYsxoGlmvFnEC4wFhl
Bm7TYHiMwY97sDVvhKkkp6WLOCporTtff3wfalYZIeHmWT6cQoKtegE5iW0D55Vr
BkaiZPCIurxPKBmbZUU2cljcif2EaLxxaA/Rxm74QWJ83iGqYOaUwb41EUGEUi6y
EeNlDUfphu3/JW5IxhPiWEgGgtB00D7wrMML2gVM/nsyv6+Y2es=
=U7zU
-----END PGP SIGNATURE-----


Closed
M
M
Mathieu Othacehe wrote on 6 Aug 2020 09:35
Re: bug#42686: Update to linux-libre 5.7
(address . 42686@debbugs.gnu.org)(address . leo@famulari.name)
87h7tgut06.fsf@gnu.org
Hey,

Toggle quote (3 lines)
> 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

Anyway, looking good, thanks for the update :)

Mathieu
?