On Tue, Sep 03, 2024 at 02:54:44AM -0600, Wu Bo via Linux-f2fs-devel wrote:
> The inode in F2FS occupies an entire 4k block. For many small files, this
> means
> they consume much more space than their actual size. Therefore, there is
> significant potential to better utilize the inode block space
On Tue, Sep 10, 2024 at 08:57:53PM +0800, Chao Yu via Linux-f2fs-devel wrote:
> After commit 5c8764f8679e ("f2fs: fix to force buffered IO on inline_data
> inode"), f2fs starts to force using buffered IO on inline_data inode.
>
> And also, it will cause f2fs_getattr() returning invalid zeroed valu
On Wed, Sep 11, 2024 at 11:06:22AM +0800, Chao Yu wrote:
> On 2024/9/11 1:06, Eric Biggers wrote:
> > On Tue, Sep 10, 2024 at 08:57:53PM +0800, Chao Yu via Linux-f2fs-devel
> > wrote:
> > > After commit 5c8764f8679e ("f2fs: fix to force buffered IO on inline_data
> > > inode"), f2fs starts to forc
Hello, here's a patch which adds Speck128/256 support to fscrypt, for
ext4/f2fs/ubifs encryption. Note that this can be applied independently
of the patches that added Speck to the crypto API since there is no hard
dependency, but the crypto API support is needed for Speck-encrypted
files to work.
[+Cc linux-fscrypt]
Hi Sheng,
On Tue, Mar 06, 2018 at 11:39:04AM +0800, Sheng Yong wrote:
> This patch introduces a new feature, F2FS_FEATURE_LOST_FOUND, which
> is set by mkfs. It creates a directory named lost+found, which saves
> unreachable files. If fsck finds a file which has no parent, or
Reserve an F2FS feature flag and inode flag for fs-verity. This is an
in-development feature that is planned be discussed at LSF/MM 2018 [1].
It will provide file-based integrity and authenticity for read-only
files. Most code will be in a filesystem-independent module, with
smaller changes neede
Hi Chao and Jaegeuk,
On Fri, Mar 30, 2018 at 09:41:36AM -0700, Jaegeuk Kim wrote:
> On 03/30, Chao Yu wrote:
> > Hi Eric,
> >
> > On 2018/3/29 2:15, Eric Biggers wrote:
> > > Reserve an F2FS feature flag and inode flag for fs-verity. This is an
> > > in-development feature that is planned be dis
[+Cc linux-ext4, linux-fsdevel]
On Mon, Apr 02, 2018 at 06:07:10PM +0800, Chao Yu wrote:
> Hi Eric and Jaegeuk,
>
> On 2018/3/31 2:34, Eric Biggers wrote:
> > Hi Chao and Jaegeuk,
> >
> > On Fri, Mar 30, 2018 at 09:41:36AM -0700, Jaegeuk Kim wrote:
> >> On 03/30, Chao Yu wrote:
> >>> Hi Eric,
>
On Tue, Apr 03, 2018 at 07:49:59AM +1000, Dave Chinner wrote:
> On Mon, Apr 02, 2018 at 11:48:37AM -0700, Eric Biggers wrote:
> > [+Cc linux-ext4, linux-fsdevel]
> >
> > On Mon, Apr 02, 2018 at 06:07:10PM +0800, Chao Yu wrote:
> > > Hi Eric and Jaegeuk,
> > >
> > > On 2018/3/31 2:34, Eric Biggers
Pass the -f option to mkfs.f2fs when it appears to support it. This is
required by f2fs-tools v1.9 and later in order to format the filesystem
even when an existing filesystem is detected. But earlier versions did
not accept this option.
Signed-off-by: Eric Biggers
---
common/config | 11 +
Pass the -f option to mkfs.f2fs when it appears to support it. This is
required by f2fs-tools v1.9 and later in order to format the filesystem
even when an existing filesystem is detected. But earlier versions did
not accept this option.
Signed-off-by: Eric Biggers
---
kvm-xfstests/test-applia
Pass the -f option to mkfs.f2fs when it appears to support it. This is
required by f2fs-tools v1.9 and later in order to format the filesystem
even when an existing filesystem is detected. But earlier versions did
not accept this option.
mkfs.f2fs doesn't yet have an option to print its version
On Fri, Apr 06, 2018 at 09:30:36AM -0400, Theodore Y. Ts'o wrote:
> On Thu, Apr 05, 2018 at 03:21:41PM -0700, Eric Biggers wrote:
> > Pass the -f option to mkfs.f2fs when it appears to support it. This is
> > required by f2fs-tools v1.9 and later in order to format the filesystem
> > even when an
Hello,
These two patches restructure f2fs's read path to allow the data to go
through multiple postprocessing steps, rather than just decryption as is
implemented currently. This is mainly in preparation for doing
authenticity verification of data via fs-verity, though this change
might also be u
Currently f2fs's ->readpage() and ->readpages() assume that either the
data undergoes no postprocessing, or decryption only. But with
fs-verity, there will be an additional authenticity verification step,
and it may be needed either by itself, or combined with decryption.
To support this, store a
Currently, fscrypt provides fscrypt_decrypt_bio_pages() which decrypts a
bio's pages asynchronously, then unlocks them afterwards. But, this
assumes that decryption is the last "postprocessing step" for the bio,
so it's incompatible with additional postprocessing steps such as
authenticity verific
Hi Michael,
On Mon, Apr 16, 2018 at 03:15:42PM -0700, Michael Halcrow wrote:
> Given recent talk I've seen on potentially applying file-based
> protections in NFS, I think it's worth making some cautionary
> observations at this stage.
>
> Moxie's Cryptographic Doom Principle is an approachable t
Hi Chao,
On Tue, Apr 17, 2018 at 05:13:12PM +0800, Chao Yu wrote:
> > +
> > +static void bio_post_read_processing(struct bio_post_read_ctx *ctx);
> > +
> > +static void decrypt_work(struct work_struct *work)
> > +{
> > + struct bio_post_read_ctx *ctx =
> > + container_of(work, struct b
Hi Chao,
On Wed, Apr 18, 2018 at 02:27:32PM +0800, Chao Yu wrote:
> Hi Eric,
>
> On 2018/4/18 1:42, Eric Biggers wrote:
> > Hi Chao,
> >
> > On Tue, Apr 17, 2018 at 05:13:12PM +0800, Chao Yu wrote:
> >>> +
> >>> +static void bio_post_read_processing(struct bio_post_read_ctx *ctx);
> >>> +
> >>>
Hello,
These two patches restructure f2fs's read path to allow the data to go
through multiple postprocessing steps, rather than just decryption as is
implemented currently. This is mainly in preparation for doing
authenticity verification of data via fs-verity, though this change
might also be u
Currently f2fs's ->readpage() and ->readpages() assume that either the
data undergoes no postprocessing, or decryption only. But with
fs-verity, there will be an additional authenticity verification step,
and it may be needed either by itself, or combined with decryption.
To support this, store a
Currently, fscrypt provides fscrypt_decrypt_bio_pages() which decrypts a
bio's pages asynchronously, then unlocks them afterwards. But, this
assumes that decryption is the last "postprocessing step" for the bio,
so it's incompatible with additional postprocessing steps such as
authenticity verific
fscrypt currently only supports AES encryption. However, many low-end
mobile devices have older CPUs that don't have AES instructions, e.g.
the ARMv8 Cryptography Extensions. Currently, user data on such devices
is not encrypted at rest because AES is too slow, even when the NEON
bit-sliced imple
From: Jann Horn
commit 4f5a100f87f32cb65d4bb1ad282a08c92f6f591e upstream.
The F2FS ioctls for starting and committing atomic writes check for
inode_owner_or_capable(), but this does not give LSMs like SELinux or
Landlock an opportunity to deny the write access - if the caller's FSUID
matches the
From: Eric Biggers
Set the bi_skip_dm_default_key flag on bios that are targeting the
contents of an encrypted file and therefore should not be en/decrypted
by dm-default-key.
Signed-off-by: Eric Biggers
---
fs/crypto/inline_crypt.c | 14 +-
fs/f2fs/data.c | 6 +-
in
From: Eric Biggers
Add a flag bi_skip_dm_default_key to struct bio. This flag indicates
that dm-default-key should not en/decrypt the bio, due to it targeting
the contents of an encrypted file.
When a bio is cloned, copy the bi_skip_dm_default_key flag.
Signed-off-by: Eric Biggers
---
block/
From: Eric Biggers
Add a new device-mapper target "dm-default-key" that is similar to
dm-crypt but has two main differences:
- It uses the blk-crypto API instead of the regular crypto API. This
allows it to take advantage of inline encryption hardware such as that
commonly built into UFS ho
This series adds "metadata encryption" support to ext4 and f2fs via a
new device-mapper target dm-default-key. dm-default-key encrypts all
data on a block device that isn't already encrypted by the filesystem.
Except for the passthrough support, dm-default-key is basically the same
as the propose
From: Eric Biggers
bio_crypt_set_ctx(), blk_crypto_init_key(), and
blk_crypto_start_using_key() are needed to use inline encryption; see
Documentation/block/inline-encryption.rst. Export them so that
dm-default-key can use them. The only reason these weren't exported
before was that inline encr
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
ar
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
arc
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 th
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 B
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
arc
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: E
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
ar
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/cr
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-off
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 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 t
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
- 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
This patchset is also available in git via:
git fetch
https://git.kernel.org/pub/scm/linux/kernel/git/ebiggers/linux.git crc32-lib-v1
CRC32 is a family of common non-cryptographic integrity check algorithms
that are fairly fast with a portable C implementation and become far
faster still wit
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-off
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
function
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
On Mon, Oct 21, 2024 at 01:11:36PM +0200, Mikulas Patocka wrote:
> Hi
>
> What about using the REQ_META flag (it is set on metadata bios and cleared
> on data bios), instead of adding a new flag with the same meaning?
>
> Mikulas
REQ_META is a hint and is not used for all metadata.
And while m
On Mon, Oct 21, 2024 at 01:52:58PM +0200, Mikulas Patocka wrote:
> On Fri, 18 Oct 2024, Eric Biggers wrote:
>
> > This series adds "metadata encryption" support to ext4 and f2fs via a
> > new device-mapper target dm-default-key. dm-default-key encrypts all
> > data on a block device that isn't al
From: Jann Horn
commit 4f5a100f87f32cb65d4bb1ad282a08c92f6f591e upstream.
The F2FS ioctls for starting and committing atomic writes check for
inode_owner_or_capable(), but this does not give LSMs like SELinux or
Landlock an opportunity to deny the write access - if the caller's FSUID
matches the
From: Jann Horn
commit 4f5a100f87f32cb65d4bb1ad282a08c92f6f591e upstream.
The F2FS ioctls for starting and committing atomic writes check for
inode_owner_or_capable(), but this does not give LSMs like SELinux or
Landlock an opportunity to deny the write access - if the caller's FSUID
matches the
From: Jann Horn
commit 4f5a100f87f32cb65d4bb1ad282a08c92f6f591e upstream.
The F2FS ioctls for starting and committing atomic writes check for
inode_owner_or_capable(), but this does not give LSMs like SELinux or
Landlock an opportunity to deny the write access - if the caller's FSUID
matches the
From: Jann Horn
commit 4f5a100f87f32cb65d4bb1ad282a08c92f6f591e upstream.
The F2FS ioctls for starting and committing atomic writes check for
inode_owner_or_capable(), but this does not give LSMs like SELinux or
Landlock an opportunity to deny the write access - if the caller's FSUID
matches 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
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 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 = crc32c_pmull_update;
> -
> -
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 Bies
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-b
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-b
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
arc
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: Ard
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/x8
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-b
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
function
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 crypt
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
ar
This patchset is also available in git via:
git fetch
https://git.kernel.org/pub/scm/linux/kernel/git/ebiggers/linux.git crc32-lib-v3
CRC32 is a family of common non-cryptographic integrity check algorithms
that are fairly fast with a portable C implementation and become far
faster still wit
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 th
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
arc
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/c
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 t
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
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
ar
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 dr
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 the crc32-$arch and crc32c-$arch algorithms if
>
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 optimized code at runtime. Set these
> >
On Mon, Sep 23, 2024 at 12:37:32AM -0600, Wu Bo via Linux-f2fs-devel wrote:
> Therefore, if the filesystem does not support DIO, it should not set
> the STATX_DIOALIGN flag.
No, that's incorrect. STATX_DIOALIGN supports reporting that DIO is
unsupported, via the alignments being 0. See the statx
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
arc
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
arc
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/c
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
ar
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-off
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
algori
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 Bies
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
- 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/x8
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
This patchset is also available in git via:
git fetch
https://git.kernel.org/pub/scm/linux/kernel/git/ebiggers/linux.git crc32-lib-v2
CRC32 is a family of common non-cryptographic integrity check algorithms
that are fairly fast with a portable C implementation and become far
faster still wit
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
function
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-b
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-b
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: Ard
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 t
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 dr
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 th
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
ar
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 register them when that code was
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:
> > > >
> > > > From: Eric Biggers
> > > >
> > > > M
1 - 100 of 161 matches
Mail list logo
