[PATCH v3] crypto: powerpc/p10-aes-gcm - simplify handling of linear associated data

From: Eric Biggers p10_aes_gcm_crypt() is abusing the scatter_walk API to get the virtual address for the first source scatterlist element. But this code is only built for PPC64 which is a !HIGHMEM platform, and it can read past a page boundary from the address returned by scatterwalk_map

Re: [PATCH v2 10/29] crypto: powerpc/p10-aes-gcm - simplify handling of linear associated data

On Thu, Jan 02, 2025 at 12:50:50PM +0100, Christophe Leroy wrote: > > > Le 30/12/2024 à 01:13, Eric Biggers a écrit : > > From: Eric Biggers > > > > p10_aes_gcm_crypt() is abusing the scatter_walk API to get the virtual > > address for the first source scatt

[PATCH v2 20/29] crypto: nx - use the new scatterwalk functions

From: Eric Biggers - In nx_walk_and_build(), use scatterwalk_start_at_pos() instead of a more complex way to achieve the same result. - Also in nx_walk_and_build(), use the new functions scatterwalk_next() which consolidates scatterwalk_clamp() and scatterwalk_map(), and use

[PATCH v2 10/29] crypto: powerpc/p10-aes-gcm - simplify handling of linear associated data

From: Eric Biggers p10_aes_gcm_crypt() is abusing the scatter_walk API to get the virtual address for the first source scatterlist element. But this code is only built for PPC64 which is a !HIGHMEM platform, and it can read past a page boundary from the address returned by scatterwalk_map

[PATCH 20/29] crypto: nx - use the new scatterwalk functions

From: Eric Biggers - In nx_walk_and_build(), use scatterwalk_start_at_pos() instead of a more complex way to achieve the same result. - Also in nx_walk_and_build(), use the new functions scatterwalk_next() which consolidates scatterwalk_clamp() and scatterwalk_map(), and use

[PATCH 10/29] crypto: powerpc/p10-aes-gcm - simplify handling of linear associated data

From: Eric Biggers p10_aes_gcm_crypt() is abusing the scatter_walk API to get the virtual address for the first source scatterlist element. But this code is only built for PPC64 which is a !HIGHMEM platform, and it can read past a page boundary from the address returned by scatterwalk_map

Re: [PATCH v4 00/19] Wire up CRC32 library functions to arch-optimized code

On Sun, Dec 01, 2024 at 05:08:25PM -0800, Eric Biggers wrote: > This patchset applies to v6.13-rc1 and is also available in git via: > > git fetch > https://git.kernel.org/pub/scm/linux/kernel/git/ebiggers/linux.git > crc32-lib-v4 > > CRC32 is a family of common non-cr

Re: [PATCH v2 00/12] Wire up CRC-T10DIF library functions to arch-optimized code

On Sun, Dec 01, 2024 at 05:20:44PM -0800, Eric Biggers wrote: > This patchset is also available in git via: > > git fetch > https://git.kernel.org/pub/scm/linux/kernel/git/ebiggers/linux.git > crc-t10dif-lib-v2 > > This patchset updates the kernel's CRC-T10D

[PATCH v4 03/19] lib/crc32: expose whether the lib is really optimized at runtime

From: Eric Biggers Make the CRC32 library export a function crc32_optimizations() which returns flags that indicate which CRC32 functions are actually executing optimized code at runtime. This will be used to determine whether the crc32[c]-$arch shash algorithms should be registered in the

[PATCH v4 01/19] lib/crc32: drop leading underscores from __crc32c_le_base

From: Eric Biggers Remove the leading underscores from __crc32c_le_base(). This is in preparation for adding crc32c_le_arch() and eventually renaming __crc32c_le() to crc32c_le(). Reviewed-by: Ard Biesheuvel Signed-off-by: Eric Biggers --- arch/arm64/lib/crc32-glue.c | 2 +- arch/riscv/lib

[PATCH v4 17/19] jbd2: switch to using the crc32c library

From: Eric Biggers Now that the crc32c() library function directly takes advantage of architecture-specific optimizations, it is unnecessary to go through the crypto API. Just use crc32c(). This is much simpler, and it improves performance due to eliminating the crypto API overhead. Reviewed

[PATCH v4 10/19] sparc/crc32: expose CRC32 functions through lib

From: Eric Biggers Move the sparc CRC32C assembly code into the lib directory and wire it up to the library interface. This allows it to be used without going through the crypto API. It remains usable via the crypto API too via the shash algorithms that use the library interface. Thus all the

