The Latest Kernel Release.

cwizardone · 11-25-2021, 07:01 AM

To those who celebrate this day, have a Happy Thanksgiving!

A second batch of release candidates for the current round of updates have been made available for testing.

5.10.82-rc2, with 153 patches, http://lkml.iu.edu/hypermail/linux/k...1.3/02869.html

5.4.162-rc2, with 100 patches, http://lkml.iu.edu/hypermail/linux/k...1.3/02871.html

4.19.218-rc2, with 321 patches, http://lkml.iu.edu/hypermail/linux/k...1.3/02966.html

4.14.256-rc2, with 250 patches, http://lkml.iu.edu/hypermail/linux/k...1.3/03029.html

4.9.291-rc2, with 206 patches, http://lkml.iu.edu/hypermail/linux/k...1.3/03063.html

4.4.293-rc2, with 160 patches, http://lkml.iu.edu/hypermail/linux/k...1.3/03092.html

cwizardone · 11-25-2021, 10:16 AM

And a third batch of release candidates:

4.19.218-rc3, with 320 patches, http://lkml.iu.edu/hypermail/linux/k...1.3/03266.html

4.14.256-rc3, with 248 patches, http://lkml.iu.edu/hypermail/linux/k...1.3/03265.html

4.9.291-rc3, with 204 patches, http://lkml.iu.edu/hypermail/linux/k...1.3/03263.html

4.4.293-rc3, with 159 patches, http://lkml.iu.edu/hypermail/linux/k...1.3/03260.html

TheRealGrogan · 11-25-2021, 11:16 AM

I don't think those changes in signal handling implementation in 5.15.5 should be going in a stable point release.

It looks like a backend thing that enforces more correct behaviour, but I'm going to wait and see if any of that gets reverted.

volkerdi · 11-25-2021, 10:11 PM

Hey folks, sorry about the lack of updates today (and happy Thanksgiving to my U.S. friends!)

Ran into a regression in 5.15.5 where it works fine on 64-bit but 32-bit yields a boot hang. A kernel bisect identified the issue was caused by:

Quote:

commit 2495decce774389f60d1942ba647f691f50f575e
Author: Borislav Petkov <bp@suse.de>
Date: Fri Nov 5 10:41:51 2021 +0100

x86/boot: Pull up cmdline preparation and early param parsing

commit 8d48bf8206f77aa8687f0e241e901e5197e52423 upstream.

Dan reports that Anjaneya Chagam can no longer use the efi=nosoftreserve
kernel command line parameter to suppress "soft reservation" behavior.

This is due to the fact that the following call-chain happens at boot:

early_reserve_memory
|-> efi_memblock_x86_reserve_range
|-> efi_fake_memmap_early

which does

if (!efi_soft_reserve_enabled())
return;

and that would have set EFI_MEM_NO_SOFT_RESERVE after having parsed
"nosoftreserve".

However, parse_early_param() gets called *after* it, leading to the boot
cmdline not being taken into account.

Therefore, carve out the command line preparation into a separate
function which does the early param parsing too. So that it all goes
together.

And then call that function before early_reserve_memory() so that the
params would have been parsed by then.

Fixes: 8aa83e6395ce ("x86/setup: Call early_reserve_memory() earlier")
Reported-by: Dan Williams <dan.j.williams@intel.com>
Reviewed-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Tested-by: Anjaneya Chagam <anjaneya.chagam@intel.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/e8dd8993c3...amel@intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

I've mailed stable@vger, so we'll see what happens.

marav · 11-26-2021, 04:07 AM

Kernel updates 5.10.82, 5.4.162, 4.19.218, 4.14.256, 4.9.291 and 4.4.293 are now available at, https://www.kernel.org/

The change logs,

https://cdn.kernel.org/pub/linux/ker...ngeLog-5.10.82

https://cdn.kernel.org/pub/linux/ker...ngeLog-5.4.162

https://cdn.kernel.org/pub/linux/ker...geLog-4.19.218

https://cdn.kernel.org/pub/linux/ker...geLog-4.14.256

https://cdn.kernel.org/pub/linux/ker...ngeLog-4.9.291

https://cdn.kernel.org/pub/linux/ker...ngeLog-4.4.293

Jan K. · 11-26-2021, 09:28 AM

Quote:

Originally Posted by volkerdi

Hey folks, sorry about the lack of updates today...

I forgive you!

marav · 11-28-2021, 02:26 PM

Quote:

Originally Posted by volkerdi

Hey folks, sorry about the lack of updates today (and happy Thanksgiving to my U.S. friends!)

Ran into a regression in 5.15.5 where it works fine on 64-bit but 32-bit yields a boot hang. A kernel bisect identified the issue was caused by:

I've mailed stable@vger, so we'll see what happens.

Probably this one

https://git.kernel.org/pub/scm/linux...5b2b42d7c43ac9

