Backport request

Backport request

[Thomas Gleixner]

[-- Attachment #1: Type: text/plain, Size: 991 bytes --]

Folks!

There are more and more people worried about these usually harmless
warnings:

	do_IRQ: 0.39 No irq handler for vector

It took a while to figure out why that happens and why it is harmless for
most interrupts, but there is also a real issue hidden for level type
IOAPIC interrupts.

The following commits in Linus tree are addressing the issue:

 b7107a67f0d1 ("x86/irq: Handle spurious interrupt after shutdown gracefully")
 dfe0cf8b51b0 ("x86/ioapic: Implement irq_get_irqchip_state() callback")
 62e0468650c3 ("genirq: Add optional hardware synchronization for shutdown")
 1d21f2af8571 ("genirq: Fix misleading synchronize_irq() documentation")
 4001d8e8762f ("genirq: Delay deactivation in free_irq()")

There is another one which makes sense to be backported:

 f8a8fe61fec8 ("x86/irq: Seperate unused system vectors from spurious entry again")

These should go back to 4.19, but not farther.

They apply cleanly to 5.1 and 5.2. A backport to 4.19 is attached.

Thanks,

	tglx

[-- Attachment #2: Type: application/octet-stream, Size: 9027 bytes --]

Re: Backport request

[Greg KH]

On Wed, Jul 17, 2019 at 12:08:38AM +0200, Thomas Gleixner wrote:
> Folks!
> 
> There are more and more people worried about these usually harmless
> warnings:
> 
> 	do_IRQ: 0.39 No irq handler for vector
> 
> It took a while to figure out why that happens and why it is harmless for
> most interrupts, but there is also a real issue hidden for level type
> IOAPIC interrupts.
> 
> The following commits in Linus tree are addressing the issue:
> 
>  b7107a67f0d1 ("x86/irq: Handle spurious interrupt after shutdown gracefully")
>  dfe0cf8b51b0 ("x86/ioapic: Implement irq_get_irqchip_state() callback")
>  62e0468650c3 ("genirq: Add optional hardware synchronization for shutdown")
>  1d21f2af8571 ("genirq: Fix misleading synchronize_irq() documentation")
>  4001d8e8762f ("genirq: Delay deactivation in free_irq()")
> 
> There is another one which makes sense to be backported:
> 
>  f8a8fe61fec8 ("x86/irq: Seperate unused system vectors from spurious entry again")
> 
> These should go back to 4.19, but not farther.
> 
> They apply cleanly to 5.1 and 5.2. A backport to 4.19 is attached.

All now queued up, thanks for the backports!

greg k-h

Re: Backport request

[Sasha Levin]

On Wed, Jul 17, 2019 at 12:08:38AM +0200, Thomas Gleixner wrote:
> 4001d8e8762f ("genirq: Delay deactivation in free_irq()")

Thomas, would just this one be relevant for 4.14 (and older)?

--
Thanks,
Sasha

Re: Backport request

[Thomas Gleixner]

Sasha,

On Wed, 17 Jul 2019, Sasha Levin wrote:

> On Wed, Jul 17, 2019 at 12:08:38AM +0200, Thomas Gleixner wrote:
> > 4001d8e8762f ("genirq: Delay deactivation in free_irq()")
> 
> Thomas, would just this one be relevant for 4.14 (and older)?

No. There the vector handling is completely different.

Thanks,

	Thomas

backport request

[Ard Biesheuvel]

Please backport

0b2c29fb68f8bf3e87a9
efi/zboot: Limit compression options to GZIP and ZSTD

to v6.12. Future work on kexec and EFI zboot will only support those
compression methods, and currently, only Loongarch on Debian uses this
with a different compression method (XZ) and so now is the time to
make this change.

Thanks,
Ard.

Re: backport request

[Greg KH]

On Sat, Jan 18, 2025 at 10:10:11AM +0100, Ard Biesheuvel wrote:
> Please backport
> 
> 0b2c29fb68f8bf3e87a9
> efi/zboot: Limit compression options to GZIP and ZSTD
> 
> to v6.12. Future work on kexec and EFI zboot will only support those
> compression methods, and currently, only Loongarch on Debian uses this
> with a different compression method (XZ) and so now is the time to
> make this change.

Now queued up, thanks.

greg k-h

Backport request

[Hemdan, Hagar Gamal Halim]

Hi,

Please backport commit:

0faf84caee63 ("cpufreq: Replace deprecated strncpy() with strscpy()")

to stable trees 5.10.y, 5.15.y, 6.1.y and 6.6.y. This commit fixes possible
Buffer not null terminated of "policy->last_governor" and "default_governor"
in __cpufreq_offline() and cpufreq_core_init().

This bug was discovered and resolved using Coverity Static Analysis
Security Testing (SAST) by Synopsys, Inc.




Amazon Web Services Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 257764 B
Sitz: Berlin
Ust-ID: DE 365 538 597

Re: Backport request

[Greg KH]

On Sat, Nov 16, 2024 at 11:08:00AM +0000, Hemdan, Hagar Gamal Halim wrote:
> Hi,
> 
> Please backport commit:
> 
> 0faf84caee63 ("cpufreq: Replace deprecated strncpy() with strscpy()")
> 
> to stable trees 5.10.y, 5.15.y, 6.1.y and 6.6.y. This commit fixes possible
> Buffer not null terminated of "policy->last_governor" and "default_governor"
> in __cpufreq_offline() and cpufreq_core_init().

Are any in-kernel users actually affected by this?  At a quick glance, I
can't see any, so why would it need to be backported?

thanks,

greg k-h

Backport request

[Hemdan, Hagar Gamal Halim]

 Hi,

Please backport commit:

59f8f0b54c8f ("md/raid10: improve code of mrdev in raid10_sync_request")

to stable trees 5.4.y, 5.10.y, 5.15.y, 6.1.y. This commit fixes Dereference after
null check of "&mrdev->nr_pending" in raid10_sync_request().

This bug was discovered and resolved using Coverity Static Analysis
Security Testing (SAST) by Synopsys, Inc.






Amazon Web Services Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 257764 B
Sitz: Berlin
Ust-ID: DE 365 538 597

Re: Backport request

[Greg KH]

On Tue, Nov 12, 2024 at 10:31:12AM +0000, Hemdan, Hagar Gamal Halim wrote:
>  Hi,
> 
> Please backport commit:
> 
> 59f8f0b54c8f ("md/raid10: improve code of mrdev in raid10_sync_request")
> 
> to stable trees 5.4.y, 5.10.y, 5.15.y, 6.1.y. This commit fixes Dereference after
> null check of "&mrdev->nr_pending" in raid10_sync_request().
> 
> This bug was discovered and resolved using Coverity Static Analysis
> Security Testing (SAST) by Synopsys, Inc.
> 
> 
> 
> 
> 
> 
> Amazon Web Services Development Center Germany GmbH
> Krausenstr. 38
> 10117 Berlin
> Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
> Eingetragen am Amtsgericht Charlottenburg unter HRB 257764 B
> Sitz: Berlin
> Ust-ID: DE 365 538 597

Now queued up, thanks.

greg k-h

backport request

[Ard Biesheuvel]

Please consider commit

15aa8fb852f995dd
x86/efistub: Omit physical KASLR when memory reservations exist

for backporting to v6.1 and later.

Thanks,
Ard.

Re: backport request

[Greg KH]

On Wed, May 29, 2024 at 10:50:04AM +0200, Ard Biesheuvel wrote:
> Please consider commit
> 
> 15aa8fb852f995dd
> x86/efistub: Omit physical KASLR when memory reservations exist
> 
> for backporting to v6.1 and later.

Now queued up,t hanks.

greg k-h

Re: backport request

[Ard Biesheuvel]

On Thu, 6 Jun 2024 at 15:10, Greg KH <gregkh@linuxfoundation.org> wrote:
>
> On Wed, May 29, 2024 at 10:50:04AM +0200, Ard Biesheuvel wrote:
> > Please consider commit
> >
> > 15aa8fb852f995dd
> > x86/efistub: Omit physical KASLR when memory reservations exist
> >
> > for backporting to v6.1 and later.
>
> Now queued up,t hanks.
>

Thanks.

I don't see it in v6.1 though - was there a problem applying it there?

Re: backport request

[Greg KH]

On Fri, Jun 07, 2024 at 10:43:19AM +0200, Ard Biesheuvel wrote:
> On Thu, 6 Jun 2024 at 15:10, Greg KH <gregkh@linuxfoundation.org> wrote:
> >
> > On Wed, May 29, 2024 at 10:50:04AM +0200, Ard Biesheuvel wrote:
> > > Please consider commit
> > >
> > > 15aa8fb852f995dd
> > > x86/efistub: Omit physical KASLR when memory reservations exist
> > >
> > > for backporting to v6.1 and later.
> >
> > Now queued up,t hanks.
> >
> 
> Thanks.
> 
> I don't see it in v6.1 though - was there a problem applying it there?

Nope, it's right here:
	https://lore.kernel.org/all/20240606131701.442284898@linuxfoundation.org/

Re: backport request

[Ard Biesheuvel]

On Fri, 7 Jun 2024 at 12:23, Greg KH <gregkh@linuxfoundation.org> wrote:
>
> On Fri, Jun 07, 2024 at 10:43:19AM +0200, Ard Biesheuvel wrote:
> > On Thu, 6 Jun 2024 at 15:10, Greg KH <gregkh@linuxfoundation.org> wrote:
> > >
> > > On Wed, May 29, 2024 at 10:50:04AM +0200, Ard Biesheuvel wrote:
> > > > Please consider commit
> > > >
> > > > 15aa8fb852f995dd
> > > > x86/efistub: Omit physical KASLR when memory reservations exist
> > > >
> > > > for backporting to v6.1 and later.
> > >
> > > Now queued up,t hanks.
> > >
> >
> > Thanks.
> >
> > I don't see it in v6.1 though - was there a problem applying it there?
>
> Nope, it's right here:
>         https://lore.kernel.org/all/20240606131701.442284898@linuxfoundation.org/

I don't see it here

https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git/log/?h=linux-6.1.y

Re: backport request

[Ard Biesheuvel]

On Fri, 7 Jun 2024 at 12:25, Ard Biesheuvel <ardb@kernel.org> wrote:
>
> On Fri, 7 Jun 2024 at 12:23, Greg KH <gregkh@linuxfoundation.org> wrote:
> >
> > On Fri, Jun 07, 2024 at 10:43:19AM +0200, Ard Biesheuvel wrote:
> > > On Thu, 6 Jun 2024 at 15:10, Greg KH <gregkh@linuxfoundation.org> wrote:
> > > >
> > > > On Wed, May 29, 2024 at 10:50:04AM +0200, Ard Biesheuvel wrote:
> > > > > Please consider commit
> > > > >
> > > > > 15aa8fb852f995dd
> > > > > x86/efistub: Omit physical KASLR when memory reservations exist
> > > > >
> > > > > for backporting to v6.1 and later.
> > > >
> > > > Now queued up,t hanks.
> > > >
> > >
> > > Thanks.
> > >
> > > I don't see it in v6.1 though - was there a problem applying it there?
> >
> > Nope, it's right here:
> >         https://lore.kernel.org/all/20240606131701.442284898@linuxfoundation.org/
>
> I don't see it here
>
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git/log/?h=linux-6.1.y

Sorry, I meant here

https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git/log/?h=queue/6.1

the other queues do have it.

Re: backport request

[Greg KH]

On Fri, Jun 07, 2024 at 12:27:49PM +0200, Ard Biesheuvel wrote:
> On Fri, 7 Jun 2024 at 12:25, Ard Biesheuvel <ardb@kernel.org> wrote:
> >
> > On Fri, 7 Jun 2024 at 12:23, Greg KH <gregkh@linuxfoundation.org> wrote:
> > >
> > > On Fri, Jun 07, 2024 at 10:43:19AM +0200, Ard Biesheuvel wrote:
> > > > On Thu, 6 Jun 2024 at 15:10, Greg KH <gregkh@linuxfoundation.org> wrote:
> > > > >
> > > > > On Wed, May 29, 2024 at 10:50:04AM +0200, Ard Biesheuvel wrote:
> > > > > > Please consider commit
> > > > > >
> > > > > > 15aa8fb852f995dd
> > > > > > x86/efistub: Omit physical KASLR when memory reservations exist
> > > > > >
> > > > > > for backporting to v6.1 and later.
> > > > >
> > > > > Now queued up,t hanks.
> > > > >
> > > >
> > > > Thanks.
> > > >
> > > > I don't see it in v6.1 though - was there a problem applying it there?
> > >
> > > Nope, it's right here:
> > >         https://lore.kernel.org/all/20240606131701.442284898@linuxfoundation.org/
> >
> > I don't see it here
> >
> > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git/log/?h=linux-6.1.y
> 
> Sorry, I meant here
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git/log/?h=queue/6.1
> 
> the other queues do have it.

Those "queue" branches are auto-generated somehow on the backend, I have
no idea how that happens as I am not involved in them at all..  The
referenced commit is in the stable queue git repo, which is what we
actually work off of, and is what we generate the other things from
(releases, and -rcs), so I don't know what is going on here, sorry.  But
don't worry, the commit is in the quilt series to be applied in the next
6.1.y release.

thanks,

greg k-h

Re: backport request

[Ard Biesheuvel]

On Fri, 7 Jun 2024 at 12:46, Greg KH <gregkh@linuxfoundation.org> wrote:
>
> On Fri, Jun 07, 2024 at 12:27:49PM +0200, Ard Biesheuvel wrote:
> > On Fri, 7 Jun 2024 at 12:25, Ard Biesheuvel <ardb@kernel.org> wrote:
> > >
> > > On Fri, 7 Jun 2024 at 12:23, Greg KH <gregkh@linuxfoundation.org> wrote:
> > > >
> > > > On Fri, Jun 07, 2024 at 10:43:19AM +0200, Ard Biesheuvel wrote:
> > > > > On Thu, 6 Jun 2024 at 15:10, Greg KH <gregkh@linuxfoundation.org> wrote:
> > > > > >
> > > > > > On Wed, May 29, 2024 at 10:50:04AM +0200, Ard Biesheuvel wrote:
> > > > > > > Please consider commit
> > > > > > >
> > > > > > > 15aa8fb852f995dd
> > > > > > > x86/efistub: Omit physical KASLR when memory reservations exist
> > > > > > >
> > > > > > > for backporting to v6.1 and later.
> > > > > >
> > > > > > Now queued up,t hanks.
> > > > > >
> > > > >
> > > > > Thanks.
> > > > >
> > > > > I don't see it in v6.1 though - was there a problem applying it there?
> > > >
> > > > Nope, it's right here:
> > > >         https://lore.kernel.org/all/20240606131701.442284898@linuxfoundation.org/
> > >
> > > I don't see it here
> > >
> > > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git/log/?h=linux-6.1.y
> >
> > Sorry, I meant here
> >
> > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git/log/?h=queue/6.1
> >
> > the other queues do have it.
>
> Those "queue" branches are auto-generated somehow on the backend, I have
> no idea how that happens as I am not involved in them at all..  The
> referenced commit is in the stable queue git repo, which is what we
> actually work off of, and is what we generate the other things from
> (releases, and -rcs), so I don't know what is going on here, sorry.  But
> don't worry, the commit is in the quilt series to be applied in the next
> 6.1.y release.
>

Ah ok, good to know - thanks.

Backport request

[Hemdan, Hagar Gamal Halim]

Hi,

Please backport commit:

ecfe9a015d3e ("pinctrl: core: handle radix_tree_insert() errors in pinctrl_register_one_pin()")

to stable trees 5.4.y, 5.10.y, 5.15.y, 6.1.y. This commit fixes error handling of radix_tree_insert().

This bug was discovered and resolved using Coverity Static Analysis
Security Testing (SAST) by Synopsys, Inc.

Thanks,
Hagar Hemdan

 




Amazon Web Services Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 257764 B
Sitz: Berlin
Ust-ID: DE 365 538 597

Re: Backport request

[Greg KH]

On Thu, May 16, 2024 at 10:16:15AM +0000, Hemdan, Hagar Gamal Halim wrote:
> Hi,
> 
> Please backport commit:
> 
> ecfe9a015d3e ("pinctrl: core: handle radix_tree_insert() errors in pinctrl_register_one_pin()")
> 
> to stable trees 5.4.y, 5.10.y, 5.15.y, 6.1.y. This commit fixes error handling of radix_tree_insert().
> 
> This bug was discovered and resolved using Coverity Static Analysis
> Security Testing (SAST) by Synopsys, Inc.

Now picked up, thanks.

greg k-h

Backport request

[Hemdan, Hagar Gamal Halim]

Hi,

Please backport commits:

c02d5feb6e2f ("ACPI: processor: perflib: Use the "no limit" frequency QoS")
99387b016022 ("ACPI: processor: perflib: Avoid updating frequency QoS unnecessarily")
e8a0e30b742f ("cpufreq: intel_pstate: Drop ACPI _PSS states table patching")

To stable trees 5.4.y, 5.10.y, 5.15.y, 6.1.y. These commits fix Intel Turbo enabling when
bringing CPUs offline and online again. I've tested this on the mentioned stable trees.
Feel free to add

Tested-by: Hagar Hemdan <hagarhem@amazon.de>

Thanks,
Hagar




Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879

Re: Backport request

[Greg KH]

On Tue, Aug 01, 2023 at 07:17:04AM +0000, Hemdan, Hagar Gamal Halim wrote:
> Hi,
> 
> Please backport commits:
> 
> c02d5feb6e2f ("ACPI: processor: perflib: Use the "no limit" frequency QoS")
> 99387b016022 ("ACPI: processor: perflib: Avoid updating frequency QoS unnecessarily")
> e8a0e30b742f ("cpufreq: intel_pstate: Drop ACPI _PSS states table patching")
> 
> To stable trees 5.4.y, 5.10.y, 5.15.y, 6.1.y. These commits fix Intel Turbo enabling when
> bringing CPUs offline and online again. I've tested this on the mentioned stable trees.
> Feel free to add
> 
> Tested-by: Hagar Hemdan <hagarhem@amazon.de>

All now queued up, thanks.

greg k-h

backport request

[Ard Biesheuvel]

Please backport commit

commit 9cf42bca30e98a1c6c9e8abf876940a551eaa3d1
Author: Ard Biesheuvel <ardb@kernel.org>
Date:   Tue Aug 2 11:00:16 2022 +0200

    efi: libstub: use EFI_LOADER_CODE region when moving the kernel in memory

to all active stable trees all the way back to v5.15. I will provide a
separate backport for v5.10, and possibly a [much] larger set of
backports for v5.4 for EFI boot support.

Thanks,
Ard.

Re: backport request

[Ard Biesheuvel]

On Tue, 25 Jul 2023 at 13:13, Ard Biesheuvel <ardb@kernel.org> wrote:
>
> Please backport commit
>
> commit 9cf42bca30e98a1c6c9e8abf876940a551eaa3d1
> Author: Ard Biesheuvel <ardb@kernel.org>
> Date:   Tue Aug 2 11:00:16 2022 +0200
>
>     efi: libstub: use EFI_LOADER_CODE region when moving the kernel in memory
>
> to all active stable trees all the way back to v5.15. I will provide a
> separate backport for v5.10,

Actually, v5.10 just needs the following patch to be applied first

commit 8a81b6bbdccae98d751644723c67bb6aa9a79571
Author: Ard Biesheuvel <ardb@kernel.org>
Date:   Mon Jul 26 16:24:01 2021 +0200

    efi/libstub: arm64: Warn when efi_random_alloc() fails

so please backport that one to v5.10 as well.

Thanks,
Ard.

Re: backport request

[Greg KH]

On Tue, Jul 25, 2023 at 01:13:34PM +0200, Ard Biesheuvel wrote:
> Please backport commit
> 
> commit 9cf42bca30e98a1c6c9e8abf876940a551eaa3d1
> Author: Ard Biesheuvel <ardb@kernel.org>
> Date:   Tue Aug 2 11:00:16 2022 +0200
> 
>     efi: libstub: use EFI_LOADER_CODE region when moving the kernel in memory
> 
> to all active stable trees all the way back to v5.15. I will provide a
> separate backport for v5.10, and possibly a [much] larger set of
> backports for v5.4 for EFI boot support.

Sure, but why?  That sounds like a new feature, if you want EFI boot
support, why not just move to a newer kernel tree?  What bug is this
fixing?

thanks,

greg k-h

Re: backport request

[Ard Biesheuvel]

On Tue, 25 Jul 2023 at 14:29, Greg KH <gregkh@linuxfoundation.org> wrote:
>
> On Tue, Jul 25, 2023 at 01:13:34PM +0200, Ard Biesheuvel wrote:
> > Please backport commit
> >
> > commit 9cf42bca30e98a1c6c9e8abf876940a551eaa3d1
> > Author: Ard Biesheuvel <ardb@kernel.org>
> > Date:   Tue Aug 2 11:00:16 2022 +0200
> >
> >     efi: libstub: use EFI_LOADER_CODE region when moving the kernel in memory
> >
> > to all active stable trees all the way back to v5.15. I will provide a
> > separate backport for v5.10, and possibly a [much] larger set of
> > backports for v5.4 for EFI boot support.
>
> Sure, but why?  That sounds like a new feature, if you want EFI boot
> support, why not just move to a newer kernel tree?  What bug is this
> fixing?
>

Perhaps it is something that the distros just needs to carry in their
forks, then.

This is related to distro forks of grub and shim, and the royal mess
they created on x86. We are making progress on the GRUB side to move
to the much simpler and cleaner generic EFI stub support that works
for x86, ARM, arm64, RISC-V and LoongArch. The problem is that the
distros have a huge set of patches between them that turn shim, GRUB
and the way x86 boots in a huge tangled mess, and they cannot phase
those out as long as they need to support older kernels, and so they
are now in a situation where they need to support all of the above.

v5.4 is the only release where it is somewhat feasible to backport the
changes [0] that would allow those GRUB out-of-tree hacks to be
dropped. I.e., the number of backported patches is quite substantial
but there are very few and minor conflicts, and the changes are
confined to EFI code. Backporting this stuff from ~v5.8 to v5.4 would
mean they can accelerate their phase out schedule by a year.
(Actually, they asked me about v4.4 but anything older than v5.4 is
really out of the question)

In any case, I promised them to take a look and I did - I won't be the
one pushing for this to get merged.

Thanks,
Ard.




[0] https://git.kernel.org/pub/scm/linux/kernel/git/ardb/linux.git/log/?h=efi-lf2-backport-x86

Re: backport request

[Greg KH]

On Tue, Jul 25, 2023 at 02:51:56PM +0200, Ard Biesheuvel wrote:
> On Tue, 25 Jul 2023 at 14:29, Greg KH <gregkh@linuxfoundation.org> wrote:
> >
> > On Tue, Jul 25, 2023 at 01:13:34PM +0200, Ard Biesheuvel wrote:
> > > Please backport commit
> > >
> > > commit 9cf42bca30e98a1c6c9e8abf876940a551eaa3d1
> > > Author: Ard Biesheuvel <ardb@kernel.org>
> > > Date:   Tue Aug 2 11:00:16 2022 +0200
> > >
> > >     efi: libstub: use EFI_LOADER_CODE region when moving the kernel in memory
> > >
> > > to all active stable trees all the way back to v5.15. I will provide a
> > > separate backport for v5.10, and possibly a [much] larger set of
> > > backports for v5.4 for EFI boot support.
> >
> > Sure, but why?  That sounds like a new feature, if you want EFI boot
> > support, why not just move to a newer kernel tree?  What bug is this
> > fixing?
> >
> 
> Perhaps it is something that the distros just needs to carry in their
> forks, then.
> 
> This is related to distro forks of grub and shim, and the royal mess
> they created on x86. We are making progress on the GRUB side to move
> to the much simpler and cleaner generic EFI stub support that works
> for x86, ARM, arm64, RISC-V and LoongArch. The problem is that the
> distros have a huge set of patches between them that turn shim, GRUB
> and the way x86 boots in a huge tangled mess, and they cannot phase
> those out as long as they need to support older kernels, and so they
> are now in a situation where they need to support all of the above.
> 
> v5.4 is the only release where it is somewhat feasible to backport the
> changes [0] that would allow those GRUB out-of-tree hacks to be
> dropped. I.e., the number of backported patches is quite substantial
> but there are very few and minor conflicts, and the changes are
> confined to EFI code. Backporting this stuff from ~v5.8 to v5.4 would
> mean they can accelerate their phase out schedule by a year.
> (Actually, they asked me about v4.4 but anything older than v5.4 is
> really out of the question)
> 
> In any case, I promised them to take a look and I did - I won't be the
> one pushing for this to get merged.

I think this is up to the distros if they want to deal with this mess on
their older kernels.  They created it, and they want to maintain it as
their "value add", so let's let them earn that value :)

So I'll not add these to any older kernels, they can use 6.1.y instead
if they want to.

thanks,

greg k-h

Re: backport request

[Ard Biesheuvel]

On Tue, 25 Jul 2023 at 15:21, Greg KH <gregkh@linuxfoundation.org> wrote:
>
> On Tue, Jul 25, 2023 at 02:51:56PM +0200, Ard Biesheuvel wrote:
> > On Tue, 25 Jul 2023 at 14:29, Greg KH <gregkh@linuxfoundation.org> wrote:
> > >
> > > On Tue, Jul 25, 2023 at 01:13:34PM +0200, Ard Biesheuvel wrote:
> > > > Please backport commit
> > > >
> > > > commit 9cf42bca30e98a1c6c9e8abf876940a551eaa3d1
> > > > Author: Ard Biesheuvel <ardb@kernel.org>
> > > > Date:   Tue Aug 2 11:00:16 2022 +0200
> > > >
> > > >     efi: libstub: use EFI_LOADER_CODE region when moving the kernel in memory
> > > >
> > > > to all active stable trees all the way back to v5.15. I will provide a
> > > > separate backport for v5.10, and possibly a [much] larger set of
> > > > backports for v5.4 for EFI boot support.
> > >
> > > Sure, but why?  That sounds like a new feature, if you want EFI boot
> > > support, why not just move to a newer kernel tree?  What bug is this
> > > fixing?
> > >
> >
> > Perhaps it is something that the distros just needs to carry in their
> > forks, then.
> >
> > This is related to distro forks of grub and shim, and the royal mess
> > they created on x86. We are making progress on the GRUB side to move
> > to the much simpler and cleaner generic EFI stub support that works
> > for x86, ARM, arm64, RISC-V and LoongArch. The problem is that the
> > distros have a huge set of patches between them that turn shim, GRUB
> > and the way x86 boots in a huge tangled mess, and they cannot phase
> > those out as long as they need to support older kernels, and so they
> > are now in a situation where they need to support all of the above.
> >
> > v5.4 is the only release where it is somewhat feasible to backport the
> > changes [0] that would allow those GRUB out-of-tree hacks to be
> > dropped. I.e., the number of backported patches is quite substantial
> > but there are very few and minor conflicts, and the changes are
> > confined to EFI code. Backporting this stuff from ~v5.8 to v5.4 would
> > mean they can accelerate their phase out schedule by a year.
> > (Actually, they asked me about v4.4 but anything older than v5.4 is
> > really out of the question)
> >
> > In any case, I promised them to take a look and I did - I won't be the
> > one pushing for this to get merged.
>
> I think this is up to the distros if they want to deal with this mess on
> their older kernels.  They created it, and they want to maintain it as
> their "value add", so let's let them earn that value :)
>
> So I'll not add these to any older kernels, they can use 6.1.y instead
> if they want to.
>

Yes, but please backport commit
9cf42bca30e98a1c6c9e8abf876940a551eaa3d1  nonetheless - that one is an
obvious bug fix.

Re: backport request

[Greg KH]

On Tue, Jul 25, 2023 at 03:25:35PM +0200, Ard Biesheuvel wrote:
> On Tue, 25 Jul 2023 at 15:21, Greg KH <gregkh@linuxfoundation.org> wrote:
> >
> > On Tue, Jul 25, 2023 at 02:51:56PM +0200, Ard Biesheuvel wrote:
> > > On Tue, 25 Jul 2023 at 14:29, Greg KH <gregkh@linuxfoundation.org> wrote:
> > > >
> > > > On Tue, Jul 25, 2023 at 01:13:34PM +0200, Ard Biesheuvel wrote:
> > > > > Please backport commit
> > > > >
> > > > > commit 9cf42bca30e98a1c6c9e8abf876940a551eaa3d1
> > > > > Author: Ard Biesheuvel <ardb@kernel.org>
> > > > > Date:   Tue Aug 2 11:00:16 2022 +0200
> > > > >
> > > > >     efi: libstub: use EFI_LOADER_CODE region when moving the kernel in memory
> > > > >
> > > > > to all active stable trees all the way back to v5.15. I will provide a
> > > > > separate backport for v5.10, and possibly a [much] larger set of
> > > > > backports for v5.4 for EFI boot support.
> > > >
> > > > Sure, but why?  That sounds like a new feature, if you want EFI boot
> > > > support, why not just move to a newer kernel tree?  What bug is this
> > > > fixing?
> > > >
> > >
> > > Perhaps it is something that the distros just needs to carry in their
> > > forks, then.
> > >
> > > This is related to distro forks of grub and shim, and the royal mess
> > > they created on x86. We are making progress on the GRUB side to move
> > > to the much simpler and cleaner generic EFI stub support that works
> > > for x86, ARM, arm64, RISC-V and LoongArch. The problem is that the
> > > distros have a huge set of patches between them that turn shim, GRUB
> > > and the way x86 boots in a huge tangled mess, and they cannot phase
> > > those out as long as they need to support older kernels, and so they
> > > are now in a situation where they need to support all of the above.
> > >
> > > v5.4 is the only release where it is somewhat feasible to backport the
> > > changes [0] that would allow those GRUB out-of-tree hacks to be
> > > dropped. I.e., the number of backported patches is quite substantial
> > > but there are very few and minor conflicts, and the changes are
> > > confined to EFI code. Backporting this stuff from ~v5.8 to v5.4 would
> > > mean they can accelerate their phase out schedule by a year.
> > > (Actually, they asked me about v4.4 but anything older than v5.4 is
> > > really out of the question)
> > >
> > > In any case, I promised them to take a look and I did - I won't be the
> > > one pushing for this to get merged.
> >
> > I think this is up to the distros if they want to deal with this mess on
> > their older kernels.  They created it, and they want to maintain it as
> > their "value add", so let's let them earn that value :)
> >
> > So I'll not add these to any older kernels, they can use 6.1.y instead
> > if they want to.
> >
> 
> Yes, but please backport commit
> 9cf42bca30e98a1c6c9e8abf876940a551eaa3d1  nonetheless - that one is an
> obvious bug fix.

Ok, will do after this round of releases are done.

greg k-h

Re: backport request

[Ard Biesheuvel]

On Tue, 25 Jul 2023 at 15:41, Greg KH <gregkh@linuxfoundation.org> wrote:
>
> On Tue, Jul 25, 2023 at 03:25:35PM +0200, Ard Biesheuvel wrote:
> > On Tue, 25 Jul 2023 at 15:21, Greg KH <gregkh@linuxfoundation.org> wrote:
> > >
> > > On Tue, Jul 25, 2023 at 02:51:56PM +0200, Ard Biesheuvel wrote:
> > > > On Tue, 25 Jul 2023 at 14:29, Greg KH <gregkh@linuxfoundation.org> wrote:
> > > > >
> > > > > On Tue, Jul 25, 2023 at 01:13:34PM +0200, Ard Biesheuvel wrote:
> > > > > > Please backport commit
> > > > > >
> > > > > > commit 9cf42bca30e98a1c6c9e8abf876940a551eaa3d1
> > > > > > Author: Ard Biesheuvel <ardb@kernel.org>
> > > > > > Date:   Tue Aug 2 11:00:16 2022 +0200
> > > > > >
> > > > > >     efi: libstub: use EFI_LOADER_CODE region when moving the kernel in memory
> > > > > >
> > > > > > to all active stable trees all the way back to v5.15. I will provide a
> > > > > > separate backport for v5.10, and possibly a [much] larger set of
> > > > > > backports for v5.4 for EFI boot support.
> > > > >
> > > > > Sure, but why?  That sounds like a new feature, if you want EFI boot
> > > > > support, why not just move to a newer kernel tree?  What bug is this
> > > > > fixing?
> > > > >
> > > >
> > > > Perhaps it is something that the distros just needs to carry in their
> > > > forks, then.
> > > >
> > > > This is related to distro forks of grub and shim, and the royal mess
> > > > they created on x86. We are making progress on the GRUB side to move
> > > > to the much simpler and cleaner generic EFI stub support that works
> > > > for x86, ARM, arm64, RISC-V and LoongArch. The problem is that the
> > > > distros have a huge set of patches between them that turn shim, GRUB
> > > > and the way x86 boots in a huge tangled mess, and they cannot phase
> > > > those out as long as they need to support older kernels, and so they
> > > > are now in a situation where they need to support all of the above.
> > > >
> > > > v5.4 is the only release where it is somewhat feasible to backport the
> > > > changes [0] that would allow those GRUB out-of-tree hacks to be
> > > > dropped. I.e., the number of backported patches is quite substantial
> > > > but there are very few and minor conflicts, and the changes are
> > > > confined to EFI code. Backporting this stuff from ~v5.8 to v5.4 would
> > > > mean they can accelerate their phase out schedule by a year.
> > > > (Actually, they asked me about v4.4 but anything older than v5.4 is
> > > > really out of the question)
> > > >
> > > > In any case, I promised them to take a look and I did - I won't be the
> > > > one pushing for this to get merged.
> > >
> > > I think this is up to the distros if they want to deal with this mess on
> > > their older kernels.  They created it, and they want to maintain it as
> > > their "value add", so let's let them earn that value :)
> > >
> > > So I'll not add these to any older kernels, they can use 6.1.y instead
> > > if they want to.
> > >
> >
> > Yes, but please backport commit
> > 9cf42bca30e98a1c6c9e8abf876940a551eaa3d1  nonetheless - that one is an
> > obvious bug fix.
>
> Ok, will do after this round of releases are done.
>

Actually, no - please disregard.

I confused myself here - the fix is fine, just not needed for v5.10 - v6.4.

Sorry for the noise.

Re: backport request

[Greg KH]

On Tue, Jul 25, 2023 at 01:13:34PM +0200, Ard Biesheuvel wrote:
> Please backport commit
> 
> commit 9cf42bca30e98a1c6c9e8abf876940a551eaa3d1
> Author: Ard Biesheuvel <ardb@kernel.org>
> Date:   Tue Aug 2 11:00:16 2022 +0200
> 
>     efi: libstub: use EFI_LOADER_CODE region when moving the kernel in memory
> 
> to all active stable trees all the way back to v5.15. I will provide a
> separate backport for v5.10, and possibly a [much] larger set of
> backports for v5.4 for EFI boot support.

Now queued up, thanks.

greg k-h

Backport request

[Juergen Gross]

[-- Attachment #1.1.1: Type: text/plain, Size: 359 bytes --]

Hi Greg,

stable kernels 5.18 and 5.15 seem to be missing upstream patch
c64cc2802a78 ("x86/entry: Move CLD to the start of the idtentry macro").
This is a prerequisite patch for 64cbd0acb582 ("x86/entry: Don't call
error_entry() for XENPV"), which is included in 5.15.y and 5.18.y.

Could you please take c64cc2802a78 for 5.15 and 5.18?


Juergen

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 3149 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 bytes --]

Re: Backport request

[Greg Kroah-Hartman]

On Wed, Aug 24, 2022 at 01:20:22PM +0200, Juergen Gross wrote:
> Hi Greg,
> 
> stable kernels 5.18 and 5.15 seem to be missing upstream patch
> c64cc2802a78 ("x86/entry: Move CLD to the start of the idtentry macro").
> This is a prerequisite patch for 64cbd0acb582 ("x86/entry: Don't call
> error_entry() for XENPV"), which is included in 5.15.y and 5.18.y.
> 
> Could you please take c64cc2802a78 for 5.15 and 5.18?

5.18 is end-of-life, so that's impossible to do now :(

For 5.15.y, the commit does not apply cleanly, can you provide a working
backport?

thanks,

greg k-h

Re: Backport request

[Juergen Gross]

[-- Attachment #1.1.1: Type: text/plain, Size: 663 bytes --]

On 24.08.22 14:10, Greg Kroah-Hartman wrote:
> On Wed, Aug 24, 2022 at 01:20:22PM +0200, Juergen Gross wrote:
>> Hi Greg,
>>
>> stable kernels 5.18 and 5.15 seem to be missing upstream patch
>> c64cc2802a78 ("x86/entry: Move CLD to the start of the idtentry macro").
>> This is a prerequisite patch for 64cbd0acb582 ("x86/entry: Don't call
>> error_entry() for XENPV"), which is included in 5.15.y and 5.18.y.
>>
>> Could you please take c64cc2802a78 for 5.15 and 5.18?
> 
> 5.18 is end-of-life, so that's impossible to do now :(
> 
> For 5.15.y, the commit does not apply cleanly, can you provide a working
> backport?

Attached.


Juergen


[-- Attachment #1.1.2: 0001-x86-entry-Move-CLD-to-the-start-of-the-idtentry-macr.patch --]
[-- Type: text/x-patch, Size: 2305 bytes --]

From 082f40e80c15c7b1173c0857014e30eef1471afd Mon Sep 17 00:00:00 2001
From: Lai Jiangshan <jiangshan.ljs@antgroup.com>
Date: Thu, 21 Apr 2022 22:10:51 +0800
Subject: [PATCH] x86/entry: Move CLD to the start of the idtentry macro

commit c64cc2802a784ecfd25d39945e57e7a147854a5b upstream.

Move it after CLAC.

Suggested-by: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Lai Jiangshan <jiangshan.ljs@antgroup.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Link: https://lore.kernel.org/r/20220503032107.680190-5-jiangshanlai@gmail.com
Signed-off-by: Juergen Gross <jgross@suse.com>
---
 arch/x86/entry/entry_64.S | 8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S
index 763ff243aeca..a3af2a9159b1 100644
--- a/arch/x86/entry/entry_64.S
+++ b/arch/x86/entry/entry_64.S
@@ -373,6 +373,7 @@ SYM_CODE_END(xen_error_entry)
 SYM_CODE_START(\asmsym)
 	UNWIND_HINT_IRET_REGS offset=\has_error_code*8
 	ASM_CLAC
+	cld
 
 	.if \has_error_code == 0
 		pushq	$-1			/* ORIG_RAX: no syscall to restart */
@@ -440,6 +441,7 @@ SYM_CODE_END(\asmsym)
 SYM_CODE_START(\asmsym)
 	UNWIND_HINT_IRET_REGS
 	ASM_CLAC
+	cld
 
 	pushq	$-1			/* ORIG_RAX: no syscall to restart */
 
@@ -495,6 +497,7 @@ SYM_CODE_END(\asmsym)
 SYM_CODE_START(\asmsym)
 	UNWIND_HINT_IRET_REGS
 	ASM_CLAC
+	cld
 
 	/*
 	 * If the entry is from userspace, switch stacks and treat it as
@@ -557,6 +560,7 @@ SYM_CODE_END(\asmsym)
 SYM_CODE_START(\asmsym)
 	UNWIND_HINT_IRET_REGS offset=8
 	ASM_CLAC
+	cld
 
 	/* paranoid_entry returns GS information for paranoid_exit in EBX. */
 	call	paranoid_entry
@@ -876,7 +880,6 @@ SYM_CODE_END(xen_failsafe_callback)
  */
 SYM_CODE_START_LOCAL(paranoid_entry)
 	UNWIND_HINT_FUNC
-	cld
 	PUSH_AND_CLEAR_REGS save_ret=1
 	ENCODE_FRAME_POINTER 8
 
@@ -1012,7 +1015,6 @@ SYM_CODE_END(paranoid_exit)
  */
 SYM_CODE_START_LOCAL(error_entry)
 	UNWIND_HINT_FUNC
-	cld
 
 	PUSH_AND_CLEAR_REGS save_ret=1
 	ENCODE_FRAME_POINTER 8
@@ -1155,6 +1157,7 @@ SYM_CODE_START(asm_exc_nmi)
 	 */
 
 	ASM_CLAC
+	cld
 
 	/* Use %rdx as our temp variable throughout */
 	pushq	%rdx
@@ -1174,7 +1177,6 @@ SYM_CODE_START(asm_exc_nmi)
 	 */
 
 	swapgs
-	cld
 	FENCE_SWAPGS_USER_ENTRY
 	SWITCH_TO_KERNEL_CR3 scratch_reg=%rdx
 	movq	%rsp, %rdx
-- 
2.35.3


[-- Attachment #1.1.3: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 3149 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 bytes --]

Re: Backport request

[Greg Kroah-Hartman]

On Wed, Aug 24, 2022 at 03:52:27PM +0200, Juergen Gross wrote:
> On 24.08.22 14:10, Greg Kroah-Hartman wrote:
> > On Wed, Aug 24, 2022 at 01:20:22PM +0200, Juergen Gross wrote:
> > > Hi Greg,
> > > 
> > > stable kernels 5.18 and 5.15 seem to be missing upstream patch
> > > c64cc2802a78 ("x86/entry: Move CLD to the start of the idtentry macro").
> > > This is a prerequisite patch for 64cbd0acb582 ("x86/entry: Don't call
> > > error_entry() for XENPV"), which is included in 5.15.y and 5.18.y.
> > > 
> > > Could you please take c64cc2802a78 for 5.15 and 5.18?
> > 
> > 5.18 is end-of-life, so that's impossible to do now :(
> > 
> > For 5.15.y, the commit does not apply cleanly, can you provide a working
> > backport?
> 
> Attached.

Thanks, now queued up.

greg k-h

Backport request

[Daniel Vetter]

Dear stable team (aka Greg)

Please backport

a04ac8273665 ("drm/i915/gt: Fixup tgl mocs for PTE tracking")

Note that this needs

4d8a5cfe3b13 ("drm/i915/gt: Initialize reserved and unspecified MOCS indices")

but that one has already a cc: stable, unfortunately the bugfix didn't.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: Backport request

[Greg KH]

On Tue, Dec 15, 2020 at 05:02:41PM +0100, Daniel Vetter wrote:
> Dear stable team (aka Greg)
> 
> Please backport
> 
> a04ac8273665 ("drm/i915/gt: Fixup tgl mocs for PTE tracking")
> 
> Note that this needs
> 
> 4d8a5cfe3b13 ("drm/i915/gt: Initialize reserved and unspecified MOCS indices")
> 
> but that one has already a cc: stable, unfortunately the bugfix didn't.

Backport to where exactly?

These all seem to be in the 5.9.y tree already, do they need to go
further back?

thanks,

greg k-h

Re: Backport request

[Daniel Vetter]

On Sat, Dec 19, 2020 at 1:41 PM Greg KH <greg@kroah.com> wrote:
>
> On Tue, Dec 15, 2020 at 05:02:41PM +0100, Daniel Vetter wrote:
> > Dear stable team (aka Greg)
> >
> > Please backport
> >
> > a04ac8273665 ("drm/i915/gt: Fixup tgl mocs for PTE tracking")
> >
> > Note that this needs
> >
> > 4d8a5cfe3b13 ("drm/i915/gt: Initialize reserved and unspecified MOCS indices")
> >
> > but that one has already a cc: stable, unfortunately the bugfix didn't.
>
> Backport to where exactly?
>
> These all seem to be in the 5.9.y tree already, do they need to go
> further back?

The 2nd one has cc: stable, so I worried that it might have escaped to
more kernels, whereas the first one does not have cc: stable. Maybe
the auto-stable picker has figured this out already (first patch does
thave the right Fixes: line), I just wanted to make sure we don't end
up with kernels with the broken in-between state.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Backport request

[Corey Minyard]

Requesting backport of:

174134ac760275457bb0d1560a0dbe6cf8a12ad6
ipmi_si: Fix error handling of platform device

to 4.15 only.  Without it, an oops can occur in certain
situations.

Thanks,

-corey

Re: Backport request

[Greg KH]

On Wed, Feb 28, 2018 at 07:56:30AM -0600, Corey Minyard wrote:
> Requesting backport of:
> 
> 174134ac760275457bb0d1560a0dbe6cf8a12ad6
> ipmi_si: Fix error handling of platform device
> 
> to 4.15 only.� Without it, an oops can occur in certain
> situations.

Now queued up, thanks.

greg k-h