- Kernel - mailweb.openeuler.org

[openeuler:OLK-5.10] BUILD SUCCESS 3fd44f97e25ee6da48514e6e8e25380254151c58
by kernel test robot 17 May '24

17 May '24

tree/branch: https://gitee.com/openeuler/kernel.git OLK-5.10 branch HEAD: 3fd44f97e25ee6da48514e6e8e25380254151c58 !7394 v2 scsi: sr: Do not leak information in ioctl Warning ids grouped by kconfigs: clang_recent_errors `-- x86_64-allnoconfig `-- Warning:openEuler-MAINTAINERS-references-a-file-that-doesn-t-exist:Documentation-networking-hinic3.rst elapsed time: 725m configs tested: 35 configs skipped: 148 The following configs have been built successfully. More configs may be tested in the coming days. tested configs: arm64 allmodconfig clang arm64 allnoconfig gcc arm64 defconfig gcc arm64 randconfig-001-20240516 gcc arm64 randconfig-002-20240516 clang arm64 randconfig-003-20240516 clang arm64 randconfig-004-20240516 gcc x86_64 allnoconfig clang x86_64 allyesconfig clang x86_64 buildonly-randconfig-001-20240517 clang x86_64 buildonly-randconfig-002-20240517 gcc x86_64 buildonly-randconfig-003-20240517 clang x86_64 buildonly-randconfig-004-20240517 gcc x86_64 buildonly-randconfig-005-20240517 gcc x86_64 buildonly-randconfig-006-20240517 clang x86_64 defconfig gcc x86_64 randconfig-001-20240517 clang x86_64 randconfig-002-20240517 clang x86_64 randconfig-003-20240517 clang x86_64 randconfig-004-20240517 gcc x86_64 randconfig-005-20240517 gcc x86_64 randconfig-006-20240517 clang x86_64 randconfig-011-20240517 clang x86_64 randconfig-012-20240517 clang x86_64 randconfig-013-20240517 clang x86_64 randconfig-014-20240517 clang x86_64 randconfig-015-20240517 gcc x86_64 randconfig-016-20240517 gcc x86_64 randconfig-071-20240517 clang x86_64 randconfig-072-20240517 gcc x86_64 randconfig-073-20240517 gcc x86_64 randconfig-074-20240517 gcc x86_64 randconfig-075-20240517 gcc x86_64 randconfig-076-20240517 clang x86_64 rhel-8.3-rust clang -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

[openeuler:openEuler-1.0-LTS 8557/22438] mm/swapfile.o: warning: objtool: missing symbol for section .text.unlikely
by kernel test robot 17 May '24

17 May '24

tree: https://gitee.com/openeuler/kernel.git openEuler-1.0-LTS head: 8ac9764e4f9b88e554a8dafd8283dab32512691c commit: 775947c125d5bd6e00e0dcf9d12c57fd5d44d07f [8557/22438] asm-generic: fix -Wtype-limits compiler warnings config: x86_64-buildonly-randconfig-001-20240516 (https://download.01.org/0day-ci/archive/20240517/202405170118.NQpCse4L-lkp@…) compiler: gcc-11 (Ubuntu 11.4.0-4ubuntu1) 11.4.0 reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240517/202405170118.NQpCse4L-lkp@…) If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot <lkp(a)intel.com> | Closes: https://lore.kernel.org/oe-kbuild-all/202405170118.NQpCse4L-lkp@intel.com/ All warnings (new ones prefixed by >>): >> mm/swapfile.o: warning: objtool: missing symbol for section .text.unlikely -- In file included from include/linux/sctp.h:57, from net/core/dev.c:145: include/uapi/linux/sctp.h:390:1: warning: alignment 4 of 'struct sctp_paddr_change' is less than 8 [-Wpacked-not-aligned] 390 | } __attribute__((packed, aligned(4))); | ^ include/uapi/linux/sctp.h:719:1: warning: alignment 4 of 'struct sctp_setpeerprim' is less than 8 [-Wpacked-not-aligned] 719 | } __attribute__((packed, aligned(4))); | ^ include/uapi/linux/sctp.h:718:33: warning: 'sspp_addr' offset 4 in 'struct sctp_setpeerprim' isn't aligned to 8 [-Wpacked-not-aligned] 718 | struct sockaddr_storage sspp_addr; | ^~~~~~~~~ include/uapi/linux/sctp.h:732:1: warning: alignment 4 of 'struct sctp_prim' is less than 8 [-Wpacked-not-aligned] 732 | } __attribute__((packed, aligned(4))); | ^ include/uapi/linux/sctp.h:731:33: warning: 'ssp_addr' offset 4 in 'struct sctp_prim' isn't aligned to 8 [-Wpacked-not-aligned] 731 | struct sockaddr_storage ssp_addr; | ^~~~~~~~ include/uapi/linux/sctp.h:783:1: warning: alignment 4 of 'struct sctp_paddrparams' is less than 8 [-Wpacked-not-aligned] 783 | } __attribute__((packed, aligned(4))); | ^ include/uapi/linux/sctp.h:775:33: warning: 'spp_address' offset 4 in 'struct sctp_paddrparams' isn't aligned to 8 [-Wpacked-not-aligned] 775 | struct sockaddr_storage spp_address; | ^~~~~~~~~~~ include/uapi/linux/sctp.h:896:1: warning: alignment 4 of 'struct sctp_paddrinfo' is less than 8 [-Wpacked-not-aligned] 896 | } __attribute__((packed, aligned(4))); | ^ include/uapi/linux/sctp.h:890:33: warning: 'spinfo_address' offset 4 in 'struct sctp_paddrinfo' isn't aligned to 8 [-Wpacked-not-aligned] 890 | struct sockaddr_storage spinfo_address; | ^~~~~~~~~~~~~~ In file included from include/linux/if_ether.h:23, from net/core/dev.c:92: include/linux/skbuff.h: In function '__skb_metadata_differs': include/linux/skbuff.h:3501:24: warning: this statement may fall through [-Wimplicit-fallthrough=] 3501 | case 32: diffs |= __it_diff(a, b, 64); | ^~ include/linux/skbuff.h:3502:9: note: here 3502 | case 24: diffs |= __it_diff(a, b, 64); | ^~~~ include/linux/skbuff.h:3502:24: warning: this statement may fall through [-Wimplicit-fallthrough=] 3502 | case 24: diffs |= __it_diff(a, b, 64); | ^~ include/linux/skbuff.h:3503:9: note: here 3503 | case 16: diffs |= __it_diff(a, b, 64); | ^~~~ include/linux/skbuff.h:3503:24: warning: this statement may fall through [-Wimplicit-fallthrough=] 3503 | case 16: diffs |= __it_diff(a, b, 64); | ^~ include/linux/skbuff.h:3504:9: note: here 3504 | case 8: diffs |= __it_diff(a, b, 64); | ^~~~ include/linux/skbuff.h:3506:24: warning: this statement may fall through [-Wimplicit-fallthrough=] 3506 | case 28: diffs |= __it_diff(a, b, 64); | ^~ include/linux/skbuff.h:3507:9: note: here 3507 | case 20: diffs |= __it_diff(a, b, 64); | ^~~~ include/linux/skbuff.h:3507:24: warning: this statement may fall through [-Wimplicit-fallthrough=] 3507 | case 20: diffs |= __it_diff(a, b, 64); | ^~ include/linux/skbuff.h:3508:9: note: here 3508 | case 12: diffs |= __it_diff(a, b, 64); | ^~~~ include/linux/skbuff.h:3508:24: warning: this statement may fall through [-Wimplicit-fallthrough=] 3508 | case 12: diffs |= __it_diff(a, b, 64); | ^~ include/linux/skbuff.h:3509:9: note: here 3509 | case 4: diffs |= __it_diff(a, b, 32); | ^~~~ >> net/core/dev.o: warning: objtool: missing symbol for section .text.unlikely -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

