Re: stable request

Re: stable request

[Thomas Backlund]

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):

applied in this order:

 From 032d049ea0f45b45c21f3f02b542aa18bc6b6428 Mon Sep 17 00:00:00 2001
From: Uros Bizjak <ubizjak@gmail.com>
Date: Fri, 27 Nov 2020 10:44:52 +0100
Subject: [PATCH] crypto: aesni - Use TEST %reg,%reg instead of CMP $0,%reg

 From ddf169a98f01d6fd46295ec0dd4c1d6385be65d4 Mon Sep 17 00:00:00 2001
From: Ard Biesheuvel <ardb@kernel.org>
Date: Tue, 8 Dec 2020 00:34:02 +0100
Subject: [PATCH] crypto: aesni - implement support for cts(cbc(aes))

 From 86ad60a65f29dd862a11c22bb4b5be28d6c5cef1 Mon Sep 17 00:00:00 2001
From: Ard Biesheuvel <ardb@kernel.org>
Date: Thu, 31 Dec 2020 17:41:54 +0100
Subject: [PATCH] crypto: x86/aes-ni-xts - use direct calls to and 4-way
stride

 From 2481104fe98d5b016fdd95d649b1235f21e491ba Mon Sep 17 00:00:00 2001
From: Ard Biesheuvel <ardb@kernel.org>
Date: Thu, 31 Dec 2020 17:41:55 +0100
Subject: [PATCH] crypto: x86/aes-ni-xts - rewrite and drop indirections
via glue helper

--
Thomas

Re: stable request

