On Mon, Sep 15, 2025 at 12:04:51PM +0200, Jan Prusakowski wrote:
> common/encrypt: Do not run _verify_ciphertext_for_encryption_policy on
> compressed FS
A better title would be something like
"common/encrypt: Explicitly set the test file to uncompressed".
(We do still run _verify_ciphertext_for_
On Mon, Sep 15, 2025 at 12:04:50PM +0200, Jan Prusakowski wrote:
> Changes in v2: (Thanks to Eric for the review)
> - Instead of disabling the test entirely when file compression is used
> we now ensure that compression of the test file is disabled.
>
> Jan Prusakowski (1):
> common/encrypt: D
On Thu, Sep 04, 2025 at 10:54:49AM +0200, Jan Prusakowski wrote:
> _verify_ciphertext_for_encryption_policy() checks if encryption works
> correctly by reading encrypted file's contents directly from a block device
> and
> comparing it to a known good ciphertext.
>
> This, however, won't work if
On Mon, Aug 11, 2025 at 03:34:35PM +0200, Christian Brauner wrote:
> On Mon, Aug 11, 2025 at 03:17:01PM +0200, Christian Brauner wrote:
> > On Sun, Aug 10, 2025 at 02:03:02AM -0700, Eric Biggers wrote:
> > > On Sun, Aug 10, 2025 at 10:47:32AM +0200, Christian Brauner wrote:
>
On Sun, Aug 10, 2025 at 07:49:53AM -0700, Christoph Hellwig wrote:
> On Sun, Aug 10, 2025 at 12:56:53AM -0700, Eric Biggers wrote:
> > This is a cleaned-up implementation of moving the i_crypt_info and
> > i_verity_info pointers out of 'struct inode' and into the fs-speci
On Sun, Aug 10, 2025 at 10:47:32AM +0200, Christian Brauner wrote:
> On Sun, Aug 10, 2025 at 12:56:53AM -0700, Eric Biggers wrote:
> > This is a cleaned-up implementation of moving the i_crypt_info and
> > i_verity_info pointers out of 'struct inode' and into the fs-speci
improving cache efficiency with
filesystems that don't support fscrypt.
Co-developed-by: Christian Brauner
Signed-off-by: Christian Brauner
Signed-off-by: Eric Biggers
---
fs/f2fs/f2fs.h | 3 +++
fs/f2fs/super.c | 7 ++-
2 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/fs
VFS_WARN_ON_ONCE() that asserts that. (This
of course defeats the optimization, but only when CONFIG_VFS_DEBUG=y.)
Signed-off-by: Eric Biggers
---
include/linux/fsverity.h | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/include/linux/fsverity.h b/include/linux/fsverity.h
improving cache efficiency with
filesystems that don't support fscrypt.
Co-developed-by: Christian Brauner
Signed-off-by: Christian Brauner
Signed-off-by: Eric Biggers
---
fs/ceph/crypto.c | 2 ++
fs/ceph/inode.c | 1 +
fs/ceph/super.h | 1 +
3 files changed, 4 insertions(+)
diff --git a/fs
improving cache efficiency with
filesystems that don't support fscrypt.
Co-developed-by: Christian Brauner
Signed-off-by: Christian Brauner
Signed-off-by: Eric Biggers
---
fs/ext4/crypto.c | 2 ++
fs/ext4/ext4.h | 4
fs/ext4/super.c | 3 +++
3 files changed, 9 insertions(+)
diff --git
improving cache efficiency on
filesystems that don't support fsverity.
Co-developed-by: Christian Brauner
Signed-off-by: Christian Brauner
Signed-off-by: Eric Biggers
---
fs/ext4/ext4.h | 4
fs/ext4/super.c | 3 +++
fs/ext4/verity.c | 2 ++
3 files changed, 9 insertions(+)
diff --git
igned-off-by: Christian Brauner
Signed-off-by: Eric Biggers
---
fs/verity/enable.c | 6 ++---
fs/verity/fsverity_private.h | 9
fs/verity/open.c | 23 ++-
fs/verity/verify.c | 2 +-
include/linux/fsverity.h
igned-off-by: Christian Brauner
Signed-off-by: Eric Biggers
---
fs/crypto/fscrypt_private.h | 4 ++--
fs/crypto/keysetup.c| 43 ++---
include/linux/fscrypt.h | 22 +++
3 files changed, 46 insertions(+), 23 deletions(-)
diff --git
improving cache efficiency on
filesystems that don't support fsverity.
Co-developed-by: Christian Brauner
Signed-off-by: Christian Brauner
Signed-off-by: Eric Biggers
---
fs/f2fs/f2fs.h | 3 +++
fs/f2fs/super.c | 3 +++
fs/f2fs/verity.c | 2 ++
3 files changed, 8 insertions(+)
diff --git a/fs
cally, their in-memory inodes are now
smaller by the size of a pointer: either 4 or 8 bytes.
Co-developed-by: Christian Brauner
Signed-off-by: Christian Brauner
Signed-off-by: Eric Biggers
---
include/linux/fs.h | 5 -
include/linux/fsverity.h | 10 --
2 files changed, 8 inser
el.org/
I'd like to take this series through the fscrypt tree for 6.18.
(fsverity normally has a separate tree, but by choosing just one tree
for this, we'll avoid conflicts in some places.)
Eric Biggers (13):
fscrypt: replace raw loads of info pointer with helper function
fscrypt:
s are
now smaller by the size of a pointer: either 4 or 8 bytes.
Co-developed-by: Christian Brauner
Signed-off-by: Christian Brauner
Signed-off-by: Eric Biggers
---
include/linux/fs.h | 5 -
include/linux/fscrypt.h | 8 ++--
2 files changed, 6 insertions(+), 7 deletions(-)
diff --
cache efficiency on
filesystems that don't support fsverity.
Co-developed-by: Christian Brauner
Signed-off-by: Christian Brauner
Signed-off-by: Eric Biggers
---
fs/btrfs/btrfs_inode.h | 5 +
fs/btrfs/inode.c | 3 +++
fs/btrfs/verity.c | 2 ++
3 files changed, 10 inser
n for replacing that with a filesystem-specific field.
Co-developed-by: Christian Brauner
Signed-off-by: Christian Brauner
Signed-off-by: Eric Biggers
---
fs/crypto/bio.c | 2 +-
fs/crypto/crypto.c | 14 --
fs/crypto/fname.c| 11 ++-
fs/crypto/ho
cache efficiency with
filesystems that don't support fscrypt.
Note that the initialization of ubifs_inode::i_crypt_info to NULL on
inode allocation is handled by the memset() in ubifs_alloc_inode().
Co-developed-by: Christian Brauner
Signed-off-by: Christian Brauner
Signed-off-by: Eric Bi
On Wed, Jul 16, 2025 at 11:37:28PM +0100, Phillip Lougher wrote:
> > There also seems to be some discrepancy between filesystems whether the
> > decompression involves vmap() of all the memory allocated or whether the
> > decompression routines can handle doing kmap_local() on individual pages.
> >
On Wed, Jul 09, 2025 at 12:26:50PM -0700, Eric Biggers wrote:
> On Mon, Jun 30, 2025 at 10:22:22AM -0700, Eric Biggers wrote:
> > This series, including all its prerequisites, is also available at:
> >
> > git fetch
> > https://git.kernel.org/pub/scm/linux/ke
On Mon, Jun 30, 2025 at 10:22:22AM -0700, Eric Biggers wrote:
> This series, including all its prerequisites, is also available at:
>
> git fetch
> https://git.kernel.org/pub/scm/linux/kernel/git/ebiggers/linux.git
> fsverity-libcrypto-v1
>
> This series makes fs/
just too high. Inline crypto engines are much more promising here,
as are on-CPU solutions like RISC-V High Assurance Cryptography.
Fixes: b30ab0e03407 ("ext4 crypto: add ext4 encryption facilities")
Cc: sta...@vger.kernel.org
Signed-off-by: Eric Biggers
---
Changed in v3:
- Further imp
On Fri, Jul 04, 2025 at 10:43:57AM +0800, Yuwen Chen wrote:
> During path traversal, the generic_ci_match function may be called
> multiple times. The number of memory allocations and releases
> in it accounts for a relatively high proportion in the flamegraph.
> This patch significantly reduces th
/crypto/ so that it no longer depends on CRYPTO.
This eliminates the need for FS_VERITY to select CRYPTO after it's been
converted to use lib/crypto/.
Signed-off-by: Eric Biggers
---
crypto/Kconfig | 3 ---
crypto/Makefile| 1 -
lib/crypto/Kc
. The library-based code is also more
efficient, since it avoids overheads such as indirect calls.
Signed-off-by: Eric Biggers
---
Documentation/filesystems/fsverity.rst | 3 +-
fs/verity/Kconfig | 6 +-
fs/verity/enable.c | 8 +-
fs/verity
efficient.
This depends on my SHA-2 library improvements for 6.17 (many patches),
so this patchset might need to wait until 6.18. But I'm also thinking
about just basing the fsverity tree on libcrypto-next for 6.17.
Eric Biggers (2):
lib/crypto: hash_info: Move hash_info.c into lib/c
On Wed, Jun 25, 2025 at 06:29:17PM +0200, Maxime MERE wrote:
> Regarding robustness and maintenance, ST ensures regular updates of its
> drivers and can fix any reported bugs. We have conducted internal tests with
> dm-crypt that demonstrate the proper functioning of these drivers for this
> type o
On Wed, Jun 25, 2025 at 06:29:26PM +0200, Maxime MERE wrote:
> Hi,
>
> On 6/25/25 08:32, Eric Biggers wrote:
> > That was the synchronous throughput. However, submitting multiple requests
> > asynchronously (which again, fscrypt doesn't actually do) barely helps.
>
On Wed, Jun 25, 2025 at 06:29:17PM +0200, Maxime MERE wrote:
>
>
> On 6/13/25 16:42, Eric Biggers wrote:
> > Honestly, the responses to this thread so far have made it even more clear
> > that
> > this patch is the right decision.
>
> The chaining system
On Wed, Jun 25, 2025 at 08:44:45AM -0400, Theodore Ts'o wrote:
> On Tue, Jun 24, 2025 at 11:32:52PM -0700, Eric Biggers wrote:
> >
> > That was the synchronous throughput. However, submitting multiple requests
> > asynchronously (which again, fscrypt doesn&#
On Wed, Jun 11, 2025 at 11:25:21PM -0700, Eric Biggers wrote:
> On Thu, Jun 12, 2025 at 12:59:14AM +0000, Eric Biggers wrote:
> > On Thu, Jun 12, 2025 at 09:21:26AM +0900, Simon Richter wrote:
> > > Hi,
> > >
> > > On 6/12/25 05:58, Eric Biggers wrote:
>
From: Eric Biggers
Make fscrypt no longer use Crypto API drivers for non-inline crypto
accelerators, even when the Crypto API prioritizes them over CPU-based
code (which unfortunately it often does). These drivers tend to be
really problematic, especially for fscrypt's synchronous wor
On Fri, Jun 13, 2025 at 11:01:03AM +0200, Maxime MERE wrote:
> Hello,
>
> On 6/11/25 22:58, Eric Biggers wrote:
> > To protect users from these buggy and seemingly unhelpful drivers that I
> > have no way of testing, let's make fscrypt not use them. Unfortunately
>
On Thu, Jun 12, 2025 at 03:57:43PM +, Eric Biggers wrote:
> On Thu, Jun 12, 2025 at 09:50:26AM +0100, Giovanni Cabiddu wrote:
> > On Wed, Jun 11, 2025 at 11:25:21PM -0700, Eric Biggers wrote:
> >
> > ...
> >
> > > FWIW, here's what happens if
On Thu, Jun 12, 2025 at 09:50:26AM +0100, Giovanni Cabiddu wrote:
> On Wed, Jun 11, 2025 at 11:25:21PM -0700, Eric Biggers wrote:
>
> ...
>
> > FWIW, here's what happens if you try to use the Intel QAT driver with
> > dm-crypt:
> >
On Thu, Jun 12, 2025 at 12:59:14AM +, Eric Biggers wrote:
> On Thu, Jun 12, 2025 at 09:21:26AM +0900, Simon Richter wrote:
> > Hi,
> >
> > On 6/12/25 05:58, Eric Biggers wrote:
> >
> > > But
> > > otherwise this style of hardware offload is basica
On Thu, Jun 12, 2025 at 09:21:26AM +0900, Simon Richter wrote:
> Hi,
>
> On 6/12/25 05:58, Eric Biggers wrote:
>
> > But
> > otherwise this style of hardware offload is basically obsolete and has
> > been superseded by hardware-accelerated crypto instructions dire
From: Eric Biggers
fscrypt has never properly supported the old-school Crypto API hardware
offload drivers, as it processes each request synchronously. There was
one report of someone successfully using such a driver 8 years ago. But
otherwise this style of hardware offload is basically
tests that were already merged into
xfstests (generic/368 and generic/369).
--------
Eric Biggers (1):
fscrypt: add support for hardware-wrapped keys
Documentation/filesystems/fscrypt.rst | 187 +++---
fs/crypto/fs
From: Eric Biggers
Since __f2fs_crc32() now calls crc32() directly, it no longer uses its
sbi argument. Remove that, and simplify its callers accordingly.
Signed-off-by: Eric Biggers
---
fs/f2fs/checkpoint.c | 13 ++---
fs/f2fs/compress.c | 5 ++---
fs/f2fs/f2fs.h | 20
On Mon, Mar 03, 2025 at 11:46:06AM +0800, Chao Yu via Linux-f2fs-devel wrote:
> This patch introduces a new flag F2FS_NOLINEAR_LOOKUP_FL, so that we can
> tag casefolded directory w/ it to disable linear lookup functionality,
> it can be used for QA.
>
> Signed-off-by: Chao Yu
> ---
> fs/f2fs/di
On Mon, Jan 13, 2025 at 06:39:32PM +, Jaegeuk Kim via Linux-f2fs-devel
wrote:
> This patch introduces an inode list to keep the page cache ranges that users
> can donate pages together.
>
> #define F2FS_IOC_DONATE_RANGE_IOW(F2FS_IOCTL_MAGIC, 27,
> \
>
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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 =
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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...
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
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
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
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
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
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:
> >
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
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
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
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
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
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
1 - 100 of 1143 matches
Mail list logo