[openeuler:openEuler-1.0-LTS] BUILD SUCCESS 8ac9764e4f9b88e554a8dafd8283dab32512691c
by kernel test robot 16 May '24

16 May '24

tree/branch: https://gitee.com/openeuler/kernel.git openEuler-1.0-LTS branch HEAD: 8ac9764e4f9b88e554a8dafd8283dab32512691c !7228 s390/zcrypt: fix reference counting on zcrypt card objects Warning ids grouped by kconfigs: gcc_recent_errors |-- arm64-allmodconfig | `-- drivers-gpu-drm-nouveau-nvkm-core-object.c:warning:ISO-C90-forbids-mixed-declarations-and-code |-- arm64-defconfig | `-- drivers-gpu-drm-nouveau-nvkm-core-object.c:warning:ISO-C90-forbids-mixed-declarations-and-code |-- arm64-randconfig-002-20240516 | `-- drivers-gpu-drm-nouveau-nvkm-core-object.c:warning:ISO-C90-forbids-mixed-declarations-and-code |-- arm64-randconfig-003-20240516 | `-- drivers-gpu-drm-nouveau-nvkm-core-object.c:warning:ISO-C90-forbids-mixed-declarations-and-code `-- x86_64-buildonly-randconfig-004-20240516 `-- drivers-gpu-drm-nouveau-nvkm-core-object.c:warning:ISO-C90-forbids-mixed-declarations-and-code clang_recent_errors |-- x86_64-allyesconfig | |-- drivers-gpu-drm-nouveau-nvkm-core-object.c:warning:mixing-declarations-and-code-is-a-C99-extension | `-- net-ipv4-arp.c:warning:comparison-of-distinct-pointer-types-(-typeof-(dev-addr_len)-(aka-unsigned-char-)-and-typeof-(sizeof-(r-arp_ha.sa_data))-(aka-unsigned-long-)) |-- x86_64-buildonly-randconfig-005-20240516 | |-- drivers-gpu-drm-nouveau-nvkm-core-object.c:warning:mixing-declarations-and-code-is-a-C99-extension | `-- net-ipv4-arp.c:warning:comparison-of-distinct-pointer-types-(-typeof-(dev-addr_len)-(aka-unsigned-char-)-and-typeof-(sizeof-(r-arp_ha.sa_data))-(aka-unsigned-long-)) |-- x86_64-randconfig-161-20240516 | `-- net-ipv4-arp.c:warning:comparison-of-distinct-pointer-types-(-typeof-(dev-addr_len)-(aka-unsigned-char-)-and-typeof-(sizeof-(r-arp_ha.sa_data))-(aka-unsigned-long-)) `-- x86_64-rhel-8.3-rust `-- net-ipv4-arp.c:warning:comparison-of-distinct-pointer-types-(-typeof-(dev-addr_len)-(aka-unsigned-char-)-and-typeof-(sizeof-(r-arp_ha.sa_data))-(aka-unsigned-long-)) elapsed time: 737m configs tested: 16 configs skipped: 148 The following configs have been built successfully. More configs may be tested in the coming days. tested configs: arm64 allmodconfig gcc arm64 allnoconfig gcc arm64 defconfig gcc arm64 randconfig-001-20240516 gcc arm64 randconfig-002-20240516 gcc arm64 randconfig-003-20240516 gcc arm64 randconfig-004-20240516 gcc x86_64 allnoconfig clang x86_64 allyesconfig clang x86_64 buildonly-randconfig-001-20240516 gcc x86_64 buildonly-randconfig-002-20240516 clang x86_64 buildonly-randconfig-003-20240516 gcc x86_64 buildonly-randconfig-004-20240516 gcc x86_64 buildonly-randconfig-005-20240516 clang x86_64 defconfig gcc x86_64 rhel-8.3-rust clang -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

[PATCH OLK-6.6] arm64: lib: improve usercopy performance by mitigating data dependencies
by Li Zetao 16 May '24

16 May '24

