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

2024-11-04 Thread Eric Biggers
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

2024-11-04 Thread Eric Biggers
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

2024-11-04 Thread Eric Biggers
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

2024-11-03 Thread Eric Biggers
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()

2024-11-03 Thread Eric Biggers
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

2024-11-03 Thread Eric Biggers
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

2024-11-03 Thread Eric Biggers
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

2024-11-03 Thread Eric Biggers
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

2024-11-03 Thread Eric Biggers
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()

2024-11-03 Thread Eric Biggers
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

2024-11-03 Thread Eric Biggers
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

2024-11-03 Thread Eric Biggers
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

2024-11-03 Thread Eric Biggers
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

2024-11-03 Thread Eric Biggers
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

2024-11-03 Thread Eric Biggers
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

2024-11-03 Thread Eric Biggers
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

2024-11-03 Thread Eric Biggers
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

2024-11-03 Thread Eric Biggers
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

2024-11-03 Thread Eric Biggers
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

2024-11-03 Thread Eric Biggers
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

2024-11-03 Thread Eric Biggers
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

2024-11-03 Thread Eric Biggers
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

2024-11-03 Thread Eric Biggers
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

2024-11-02 Thread Eric Biggers
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

2024-10-25 Thread Eric Biggers
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

2024-10-25 Thread Eric Biggers
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

2024-10-25 Thread Eric Biggers
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

2024-10-25 Thread Eric Biggers
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

2024-10-25 Thread Eric Biggers
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

2024-10-25 Thread Eric Biggers
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

2024-10-25 Thread Eric Biggers
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()

2024-10-25 Thread Eric Biggers
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

2024-10-25 Thread Eric Biggers
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

2024-10-25 Thread Eric Biggers
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

2024-10-25 Thread Eric Biggers
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

2024-10-25 Thread Eric Biggers
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()

2024-10-25 Thread Eric Biggers
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

2024-10-25 Thread Eric Biggers
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

2024-10-25 Thread Eric Biggers
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

2024-10-25 Thread Eric Biggers
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

2024-10-25 Thread Eric Biggers
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

2024-10-25 Thread Eric Biggers
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

2024-10-25 Thread Eric Biggers
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

2024-10-25 Thread Eric Biggers
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

2024-10-25 Thread Eric Biggers
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

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

2024-10-25 Thread Eric Biggers
y 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 Ard's Reviewed-by. Eric Biggers (18): lib/crc32: drop leading underscores

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

2024-10-25 Thread Eric Biggers
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

Re: [PATCH 07/15] s390/crc32: expose CRC32 functions through lib

2024-10-21 Thread Eric Biggers
On Mon, Oct 21, 2024 at 12:40:07PM +0200, Heiko Carstens wrote: > What makes sure that all of the code is available automatically if the > CPU supports the instructions like before? I can see that all CRC32 > related config options support also module build options. > > Before this patch, this mod

[PATCH 08/15] sparc/crc32: expose CRC32 functions through lib

2024-10-20 Thread Eric Biggers
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 04/15] loongarch/crc32: expose CRC32 functions through lib

2024-10-20 Thread Eric Biggers
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 13/15] ext4: switch to using the crc32c library

2024-10-20 Thread Eric Biggers
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

[PATCH 11/15] x86/crc32: expose CRC32 functions through lib

2024-10-20 Thread Eric Biggers
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 14/15] jbd2: switch to using the crc32c library

2024-10-20 Thread Eric Biggers
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

[PATCH 07/15] s390/crc32: expose CRC32 functions through lib

2024-10-20 Thread Eric Biggers
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 15/15] f2fs: switch to using the crc32 library

2024-10-20 Thread Eric Biggers
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. Signed-off-by: Eric

[PATCH 09/15] x86/crc32: update prototype for crc_pcl()

2024-10-20 Thread Eric Biggers
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. Signed-off-by

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

2024-10-20 Thread Eric Biggers
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 06/15] powerpc/crc32: expose CRC32 functions through lib

2024-10-20 Thread Eric Biggers
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 10/15] x86/crc32: update prototype for crc32_pclmul_le_16()

2024-10-20 Thread Eric Biggers
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. Signed-off-by: Eric Biggers --- arch/x86/crypto/crc32-pclmul_asm.S

[PATCH 05/15] mips/crc32: expose CRC32 functions through lib