[PATCH v4 02/19] lib/crc32: improve support for arch-specific overrides

From: Eric Biggers Currently the CRC32 library functions are defined as weak symbols, and the arm64 and riscv architectures override them. This method of arch-specific overrides has the limitation that it only works when both the base and arch code is built-in. Also, it makes the arch-specific

[PATCH v4 00/19] Wire up CRC32 library functions to arch-optimized code

hanged in v2: - Added a way to determine if the arch-optimized code is actually being used at runtime, and used this to register the appropriate shash algorithms with crypto API. - Added a patch that converts iSCSI to use the library. - Listed a bcachefs patch as a dependency. - Added

[PATCH v4 09/19] s390/crc32: expose CRC32 functions through lib

From: Eric Biggers Move the s390 CRC32 assembly code into the lib directory and wire it up to the library interface. This allows it to be used without going through the crypto API. It remains usable via the crypto API too via the shash algorithms that use the library interface. Thus all the

[PATCH v2 10/12] lib/crc32test: delete obsolete crc32test.c

From: Eric Biggers Delete crc32test.c, since it has been superseded by crc_kunit.c. Reviewed-by: Ard Biesheuvel Reviewed-by: Martin K. Petersen Cc: Vinicius Peixoto Signed-off-by: Eric Biggers --- arch/m68k/configs/amiga_defconfig| 1 - arch/m68k/configs/apollo_defconfig | 1

[PATCH v2 11/12] powerpc/crc: delete obsolete crc-vpmsum_test.c

From: Eric Biggers Delete crc-vpmsum_test.c, since its functionality is now covered by the new crc_kunit.c as well as the crypto subsystem's fuzz tests. Reviewed-by: Ard Biesheuvel Reviewed-by: Martin K. Petersen Cc: Vinicius Peixoto Signed-off-by: Eric Biggers --- arch/powerpc/co

[PATCH v2 12/12] MAINTAINERS: add entry for CRC library

From: Eric Biggers I am volunteering to maintain the kernel's CRC library code. Ard has volunteered to be a reviewer. Reviewed-by: Ard Biesheuvel Reviewed-by: Martin K. Petersen Signed-off-by: Eric Biggers --- MAINTAINERS | 11 +++ 1 file changed, 11 insertions(+) diff --

[PATCH v2 08/12] lib/crc_kunit.c: add KUnit test suite for CRC library functions

From: Eric Biggers Add a KUnit test suite for the crc16, crc_t10dif, crc32_le, crc32_be, crc32c, and crc64_be library functions. It avoids code duplication by sharing most logic among all CRC variants. The test suite includes: - Differential fuzz test of each CRC function against a simple

[PATCH v2 09/12] lib/crc16_kunit: delete obsolete crc16_kunit.c

From: Eric Biggers This new test showed up in v6.13-rc1. Delete it since it is being superseded by crc_kunit.c, which is more comprehensive (tests multiple CRC variants without duplicating code, includes a benchmark, etc.). Cc: Vinicius Peixoto Signed-off-by: Eric Biggers --- lib

[PATCH v2 07/12] powerpc/crc-t10dif: expose CRC-T10DIF function through lib

From: Eric Biggers Move the powerpc CRC-T10DIF assembly code into the lib directory and wire it up to the library interface. This allows it to be used without going through the crypto API. It remains usable via the crypto API too via the shash algorithms that use the library interface. Thus

[PATCH v2 06/12] arm64/crc-t10dif: expose CRC-T10DIF function through lib

From: Eric Biggers Move the arm64 CRC-T10DIF assembly code into the lib directory and wire it up to the library interface. This allows it to be used without going through the crypto API. It remains usable via the crypto API too via the shash algorithms that use the library interface. Thus all

[PATCH v2 05/12] arm/crc-t10dif: expose CRC-T10DIF function through lib

From: Eric Biggers Move the arm CRC-T10DIF assembly code into the lib directory and wire it up to the library interface. This allows it to be used without going through the crypto API. It remains usable via the crypto API too via the shash algorithms that use the library interface. Thus all

[PATCH v2 03/12] crypto: crct10dif - expose arch-optimized lib function

From: Eric Biggers Now that crc_t10dif_update() may be directly optimized for each architecture, make the shash driver for crct10dif register a crct10dif-$arch algorithm that uses it, instead of only crct10dif-generic which uses crc_t10dif_generic(). The result is that architecture-optimized

