The series contains stuff I caught last week while working on some
x86 code. It can be considered a material for fixes or for next,
I'm okay with either, although leaning more towards fixes :P
Notes on patches:
* 0001: I didn't put any "Fixes:" tag since it's not linear. The
lines changed with this patch came from the initial x86
KASLR series, but that unconditional jump to the kernel
beginning already was there. It goes at least from the set
that brought relocatable kernel support to x86, but this
is quite prehistoric already and might not look really
relatable. So up to you whether it needs any.
* 0002: doesn't fix anything, except that having any files listed
in that whitelist already is an architecture bug :D And
it wouldn't be convenient to decouple it from #0001, but
up to you as well.
From v1[0]:
* collect the Tested-by tags (Jiri);
* don't add pathetic returns after noreturn error() (Jiri);
* debug-print the entry point offset via debug_putaddr() before
booting (Jiri);
* always have an empty line before return statements (Jiri).
[0] https://lore.kernel.org/all/[email protected]
Alexander Lobakin (2):
x86/boot: robustify calling startup_{32,64}() from the decompressor
code
scripts/head-object-list: remove x86 from the list
arch/x86/boot/compressed/head_32.S | 2 +-
arch/x86/boot/compressed/head_64.S | 2 +-
arch/x86/boot/compressed/misc.c | 16 ++++++++++------
scripts/head-object-list.txt | 6 ------
4 files changed, 12 insertions(+), 14 deletions(-)
--
2.38.1
Now that x86 boot code is not hardcoded to the particular linking
order, remove x86 files from the list and let them be placed inside
the vmlinux according only to the linker script and linker
preferences.
Tested-by: Jiri Slaby <[email protected]>
Signed-off-by: Alexander Lobakin <[email protected]>
---
scripts/head-object-list.txt | 6 ------
1 file changed, 6 deletions(-)
diff --git a/scripts/head-object-list.txt b/scripts/head-object-list.txt
index b16326a92c45..405d2942898a 100644
--- a/scripts/head-object-list.txt
+++ b/scripts/head-object-list.txt
@@ -44,10 +44,4 @@ arch/s390/kernel/head64.o
arch/sh/kernel/head_32.o
arch/sparc/kernel/head_32.o
arch/sparc/kernel/head_64.o
-arch/x86/kernel/head_32.o
-arch/x86/kernel/head_64.o
-arch/x86/kernel/head32.o
-arch/x86/kernel/head64.o
-arch/x86/kernel/ebda.o
-arch/x86/kernel/platform-quirks.o
arch/xtensa/kernel/head.o
--
2.38.1
From: Alexander Lobakin <[email protected]>
Date: Tue, 1 Nov 2022 17:15:27 +0100
> The series contains stuff I caught last week while working on some
> x86 code. It can be considered a material for fixes or for next,
> I'm okay with either, although leaning more towards fixes :P
>
> Notes on patches:
> * 0001: I didn't put any "Fixes:" tag since it's not linear. The
> lines changed with this patch came from the initial x86
> KASLR series, but that unconditional jump to the kernel
> beginning already was there. It goes at least from the set
> that brought relocatable kernel support to x86, but this
> is quite prehistoric already and might not look really
> relatable. So up to you whether it needs any.
> * 0002: doesn't fix anything, except that having any files listed
> in that whitelist already is an architecture bug :D And
> it wouldn't be convenient to decouple it from #0001, but
> up to you as well.
>
> From v1[0]:
> * collect the Tested-by tags (Jiri);
> * don't add pathetic returns after noreturn error() (Jiri);
> * debug-print the entry point offset via debug_putaddr() before
> booting (Jiri);
> * always have an empty line before return statements (Jiri).
>
> [0] https://lore.kernel.org/all/[email protected]
>
> Alexander Lobakin (2):
> x86/boot: robustify calling startup_{32,64}() from the decompressor
> code
> scripts/head-object-list: remove x86 from the list
>
> arch/x86/boot/compressed/head_32.S | 2 +-
> arch/x86/boot/compressed/head_64.S | 2 +-
> arch/x86/boot/compressed/misc.c | 16 ++++++++++------
> scripts/head-object-list.txt | 6 ------
> 4 files changed, 12 insertions(+), 14 deletions(-)
Ping?
Also, I managed to remove .head.text at all from x86. Would it be
better to respin this series with the third patch or send a
follow-up later?
>
> --
> 2.38.1
Thanks,
Olek
On 11/7/22 04:55, Alexander Lobakin wrote:
> Ping?
>
> Also, I managed to remove .head.text at all from x86. Would it be
> better to respin this series with the third patch or send a
> follow-up later?
>
Hi Alexander,
Things are a bit busy in the review queue at the moment. As always,
we'd love help reviewing stuff. So, while you're waiting for us to
review this, could you perhaps look around and find a series that's also
hurting for review tags?
From: Dave Hansen <[email protected]>
Date: Tue, 8 Nov 2022 15:09:07 -0800
> On 11/7/22 04:55, Alexander Lobakin wrote:
> > Ping?
> >
> > Also, I managed to remove .head.text at all from x86. Would it be
> > better to respin this series with the third patch or send a
> > follow-up later?
> >
>
> Hi Alexander,
Hey,
>
> Things are a bit busy in the review queue at the moment. As always,
> we'd love help reviewing stuff. So, while you're waiting for us to
> review this, could you perhaps look around and find a series that's also
> hurting for review tags?
I've got Reviewed-by and Tested-by from Jiri, isn't that enough? Or
I need also some other group to get tags from?
Thanks,
Olek
On Mon, Nov 21, 2022 at 01:09:18PM +0100, Alexander Lobakin wrote:
> > Things are a bit busy in the review queue at the moment. As always,
> > we'd love help reviewing stuff. So, while you're waiting for us to
> > review this, could you perhaps look around and find a series that's also
> > hurting for review tags?
>
> I've got Reviewed-by and Tested-by from Jiri, isn't that enough? Or
> I need also some other group to get tags from?
What he actually means is if *you* yourself help out with patch review.
Like find a set on lkml which you're interested in - I believe there
will be no shortage of such sets - and poke at it, review it, ask
devil's advocate questions, etc.
The distribution of work - gazillion submitters vs a handful of
maintainers simply cannot scale and instead of submitters pinging
maintainers all the time when they can look at their set, submitters
could review other submitters' work in the meantime, while waiting.
I.e., a win-win-win situation. :-)
Makes more sense?
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
From: Borislav Petkov <[email protected]>
Date: Mon, 21 Nov 2022 14:14:43 +0100
> On Mon, Nov 21, 2022 at 01:09:18PM +0100, Alexander Lobakin wrote:
> > > Things are a bit busy in the review queue at the moment. As always,
> > > we'd love help reviewing stuff. So, while you're waiting for us to
> > > review this, could you perhaps look around and find a series that's also
> > > hurting for review tags?
> >
> > I've got Reviewed-by and Tested-by from Jiri, isn't that enough? Or
> > I need also some other group to get tags from?
>
> What he actually means is if *you* yourself help out with patch review.
> Like find a set on lkml which you're interested in - I believe there
> will be no shortage of such sets - and poke at it, review it, ask
> devil's advocate questions, etc.
>
> The distribution of work - gazillion submitters vs a handful of
> maintainers simply cannot scale and instead of submitters pinging
> maintainers all the time when they can look at their set, submitters
> could review other submitters' work in the meantime, while waiting.
>
> I.e., a win-win-win situation. :-)
>
> Makes more sense?
I know, I got it from the first read :D I try to review stuff I have
mature knowledge in each day, not that lots of them are from the x86
ML :s
>
> --
> Regards/Gruss,
> Boris.
>
> https://people.kernel.org/tglx/notes-about-netiquette
Thanks,
Olek
From: Alexander Lobakin <[email protected]>
Date: Mon, 21 Nov 2022 17:00:30 +0100
> From: Borislav Petkov <[email protected]>
> Date: Mon, 21 Nov 2022 14:14:43 +0100
>
> > On Mon, Nov 21, 2022 at 01:09:18PM +0100, Alexander Lobakin wrote:
> > > > Things are a bit busy in the review queue at the moment. As always,
> > > > we'd love help reviewing stuff. So, while you're waiting for us to
> > > > review this, could you perhaps look around and find a series that's also
> > > > hurting for review tags?
[...]
> I know, I got it from the first read :D I try to review stuff I have
> mature knowledge in each day, not that lots of them are from the x86
> ML :s
I was hoping it would hit one of the 6.1 RCs as a fix, oh well :D
Why did some other fixes hit the x86 tree during that time then?
>
> >
> > --
> > Regards/Gruss,
> > Boris.
> >
> > https://people.kernel.org/tglx/notes-about-netiquette
>
> Thanks,
> Olek
Thanks,
Olek
On Wed, Dec 07, 2022 at 04:08:54PM +0100, Alexander Lobakin wrote:
> I was hoping it would hit one of the 6.1 RCs as a fix,
As a fix for which existing configuration which breaks if this fix is
missing?
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
From: Borislav Petkov <[email protected]>
Date: Wed, 7 Dec 2022 16:24:00 +0100
> On Wed, Dec 07, 2022 at 04:08:54PM +0100, Alexander Lobakin wrote:
> > I was hoping it would hit one of the 6.1 RCs as a fix,
>
> As a fix for which existing configuration which breaks if this fix is
> missing?
Ugh, fair enough :D Without it, FG-KASLR is broken, GCC-LTO is
broken, but none of them is in the mainline.
I recall there were some folks with LLD for which this $(head-y)
removal caused issues as well. But if they're quiet now, seems like
they don't hardly need it.
But not every fix is a fix only when it's easy to find a repro,
right...? But at least such are not urgent, you're correct here.
>
> --
> Regards/Gruss,
> Boris.
>
> https://people.kernel.org/tglx/notes-about-netiquette
Thanks,
Olek
On Wed, Dec 07, 2022 at 04:30:00PM +0100, Alexander Lobakin wrote:
> But not every fix is a fix only when it's easy to find a repro,
> right...?
The basic rule is: only regression fixes during the -rc phase.
Documentation/process/2.Process.rst
although there it is not spelled out that it is regressions only. But
this is the rule we adhere to in the tip tree in general.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette