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

[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

Backport request

[Juergen Gross]

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

I'd like to request backport of upstream commit bc6a499ebcf1
("libxl: correct xenstore entry for empty cdrom") to at least
4.8 and 4.7.

As libxl sources have been split in 4.9 the patch doesn't apply.
Attached patch applies cleanly to 4.8 and with an offset to 4.7.


Juergen

[-- Attachment #2: cdrom.patch --]
[-- Type: text/x-patch, Size: 1614 bytes --]

>From bc6a499ebcf102060987fb845c1450a38de441c7 Mon Sep 17 00:00:00 2001
From: Juergen Gross <jgross@suse.com>
Date: Wed, 15 Feb 2017 12:11:12 +0100
Subject: [PATCH] libxl: correct xenstore entry for empty cdrom

Specifying an empty cdrom device will result in a Xenstore entry

params = aio:(null)

as the physical device path isn't existing. This lets a domain booted
via OVMF hang as OVMF is checking for "aio:" only in order to detect
the empty cdrom case.

Use an empty string for the physical device path in this case. As a
cdrom device for HVM is always backed by qdisk we only need to cover this
backend.

Signed-off-by: Juergen Gross <jgross@suse.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
---
 tools/libxl/libxl.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index ac49df2..63de75c 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -2255,7 +2255,8 @@ static void device_disk_add(libxl__egc *egc, uint32_t domid,
             case LIBXL_DISK_BACKEND_QDISK:
                 flexarray_append(back, "params");
                 flexarray_append(back, GCSPRINTF("%s:%s",
-                              libxl__device_disk_string_of_format(disk->format), disk->pdev_path));
+                              libxl__device_disk_string_of_format(disk->format),
+                              disk->pdev_path ? : ""));
                 if (libxl_defbool_val(disk->colo_enable)) {
                     flexarray_append(back, "colo-host");
                     flexarray_append(back, libxl__sprintf(gc, "%s", disk->colo_host));
-- 
2.1.4


[-- Attachment #3: Type: text/plain, Size: 127 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: Backport request

[Juergen Gross]

On 01/03/17 13:31, Juergen Gross wrote:
> I'd like to request backport of upstream commit bc6a499ebcf1
> ("libxl: correct xenstore entry for empty cdrom") to at least
> 4.8 and 4.7.
> 
> As libxl sources have been split in 4.9 the patch doesn't apply.
> Attached patch applies cleanly to 4.8 and with an offset to 4.7.

Ping?


Juergen


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: Backport request

[Ian Jackson]

Juergen Gross writes ("Backport request"):
> I'd like to request backport of upstream commit bc6a499ebcf1
> ("libxl: correct xenstore entry for empty cdrom") to at least
> 4.8 and 4.7.
> 
> As libxl sources have been split in 4.9 the patch doesn't apply.
> Attached patch applies cleanly to 4.8 and with an offset to 4.7.

Thanks for fixing this up.  I have pushed this to 4.7 and 4.8.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Backport request

[Andrew Cooper]

Hello,

Can you please backport c/s 0896bd8bea84526b00e00d2d076f4f953a3d73cb
"x86: map portion of kexec crash area that is within the direct map
area" to staging-4.3 ASAP, as following the backport of
8d611a00d3389d9c16506326e24145b94ac6fb86 "kexec/x86: do not map crash
kernel area", kexec loading is broken in exactly the same way as it was
in staging.

~Andrew

Re: Backport request

[David Vrabel]

On 13/01/14 09:49, Andrew Cooper wrote:
> Hello,
> 
> Can you please backport c/s 0896bd8bea84526b00e00d2d076f4f953a3d73cb
> "x86: map portion of kexec crash area that is within the direct map
> area" to staging-4.3 ASAP, as following the backport of
> 8d611a00d3389d9c16506326e24145b94ac6fb86 "kexec/x86: do not map crash
> kernel area", kexec loading is broken in exactly the same way as it was
> in staging.

This shouldn't be necessary for 4.3 as the old kexec implementation
didn't use map_domain_page() but used several fixmap slots instead.

If this is broken in our XenServer 4.3 tree it's because we've
backported the new kexec implementation and we'll have to do the
backport of 0896bd8be ourselves.

David

Re: Backport request

[Jan Beulich]

>>> On 13.01.14 at 10:49, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
> Can you please backport c/s 0896bd8bea84526b00e00d2d076f4f953a3d73cb
> "x86: map portion of kexec crash area that is within the direct map
> area" to staging-4.3 ASAP, as following the backport of
> 8d611a00d3389d9c16506326e24145b94ac6fb86 "kexec/x86: do not map crash
> kernel area", kexec loading is broken in exactly the same way as it was
> in staging.

Not without explaining how it is broken: According to my own
checking as well as Daniel's there was no need for the kexec area
to be mapped at all in the old implementation.

Furthermore, I'd prefer to revert 8d611a00 (dff90d0c on 4.2)
instead if there really is an issue. That's largely because, as
noted in the extra comment I added to 0896bd8b, the change is
still incomplete (and hence not much better than the code with
Daniel's change reverted).

Jan

Re: Backport request

[David Vrabel]

On 13/01/14 11:13, Jan Beulich wrote:
>>>> On 13.01.14 at 10:49, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>> Can you please backport c/s 0896bd8bea84526b00e00d2d076f4f953a3d73cb
>> "x86: map portion of kexec crash area that is within the direct map
>> area" to staging-4.3 ASAP, as following the backport of
>> 8d611a00d3389d9c16506326e24145b94ac6fb86 "kexec/x86: do not map crash
>> kernel area", kexec loading is broken in exactly the same way as it was
>> in staging.
> 
> Not without explaining how it is broken: According to my own
> checking as well as Daniel's there was no need for the kexec area
> to be mapped at all in the old implementation.
> 
> Furthermore, I'd prefer to revert 8d611a00 (dff90d0c on 4.2)
> instead if there really is an issue. That's largely because, as
> noted in the extra comment I added to 0896bd8b, the change is
> still incomplete (and hence not much better than the code with
> Daniel's change reverted).

In that comment it says:

  "That's primarily because map_domain_page()
   (needed when the area is outside the direct mapping range) may be
   unusable when wanting to kexec due to a crash,"

But map_domain_page() is only used when loading the crash image, not
during exec.

David

Re: Backport request

[Jan Beulich]

>>> On 13.01.14 at 12:30, David Vrabel <david.vrabel@citrix.com> wrote:
> On 13/01/14 11:13, Jan Beulich wrote:
>>>>> On 13.01.14 at 10:49, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>>> Can you please backport c/s 0896bd8bea84526b00e00d2d076f4f953a3d73cb
>>> "x86: map portion of kexec crash area that is within the direct map
>>> area" to staging-4.3 ASAP, as following the backport of
>>> 8d611a00d3389d9c16506326e24145b94ac6fb86 "kexec/x86: do not map crash
>>> kernel area", kexec loading is broken in exactly the same way as it was
>>> in staging.
>> 
>> Not without explaining how it is broken: According to my own
>> checking as well as Daniel's there was no need for the kexec area
>> to be mapped at all in the old implementation.
>> 
>> Furthermore, I'd prefer to revert 8d611a00 (dff90d0c on 4.2)
>> instead if there really is an issue. That's largely because, as
>> noted in the extra comment I added to 0896bd8b, the change is
>> still incomplete (and hence not much better than the code with
>> Daniel's change reverted).
> 
> In that comment it says:
> 
>   "That's primarily because map_domain_page()
>    (needed when the area is outside the direct mapping range) may be
>    unusable when wanting to kexec due to a crash,"
> 
> But map_domain_page() is only used when loading the crash image, not
> during exec.

That's good to know, but I don't think it's a good idea either. Seeing
that map_domain_page() is being used in the code _at all_ may
make someone try to use it in a path that is used during kexec. And
it being used by other functions in the same file may also result in
one of those functions suddenly also getting used on a kexec path.

Together with the issue of the area potentially ending up in a
PFN compression hole, to me this is enough reason to still expect
that these uses get dropped again.

Jan

Re: Backport request

[Daniel Kiper]

On Mon, Jan 13, 2014 at 11:36:34AM +0000, Jan Beulich wrote:
> >>> On 13.01.14 at 12:30, David Vrabel <david.vrabel@citrix.com> wrote:
> > On 13/01/14 11:13, Jan Beulich wrote:
> >>>>> On 13.01.14 at 10:49, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
> >>> Can you please backport c/s 0896bd8bea84526b00e00d2d076f4f953a3d73cb
> >>> "x86: map portion of kexec crash area that is within the direct map
> >>> area" to staging-4.3 ASAP, as following the backport of
> >>> 8d611a00d3389d9c16506326e24145b94ac6fb86 "kexec/x86: do not map crash
> >>> kernel area", kexec loading is broken in exactly the same way as it was
> >>> in staging.
> >>
> >> Not without explaining how it is broken: According to my own
> >> checking as well as Daniel's there was no need for the kexec area
> >> to be mapped at all in the old implementation.
> >>
> >> Furthermore, I'd prefer to revert 8d611a00 (dff90d0c on 4.2)
> >> instead if there really is an issue. That's largely because, as
> >> noted in the extra comment I added to 0896bd8b, the change is
> >> still incomplete (and hence not much better than the code with
> >> Daniel's change reverted).
> >
> > In that comment it says:
> >
> >   "That's primarily because map_domain_page()
> >    (needed when the area is outside the direct mapping range) may be
> >    unusable when wanting to kexec due to a crash,"
> >
> > But map_domain_page() is only used when loading the crash image, not
> > during exec.
>
> That's good to know, but I don't think it's a good idea either. Seeing
> that map_domain_page() is being used in the code _at all_ may
> make someone try to use it in a path that is used during kexec. And
> it being used by other functions in the same file may also result in
> one of those functions suddenly also getting used on a kexec path.
>
> Together with the issue of the area potentially ending up in a
> PFN compression hole, to me this is enough reason to still expect
> that these uses get dropped again.

map_domain_page() is used during kexec and crash image load.
However, it is not used when a given image is executed.

Daniel