marav · 11-28-2021, 04:44 PM

5.16-rc3
Release Candidate 3, for the 5.16 "mainline" development kernel has been been made available for testing

https://git.kernel.org/torvalds/t/linux-5.16-rc3.tar.gz

Mr. Torvalds' announcement,

https://lkml.org/lkml/2021/11/28/300

cwizardone · 11-28-2021, 04:49 PM

As of the moment, the tarball is "not found."

USUARIONUEVO · 11-28-2021, 05:31 PM

Quote:

Originally Posted by cwizardone

As of the moment, the tarball is "not found."

Here download , no problem.

marav · 11-28-2021, 05:43 PM

Quote:

Originally Posted by marav

Probably this one

https://git.kernel.org/pub/scm/linux...5b2b42d7c43ac9

with

Code:

diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index c410be738ae78..6a190c7f4d71b 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -742,7 +742,7 @@ dump_kernel_offset(struct notifier_block *self, unsigned long v, void *p)
 	return 0;
 }
 
-static char *prepare_command_line(void)
+static char * __init prepare_command_line(void)
 {
 #ifdef CONFIG_CMDLINE_BOOL
 #ifdef CONFIG_CMDLINE_OVERRIDE

It seems to work

Code:

root@slack32:~# uname -a
Linux slack32.local 5.15.5-smp #1 SMP PREEMPT Sun Nov 28 20:48:32 CET 2021 i686 AMD Ryzen 7 5700U with Radeon Graphics AuthenticAMD GNU/Linux

volkerdi · 11-28-2021, 11:11 PM

Quote:

Originally Posted by marav

Probably this one

https://git.kernel.org/pub/scm/linux...5b2b42d7c43ac9

Nope.

Tried it, hangs the same way. I think I'm looking at something a little more obscure... I tried two other machines here and both of them booted the problem kernel just fine.

I'll push the next kernel no matter what and then we'll see if this is widespread or not. If it isn't, probably I'll dump the i7 for a Ryzen as my main build box.

Or, as the developer who got back to me on this helpfully suggested, I could just run the "orders of magnitude" better tested x86_64 kernel instead.

LuckyCyborg · 11-29-2021, 02:59 AM

Quote:

Originally Posted by volkerdi

Nope.

Tried it, hangs the same way. I think I'm looking at something a little more obscure... I tried two other machines here and both of them booted the problem kernel just fine.

I'll push the next kernel no matter what and then we'll see if this is widespread or not. If it isn't, probably I'll dump the i7 for a Ryzen as my main build box.

Or, as the developer who got back to me on this helpfully suggested, I could just run the "orders of magnitude" better tested x86_64 kernel instead.

This means you consider shipping a x86_64 kernel on Slackware i586?

IF yes, this would be fantastic great news, because the Slackware i586 works perfectly with a x86_64 kernel and it's probably the fastest combination possible (even faster than Slackware64), at least according with my own humble experiments.

However, there's needed a x86_64 cross-compiler or a "reverse multilib" compiler, which where's I struggled a lot.

But, certainly for you this would not be a problem, if you intend to adopt this design.

cwizardone · 11-29-2021, 12:40 PM

Year 2021, Round 80

Another batch of updates has been scheduled for release on Wednesday, 01 December 2021, at approximately 18:00, GMT. If no problems are found while testing the release candidates, they might be available sometime on Tuesday (depending on your time zone).

The details:

5.15.6-rc1, with 179 patches, http://lkml.iu.edu/hypermail/linux/k...1.3/06760.html

5.10.83-rc1, with 121 patches, http://lkml.iu.edu/hypermail/linux/k...1.3/07320.html

5.4.163-rc1, with 92 patches, http://lkml.iu.edu/hypermail/linux/k...1.3/06636.html

4.19.219-rc1, with 69 patches, http://lkml.iu.edu/hypermail/linux/k...1.3/06622.html

volkerdi · 11-29-2021, 12:57 PM

Quote:

Originally Posted by LuckyCyborg

This means you consider shipping a x86_64 kernel on Slackware i586?

IF yes, this would be fantastic great news, because the Slackware i586 works perfectly with a x86_64 kernel and it's probably the fastest combination possible (even faster than Slackware64), at least according with my own humble experiments.

However, there's needed a x86_64 cross-compiler or a "reverse multilib" compiler, which where's I struggled a lot.

But, certainly for you this would not be a problem, if you intend to adopt this design.

Clearly you took this comment the wrong way.

I suspect the person who wrote to me had no idea my use case was developing a 32-bit Linux distribution.

I've personally used an x86_64 kernel with a 32-bit userspace before, and it works great. But as you point out, it's not self-hosting without a lot of additional complexity, and therefore it's extremely unlikely that I'd ever ship 32-bit Slackware with an x86_64 kernel.