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
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.
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
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
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.
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?
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.
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")
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.
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.
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
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
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.
linux-stable-mirror@lists.linaro.org