2024-10-20 Thread Eric Biggers
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 00/15] Wire up CRC32 library functions to arch-optimized code

2024-10-20 Thread Eric Biggers
ith the whole patchset directly to Linus. Another is to have at least patches 1-2 and the above dependencies taken through the crypto tree in v6.13; then the arch patches can land separately afterwards, followed by the rest. Eric Biggers (15): lib/crc32: drop leading underscores from __crc32c_

[PATCH 03/15] arm/crc32: expose CRC32 functions through lib

2024-10-20 Thread Eric Biggers
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 02/15] lib/crc32: improve support for arch-specific overrides

2024-10-20 Thread Eric Biggers
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 01/15] lib/crc32: drop leading underscores from __crc32c_le_base

2024-10-20 Thread Eric Biggers
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(). Signed-off-by: Eric Biggers --- arch/arm64/lib/crc32-glue.c | 2 +- arch/riscv/lib/crc32.c | 2 +- crypto

Re: [PATCH v2 05/17] vdso: Avoid call to memset() by getrandom

2024-08-27 Thread Eric Biggers
On Thu, Aug 22, 2024 at 09:13:13AM +0200, Christophe Leroy wrote: > With the current implementation, __cvdso_getrandom_data() calls > memset(), which is unexpected in the VDSO. > > Rewrite opaque data initialisation to avoid memset(). > > Signed-off-by: Christophe Leroy > --- > lib/vdso/getrand

Re: Add fchmodat2() - or add a more general syscall?

2023-07-26 Thread Eric Biggers
On Tue, Jul 25, 2023 at 04:58:34PM +0100, David Howells wrote: > Rather than adding a fchmodat2() syscall, should we add a "set_file_attrs()" > syscall that takes a mask and allows you to set a bunch of stuff all in one > go? Basically, an interface to notify_change() in the kernel that would allo

Re: [RFC PATCH 01/21] crypto: scomp - Revert "add support for deflate rfc1950 (zlib)"

2023-07-18 Thread Eric Biggers
On Tue, Jul 18, 2023 at 03:32:39PM -0700, Eric Biggers wrote: > On Tue, Jul 18, 2023 at 02:58:27PM +0200, Ard Biesheuvel wrote: > > This reverts commit a368f43d6e3a001e684e9191a27df384fbff12f5. > > > > "zlib-deflate" was introduced 6 years ago, but it does not have

Re: [RFC PATCH 05/21] ubifs: Pass worst-case buffer size to compression routines

2023-07-18 Thread Eric Biggers
On Tue, Jul 18, 2023 at 02:58:31PM +0200, Ard Biesheuvel wrote: > Currently, the ubifs code allocates a worst case buffer size to > recompress a data node, but does not pass the size of that buffer to the > compression code. This means that the compression code will never use > the additional space

Re: [RFC PATCH 01/21] crypto: scomp - Revert "add support for deflate rfc1950 (zlib)"

2023-07-18 Thread Eric Biggers
On Tue, Jul 18, 2023 at 02:58:27PM +0200, Ard Biesheuvel wrote: > This reverts commit a368f43d6e3a001e684e9191a27df384fbff12f5. > > "zlib-deflate" was introduced 6 years ago, but it does not have any > users. So let's remove the generic implementation and the test vectors, > but retain the "zlib-d

Re: [PATCH v12 0/6] implement getrandom() in vDSO

2022-12-21 Thread Eric Biggers
On Wed, Dec 21, 2022 at 03:25:49PM +0100, Jason A. Donenfeld wrote: > On Tue, Dec 20, 2022 at 08:13:14PM +0000, Eric Biggers wrote: > > On Tue, Dec 20, 2022 at 05:17:52PM +, Christophe Leroy wrote: > > > Hi Jason, > > > > > > Le 12/12/2022 à 19:53, Jason A.

Re: [PATCH v12 0/6] implement getrandom() in vDSO

2022-12-20 Thread Eric Biggers
On Tue, Dec 20, 2022 at 05:17:52PM +, Christophe Leroy wrote: > Hi Jason, > > Le 12/12/2022 à 19:53, Jason A. Donenfeld a écrit : > > Changes v11->v12: > > > > - In order to avoid mlock()ing pages, and the related rlimit and fork > >inheritance issues there, Introduce VM_D

Re: [PATCH 0/4] crypto: nintendo-aes - add a new AES driver