hulk inclusion category: performance bugzilla: https://gitee.com/openeuler/kernel/issues/I9PXLD?from=project-issue CVE: NA -------------------------------- In the copy_from/to_user scenario, due to the need to accurately calculate the number of copied bytes for fixup, it is necessary to increment the values of src and dst after each copy of the data. Therefore, this introduce RAW dependency which result in some bubble in pipline and degrade the IPC. Consider updating the values of src and dst only when the copy is completed in the current stage to reduce data dependence. But this will break the function of fixup, so in order to maintain the function of fixup, a new macro USER_OFF is introduced to determine the number of bytes that load/store has completed copying at this stage, the final number of bytes that have not been copied can be determined. The following are the test results of UnixBench in HiSilicon KunPeng920: without this patch with this patch System Benchmarks Index Values INDEX INDEX Dhrystone 2 using register variables 3714.0 3770.5 Double-Precision Whetstone 797.1 797.1 Execl Throughput 665.8 663.9 File Copy 1024 bufsize 2000 maxblocks 2465.5 2435.5 File Copy 256 bufsize 500 maxblocks 1748.2 1724.4 File Copy 4096 bufsize 8000 maxblocks 3734.4 3634.8 Pipe Throughput 1019.9 1022.0 Pipe-based Context Switching 346.9 394.0 Process Creation 500.1 512.0 Shell Scripts (1 concurrent) 1495.8 1521.4 Shell Scripts (8 concurrent) 5132.4 5202.2 System Call Overhead 681.6 697.2 ======== ======== System Benchmarks Index Score 1325.3 1343.7 Signed-off-by: Li Zetao <lizetao1(a)huawei.com> --- arch/arm64/include/asm/asm-uaccess.h | 29 ---- arch/arm64/lib/copy_from_user.S | 241 +++++++++++++++++++++----- arch/arm64/lib/copy_to_user.S | 242 ++++++++++++++++++++++----- 3 files changed, 406 insertions(+), 106 deletions(-) diff --git a/arch/arm64/include/asm/asm-uaccess.h b/arch/arm64/include/asm/asm-uaccess.h index 7bbebfa5b7103..7a872c77c03ac 100644 --- a/arch/arm64/include/asm/asm-uaccess.h +++ b/arch/arm64/include/asm/asm-uaccess.h @@ -65,33 +65,4 @@ alternative_else_nop_endif 9999: x; \ _asm_extable_uaccess 9999b, l -/* - * Generate the assembly for LDTR/STTR with exception table entries. - * This is complicated as there is no post-increment or pair versions of the - * unprivileged instructions, and USER() only works for single instructions. - */ - .macro user_ldp l, reg1, reg2, addr, post_inc -8888: ldtr \reg1, [\addr]; -8889: ldtr \reg2, [\addr, #8]; - add \addr, \addr, \post_inc; - - _asm_extable_uaccess 8888b, \l; - _asm_extable_uaccess 8889b, \l; - .endm - - .macro user_stp l, reg1, reg2, addr, post_inc -8888: sttr \reg1, [\addr]; -8889: sttr \reg2, [\addr, #8]; - add \addr, \addr, \post_inc; - - _asm_extable_uaccess 8888b,\l; - _asm_extable_uaccess 8889b,\l; - .endm - - .macro user_ldst l, inst, reg, addr, post_inc -8888: \inst \reg, [\addr]; - add \addr, \addr, \post_inc; - - _asm_extable_uaccess 8888b, \l; - .endm #endif diff --git a/arch/arm64/lib/copy_from_user.S b/arch/arm64/lib/copy_from_user.S index 34e3179075244..a80b8679c4b58 100644 --- a/arch/arm64/lib/copy_from_user.S +++ b/arch/arm64/lib/copy_from_user.S @@ -20,54 +20,219 @@ * x0 - bytes not copied */ - .macro ldrb1 reg, ptr, val - user_ldst 9998f, ldtrb, \reg, \ptr, \val - .endm +dstin .req x0 +end .req x5 +src .req x1 +srcin .req x15 +count .req x2 +tmp1 .req x3 +tmp1w .req w3 +tmp2 .req x4 +tmp2w .req w4 +dst .req x6 - .macro strb1 reg, ptr, val - strb \reg, [\ptr], \val - .endm +A_l .req x7 +A_h .req x8 +B_l .req x9 +B_h .req x10 +C_l .req x11 +C_h .req x12 +D_l .req x13 +D_h .req x14 - .macro ldrh1 reg, ptr, val - user_ldst 9997f, ldtrh, \reg, \ptr, \val - .endm +#define USER_OFF(off, x...) USER(fixup_offset_##off, x) +#define FIXUP_OFFSET(n) \ +fixup_offset_##n: \ + sub x0, end, dst; \ + sub x0, x0, n; \ + ret - .macro strh1 reg, ptr, val - strh \reg, [\ptr], \val - .endm +FIXUP_OFFSET(0) +FIXUP_OFFSET(8) +FIXUP_OFFSET(16) +FIXUP_OFFSET(24) +FIXUP_OFFSET(32) +FIXUP_OFFSET(40) +FIXUP_OFFSET(48) +FIXUP_OFFSET(56) - .macro ldr1 reg, ptr, val - user_ldst 9997f, ldtr, \reg, \ptr, \val - .endm +SYM_FUNC_START(__arch_copy_from_user) + add end, x0, x2 + mov srcin, x1 - .macro str1 reg, ptr, val - str \reg, [\ptr], \val - .endm + mov dst, dstin + cmp count, #16 + /*When memory length is less than 16, the accessed are not aligned.*/ + b.lo .Ltiny15 - .macro ldp1 reg1, reg2, ptr, val - user_ldp 9997f, \reg1, \reg2, \ptr, \val - .endm + neg tmp2, src + ands tmp2, tmp2, #15/* Bytes to reach alignment. */ + b.eq .LSrcAligned + sub count, count, tmp2 + /* + * Copy the leading memory data from src to dst in an increasing + * address order.By this way,the risk of overwriting the source + * memory data is eliminated when the distance between src and + * dst is less than 16. The memory accesses here are alignment. + */ + tbz tmp2, #0, 1f +USER_OFF(0, ldtrb tmp1w, [src, #0]) + strb tmp1w, [dst], #1 + add src, src, #1 +1: + tbz tmp2, #1, 2f +USER_OFF(0, ldtrh tmp1w, [src, #0]) + strh tmp1w, [dst], #2 + add src, src, #2 +2: + tbz tmp2, #2, 3f +USER_OFF(0, ldtr tmp1w, [src, #0]) + str tmp1w, [dst], #4 + add src, src, #4 +3: + tbz tmp2, #3, .LSrcAligned +USER_OFF(0, ldtr tmp1, [src, #0]) + str tmp1, [dst], #8 + add src, src, #8 - .macro stp1 reg1, reg2, ptr, val - stp \reg1, \reg2, [\ptr], \val - .endm +.LSrcAligned: + cmp count, #64 + b.ge .Lcpy_over64 + /* + * Deal with small copies quickly by dropping straight into the + * exit block. + */ +.Ltail63: + /* + * Copy up to 48 bytes of data. At this point we only need the + * bottom 6 bits of count to be accurate. + */ + ands tmp1, count, #0x30 + b.eq .Ltiny15 + USER_OFF(0, ldtr A_l, [src, #0]) + USER_OFF(8, ldtr A_h, [src, #8]) + cmp tmp1w, #0x20 + b.eq 1f + b.lt 2f + stp A_l, A_h, [dst], #16 + add src, src, #16 + USER_OFF(0, ldtr A_l, [src, #0]) + USER_OFF(8, ldtr A_h, [src, #8]) +1: + stp A_l, A_h, [dst], #16 + add src, src, #16 + USER_OFF(0, ldtr A_l, [src, #0]) + USER_OFF(8, ldtr A_h, [src, #8]) +2: + stp A_l, A_h, [dst], #16 + add src, src, #16 +.Ltiny15: + /* + * Prefer to break one ldp/stp into several load/store to access + * memory in an increasing address order,rather than to load/store 16 + * bytes from (src-16) to (dst-16) and to backward the src to aligned + * address,which way is used in original cortex memcpy. If keeping + * the original memcpy process here, memmove need to satisfy the + * precondition that src address is at least 16 bytes bigger than dst + * address,otherwise some source data will be overwritten when memove + * call memcpy directly. To make memmove simpler and decouple the + * memcpy's dependency on memmove, withdrew the original process. + */ + tbz count, #3, 1f +USER_OFF(0, ldtr tmp1, [src, #0]) + str tmp1, [dst], #8 + add src, src, #8 +1: + tbz count, #2, 2f +USER_OFF(0, ldtr tmp1w, [src, #0]) + str tmp1w, [dst], #4 + add src, src, #4 +2: + tbz count, #1, 3f +USER_OFF(0, ldtrh tmp1w, [src, #0]) + strh tmp1w, [dst], #2 + add src, src, #2 +3: + tbz count, #0, .Lexitfunc +USER_OFF(0, ldtrb tmp1w, [src, #0]) + strb tmp1w, [dst], #1 + add src, src, #1 -end .req x5 -srcin .req x15 -SYM_FUNC_START(__arch_copy_from_user) - add end, x0, x2 - mov srcin, x1 -#include "copy_template.S" + b .Lexitfunc + +.Lcpy_over64: + .p2align L1_CACHE_SHIFT + USER_OFF(0, ldtr A_l, [src, #0]) + USER_OFF(8, ldtr A_h, [src, #8]) + subs count, count, #128 + b.ge .Lcpy_body_large + /* + * Less than 128 bytes to copy, so handle 64 here and then jump + * to the tail. + */ + stp A_l, A_h, [dst, #0] +USER_OFF(16, ldtr B_l, [src, #16]) +USER_OFF(24, ldtr B_h, [src, #24]) +USER_OFF(32, ldtr C_l, [src, #32]) +USER_OFF(40, ldtr C_h, [src, #40]) + stp B_l, B_h, [dst, #16] + stp C_l, C_h, [dst, #32] +USER_OFF(48, ldtr D_l, [src, #48]) +USER_OFF(56, ldtr D_h, [src, #56]) + add src, src, #64 + stp D_l, D_h, [dst, #48] + add dst, dst, #64 + + tst count, #0x3f + b.ne .Ltail63 + b .Lexitfunc + + /* + * Critical loop. Start at a new cache line boundary. Assuming + * 64 bytes per line this ensures the entire loop is in one line. + */ +.Lcpy_body_large: + /* pre-get 64 bytes data. */ +USER_OFF(16, ldtr B_l, [src, #16]) +USER_OFF(24, ldtr B_h, [src, #24]) +USER_OFF(32, ldtr C_l, [src, #32]) +USER_OFF(40, ldtr C_h, [src, #40]) +USER_OFF(48, ldtr D_l, [src, #48]) +USER_OFF(56, ldtr D_h, [src, #56]) + add src, src, #64 + +1: + /* + * interlace the load of next 64 bytes data block with store of the last + * loaded 64 bytes data. + */ + stp A_l, A_h, [dst, #0] +USER_OFF(0, ldtr A_l, [src, #0]) +USER_OFF(8, ldtr A_h, [src, #8]) + stp B_l, B_h, [dst, #16] +USER_OFF(16, ldtr B_l, [src, #16]) +USER_OFF(24, ldtr B_h, [src, #24]) + stp C_l, C_h, [dst, #32] +USER_OFF(32, ldtr C_l, [src, #32]) +USER_OFF(40, ldtr C_h, [src, #40]) + stp D_l, D_h, [dst, #48] +USER_OFF(48, ldtr D_l, [src, #48]) + add dst, dst, #64 +USER_OFF(56, ldtr D_h, [src, #56]) + add src, src, #64 + subs count, count, #64 + b.ge 1b + stp A_l, A_h, [dst, #0] + stp B_l, B_h, [dst, #16] + stp C_l, C_h, [dst, #32] + stp D_l, D_h, [dst, #48] + add dst, dst, #64 + + tst count, #0x3f + b.ne .Ltail63 +.Lexitfunc: mov x0, #0 // Nothing to copy ret - // Exception fixups -9997: cmp dst, dstin - b.ne 9998f - // Before being absolutely sure we couldn't copy anything, try harder -USER(9998f, ldtrb tmp1w, [srcin]) - strb tmp1w, [dst], #1 -9998: sub x0, end, dst // bytes not copied - ret SYM_FUNC_END(__arch_copy_from_user) EXPORT_SYMBOL(__arch_copy_from_user) diff --git a/arch/arm64/lib/copy_to_user.S b/arch/arm64/lib/copy_to_user.S index 2ac716c0d6d8c..7b69dece56f6d 100644 --- a/arch/arm64/lib/copy_to_user.S +++ b/arch/arm64/lib/copy_to_user.S @@ -19,55 +19,219 @@ * Returns: * x0 - bytes not copied */ - .macro ldrb1 reg, ptr, val - KERNEL_ME_SAFE(9998f, ldrb \reg, [\ptr], \val) - .endm - .macro strb1 reg, ptr, val - user_ldst 9998f, sttrb, \reg, \ptr, \val - .endm - - .macro ldrh1 reg, ptr, val - KERNEL_ME_SAFE(9998f, ldrh \reg, [\ptr], \val) - .endm - - .macro strh1 reg, ptr, val - user_ldst 9997f, sttrh, \reg, \ptr, \val - .endm - - .macro ldr1 reg, ptr, val - KERNEL_ME_SAFE(9998f, ldr \reg, [\ptr], \val) - .endm +dstin .req x0 +src .req x1 +end .req x5 +srcin .req x15 +count .req x2 +tmp1 .req x3 +tmp1w .req w3 +tmp2 .req x4 +tmp2w .req w4 +dst .req x6 - .macro str1 reg, ptr, val - user_ldst 9997f, sttr, \reg, \ptr, \val - .endm +A_l .req x7 +A_h .req x8 +B_l .req x9 +B_h .req x10 +C_l .req x11 +C_h .req x12 +D_l .req x13 +D_h .req x14 - .macro ldp1 reg1, reg2, ptr, val - KERNEL_ME_SAFE(9998f, ldp \reg1, \reg2, [\ptr], \val) - .endm +#define USER_OFF(off, x...) USER(fixup_offset_##off, x) +#define FIXUP_OFFSET(n) \ +fixup_offset_##n: \ + sub x0, end, dst; \ + sub x0, x0, n; \ + ret - .macro stp1 reg1, reg2, ptr, val - user_stp 9997f, \reg1, \reg2, \ptr, \val - .endm +FIXUP_OFFSET(0) +FIXUP_OFFSET(8) +FIXUP_OFFSET(16) +FIXUP_OFFSET(24) +FIXUP_OFFSET(32) +FIXUP_OFFSET(40) +FIXUP_OFFSET(48) +FIXUP_OFFSET(56) -end .req x5 -srcin .req x15 SYM_FUNC_START(__arch_copy_to_user) add end, x0, x2 mov srcin, x1 -#include "copy_template.S" + mov dst, dstin + cmp count, #16 + /*When memory length is less than 16, the accessed are not aligned.*/ + b.lo .Ltiny15 + + neg tmp2, src + ands tmp2, tmp2, #15/* Bytes to reach alignment. */ + b.eq .LSrcAligned + sub count, count, tmp2 + /* + * Copy the leading memory data from src to dst in an increasing + * address order.By this way,the risk of overwriting the source + * memory data is eliminated when the distance between src and + * dst is less than 16. The memory accesses here are alignment. + */ + tbz tmp2, #0, 1f + ldrb tmp1w, [src], #1 +USER_OFF(0, sttrb tmp1w, [dst, #0]) + add dst, dst, #1 +1: + tbz tmp2, #1, 2f + ldrh tmp1w, [src], #2 +USER_OFF(0, sttrh tmp1w, [dst, #0]) + add dst, dst, #2 +2: + tbz tmp2, #2, 3f + ldr tmp1w, [src], #4 +USER_OFF(0, sttr tmp1w, [dst, #0]) + add dst, dst, #4 +3: + tbz tmp2, #3, .LSrcAligned + ldr tmp1, [src], #8 +USER_OFF(0, sttr tmp1, [dst, #0]) + add dst, dst, #8 + +.LSrcAligned: + cmp count, #64 + b.ge .Lcpy_over64 + /* + * Deal with small copies quickly by dropping straight into the + * exit block. + */ +.Ltail63: + /* + * Copy up to 48 bytes of data. At this point we only need the + * bottom 6 bits of count to be accurate. + */ + ands tmp1, count, #0x30 + b.eq .Ltiny15 + ldp A_l, A_h, [src], #16 + cmp tmp1w, #0x20 + b.eq 1f + b.lt 2f +USER_OFF(0, sttr A_l, [dst, #0]) +USER_OFF(8, sttr A_h, [dst, #8]) + ldp A_l, A_h, [src], #16 + add dst, dst, #16 +1: +USER_OFF(0, sttr A_l, [dst, #0]) +USER_OFF(8, sttr A_h, [dst, #8]) + ldp A_l, A_h, [src], #16 + add dst, dst, #16 +2: +USER_OFF(0, sttr A_l, [dst, #0]) +USER_OFF(8, sttr A_h, [dst, #8]) + add dst, dst, #16 +.Ltiny15: + /* + * Prefer to break one ldp/stp into several load/store to access + * memory in an increasing address order,rather than to load/store 16 + * bytes from (src-16) to (dst-16) and to backward the src to aligned + * address,which way is used in original cortex memcpy. If keeping + * the original memcpy process here, memmove need to satisfy the + * precondition that src address is at least 16 bytes bigger than dst + * address,otherwise some source data will be overwritten when memove + * call memcpy directly. To make memmove simpler and decouple the + * memcpy's dependency on memmove, withdrew the original process. + */ + tbz count, #3, 1f + ldr tmp1, [src], #8 +USER_OFF(0, sttr tmp1, [dst, #0]) + add dst, dst, #8 +1: + tbz count, #2, 2f + ldr tmp1w, [src], #4 +USER_OFF(0, sttr tmp1w, [dst, #0]) + add dst, dst, #4 +2: + tbz count, #1, 3f + ldrh tmp1w, [src], #2 +USER_OFF(0, sttrh tmp1w, [dst, #0]) + add dst, dst, #2 +3: + tbz count, #0, .Lexitfunc + ldrb tmp1w, [src], #1 +USER_OFF(0, sttrb tmp1w, [dst, #0]) + add dst, dst, #1 + + b .Lexitfunc + +.Lcpy_over64: + .p2align L1_CACHE_SHIFT + ldp A_l, A_h, [src, #0] + subs count, count, #128 + b.ge .Lcpy_body_large + /* + * Less than 128 bytes to copy, so handle 64 here and then jump + * to the tail. + */ +USER_OFF(0, sttr A_l, [dst, #0]) +USER_OFF(8, sttr A_h, [dst, #8]) + ldp B_l, B_h, [src, #16] + ldp C_l, C_h, [src, #32] +USER_OFF(16, sttr B_l, [dst, #16]) +USER_OFF(24, sttr B_h, [dst, #24]) +USER_OFF(32, sttr C_l, [dst, #32]) +USER_OFF(40, sttr C_h, [dst, #40]) + ldp D_l, D_h, [src, #48] + add src, src, #64 +USER_OFF(48, sttr D_l, [dst, #48]) +USER_OFF(56, sttr D_h, [dst, #56]) + add dst, dst, #64 + + tst count, #0x3f + b.ne .Ltail63 + b .Lexitfunc + + /* + * Critical loop. Start at a new cache line boundary. Assuming + * 64 bytes per line this ensures the entire loop is in one line. + */ +.Lcpy_body_large: + /* pre-get 64 bytes data. */ + ldp B_l, B_h, [src, #16] + ldp C_l, C_h, [src, #32] + ldp D_l, D_h, [src, #48] + add src, src, #64 +1: + /* + * interlace the load of next 64 bytes data block with store of the last + * loaded 64 bytes data. + */ +USER_OFF(0, sttr A_l, [dst, #0]) +USER_OFF(8, sttr A_h, [dst, #8]) + ldp A_l, A_h, [src, #0] +USER_OFF(16, sttr B_l, [dst, #16]) +USER_OFF(24, sttr B_h, [dst, #24]) + ldp B_l, B_h, [src, #16] +USER_OFF(32, sttr C_l, [dst, #32]) +USER_OFF(40, sttr C_h, [dst, #40]) + ldp C_l, C_h, [src, #32] +USER_OFF(48, sttr D_l, [dst, #48]) +USER_OFF(56, sttr D_h, [dst, #56]) + add dst, dst, #64 + ldp D_l, D_h, [src, #48] + add src, src, #64 + subs count, count, #64 + b.ge 1b +USER_OFF(0, sttr A_l, [dst, #0]) +USER_OFF(8, sttr A_h, [dst, #8]) +USER_OFF(16, sttr B_l, [dst, #16]) +USER_OFF(24, sttr B_h, [dst, #24]) +USER_OFF(32, sttr C_l, [dst, #32]) +USER_OFF(40, sttr C_h, [dst, #40]) +USER_OFF(48, sttr D_l, [dst, #48]) +USER_OFF(56, sttr D_h, [dst, #56]) + add dst, dst, #64 + + tst count, #0x3f + b.ne .Ltail63 +.Lexitfunc: mov x0, #0 ret - // Exception fixups -9997: cmp dst, dstin - b.ne 9998f - // Before being absolutely sure we couldn't copy anything, try harder -KERNEL_ME_SAFE(9998f, ldrb tmp1w, [srcin]) -USER(9998f, sttrb tmp1w, [dst]) - add dst, dst, #1 -9998: sub x0, end, dst // bytes not copied - ret SYM_FUNC_END(__arch_copy_to_user) EXPORT_SYMBOL(__arch_copy_to_user) -- 2.34.1

