Hi Nick,
On 2020/9/17 2:39, Nick Terrell wrote:
On Sep 15, 2020, at 11:31 PM, Chao Yu wrote:
Hi Nick,
remove not related mailing list.
On 2020/9/16 11:43, Nick Terrell wrote:
From: Nick Terrell
Move away from the compatibility wrapper to the zstd-1.4.6 API. This
code is more efficient b
On 14/9/2020 3:55 pm, Chao Yu wrote:
Hi Chris,
On 2020/9/14 15:38, Chris Ruehl wrote:
I must say sorry for the noise, I checked the Ram and CPU, we have a bad
RAM which can't follow the 992Mhz and causes the problem, once limit the
CPU speed to 800Mhz the problem is gone. Both 4.9 & 5.4
Ok
From: Eric Biggers
fscrypt_get_encryption_info() has never actually been safe to call in a
context that needs GFP_NOFS, since it calls crypto_alloc_skcipher().
crypto_alloc_skcipher() isn't GFP_NOFS-safe, even if called under
memalloc_nofs_save(). This is because it may load kernel modules, and
From: Eric Biggers
Now that all filesystems have been converted to use
fscrypt_prepare_new_inode() and fscrypt_set_context(),
fscrypt_inherit_context() is no longer used. Remove it.
Signed-off-by: Eric Biggers
---
fs/crypto/policy.c | 37 -
include/lin
From: Eric Biggers
The fscrypt UAPI header defines fscrypt_policy to fscrypt_policy_v1,
for source compatibility with old userspace programs.
Internally, the kernel doesn't want that compatibility definition.
Instead, fscrypt_private.h #undefs it and re-defines it to a union.
That works for now
From: Eric Biggers
Convert f2fs to use the new functions fscrypt_prepare_new_inode() and
fscrypt_set_context(). This avoids calling
fscrypt_get_encryption_info() from under f2fs_lock_op(), which can
deadlock because fscrypt_get_encryption_info() isn't GFP_NOFS-safe.
For more details about this
From: Eric Biggers
The behavior of the test_dummy_encryption mount option is that when a
new file (or directory or symlink) is created in an unencrypted
directory, it's automatically encrypted using a dummy encryption policy.
That's it; in particular, the encryption (or lack thereof) of existing
From: Eric Biggers
In preparation for moving the logic for "get the encryption policy
inherited by new files in this directory" to a single place, make
fscrypt_prepare_symlink() a regular function rather than an inline
function that wraps __fscrypt_prepare_symlink().
This way, the new function f
Hello,
This series reworks the implementation of creating new encrypted files
by introducing new helper functions that allow filesystems to set up the
inodes' keys earlier, prior to taking too many filesystem locks.
This fixes deadlocks that are possible during memory reclaim because
fscrypt_get_
From: Eric Biggers
Now that all filesystems have been converted to use
fscrypt_prepare_new_inode(), the encryption key for new symlink inodes
is now already set up whenever we try to encrypt the symlink target.
Enforce this rather than try to set up the key again when it may be too
late to do so
From: Eric Biggers
Now that a fscrypt_info may be set up for inodes that are currently
being created and haven't yet had an inode number assigned, avoid
logging confusing messages about "inode 0".
Signed-off-by: Eric Biggers
---
fs/crypto/crypto.c | 4 +++-
fs/crypto/keyring.c | 9 +++--
From: Eric Biggers
fscrypt_get_encryption_info() is intended to be GFP_NOFS-safe. But
actually it isn't, since it uses functions like crypto_alloc_skcipher()
which aren't GFP_NOFS-safe, even when called under memalloc_nofs_save().
Therefore it can deadlock when called from a context that needs
G
From: Eric Biggers
Convert ubifs to use the new functions fscrypt_prepare_new_inode() and
fscrypt_set_context().
Unlike ext4 and f2fs, this doesn't appear to fix any deadlock bug. But
it does shorten the code slightly and get all filesystems using the same
helper functions, so that fscrypt_inhe
From: Eric Biggers
Convert ext4 to use the new functions fscrypt_prepare_new_inode() and
fscrypt_set_context(). This avoids calling
fscrypt_get_encryption_info() from within a transaction, which can
deadlock because fscrypt_get_encryption_info() isn't GFP_NOFS-safe.
For more details about this
From: Eric Biggers
To compute a new inode's xattr credits, we need to know whether the
inode will be encrypted or not. When we switch to use the new helper
function fscrypt_prepare_new_inode(), we won't find out whether the
inode will be encrypted until slightly later than is currently the case.
From: Eric Biggers
fscrypt_set_test_dummy_encryption() requires that the optional argument
to the test_dummy_encryption mount option be specified as a substring_t.
That doesn't work well with filesystems that use the new mount API,
since the new way of parsing mount options doesn't use substring_
在 2020/9/16 17:49, Yuchao (T) 写道:
> On 2020/9/16 14:56, wangxiaojun (N) wrote:
>> 在 2020/9/16 10:57, Yuchao (T) 写道:
>>> On 2020/9/16 9:54, Xiaojun Wang wrote:
Meta area is not included in section_count computation.
The code in mkfs/f2fs_format.c is:
total_zones = get_sb(segment_co
> On Sep 15, 2020, at 8:42 PM, Nick Terrell wrote:
>
> From: Nick Terrell
>
> Upgrade to the latest upstream zstd version 1.4.6.
>
> This patch is 100% generated from upstream zstd commit c4763f087c2b [0].
>
> This patch is very large because it is transitioning from the custom
> kernel zstd
> On Sep 15, 2020, at 11:31 PM, Chao Yu wrote:
>
> Hi Nick,
>
> remove not related mailing list.
>
> On 2020/9/16 11:43, Nick Terrell wrote:
>> From: Nick Terrell
>> Move away from the compatibility wrapper to the zstd-1.4.6 API. This
>> code is more efficient because it uses the single-pass
On Wed, Sep 16, 2020 at 03:46:18PM +0100, Christoph Hellwig wrote:
> On Wed, Sep 16, 2020 at 10:43:04AM -0400, Chris Mason wrote:
> > Otherwise we just end up with drift and kernel-specific bugs that are harder
> > to debug. To the extent those APIs make us contort the kernel code, I???m
> > sure
On 16 Sep 2020, at 10:46, Christoph Hellwig wrote:
On Wed, Sep 16, 2020 at 10:43:04AM -0400, Chris Mason wrote:
Otherwise we just end up with drift and kernel-specific bugs that are
harder
to debug. To the extent those APIs make us contort the kernel code,
I???m
sure Nick is interested in im
On Wed, Sep 16, 2020 at 10:43:04AM -0400, Chris Mason wrote:
> Otherwise we just end up with drift and kernel-specific bugs that are harder
> to debug. To the extent those APIs make us contort the kernel code, I???m
> sure Nick is interested in improving things in both places.
Seriously, we do no
On 16 Sep 2020, at 10:30, Christoph Hellwig wrote:
On Wed, Sep 16, 2020 at 10:20:52AM -0400, Chris Mason wrote:
It???s not completely clear what you???re asking for here. If the
API
matches what???s in zstd-1.4.6, that seems like a reasonable way to
label
it. That???s what the upstream is f
On Wed, Sep 16, 2020 at 10:20:52AM -0400, Chris Mason wrote:
> It???s not completely clear what you???re asking for here. If the API
> matches what???s in zstd-1.4.6, that seems like a reasonable way to label
> it. That???s what the upstream is for this code.
>
> I???m also not sure why we???re
On 16 Sep 2020, at 4:49, Christoph Hellwig wrote:
On Tue, Sep 15, 2020 at 08:42:59PM -0700, Nick Terrell wrote:
From: Nick Terrell
Move away from the compatibility wrapper to the zstd-1.4.6 API. This
code is functionally equivalent.
Again, please use sensible names And no one gives a fuck
On 2020/9/16 14:56, wangxiaojun (N) wrote:
在 2020/9/16 10:57, Yuchao (T) 写道:
On 2020/9/16 9:54, Xiaojun Wang wrote:
Meta area is not included in section_count computation.
The code in mkfs/f2fs_format.c is:
total_zones = get_sb(segment_count) / (c.segs_per_zone) -
On Tue, Sep 15, 2020 at 08:42:59PM -0700, Nick Terrell wrote:
> From: Nick Terrell
>
> Move away from the compatibility wrapper to the zstd-1.4.6 API. This
> code is functionally equivalent.
Again, please use sensible names And no one gives a fuck if this bad
API is "zstd-1.4.6" as the Linux ke
> + const size_t wksp_size = ZSTD_estimateCCtxSize(ZSTD_DEF_LEVEL);
> +
> + if (ZSTD_isError(wksp_size)) {
> + ret = -EINVAL;
> + goto out_free;
> + }
Pleas switch to properly named functions when you touch this.
The API names here look like a cat threw up on t
On Tue, Sep 15, 2020 at 08:42:54PM -0700, Nick Terrell wrote:
> From: Nick Terrell
>
> Adds zstd_compat.h which provides the necessary functions from the
> current zstd.h API. It is only active for zstd versions 1.4.6 and newer.
> That means it is disabled currently, but will become active when a
The type of SM_I(sbi)->reserved_segments is unsigned int,
so change the return value to unsigned int.
The type cast can be removed in reserved_sections as a result.
Signed-off-by: Xiaojun Wang
---
fs/f2fs/segment.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/fs/f2fs/s
30 matches
Mail list logo