[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.

-- 
Ard.


> applied in this order:
>
>  From 032d049ea0f45b45c21f3f02b542aa18bc6b6428 Mon Sep 17 00:00:00 2001
> From: Uros Bizjak <ubizjak@gmail.com>
> Date: Fri, 27 Nov 2020 10:44:52 +0100
> Subject: [PATCH] crypto: aesni - Use TEST %reg,%reg instead of CMP $0,%reg
>
>  From ddf169a98f01d6fd46295ec0dd4c1d6385be65d4 Mon Sep 17 00:00:00 2001
> From: Ard Biesheuvel <ardb@kernel.org>
> Date: Tue, 8 Dec 2020 00:34:02 +0100
> Subject: [PATCH] crypto: aesni - implement support for cts(cbc(aes))
>
>  From 86ad60a65f29dd862a11c22bb4b5be28d6c5cef1 Mon Sep 17 00:00:00 2001
> From: Ard Biesheuvel <ardb@kernel.org>
> Date: Thu, 31 Dec 2020 17:41:54 +0100
> Subject: [PATCH] crypto: x86/aes-ni-xts - use direct calls to and 4-way
> stride
>
>  From 2481104fe98d5b016fdd95d649b1235f21e491ba Mon Sep 17 00:00:00 2001
> From: Ard Biesheuvel <ardb@kernel.org>
> Date: Thu, 31 Dec 2020 17:41:55 +0100
> Subject: [PATCH] crypto: x86/aes-ni-xts - rewrite and drop indirections
> via glue helper
>
> --
> Thomas
>

Re: stable request

[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...

--
Thomas

> --
> Ard.
>
>
>> applied in this order:
>>
>>   From 032d049ea0f45b45c21f3f02b542aa18bc6b6428 Mon Sep 17 00:00:00 2001
>> From: Uros Bizjak <ubizjak@gmail.com>
>> Date: Fri, 27 Nov 2020 10:44:52 +0100
>> Subject: [PATCH] crypto: aesni - Use TEST %reg,%reg instead of CMP $0,%reg
>>
>>   From ddf169a98f01d6fd46295ec0dd4c1d6385be65d4 Mon Sep 17 00:00:00 2001
>> From: Ard Biesheuvel <ardb@kernel.org>
>> Date: Tue, 8 Dec 2020 00:34:02 +0100
>> Subject: [PATCH] crypto: aesni - implement support for cts(cbc(aes))
>>
>>   From 86ad60a65f29dd862a11c22bb4b5be28d6c5cef1 Mon Sep 17 00:00:00 2001
>> From: Ard Biesheuvel <ardb@kernel.org>
>> Date: Thu, 31 Dec 2020 17:41:54 +0100
>> Subject: [PATCH] crypto: x86/aes-ni-xts - use direct calls to and 4-way
>> stride
>>
>>   From 2481104fe98d5b016fdd95d649b1235f21e491ba Mon Sep 17 00:00:00 2001
>> From: Ard Biesheuvel <ardb@kernel.org>
>> Date: Thu, 31 Dec 2020 17:41:55 +0100
>> Subject: [PATCH] crypto: x86/aes-ni-xts - rewrite and drop indirections
>> via glue helper
>>
>> --
>> Thomas
>>

Re: stable request

[Thomas Backlund]

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...

--

Thomas



> --
> Thomas
>
>> --
>> Ard.
>>
>>
>>> applied in this order:
>>>
>>>    From 032d049ea0f45b45c21f3f02b542aa18bc6b6428 Mon Sep 17 00:00:00 2001
>>> From: Uros Bizjak <ubizjak@gmail.com>
>>> Date: Fri, 27 Nov 2020 10:44:52 +0100
>>> Subject: [PATCH] crypto: aesni - Use TEST %reg,%reg instead of CMP $0,%reg
>>>
>>>    From ddf169a98f01d6fd46295ec0dd4c1d6385be65d4 Mon Sep 17 00:00:00 2001
>>> From: Ard Biesheuvel <ardb@kernel.org>
>>> Date: Tue, 8 Dec 2020 00:34:02 +0100
>>> Subject: [PATCH] crypto: aesni - implement support for cts(cbc(aes))
>>>
>>>    From 86ad60a65f29dd862a11c22bb4b5be28d6c5cef1 Mon Sep 17 00:00:00 2001
>>> From: Ard Biesheuvel <ardb@kernel.org>
>>> Date: Thu, 31 Dec 2020 17:41:54 +0100
>>> Subject: [PATCH] crypto: x86/aes-ni-xts - use direct calls to and 4-way
>>> stride
>>>
>>>    From 2481104fe98d5b016fdd95d649b1235f21e491ba Mon Sep 17 00:00:00 2001
>>> From: Ard Biesheuvel <ardb@kernel.org>
>>> Date: Thu, 31 Dec 2020 17:41:55 +0100
>>> Subject: [PATCH] crypto: x86/aes-ni-xts - rewrite and drop indirections
>>> via glue helper
>>>
>>> --
>>> Thomas
>>>

Re: stable request

[Ard Biesheuvel]

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.

-- 
Ard.

Re: stable request

[Sasha Levin]

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?

-- 
Thanks,
Sasha

Re: stable request

[Ard Biesheuvel]

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.

Re: stable request

[Sasha Levin]

On Thu, Mar 18, 2021 at 03:15:35PM +0100, Ard Biesheuvel wrote:
>On Thu, 18 Mar 2021 at 14:03, Sasha Levin <sashal@kernel.org> wrote:
>> 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.

Hm, I'm seeing a lot more conflicts on 5.4 that I'm not too comfortable
with resolving.

I should be taking just these two, right?

	032d049ea0f4 ("crypto: aesni - Use TEST %reg,%reg instead of CMP $0,%reg")
	86ad60a65f29 ("crypto: x86/aes-ni-xts - use direct calls to and 4-way stride")

-- 
Thanks,
Sasha

Re: stable request

[Ard Biesheuvel]

On Thu, 18 Mar 2021 at 17:42, Sasha Levin <sashal@kernel.org> wrote:
>
> On Thu, Mar 18, 2021 at 03:15:35PM +0100, Ard Biesheuvel wrote:
> >On Thu, 18 Mar 2021 at 14:03, Sasha Levin <sashal@kernel.org> wrote:
> >> 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.
>
> Hm, I'm seeing a lot more conflicts on 5.4 that I'm not too comfortable
> with resolving.
>
> I should be taking just these two, right?
>
>         032d049ea0f4 ("crypto: aesni - Use TEST %reg,%reg instead of CMP $0,%reg")
>         86ad60a65f29 ("crypto: x86/aes-ni-xts - use direct calls to and 4-way stride")
>

I'll take a look into this, and send separate 5.4 and 4.19 backports
if feasible, or forget about it otherwise.

Re: stable request

[Ard Biesheuvel]

On Thu, 18 Mar 2021 at 18:13, Ard Biesheuvel <ardb@kernel.org> wrote:
>
> On Thu, 18 Mar 2021 at 17:42, Sasha Levin <sashal@kernel.org> wrote:
> >
> > On Thu, Mar 18, 2021 at 03:15:35PM +0100, Ard Biesheuvel wrote:
> > >On Thu, 18 Mar 2021 at 14:03, Sasha Levin <sashal@kernel.org> wrote:
> > >> 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.
> >
> > Hm, I'm seeing a lot more conflicts on 5.4 that I'm not too comfortable
> > with resolving.
> >
> > I should be taking just these two, right?
> >
> >         032d049ea0f4 ("crypto: aesni - Use TEST %reg,%reg instead of CMP $0,%reg")
> >         86ad60a65f29 ("crypto: x86/aes-ni-xts - use direct calls to and 4-way stride")
> >
>
> I'll take a look into this, and send separate 5.4 and 4.19 backports
> if feasible, or forget about it otherwise.

v5.4 was straight-forward but v4.19 looks a bit more complicated, and
given that this only affects performance, I am not going to bother
unless anyone specifically asks for it.

Re: stable request

[Thomas Backlund]

Den 18-03-2021 kl. 15:03, skrev Sasha Levin:
>
> 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


>
> Queued up for 5.10 and 5.11.
>

I dont see:
86ad60a65f29 ("crypto: x86/aes-ni-xts - use direct calls to and 4-way
stride")

in 5.11 queue.

--
Thomas

Re: stable request

[Greg KH]

On Fri, Mar 19, 2021 at 07:35:44AM +0000, Thomas Backlund wrote:
> Den 18-03-2021 kl. 15:03, skrev Sasha Levin:
> >
> > 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
> 
> 
> >
> > Queued up for 5.10 and 5.11.
> >
> 
> I dont see:
> 86ad60a65f29 ("crypto: x86/aes-ni-xts - use direct calls to and 4-way
> stride")
> 
> in 5.11 queue.

Now added by me, Sasha might have forgotten to push his queue...

thanks,

greg k-h

Re: stable request

[Sasha Levin]

On Fri, Mar 19, 2021 at 11:50:06AM +0100, Greg KH wrote:
>On Fri, Mar 19, 2021 at 07:35:44AM +0000, Thomas Backlund wrote:
>> Den 18-03-2021 kl. 15:03, skrev Sasha Levin:
>> >
>> > 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
>>
>>
>> >
>> > Queued up for 5.10 and 5.11.
>> >
>>
>> I dont see:
>> 86ad60a65f29 ("crypto: x86/aes-ni-xts - use direct calls to and 4-way
>> stride")
>>
>> in 5.11 queue.
>
>Now added by me, Sasha might have forgotten to push his queue...

Thanks Greg, yes - it was sitting locally waiting for my build tests to
finish.

-- 
Thanks,
Sasha

stable request

[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.

-- 
Ard.

Re: [PATCH net-next] net: ipv6: fix listify ip6_rcv_finish in case of forwarding

[David Miller]

From: Xin Long <lucien.xin@gmail.com>
Date: Fri, 23 Aug 2019 19:33:03 +0800

> We need a similar fix for ipv6 as Commit 0761680d5215 ("net: ipv4: fix
> listify ip_rcv_finish in case of forwarding") does for ipv4.
> 
> This issue can be reprocuded by syzbot since Commit 323ebb61e32b ("net:
> use listified RX for handling GRO_NORMAL skbs") on net-next. The call
> trace was:
 ...
> Fixes: d8269e2cbf90 ("net: ipv6: listify ipv6_rcv() and ip6_rcv_finish()")
> Fixes: 323ebb61e32b ("net: use listified RX for handling GRO_NORMAL skbs")
> Reported-by: syzbot+eb349eeee854e389c36d@syzkaller.appspotmail.com
> Reported-by: syzbot+4a0643a653ac375612d1@syzkaller.appspotmail.com
> Signed-off-by: Xin Long <lucien.xin@gmail.com>

Applied, thanks.

Re: [PATCH net-next] net: ipv6: fix listify ip6_rcv_finish in case of forwarding

[Edward Cree]

On 23/08/2019 22:42, David Miller wrote:
> From: Xin Long <lucien.xin@gmail.com>
> Date: Fri, 23 Aug 2019 19:33:03 +0800
>
>> We need a similar fix for ipv6 as Commit 0761680d5215 ("net: ipv4: fix
>> listify ip_rcv_finish in case of forwarding") does for ipv4.
>>
>> This issue can be reprocuded by syzbot since Commit 323ebb61e32b ("net:
>> use listified RX for handling GRO_NORMAL skbs") on net-next. The call
>> trace was:
>  ...
>> Fixes: d8269e2cbf90 ("net: ipv6: listify ipv6_rcv() and ip6_rcv_finish()")
>> Fixes: 323ebb61e32b ("net: use listified RX for handling GRO_NORMAL skbs")
>> Reported-by: syzbot+eb349eeee854e389c36d@syzkaller.appspotmail.com
>> Reported-by: syzbot+4a0643a653ac375612d1@syzkaller.appspotmail.com
>> Signed-off-by: Xin Long <lucien.xin@gmail.com>
> Applied, thanks.
Just noticed that this only went to net-next (and 5.4-rc1), when actually
 it's needed on all kernels back to 4.19 (per the first Fixes: tag).  The
 second Fixes: reference, 323ebb61e32b, merely enables syzbot to hit it on
 whatever hardware it has, but the bug was already there, and hittable on
 sfc NICs.
David, can this go to stable please?

Stable request (was Re: [PATCH net-next] net: ipv6: fix listify ip6_rcv_finish in case of forwarding

[Edward Cree]

On 04/10/2019 16:17, Edward Cree wrote:
> On 23/08/2019 22:42, David Miller wrote:
>> From: Xin Long <lucien.xin@gmail.com>
>> Date: Fri, 23 Aug 2019 19:33:03 +0800
>>
>>> We need a similar fix for ipv6 as Commit 0761680d5215 ("net: ipv4: fix
>>> listify ip_rcv_finish in case of forwarding") does for ipv4.
>>>
>>> This issue can be reprocuded by syzbot since Commit 323ebb61e32b ("net:
>>> use listified RX for handling GRO_NORMAL skbs") on net-next. The call
>>> trace was:
>>  ...
>>> Fixes: d8269e2cbf90 ("net: ipv6: listify ipv6_rcv() and ip6_rcv_finish()")
>>> Fixes: 323ebb61e32b ("net: use listified RX for handling GRO_NORMAL skbs")
>>> Reported-by: syzbot+eb349eeee854e389c36d@syzkaller.appspotmail.com
>>> Reported-by: syzbot+4a0643a653ac375612d1@syzkaller.appspotmail.com
>>> Signed-off-by: Xin Long <lucien.xin@gmail.com>
>> Applied, thanks.
> Just noticed that this only went to net-next (and 5.4-rc1), when actually
>  it's needed on all kernels back to 4.19 (per the first Fixes: tag).  The
>  second Fixes: reference, 323ebb61e32b, merely enables syzbot to hit it on
>  whatever hardware it has, but the bug was already there, and hittable on
>  sfc NICs.
> David, can this go to stable please?
Hi, did this get missed or was my request improper in some way?
Our testing has been hitting this issue on distro kernels (Fedora, Debian,
 Ubuntu), we'd like the fix to get everywhere it's needed and AIUI -stable
 is the proper route for that.
For reference, the fix was committed as c7a42eb49212.

-Ed

Re: Stable request

[David Miller]

From: Edward Cree <ecree@solarflare.com>
Date: Wed, 16 Oct 2019 16:26:50 +0100

> On 04/10/2019 16:17, Edward Cree wrote:
>> On 23/08/2019 22:42, David Miller wrote:
>>> From: Xin Long <lucien.xin@gmail.com>
>>> Date: Fri, 23 Aug 2019 19:33:03 +0800
>>>
>>>> We need a similar fix for ipv6 as Commit 0761680d5215 ("net: ipv4: fix
>>>> listify ip_rcv_finish in case of forwarding") does for ipv4.
>>>>
>>>> This issue can be reprocuded by syzbot since Commit 323ebb61e32b ("net:
>>>> use listified RX for handling GRO_NORMAL skbs") on net-next. The call
>>>> trace was:
>>>  ...
>>>> Fixes: d8269e2cbf90 ("net: ipv6: listify ipv6_rcv() and ip6_rcv_finish()")
>>>> Fixes: 323ebb61e32b ("net: use listified RX for handling GRO_NORMAL skbs")
>>>> Reported-by: syzbot+eb349eeee854e389c36d@syzkaller.appspotmail.com
>>>> Reported-by: syzbot+4a0643a653ac375612d1@syzkaller.appspotmail.com
>>>> Signed-off-by: Xin Long <lucien.xin@gmail.com>
>>> Applied, thanks.
>> Just noticed that this only went to net-next (and 5.4-rc1), when actually
>>  it's needed on all kernels back to 4.19 (per the first Fixes: tag).  The
>>  second Fixes: reference, 323ebb61e32b, merely enables syzbot to hit it on
>>  whatever hardware it has, but the bug was already there, and hittable on
>>  sfc NICs.
>> David, can this go to stable please?
> Hi, did this get missed or was my request improper in some way?

Sorry, I'm just getting over a cold and very backlogged on this kind of stuff.

I'll get to this while I can Ed.

Re: Stable request

[David Miller]

From: Edward Cree <ecree@solarflare.com>
Date: Wed, 16 Oct 2019 16:26:50 +0100

> On 04/10/2019 16:17, Edward Cree wrote:
>> On 23/08/2019 22:42, David Miller wrote:
>>> From: Xin Long <lucien.xin@gmail.com>
>>> Date: Fri, 23 Aug 2019 19:33:03 +0800
>>>
>>>> We need a similar fix for ipv6 as Commit 0761680d5215 ("net: ipv4: fix
>>>> listify ip_rcv_finish in case of forwarding") does for ipv4.
>>>>
>>>> This issue can be reprocuded by syzbot since Commit 323ebb61e32b ("net:
>>>> use listified RX for handling GRO_NORMAL skbs") on net-next. The call
>>>> trace was:
>>>  ...
>>>> Fixes: d8269e2cbf90 ("net: ipv6: listify ipv6_rcv() and ip6_rcv_finish()")
>>>> Fixes: 323ebb61e32b ("net: use listified RX for handling GRO_NORMAL skbs")
>>>> Reported-by: syzbot+eb349eeee854e389c36d@syzkaller.appspotmail.com
>>>> Reported-by: syzbot+4a0643a653ac375612d1@syzkaller.appspotmail.com
>>>> Signed-off-by: Xin Long <lucien.xin@gmail.com>
>>> Applied, thanks.
>> Just noticed that this only went to net-next (and 5.4-rc1), when actually
>>  it's needed on all kernels back to 4.19 (per the first Fixes: tag).  The
>>  second Fixes: reference, 323ebb61e32b, merely enables syzbot to hit it on
>>  whatever hardware it has, but the bug was already there, and hittable on
>>  sfc NICs.
>> David, can this go to stable please?
> Hi, did this get missed or was my request improper in some way?

Sorry, I'm just getting over a cold and very backlogged on this kind of stuff.

I'll get to this while I can Ed.

Re: Stable request

[David Miller]

From: Edward Cree <ecree@solarflare.com>
Date: Wed, 16 Oct 2019 16:26:50 +0100

> Hi, did this get missed or was my request improper in some way?
> Our testing has been hitting this issue on distro kernels (Fedora, Debian,
>  Ubuntu), we'd like the fix to get everywhere it's needed and AIUI -stable
>  is the proper route for that.
> For reference, the fix was committed as c7a42eb49212.

I've queued this up for my next set of -stable submissions.

Thanks Ed.

Re: Stable request

[David Miller]

From: Edward Cree <ecree@solarflare.com>
Date: Wed, 16 Oct 2019 16:26:50 +0100

> Hi, did this get missed or was my request improper in some way?
> Our testing has been hitting this issue on distro kernels (Fedora, Debian,
>  Ubuntu), we'd like the fix to get everywhere it's needed and AIUI -stable
>  is the proper route for that.
> For reference, the fix was committed as c7a42eb49212.

I've queued this up for my next set of -stable submissions.

Thanks Ed.