2 1

[PATCH OLK-6.6 0/9] ext4/mm: ext4 enable large folio by default and add thp align
by Zhang Yi 16 May '24

16 May '24

PATCH 1-2: improve ext4 unixbench pref. PATCH 3: ext4 enable large folio on 4k PAGE_SIZE by defalut. PATCH 4-9: add thp align. Kefeng Wang (5): mm: filemap: make mTHP configurable for exec mapping mm: thp: document thp_exec_enabled sysfs interface mm: huge_memory: add folio_get_unmapped_area() mm: huge_memory: add thp mapping align control mm: thp: document thp_mapping_align sysfs interface Ryan Roberts (1): mm/filemap: Allow arch to request folio size for exec memory Yang Erkun (2): iomap: export __iomap_write_{begin|end} ext4: fallback to generic_perform_write once iov_iter_count <= PAGE_SIZE Zhang Yi (1): ext4: default enable iomap for buffered IO and large folio Documentation/admin-guide/mm/transhuge.rst | 17 ++- arch/arm64/include/asm/pgtable.h | 12 ++ fs/ext4/file.c | 3 +- fs/ext4/inode.c | 124 ++++++++++++++++ fs/ext4/super.c | 21 ++- fs/iomap/buffered-io.c | 6 +- include/linux/huge_mm.h | 3 + include/linux/iomap.h | 4 + include/linux/pgtable.h | 12 ++ include/trace/events/ext4.h | 15 ++ mm/filemap.c | 42 ++++++ mm/huge_memory.c | 164 +++++++++++++++++++-- 12 files changed, 392 insertions(+), 31 deletions(-) -- 2.39.2