2021-09-21 Thread Eric Biggers
On Tue, Sep 21, 2021 at 11:39:26PM +0200, Emmanuel Gil Peyrot wrote: > This engine implements AES in CBC mode, using 128-bit keys only. It is > present on both the Wii and the Wii U, and is apparently identical in > both consoles. > > The hardware is capable of firing an interrupt when the operat

Re: Buggy commit tracked to: "Re: [PATCH 2/9] iov_iter: move rw_copy_check_uvector() into lib/iov_iter.c"

2020-10-22 Thread Eric Biggers
On Thu, Oct 22, 2020 at 10:00:44AM -0700, Nick Desaulniers wrote: > On Thu, Oct 22, 2020 at 9:40 AM Matthew Wilcox wrote: > > > > On Thu, Oct 22, 2020 at 04:35:17PM +, David Laight wrote: > > > Wait... > > > readv(2) defines: > > > ssize_t readv(int fd, const struct iovec *iov, int iovcn

Re: [PATCH RFC PKS/PMEM 22/58] fs/f2fs: Utilize new kmap_thread()

2020-10-12 Thread Eric Biggers
On Sun, Oct 11, 2020 at 11:56:35PM -0700, Ira Weiny wrote: > > > > And I still don't really understand. After this patchset, there is still > > code > > nearly identical to the above (doing a temporary mapping just for a memcpy) > > that > > would still be using kmap_atomic(). > > I don't unde

Re: [PATCH RFC PKS/PMEM 22/58] fs/f2fs: Utilize new kmap_thread()

2020-10-09 Thread Eric Biggers
On Sat, Oct 10, 2020 at 01:39:54AM +0100, Matthew Wilcox wrote: > On Fri, Oct 09, 2020 at 02:34:34PM -0700, Eric Biggers wrote: > > On Fri, Oct 09, 2020 at 12:49:57PM -0700, ira.we...@intel.com wrote: > > > The kmap() calls in this FS are localized to a single thread. To avoid &

Re: [PATCH 05/14] fs: don't allow kernel reads and writes without iter ops

2020-10-09 Thread Eric Biggers
On Fri, Oct 09, 2020 at 06:03:31PM -0700, Linus Torvalds wrote: > On Fri, Oct 9, 2020 at 3:06 PM Eric Biggers wrote: > > > > It's a bit unintuitive that ppos=NULL means "use pos 0", not "use > > file->f_pos". > > That's not at all wh

Re: [PATCH 05/14] fs: don't allow kernel reads and writes without iter ops

2020-10-09 Thread Eric Biggers
On Fri, Oct 02, 2020 at 09:27:09AM -0700, Linus Torvalds wrote: > On Thu, Oct 1, 2020 at 3:41 PM Al Viro wrote: > > > > Better > > loff_t dummy = 0; > > ... > > wr = __kernel_write(file, data, bytes, &dummy); > > No, just fix __kernel_write() to work correctly. > > The fa

Re: [PATCH RFC PKS/PMEM 22/58] fs/f2fs: Utilize new kmap_thread()

2020-10-09 Thread Eric Biggers
On Fri, Oct 09, 2020 at 12:49:57PM -0700, ira.we...@intel.com wrote: > From: Ira Weiny > > The kmap() calls in this FS are localized to a single thread. To avoid > the over head of global PKRS updates use the new kmap_thread() call. > > Cc: Jaegeuk Kim > Cc: Chao Yu > Signed-off-by: Ira Weiny

Re: [PATCH 05/14] fs: don't allow kernel reads and writes without iter ops

2020-10-01 Thread Eric Biggers
Christoph, Al, and Linus: On Thu, Sep 03, 2020 at 04:22:33PM +0200, Christoph Hellwig wrote: > @@ -510,28 +524,31 @@ static ssize_t new_sync_write(struct file *filp, const > char __user *buf, size_t > /* caller is responsible for file_start_write/file_end_write */ > ssize_t __kernel_write(struc

Re: [PATCH 19/22] crypto: inside-secure - add check for xts input length equal to zero

2020-08-10 Thread Eric Biggers
On Mon, Aug 10, 2020 at 05:33:39PM +0300, Horia Geantă wrote: > On 8/10/2020 4:45 PM, Herbert Xu wrote: > > On Mon, Aug 10, 2020 at 10:20:20AM +, Van Leeuwen, Pascal wrote: > >> > >> With all due respect, but this makes no sense. > > > > I agree. This is a lot of churn for no gain. > > > I w

Re: [PATCH v4 1/3] mm/slab: Use memzero_explicit() in kzfree()

2020-06-15 Thread Eric Biggers
On Mon, Jun 15, 2020 at 09:57:16PM -0400, Waiman Long wrote: > The kzfree() function is normally used to clear some sensitive > information, like encryption keys, in the buffer before freeing it back > to the pool. Memset() is currently used for the buffer clearing. However, > it is entirely possib

Re: [PATCH 0/7] sha1 library cleanup

2020-05-03 Thread Eric Biggers
On Sat, May 02, 2020 at 03:05:46PM -0600, Jason A. Donenfeld wrote: > Thanks for this series. I like the general idea. I think it might make > sense, though, to separate things out into sha1.h and sha256.h. That > will be nice preparation work for when we eventually move obsolete > primitives into

[PATCH 0/7] sha1 library cleanup

2020-05-02 Thread Eric Biggers
. This patch series applies to cryptodev/master. Eric Biggers (7): mptcp: use SHA256_BLOCK_SIZE, not SHA_MESSAGE_BYTES crypto: powerpc/sha1 - remove unused temporary workspace crypto: powerpc/sha1 - prefix the "sha1_" functions crypto: s390/sha1 - prefix the "sha1_" fu

[PATCH 2/7] crypto: powerpc/sha1 - remove unused temporary workspace

2020-05-02 Thread Eric Biggers
From: Eric Biggers The PowerPC implementation of SHA-1 doesn't actually use the 16-word temporary array that's passed to the assembly code. This was probably meant to correspond to the 'W' array that lib/sha1.c uses. However, in sha1-powerpc-asm.S these values are actually

[PATCH 3/7] crypto: powerpc/sha1 - prefix the "sha1_" functions

2020-05-02 Thread Eric Biggers
From: Eric Biggers Prefix the PowerPC SHA-1 functions with "powerpc_sha1_" rather than "sha1_". This allows us to rename the library function sha_init() to sha1_init() without causing a naming collision. Cc: linuxppc-dev@lists.ozlabs.org Cc: Benjamin Herrenschmidt Cc:

[PATCH v2 0/3] crypto: powerpc - convert SPE AES algorithms to skcipher API

2019-10-14 Thread Eric Biggers
plit fixes into separate patches. - Made ppc_aes_setkey_skcipher() call ppc_aes_setkey(), rather than creating a separate expand_key() function. This keeps the code shorter. Eric Biggers (3): crypto: powerpc - don't unnecessarily use atomic scatterwalk crypto: powerpc - don't set ivsi

[PATCH v2 2/3] crypto: powerpc - don't set ivsize for AES-ECB

2019-10-14 Thread Eric Biggers
From: Eric Biggers Set the ivsize for the "ecb-ppc-spe" algorithm to 0, since ECB mode doesn't take an IV. This fixes a failure in the extra crypto self-tests: alg: skcipher: ivsize for ecb-ppc-spe (16) doesn't match generic impl (0) Signed-off-by: Eric Bigger

[PATCH v2 3/3] crypto: powerpc - convert SPE AES algorithms to skcipher API

2019-10-14 Thread Eric Biggers
From: Eric Biggers Convert the glue code for the PowerPC SPE implementations of AES-ECB, AES-CBC, AES-CTR, and AES-XTS from the deprecated "blkcipher" API to the "skcipher" API. This is needed in order for the blkcipher API to be removed. Tested with: export ARCH=p

[PATCH v2 1/3] crypto: powerpc - don't unnecessarily use atomic scatterwalk

2019-10-14 Thread Eric Biggers
From: Eric Biggers The PowerPC SPE implementations of AES modes only disable preemption during the actual encryption/decryption, not during the scatterwalk functions. It's therefore unnecessary to request an atomic scatterwalk. So don't do so. Signed-off-by: Eric Biggers --- ar

Re: [PATCH] crypto: powerpc - convert SPE AES algorithms to skcipher API

2019-10-14 Thread Eric Biggers
On Mon, Oct 14, 2019 at 10:45:22AM +0200, Ard Biesheuvel wrote: > Hi Eric, > > On Sat, 12 Oct 2019 at 04:32, Eric Biggers wrote: > > > > From: Eric Biggers > > > > Convert the glue code for the PowerPC SPE implementations of AES-ECB, > > AES-CBC, A

Re: [PATCH 0/4] crypto: nx - convert to skcipher API

2019-10-13 Thread Eric Biggers
On Sun, Oct 13, 2019 at 05:31:31PM +0200, Ard Biesheuvel wrote: > On Sun, 13 Oct 2019 at 08:29, Ard Biesheuvel > wrote: > > > > On Sun, 13 Oct 2019 at 06:40, Eric Biggers wrote: > > > > > > This series converts the PowerPC Nest (NX) implementations of

[PATCH 1/4] crypto: nx - don't abuse blkcipher_desc to pass iv around

2019-10-12 Thread Eric Biggers
From: Eric Biggers The NX crypto driver is using 'struct blkcipher_desc' to pass the IV around, even for AEADs (for which it creates the struct on the stack). This is not appropriate since this structure is part of the "blkcipher" API, which is deprecated and will be remove

[PATCH 4/4] crypto: nx - convert AES-CTR to skcipher API

2019-10-12 Thread Eric Biggers
From: Eric Biggers Convert the PowerPC Nest (NX) implementation of AES-CTR from the deprecated "blkcipher" API to the "skcipher" API. This is needed in order for the blkcipher API to be removed. Signed-off-by: Eric Biggers --- drivers/crypto/

[PATCH 0/4] crypto: nx - convert to skcipher API

2019-10-12 Thread Eric Biggers
has this hardware, please test this patchset with CONFIG_CRYPTO_MANAGER_EXTRA_TESTS=y. Eric Biggers (4): crypto: nx - don't abuse blkcipher_desc to pass iv around crypto: nx - convert AES-ECB to skcipher API crypto: nx - convert AES-CBC to skcipher API crypto: nx - convert AES-CTR to

[PATCH 3/4] crypto: nx - convert AES-CBC to skcipher API

2019-10-12 Thread Eric Biggers
From: Eric Biggers Convert the PowerPC Nest (NX) implementation of AES-CBC from the deprecated "blkcipher" API to the "skcipher" API. This is needed in order for the blkcipher API to be removed. Signed-off-by: Eric Biggers --- drivers/crypto/

[PATCH 2/4] crypto: nx - convert AES-ECB to skcipher API

2019-10-12 Thread Eric Biggers
From: Eric Biggers Convert the PowerPC Nest (NX) implementation of AES-ECB from the deprecated "blkcipher" API to the "skcipher" API. This is needed in order for the blkcipher API to be removed. Signed-off-by: Eric Biggers --- drivers/crypto/

[PATCH] crypto: powerpc - convert SPE AES algorithms to skcipher API

2019-10-11 Thread Eric Biggers
From: Eric Biggers Convert the glue code for the PowerPC SPE implementations of AES-ECB, AES-CBC, AES-CTR, and AES-XTS from the deprecated "blkcipher" API to the "skcipher" API. Tested with: export ARCH=powerpc CROSS_COMPILE=powerpc-linux-gnu- make mpc85xx_d

[PATCH] crypto: testmgr - fix length truncation with large page size

2019-05-20 Thread Eric Biggers
From: Eric Biggers On PowerPC with CONFIG_CRYPTO_MANAGER_EXTRA_TESTS=y, there is sometimes a crash in generate_random_aead_testvec(). The problem is that the generated test vectors use data lengths of up to about 2 * PAGE_SIZE, which is 128 KiB on PowerPC; however, the data length fields in the

[PATCH] crypto: vmx - convert to skcipher API

2019-05-20 Thread Eric Biggers
From: Eric Biggers Convert the VMX implementations of AES-CBC, AES-CTR, and AES-XTS from the deprecated "blkcipher" API to the "skcipher" API. As part of this, I moved the skcipher_request for the fallback algorithm off the stack and into the request context of the parent

[PATCH] crypto: vmx - convert to SPDX license identifiers

2019-05-20 Thread Eric Biggers
From: Eric Biggers Remove the boilerplate license text and replace it with the equivalent SPDX license identifier. Signed-off-by: Eric Biggers --- drivers/crypto/vmx/aes.c | 14 +- drivers/crypto/vmx/aes_cbc.c | 14 +- drivers/crypto/vmx/aes_ctr.c | 14

  1   2   >