[PATCH v2 04/12] x86/crc-t10dif: expose CRC-T10DIF function through lib

From: Eric Biggers Move the x86 CRC-T10DIF assembly code into the lib directory and wire it up to the library interface. This allows it to be used without going through the crypto API. It remains usable via the crypto API too via the shash algorithms that use the library interface. Thus all

[PATCH v2 02/12] lib/crc-t10dif: add support for arch overrides

From: Eric Biggers Following what was done for CRC32, add support for architecture-specific override of the CRC-T10DIF library. This will allow the CRC-T10DIF library functions to access architecture-optimized code directly. Reviewed-by: Ard Biesheuvel Reviewed-by: Martin K. Petersen Signed

[PATCH v2 01/12] lib/crc-t10dif: stop wrapping the crypto API

From: Eric Biggers In preparation for making the CRC-T10DIF library directly optimized for each architecture, like what has been done for CRC32, get rid of the weird layering where crc_t10dif_update() calls into the crypto API. Instead, move crc_t10dif_generic() into the crc-t10dif library

[PATCH v2 00/12] Wire up CRC-T10DIF library functions to arch-optimized code

been added yet. - Clarified a commit message. - Added Reviewed-by and Acked-by's. Eric Biggers (12): lib/crc-t10dif: stop wrapping the crypto API lib/crc-t10dif: add support for arch overrides crypto: crct10dif - expose arch-optimized lib function x86/crc-t10dif: expose CRC-T10DIF function t

[PATCH v4 11/19] x86/crc32: update prototype for crc_pcl()

From: Eric Biggers - Change the len parameter from unsigned int to size_t, so that the library function which takes a size_t can safely use this code. - Rename to crc32c_x86_3way() which is much clearer. - Move the crc parameter to the front, as this is the usual convention. Reviewed-by

[PATCH v4 07/19] mips/crc32: expose CRC32 functions through lib

From: Eric Biggers Move the mips CRC32 assembly code into the lib directory and wire it up to the library interface. This allows it to be used without going through the crypto API. It remains usable via the crypto API too via the shash algorithms that use the library interface. Thus all the

[PATCH v4 13/19] x86/crc32: expose CRC32 functions through lib

From: Eric Biggers Move the x86 CRC32 assembly code into the lib directory and wire it up to the library interface. This allows it to be used without going through the crypto API. It remains usable via the crypto API too via the shash algorithms that use the library interface. Thus all the

[PATCH v4 19/19] scsi: target: iscsi: switch to using the crc32c library

From: Eric Biggers Now that the crc32c() library function directly takes advantage of architecture-specific optimizations, it is unnecessary to go through the crypto API. Just use crc32c(). This is much simpler, and it improves performance due to eliminating the crypto API overhead. Reviewed

[PATCH v4 18/19] f2fs: switch to using the crc32 library

From: Eric Biggers Now that the crc32() library function takes advantage of architecture-specific optimizations, it is unnecessary to go through the crypto API. Just use crc32(). This is much simpler, and it improves performance due to eliminating the crypto API overhead. Reviewed-by: Ard

[PATCH v4 16/19] ext4: switch to using the crc32c library

From: Eric Biggers Now that the crc32c() library function directly takes advantage of architecture-specific optimizations, it is unnecessary to go through the crypto API. Just use crc32c(). This is much simpler, and it improves performance due to eliminating the crypto API overhead. Reviewed

[PATCH v4 14/19] bcachefs: Explicitly select CRYPTO from BCACHEFS_FS

From: Eric Biggers Explicitly select CRYPTO from BCACHEFS_FS, so that this dependency of CRYPTO_SHA256, CRYPTO_CHACHA20, and CRYPTO_POLY1305 (which are also selected) is satisfied. Currently this dependency is satisfied indirectly via LIBCRC32C, but this is fragile and is planned to change

[PATCH v4 12/19] x86/crc32: update prototype for crc32_pclmul_le_16()

From: Eric Biggers - Change the len parameter from unsigned int to size_t, so that the library function which takes a size_t can safely use this code. - Move the crc parameter to the front, as this is the usual convention. Reviewed-by: Ard Biesheuvel Signed-off-by: Eric Biggers --- arch

[PATCH v4 15/19] lib/crc32: make crc32c() go directly to lib

From: Eric Biggers Now that the lower level __crc32c_le() library function is optimized for each architecture, make crc32c() just call that instead of taking an inefficient and error-prone detour through the shash API. Note: a future cleanup should make crc32c_le() be the actual library