2 10

[PATCH OLK-6.6 1/9] iomap: export __iomap_write_{begin|end}
by Zhang Yi 16 May '24

16 May '24

From: Yang Erkun <yangerkun(a)huawei.com> hulk inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I9DN5Z CVE: NA -------------------------------- This two functions will use with latter patch, export it. Signed-off-by: Yang Erkun <yangerkun(a)huawei.com> --- fs/iomap/buffered-io.c | 6 ++++-- include/linux/iomap.h | 4 ++++ 2 files changed, 8 insertions(+), 2 deletions(-) diff --git a/fs/iomap/buffered-io.c b/fs/iomap/buffered-io.c index fee0bb9b5d75..dbd56c36ce2b 100644 --- a/fs/iomap/buffered-io.c +++ b/fs/iomap/buffered-io.c @@ -665,7 +665,7 @@ static int iomap_read_folio_sync(loff_t block_start, struct folio *folio, return submit_bio_wait(&bio); } -static int __iomap_write_begin(const struct iomap_iter *iter, loff_t pos, +int __iomap_write_begin(const struct iomap_iter *iter, loff_t pos, size_t len, struct folio *folio) { const struct iomap *srcmap = iomap_iter_srcmap(iter); @@ -727,6 +727,7 @@ static int __iomap_write_begin(const struct iomap_iter *iter, loff_t pos, return 0; } +EXPORT_SYMBOL_GPL(__iomap_write_begin); static struct folio *__iomap_get_folio(struct iomap_iter *iter, loff_t pos, size_t len) @@ -825,7 +826,7 @@ static int iomap_write_begin(struct iomap_iter *iter, loff_t pos, return status; } -static bool __iomap_write_end(struct inode *inode, loff_t pos, size_t len, +bool __iomap_write_end(struct inode *inode, loff_t pos, size_t len, size_t copied, struct folio *folio) { flush_dcache_folio(folio); @@ -848,6 +849,7 @@ static bool __iomap_write_end(struct inode *inode, loff_t pos, size_t len, filemap_dirty_folio(inode->i_mapping, folio); return true; } +EXPORT_SYMBOL_GPL(__iomap_write_end); static void iomap_write_end_inline(const struct iomap_iter *iter, struct folio *folio, loff_t pos, size_t copied) diff --git a/include/linux/iomap.h b/include/linux/iomap.h index 6fc1c858013d..daf0a86ba377 100644 --- a/include/linux/iomap.h +++ b/include/linux/iomap.h @@ -258,6 +258,10 @@ static inline const struct iomap *iomap_iter_srcmap(const struct iomap_iter *i) ssize_t iomap_file_buffered_write(struct kiocb *iocb, struct iov_iter *from, const struct iomap_ops *ops); +int __iomap_write_begin(const struct iomap_iter *iter, loff_t pos, + size_t len, struct folio *folio); +bool __iomap_write_end(struct inode *inode, loff_t pos, size_t len, + size_t copied, struct folio *folio); int iomap_file_buffered_write_punch_delalloc(struct inode *inode, struct iomap *iomap, loff_t pos, loff_t length, ssize_t written, int (*punch)(struct inode *inode, loff_t pos, loff_t length)); -- 2.39.2

2 10

[PATCH OLK-5.10] x86/cpufeatures: Fix dependencies for GFNI, VAES, and VPCLMULQDQ
by Yang Yingliang 16 May '24

16 May '24

From: Eric Biggers <ebiggers(a)google.com> mainline inclusion from mainline-v6.9-rc5 commit 9543f6e26634537997b6e909c20911b7bf4876de category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I9NZ3E Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- Fix cpuid_deps[] to list the correct dependencies for GFNI, VAES, and VPCLMULQDQ. These features don't depend on AVX512, and there exist CPUs that support these features but not AVX512. GFNI actually doesn't even depend on AVX. This prevents GFNI from being unnecessarily disabled if AVX is disabled to mitigate the GDS vulnerability. This also prevents all three features from being unnecessarily disabled if AVX512VL (or its dependency AVX512F) were to be disabled, but it looks like there isn't any case where this happens anyway. Fixes: c128dbfa0f87 ("x86/cpufeatures: Enable new SSE/AVX/AVX512 CPU features") Signed-off-by: Eric Biggers <ebiggers(a)google.com> Signed-off-by: Borislav Petkov (AMD) <bp(a)alien8.de> Acked-by: Dave Hansen <dave.hansen(a)linux.intel.com> Link: https://lore.kernel.org/r/20240417060434.47101-1-ebiggers@kernel.org Signed-off-by: Yang Yingliang <yangyingliang(a)huawei.com> --- arch/x86/kernel/cpu/cpuid-deps.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/arch/x86/kernel/cpu/cpuid-deps.c b/arch/x86/kernel/cpu/cpuid-deps.c index 0e99ec22d9c1..0ff8fd49550c 100644 --- a/arch/x86/kernel/cpu/cpuid-deps.c +++ b/arch/x86/kernel/cpu/cpuid-deps.c @@ -44,7 +44,10 @@ static const struct cpuid_dep cpuid_deps[] = { { X86_FEATURE_F16C, X86_FEATURE_XMM2, }, { X86_FEATURE_AES, X86_FEATURE_XMM2 }, { X86_FEATURE_SHA_NI, X86_FEATURE_XMM2 }, + { X86_FEATURE_GFNI, X86_FEATURE_XMM2 }, { X86_FEATURE_FMA, X86_FEATURE_AVX }, + { X86_FEATURE_VAES, X86_FEATURE_AVX }, + { X86_FEATURE_VPCLMULQDQ, X86_FEATURE_AVX }, { X86_FEATURE_AVX2, X86_FEATURE_AVX, }, { X86_FEATURE_AVX512F, X86_FEATURE_AVX, }, { X86_FEATURE_AVX512IFMA, X86_FEATURE_AVX512F }, @@ -56,9 +59,6 @@ static const struct cpuid_dep cpuid_deps[] = { { X86_FEATURE_AVX512VL, X86_FEATURE_AVX512F }, { X86_FEATURE_AVX512VBMI, X86_FEATURE_AVX512F }, { X86_FEATURE_AVX512_VBMI2, X86_FEATURE_AVX512VL }, - { X86_FEATURE_GFNI, X86_FEATURE_AVX512VL }, - { X86_FEATURE_VAES, X86_FEATURE_AVX512VL }, - { X86_FEATURE_VPCLMULQDQ, X86_FEATURE_AVX512VL }, { X86_FEATURE_AVX512_VNNI, X86_FEATURE_AVX512VL }, { X86_FEATURE_AVX512_BITALG, X86_FEATURE_AVX512VL }, { X86_FEATURE_AVX512_4VNNIW, X86_FEATURE_AVX512F }, -- 2.25.1

2 1

[PATCH openEuler-1.0-LTS] x86/cpufeatures: Fix dependencies for GFNI, VAES, and VPCLMULQDQ
by Yang Yingliang 16 May '24

16 May '24

From: Eric Biggers <ebiggers(a)google.com> mainline inclusion from mainline-v6.9-rc5 commit 9543f6e26634537997b6e909c20911b7bf4876de category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I9NZ3E Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- Fix cpuid_deps[] to list the correct dependencies for GFNI, VAES, and VPCLMULQDQ. These features don't depend on AVX512, and there exist CPUs that support these features but not AVX512. GFNI actually doesn't even depend on AVX. This prevents GFNI from being unnecessarily disabled if AVX is disabled to mitigate the GDS vulnerability. This also prevents all three features from being unnecessarily disabled if AVX512VL (or its dependency AVX512F) were to be disabled, but it looks like there isn't any case where this happens anyway. Fixes: c128dbfa0f87 ("x86/cpufeatures: Enable new SSE/AVX/AVX512 CPU features") Signed-off-by: Eric Biggers <ebiggers(a)google.com> Signed-off-by: Borislav Petkov (AMD) <bp(a)alien8.de> Acked-by: Dave Hansen <dave.hansen(a)linux.intel.com> Link: https://lore.kernel.org/r/20240417060434.47101-1-ebiggers@kernel.org Conflicts: arch/x86/kernel/cpu/cpuid-deps.c [yyl: adjust context] Signed-off-by: Yang Yingliang <yangyingliang(a)huawei.com> --- arch/x86/kernel/cpu/cpuid-deps.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/arch/x86/kernel/cpu/cpuid-deps.c b/arch/x86/kernel/cpu/cpuid-deps.c index a444028d8145..a86dfa5badcd 100644 --- a/arch/x86/kernel/cpu/cpuid-deps.c +++ b/arch/x86/kernel/cpu/cpuid-deps.c @@ -39,7 +39,10 @@ static const struct cpuid_dep cpuid_deps[] = { { X86_FEATURE_F16C, X86_FEATURE_XMM2, }, { X86_FEATURE_AES, X86_FEATURE_XMM2 }, { X86_FEATURE_SHA_NI, X86_FEATURE_XMM2 }, + { X86_FEATURE_GFNI, X86_FEATURE_XMM2 }, { X86_FEATURE_FMA, X86_FEATURE_AVX }, + { X86_FEATURE_VAES, X86_FEATURE_AVX }, + { X86_FEATURE_VPCLMULQDQ, X86_FEATURE_AVX }, { X86_FEATURE_AVX2, X86_FEATURE_AVX, }, { X86_FEATURE_AVX512F, X86_FEATURE_AVX, }, { X86_FEATURE_AVX512IFMA, X86_FEATURE_AVX512F }, @@ -51,9 +54,6 @@ static const struct cpuid_dep cpuid_deps[] = { { X86_FEATURE_AVX512VL, X86_FEATURE_AVX512F }, { X86_FEATURE_AVX512VBMI, X86_FEATURE_AVX512F }, { X86_FEATURE_AVX512_VBMI2, X86_FEATURE_AVX512VL }, - { X86_FEATURE_GFNI, X86_FEATURE_AVX512VL }, - { X86_FEATURE_VAES, X86_FEATURE_AVX512VL }, - { X86_FEATURE_VPCLMULQDQ, X86_FEATURE_AVX512VL }, { X86_FEATURE_AVX512_VNNI, X86_FEATURE_AVX512VL }, { X86_FEATURE_AVX512_BITALG, X86_FEATURE_AVX512VL }, { X86_FEATURE_AVX512_4VNNIW, X86_FEATURE_AVX512F }, -- 2.25.1

2 1

[PATCH OLK-5.10] x86/cpufeatures: Fix dependencies for GFNI, VAES, and VPCLMULQDQ
by Yang Yingliang 16 May '24

16 May '24

From: Eric Biggers <ebiggers(a)google.com> Fix cpuid_deps[] to list the correct dependencies for GFNI, VAES, and VPCLMULQDQ. These features don't depend on AVX512, and there exist CPUs that support these features but not AVX512. GFNI actually doesn't even depend on AVX. This prevents GFNI from being unnecessarily disabled if AVX is disabled to mitigate the GDS vulnerability. This also prevents all three features from being unnecessarily disabled if AVX512VL (or its dependency AVX512F) were to be disabled, but it looks like there isn't any case where this happens anyway. Fixes: c128dbfa0f87 ("x86/cpufeatures: Enable new SSE/AVX/AVX512 CPU features") Signed-off-by: Eric Biggers <ebiggers(a)google.com> Signed-off-by: Borislav Petkov (AMD) <bp(a)alien8.de> Acked-by: Dave Hansen <dave.hansen(a)linux.intel.com> Link: https://lore.kernel.org/r/20240417060434.47101-1-ebiggers@kernel.org --- arch/x86/kernel/cpu/cpuid-deps.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/arch/x86/kernel/cpu/cpuid-deps.c b/arch/x86/kernel/cpu/cpuid-deps.c index 0e99ec22d9c1..0ff8fd49550c 100644 --- a/arch/x86/kernel/cpu/cpuid-deps.c +++ b/arch/x86/kernel/cpu/cpuid-deps.c @@ -44,7 +44,10 @@ static const struct cpuid_dep cpuid_deps[] = { { X86_FEATURE_F16C, X86_FEATURE_XMM2, }, { X86_FEATURE_AES, X86_FEATURE_XMM2 }, { X86_FEATURE_SHA_NI, X86_FEATURE_XMM2 }, + { X86_FEATURE_GFNI, X86_FEATURE_XMM2 }, { X86_FEATURE_FMA, X86_FEATURE_AVX }, + { X86_FEATURE_VAES, X86_FEATURE_AVX }, + { X86_FEATURE_VPCLMULQDQ, X86_FEATURE_AVX }, { X86_FEATURE_AVX2, X86_FEATURE_AVX, }, { X86_FEATURE_AVX512F, X86_FEATURE_AVX, }, { X86_FEATURE_AVX512IFMA, X86_FEATURE_AVX512F }, @@ -56,9 +59,6 @@ static const struct cpuid_dep cpuid_deps[] = { { X86_FEATURE_AVX512VL, X86_FEATURE_AVX512F }, { X86_FEATURE_AVX512VBMI, X86_FEATURE_AVX512F }, { X86_FEATURE_AVX512_VBMI2, X86_FEATURE_AVX512VL }, - { X86_FEATURE_GFNI, X86_FEATURE_AVX512VL }, - { X86_FEATURE_VAES, X86_FEATURE_AVX512VL }, - { X86_FEATURE_VPCLMULQDQ, X86_FEATURE_AVX512VL }, { X86_FEATURE_AVX512_VNNI, X86_FEATURE_AVX512VL }, { X86_FEATURE_AVX512_BITALG, X86_FEATURE_AVX512VL }, { X86_FEATURE_AVX512_4VNNIW, X86_FEATURE_AVX512F }, -- 2.25.1

2 1

[PATCH openEuler-1.0-LTS] x86/cpufeatures: Fix dependencies for GFNI, VAES, and VPCLMULQDQ
by Yang Yingliang 16 May '24

16 May '24

From: Eric Biggers <ebiggers(a)google.com> Fix cpuid_deps[] to list the correct dependencies for GFNI, VAES, and VPCLMULQDQ. These features don't depend on AVX512, and there exist CPUs that support these features but not AVX512. GFNI actually doesn't even depend on AVX. This prevents GFNI from being unnecessarily disabled if AVX is disabled to mitigate the GDS vulnerability. This also prevents all three features from being unnecessarily disabled if AVX512VL (or its dependency AVX512F) were to be disabled, but it looks like there isn't any case where this happens anyway. Fixes: c128dbfa0f87 ("x86/cpufeatures: Enable new SSE/AVX/AVX512 CPU features") Signed-off-by: Eric Biggers <ebiggers(a)google.com> Signed-off-by: Borislav Petkov (AMD) <bp(a)alien8.de> Acked-by: Dave Hansen <dave.hansen(a)linux.intel.com> Link: https://lore.kernel.org/r/20240417060434.47101-1-ebiggers@kernel.org Conflicts: arch/x86/kernel/cpu/cpuid-deps.c [yyl: adjust context] Signed-off-by: Yang Yingliang <yangyingliang(a)huawei.com> --- arch/x86/kernel/cpu/cpuid-deps.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/arch/x86/kernel/cpu/cpuid-deps.c b/arch/x86/kernel/cpu/cpuid-deps.c index a444028d8145..a86dfa5badcd 100644 --- a/arch/x86/kernel/cpu/cpuid-deps.c +++ b/arch/x86/kernel/cpu/cpuid-deps.c @@ -39,7 +39,10 @@ static const struct cpuid_dep cpuid_deps[] = { { X86_FEATURE_F16C, X86_FEATURE_XMM2, }, { X86_FEATURE_AES, X86_FEATURE_XMM2 }, { X86_FEATURE_SHA_NI, X86_FEATURE_XMM2 }, + { X86_FEATURE_GFNI, X86_FEATURE_XMM2 }, { X86_FEATURE_FMA, X86_FEATURE_AVX }, + { X86_FEATURE_VAES, X86_FEATURE_AVX }, + { X86_FEATURE_VPCLMULQDQ, X86_FEATURE_AVX }, { X86_FEATURE_AVX2, X86_FEATURE_AVX, }, { X86_FEATURE_AVX512F, X86_FEATURE_AVX, }, { X86_FEATURE_AVX512IFMA, X86_FEATURE_AVX512F }, @@ -51,9 +54,6 @@ static const struct cpuid_dep cpuid_deps[] = { { X86_FEATURE_AVX512VL, X86_FEATURE_AVX512F }, { X86_FEATURE_AVX512VBMI, X86_FEATURE_AVX512F }, { X86_FEATURE_AVX512_VBMI2, X86_FEATURE_AVX512VL }, - { X86_FEATURE_GFNI, X86_FEATURE_AVX512VL }, - { X86_FEATURE_VAES, X86_FEATURE_AVX512VL }, - { X86_FEATURE_VPCLMULQDQ, X86_FEATURE_AVX512VL }, { X86_FEATURE_AVX512_VNNI, X86_FEATURE_AVX512VL }, { X86_FEATURE_AVX512_BITALG, X86_FEATURE_AVX512VL }, { X86_FEATURE_AVX512_4VNNIW, X86_FEATURE_AVX512F }, -- 2.25.1

2 1