Re: stable request

[Ard Biesheuvel <ardb@kernel.org>]

On Thu, 18 Mar 2021 at 14:03, Sasha Levin <sashal@kernel.org> wrote:
>
> On Tue, Mar 16, 2021 at 01:35:40PM +0100, Ard Biesheuvel wrote:
> >On Tue, 16 Mar 2021 at 13:28, Thomas Backlund <tmb@tmb.nu> wrote:
> >>
> >>
> >> Den 16.3.2021 kl. 14:15, skrev Thomas Backlund:
> >> >
> >> > Den 16.3.2021 kl. 12:17, skrev Ard Biesheuvel:
> >> >> On Tue, 16 Mar 2021 at 10:21, Thomas Backlund <tmb@tmb.nu> wrote:
> >> >>> Den 16.3.2021 kl. 08:37, skrev Ard Biesheuvel:
> >> >>>> Please consider backporting commit
> >> >>>>
> >> >>>> 86ad60a65f29dd862a11c22bb4b5be28d6c5cef1
> >> >>>> crypto: x86/aes-ni-xts - use direct calls to and 4-way stride
> >> >>>>
> >> >>>> to stable. It addresses a rather substantial retpoline-related
> >> >>>> performance regression in the AES-NI XTS code, which is a widely used
> >> >>>> disk encryption algorithm on x86.
> >> >>>>
> >> >>> To get all the nice bits, we added the following in Mageia 5.10 / 5.11
> >> >>> series kerenels (the 2 first is needed to get the third to apply/build
> >> >>> nicely):
> >> >>>
> >> >> I will leave it up to the -stable maintainers to decide, but I will
> >> >> point out that none of the additional patches fix any bugs, so this
> >> >> may violate the stable kernel rules. In fact, I deliberately split the
> >> >> XTS changes into two  patches so that the first one could be
> >> >> backported individually.
> >> >
> >> > Yes, I understand that.
> >> >
> >> > but commit
> >> >
> >> > 86ad60a65f29dd862a11c22bb4b5be28d6c5cef1
> >> > crypto: x86/aes-ni-xts - use direct calls to and 4-way stride
> >> >
> >> > only applies cleanly on 5.11.
> >> >
> >> >
> >> > So if it's wanted in 5.10 you need the 2 others too... unless you intend to provide a tested backport...
> >> > and IIRC GregKH prefers 1:1 matching of patches between -stable and linus tree unless they are too intrusive.
> >> >
> >> >
> >> > As for the last one I seem to remember comments that it too was part of the "affects performance", but I might be remembering wrong... and since you are Author of them I assume you know better about the facts :)
> >> >
> >> >
> >> > That's why I listed them as an extra "hopefully helfpful" info and datapoint that they work...
> >> > We have been carrying them in 5.10 series since we rebased to 5.10.8 on January 17th, 2021
> >> >
> >> >
> >> > but in the end it's up to the -stable maintainers as you point out...
> >>
> >>
> >> and now  I re-checked...
> >>
> >> Only the first is needed to get your fix to apply cleanly on 5.10
> >>
> >>
> >> the second came in as a pre-req for the fourth patch...
> >>
> >
> >OK so that would be
> >
> >032d049ea0f45b45c21f3f02b542aa18bc6b6428
> >Uros Bizjak <ubizjak@gmail.com>
> >crypto: aesni - Use TEST %reg,%reg instead of CMP $0,%reg
> >
> >which is already in 5.11, but needs to be backported as well for the
> >originally requested backport to apply cleanly to 5.10 and earlier.
> >
> >Thanks for digging that up.
>
> Queued up for 5.10 and 5.11.
>
> What about anything older than 5.10? Looks like it's needed there too?
>

Yes, 4.19 and 5.4 should probably get this too. They should apply with
minimal effort, afaict. The only conflicting change is
34fdce6981b96920ced4e0ee56e9db3fb03a33f0, which changed

--- a/arch/x86/crypto/aesni-intel_asm.S
+++ b/arch/x86/crypto/aesni-intel_asm.S
@@ -2758,7 +2758,7 @@ SYM_FUNC_START(aesni_xts_crypt8)
        pxor INC, STATE4
        movdqu IV, 0x30(OUTP)

-       CALL_NOSPEC %r11
+       CALL_NOSPEC r11

        movdqu 0x00(OUTP), INC
        pxor INC, STATE1
@@ -2803,7 +2803,7 @@ SYM_FUNC_START(aesni_xts_crypt8)
        _aesni_gf128mul_x_ble()
        movups IV, (IVP)

-       CALL_NOSPEC %r11
+       CALL_NOSPEC r11

        movdqu 0x40(OUTP), INC
        pxor INC, STATE1

but those CALL_NOSPEC calls are being removed by this patch anyway, so
that shouldn't matter.