[PATCH v4 06/19] loongarch/crc32: expose CRC32 functions through lib

From: Eric Biggers Move the loongarch CRC32 assembly code into the lib directory and wire it up to the library interface. This allows it to be used without going through the crypto API. It remains usable via the crypto API too via the shash algorithms that use the library interface. Thus all

[PATCH v4 08/19] powerpc/crc32: expose CRC32 functions through lib

From: Eric Biggers Move the powerpc CRC32C assembly code into the lib directory and wire it up to the library interface. This allows it to be used without going through the crypto API. It remains usable via the crypto API too via the shash algorithms that use the library interface. Thus all

[PATCH v4 04/19] crypto: crc32 - don't unnecessarily register arch algorithms

From: Eric Biggers Instead of registering the crc32-$arch and crc32c-$arch algorithms if the arch-specific code was built, only register them when that code was built *and* is not falling back to the base implementation at runtime. This avoids confusing users like btrfs which checks the shash

[PATCH v4 05/19] arm/crc32: expose CRC32 functions through lib

From: Eric Biggers Move the arm CRC32 assembly code into the lib directory and wire it up to the library interface. This allows it to be used without going through the crypto API. It remains usable via the crypto API too via the shash algorithms that use the library interface. Thus all the

Re: [PATCH 00/11] Wire up CRC-T10DIF library functions to arch-optimized code

On Tue, Nov 19, 2024 at 09:59:53AM +0100, Ard Biesheuvel wrote: > > Eric Biggers (11): > > lib/crc-t10dif: stop wrapping the crypto API > > lib/crc-t10dif: add support for arch overrides > > crypto: crct10dif - expose arch-optimized lib function > > x86

Re: [PATCH 00/11] Wire up CRC-T10DIF library functions to arch-optimized code

Hi Zhihang, On Tue, Nov 19, 2024 at 06:05:58PM +0800, Zhihang Shao wrote: > > I still want to submit an optimization patchabout CRC-T10DIFfor RISC-V. > > I don't know if it would be more appropriate for me to rewrite a patch after > your patch is officially applied. > > What do you think? Plea

[PATCH 02/11] lib/crc-t10dif: add support for arch overrides

From: Eric Biggers Following what was done for CRC32, add support for architecture-specific override of the CRC-T10DIF library. This will allow the CRC-T10DIF library functions to access architecture-optimized code directly. Signed-off-by: Eric Biggers --- include/linux/crc-t10dif.h | 12

[PATCH 06/11] arm64/crc-t10dif: expose CRC-T10DIF function through lib

From: Eric Biggers Move the arm64 CRC-T10DIF assembly code into the lib directory and wire it up to the library interface. This allows it to be used without going through the crypto API. It remains usable via the crypto API too via the shash algorithms that use the library interface. Thus all

[PATCH 01/11] lib/crc-t10dif: stop wrapping the crypto API

From: Eric Biggers In preparation for making the CRC-T10DIF library optimized for each architecture, like what has been done for CRC32, get rid of the weird layering where crc_t10dif_update() calls into the crypto API. Instead, move crc_t10dif_generic() into the crc-t10dif library module, and

[PATCH 08/11] lib/crc_kunit.c: add KUnit test suite for CRC library functions

From: Eric Biggers Add a KUnit test suite for the crc16, crc_t10dif, crc32_le, crc32_be, crc32c, and crc64_be library functions. It avoids code duplication by sharing most logic among all CRC variants. The test suite includes: - Differential fuzz test of each CRC function against a simple

[PATCH 05/11] arm/crc-t10dif: expose CRC-T10DIF function through lib

From: Eric Biggers Move the arm CRC-T10DIF assembly code into the lib directory and wire it up to the library interface. This allows it to be used without going through the crypto API. It remains usable via the crypto API too via the shash algorithms that use the library interface. Thus all

[PATCH 00/11] Wire up CRC-T10DIF library functions to arch-optimized code

letes some older ad-hoc tests that are obsoleted by it. This patchset has several dependencies including my CRC32 patchset and patches queued in several trees for 6.13. It can be retrieved from git using the command given above. This is targeting 6.14. Eric Biggers (11): lib/crc-t10dif: sto

[PATCH 07/11] powerpc/crc-t10dif: expose CRC-T10DIF function through lib

From: Eric Biggers Move the powerpc CRC-T10DIF assembly code into the lib directory and wire it up to the library interface. This allows it to be used without going through the crypto API. It remains usable via the crypto API too via the shash algorithms that use the library interface. Thus

[PATCH 09/11] lib/crc32test: delete obsolete crc32test.c

From: Eric Biggers Delete crc32test.c, since it has been superseded by crc_kunit.c. Signed-off-by: Eric Biggers --- arch/m68k/configs/amiga_defconfig| 1 - arch/m68k/configs/apollo_defconfig | 1 - arch/m68k/configs/atari_defconfig| 1 - arch/m68k/configs/bvme6000_defconfig

[PATCH 11/11] MAINTAINERS: add entry for CRC library

From: Eric Biggers I am volunteering to maintain the kernel's CRC library code. Signed-off-by: Eric Biggers --- MAINTAINERS | 11 +++ 1 file changed, 11 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index a27407950242..2bfbdcad0282 100644 --- a/MAINTAINERS +++ b/MAINTA

[PATCH 10/11] powerpc/crc: delete obsolete crc-vpmsum_test.c

From: Eric Biggers Delete crc-vpmsum_test.c, since its functionality is now covered by the new crc_kunit.c as well as the crypto subsystem's fuzz tests. Signed-off-by: Eric Biggers --- arch/powerpc/configs/ppc64_defconfig | 1 - arch/powerpc/crypto/Kconfig | 9 -- arch/po

[PATCH 04/11] x86/crc-t10dif: expose CRC-T10DIF function through lib

From: Eric Biggers Move the x86 CRC-T10DIF assembly code into the lib directory and wire it up to the library interface. This allows it to be used without going through the crypto API. It remains usable via the crypto API too via the shash algorithms that use the library interface. Thus all

[PATCH 03/11] crypto: crct10dif - expose arch-optimized lib function

From: Eric Biggers Now that crc_t10dif_update() may be directly optimized for each architecture, make the shash driver for crct10dif register a crct10dif-$arch algorithm that uses it, instead of only crct10dif-generic which uses crc_t10dif_generic(). The result is that architecture-optimized

Re: [PATCH v3 05/18] arm/crc32: expose CRC32 functions through lib

On Sun, Nov 03, 2024 at 02:31:41PM -0800, Eric Biggers wrote: > -static int __init crc32_pmull_mod_init(void) > -{ > - if (elf_hwcap2 & HWCAP2_PMULL) { > - crc32_pmull_algs[0].update = crc32_pmull_update; > - crc32_pmull_algs[1].update =

Re: [PATCH v3 16/18] jbd2: switch to using the crc32c library

On Mon, Nov 04, 2024 at 08:01:36AM -0800, Darrick J. Wong wrote: > Same comment as my last reply about removing trivial helpers, but > otherwise > Reviewed-by: Darrick J. Wong > > If you push this for 6.13 I'd be happy that the shash junk finally went > away. The onstack struct desc thing in the

Re: [PATCH v3 15/18] ext4: switch to using the crc32c library

On Mon, Nov 04, 2024 at 07:59:00AM -0800, Darrick J. Wong wrote: > Hmm. Looking at your git branch (which was quite helpful to link to!) I > think for XFS we don't need to change the crc32c() calls, and the only > porting work that needs to be done is mirroring this Kconfig change? > And that does

[PATCH v3 18/18] scsi: target: iscsi: switch to using the crc32c library

From: Eric Biggers Now that the crc32c() library function directly takes advantage of architecture-specific optimizations, it is unnecessary to go through the crypto API. Just use crc32c(). This is much simpler, and it improves performance due to eliminating the crypto API overhead. Reviewed

[PATCH v3 11/18] x86/crc32: update prototype for crc_pcl()

From: Eric Biggers - Change the len parameter from unsigned int to size_t, so that the library function which takes a size_t can safely use this code. - Rename to crc32c_x86_3way() which is much clearer. - Move the crc parameter to the front, as this is the usual convention. Reviewed-by

[PATCH v3 17/18] f2fs: switch to using the crc32 library

From: Eric Biggers Now that the crc32() library function takes advantage of architecture-specific optimizations, it is unnecessary to go through the crypto API. Just use crc32(). This is much simpler, and it improves performance due to eliminating the crypto API overhead. Reviewed-by: Ard

[PATCH v3 13/18] x86/crc32: expose CRC32 functions through lib

From: Eric Biggers Move the x86 CRC32 assembly code into the lib directory and wire it up to the library interface. This allows it to be used without going through the crypto API. It remains usable via the crypto API too via the shash algorithms that use the library interface. Thus all the

[PATCH v3 10/18] sparc/crc32: expose CRC32 functions through lib

From: Eric Biggers Move the sparc CRC32C assembly code into the lib directory and wire it up to the library interface. This allows it to be used without going through the crypto API. It remains usable via the crypto API too via the shash algorithms that use the library interface. Thus all the

[PATCH v3 16/18] jbd2: switch to using the crc32c library

From: Eric Biggers Now that the crc32c() library function directly takes advantage of architecture-specific optimizations, it is unnecessary to go through the crypto API. Just use crc32c(). This is much simpler, and it improves performance due to eliminating the crypto API overhead. Reviewed

[PATCH v3 12/18] x86/crc32: update prototype for crc32_pclmul_le_16()

From: Eric Biggers - Change the len parameter from unsigned int to size_t, so that the library function which takes a size_t can safely use this code. - Move the crc parameter to the front, as this is the usual convention. Reviewed-by: Ard Biesheuvel Signed-off-by: Eric Biggers --- arch

[PATCH v3 09/18] s390/crc32: expose CRC32 functions through lib

From: Eric Biggers Move the s390 CRC32 assembly code into the lib directory and wire it up to the library interface. This allows it to be used without going through the crypto API. It remains usable via the crypto API too via the shash algorithms that use the library interface. Thus all the

[PATCH v3 15/18] ext4: switch to using the crc32c library

From: Eric Biggers Now that the crc32c() library function directly takes advantage of architecture-specific optimizations, it is unnecessary to go through the crypto API. Just use crc32c(). This is much simpler, and it improves performance due to eliminating the crypto API overhead. Reviewed

[PATCH v3 08/18] powerpc/crc32: expose CRC32 functions through lib

From: Eric Biggers Move the powerpc CRC32C assembly code into the lib directory and wire it up to the library interface. This allows it to be used without going through the crypto API. It remains usable via the crypto API too via the shash algorithms that use the library interface. Thus all

[PATCH v3 14/18] lib/crc32: make crc32c() go directly to lib

From: Eric Biggers Now that the lower level __crc32c_le() library function is optimized for each architecture, make crc32c() just call that instead of taking an inefficient and error-prone detour through the shash API. Note: a future cleanup should make crc32c_le() be the actual library

[PATCH v3 06/18] loongarch/crc32: expose CRC32 functions through lib

From: Eric Biggers Move the loongarch CRC32 assembly code into the lib directory and wire it up to the library interface. This allows it to be used without going through the crypto API. It remains usable via the crypto API too via the shash algorithms that use the library interface. Thus all

[PATCH v3 02/18] lib/crc32: improve support for arch-specific overrides

From: Eric Biggers Currently the CRC32 library functions are defined as weak symbols, and the arm64 and riscv architectures override them. This method of arch-specific overrides has the limitation that it only works when both the base and arch code is built-in. Also, it makes the arch-specific

[PATCH v3 07/18] mips/crc32: expose CRC32 functions through lib

From: Eric Biggers Move the mips CRC32 assembly code into the lib directory and wire it up to the library interface. This allows it to be used without going through the crypto API. It remains usable via the crypto API too via the shash algorithms that use the library interface. Thus all the

[PATCH v3 05/18] arm/crc32: expose CRC32 functions through lib

From: Eric Biggers Move the arm CRC32 assembly code into the lib directory and wire it up to the library interface. This allows it to be used without going through the crypto API. It remains usable via the crypto API too via the shash algorithms that use the library interface. Thus all the

[PATCH v3 03/18] lib/crc32: expose whether the lib is really optimized at runtime

From: Eric Biggers Make the CRC32 library export a function crc32_optimizations() which returns flags that indicate which CRC32 functions are actually executing optimized code at runtime. This will be used to determine whether the crc32[c]-$arch shash algorithms should be registered in the

[PATCH v3 01/18] lib/crc32: drop leading underscores from __crc32c_le_base

From: Eric Biggers Remove the leading underscores from __crc32c_le_base(). This is in preparation for adding crc32c_le_arch() and eventually renaming __crc32c_le() to crc32c_le(). Reviewed-by: Ard Biesheuvel Signed-off-by: Eric Biggers --- arch/arm64/lib/crc32-glue.c | 2 +- arch/riscv/lib

[PATCH v3 04/18] crypto: crc32 - don't unnecessarily register arch algorithms

From: Eric Biggers Instead of registering the crc32-$arch and crc32c-$arch algorithms if the arch-specific code was built, only register them when that code was built *and* is not falling back to the base implementation at runtime. This avoids confusing users like btrfs which checks the shash

[PATCH v3 00/18] Wire up CRC32 library functions to arch-optimized code

rithms with crypto API. - Added a patch that converts iSCSI to use the library. - Listed a bcachefs patch as a dependency. - Added Ard's Reviewed-by. Eric Biggers (18): lib/crc32: drop leading underscores from __crc32c_le_base lib/crc32: improve support for arch-specific overrides lib

Re: [PATCH v2 06/18] loongarch/crc32: expose CRC32 functions through lib

On Sun, Nov 03, 2024 at 09:36:55PM +0800, WangYuli wrote: > Even though the narrower CRC instructions doesn't require GRLEN=64, they > still *aren't* part of LA32 (LoongArch reference manual v1.10, Volume 1, > Table 2-1). > Link: > https://lore.kernel.org/all/0a7d0a9e-c56e-4ee2-a83b-00164a450...

Re: [PATCH v2 04/18] crypto: crc32 - don't unnecessarily register arch algorithms

On Sat, Nov 02, 2024 at 07:08:43PM +0800, Herbert Xu wrote: > On Sat, Nov 02, 2024 at 12:05:01PM +0100, Ard Biesheuvel wrote: > > > > The only issue resulting from *not* taking this patch is that btrfs > > may misidentify the CRC32 implementation as being 'slow' and take an > > alternative code pat

Re: [PATCH v2 04/18] crypto: crc32 - don't unnecessarily register arch algorithms

On Fri, Oct 25, 2024 at 10:02:39PM +, Eric Biggers wrote: > On Fri, Oct 25, 2024 at 10:47:15PM +0200, Ard Biesheuvel wrote: > > On Fri, 25 Oct 2024 at 21:15, Eric Biggers wrote: > > > > > > From: Eric Biggers > > > > > > Instead of registering t

Re: [PATCH v2 03/18] lib/crc32: expose whether the lib is really optimized at runtime

On Fri, Oct 25, 2024 at 11:37:45PM +0200, Ard Biesheuvel wrote: > On Fri, 25 Oct 2024 at 23:32, Eric Biggers wrote: > > > > On Fri, Oct 25, 2024 at 10:32:14PM +0200, Ard Biesheuvel wrote: > > > On Fri, 25 Oct 2024 at 21:15, Eric Biggers wrote: > >

[PATCH v2 18/18] scsi: target: iscsi: switch to using the crc32c library

From: Eric Biggers Now that the crc32c() library function directly takes advantage of architecture-specific optimizations, it is unnecessary to go through the crypto API. Just use crc32c(). This is much simpler, and it improves performance due to eliminating the crypto API overhead. Signed

Re: [PATCH v2 04/18] crypto: crc32 - don't unnecessarily register arch algorithms

On Fri, Oct 25, 2024 at 10:47:15PM +0200, Ard Biesheuvel wrote: > On Fri, 25 Oct 2024 at 21:15, Eric Biggers wrote: > > > > From: Eric Biggers > > > > Instead of registering the crc32-$arch and crc32c-$arch algorithms if > > the arch-specific code was built, only

Re: [PATCH v2 03/18] lib/crc32: expose whether the lib is really optimized at runtime

On Fri, Oct 25, 2024 at 10:32:14PM +0200, Ard Biesheuvel wrote: > On Fri, 25 Oct 2024 at 21:15, Eric Biggers wrote: > > > > From: Eric Biggers > > > > Make the CRC32 library export some flags that indicate which CRC32 > > functions are actually executing opti

[PATCH v2 14/18] lib/crc32: make crc32c() go directly to lib

From: Eric Biggers Now that the lower level __crc32c_le() library function is optimized for each architecture, make crc32c() just call that instead of taking an inefficient and error-prone detour through the shash API. Note: a future cleanup should make crc32c_le() be the actual library

[PATCH v2 05/18] arm/crc32: expose CRC32 functions through lib

From: Eric Biggers Move the arm CRC32 assembly code into the lib directory and wire it up to the library interface. This allows it to be used without going through the crypto API. It remains usable via the crypto API too via the shash algorithms that use the library interface. Thus all the

[PATCH v2 11/18] x86/crc32: update prototype for crc_pcl()

From: Eric Biggers - Change the len parameter from unsigned int to size_t, so that the library function which takes a size_t can safely use this code. - Rename to crc32c_x86_3way() which is much clearer. - Move the crc parameter to the front, as this is the usual convention. Reviewed-by

[PATCH v2 16/18] jbd2: switch to using the crc32c library

From: Eric Biggers Now that the crc32c() library function directly takes advantage of architecture-specific optimizations, it is unnecessary to go through the crypto API. Just use crc32c(). This is much simpler, and it improves performance due to eliminating the crypto API overhead. Reviewed

[PATCH v2 13/18] x86/crc32: expose CRC32 functions through lib

From: Eric Biggers Move the x86 CRC32 assembly code into the lib directory and wire it up to the library interface. This allows it to be used without going through the crypto API. It remains usable via the crypto API too via the shash algorithms that use the library interface. Thus all the

[PATCH v2 15/18] ext4: switch to using the crc32c library

From: Eric Biggers Now that the crc32c() library function directly takes advantage of architecture-specific optimizations, it is unnecessary to go through the crypto API. Just use crc32c(). This is much simpler, and it improves performance due to eliminating the crypto API overhead. Reviewed

[PATCH v2 17/18] f2fs: switch to using the crc32 library

From: Eric Biggers Now that the crc32() library function takes advantage of architecture-specific optimizations, it is unnecessary to go through the crypto API. Just use crc32(). This is much simpler, and it improves performance due to eliminating the crypto API overhead. Reviewed-by: Ard

[PATCH v2 12/18] x86/crc32: update prototype for crc32_pclmul_le_16()

From: Eric Biggers - Change the len parameter from unsigned int to size_t, so that the library function which takes a size_t can safely use this code. - Move the crc parameter to the front, as this is the usual convention. Reviewed-by: Ard Biesheuvel Signed-off-by: Eric Biggers --- arch

[PATCH v2 10/18] sparc/crc32: expose CRC32 functions through lib

From: Eric Biggers Move the sparc CRC32C assembly code into the lib directory and wire it up to the library interface. This allows it to be used without going through the crypto API. It remains usable via the crypto API too via the shash algorithms that use the library interface. Thus all the

[PATCH v2 02/18] lib/crc32: improve support for arch-specific overrides

From: Eric Biggers Currently the CRC32 library functions are defined as weak symbols, and the arm64 and riscv architectures override them. This method of arch-specific overrides has the limitation that it only works when both the base and arch code is built-in. Also, it makes the arch-specific

[PATCH v2 07/18] mips/crc32: expose CRC32 functions through lib

From: Eric Biggers Move the mips CRC32 assembly code into the lib directory and wire it up to the library interface. This allows it to be used without going through the crypto API. It remains usable via the crypto API too via the shash algorithms that use the library interface. Thus all the

[PATCH v2 08/18] powerpc/crc32: expose CRC32 functions through lib

From: Eric Biggers Move the powerpc CRC32C assembly code into the lib directory and wire it up to the library interface. This allows it to be used without going through the crypto API. It remains usable via the crypto API too via the shash algorithms that use the library interface. Thus all

[PATCH v2 09/18] s390/crc32: expose CRC32 functions through lib

From: Eric Biggers Move the s390 CRC32 assembly code into the lib directory and wire it up to the library interface. This allows it to be used without going through the crypto API. It remains usable via the crypto API too via the shash algorithms that use the library interface. Thus all the

[PATCH v2 06/18] loongarch/crc32: expose CRC32 functions through lib

From: Eric Biggers Move the loongarch CRC32 assembly code into the lib directory and wire it up to the library interface. This allows it to be used without going through the crypto API. It remains usable via the crypto API too via the shash algorithms that use the library interface. Thus all

[PATCH v2 04/18] crypto: crc32 - don't unnecessarily register arch algorithms

From: Eric Biggers Instead of registering the crc32-$arch and crc32c-$arch algorithms if the arch-specific code was built, only register them when that code was built *and* is not falling back to the base implementation at runtime. This avoids confusing users like btrfs which checks the shash

[PATCH v2 03/18] lib/crc32: expose whether the lib is really optimized at runtime

From: Eric Biggers Make the CRC32 library export some flags that indicate which CRC32 functions are actually executing optimized code at runtime. Set these correctly from the architectures that implement the CRC32 functions. This will be used to determine whether the crc32[c]-$arch shash

  1   2   >