Re: [f2fs-dev] [PATCH] Revert "ext4 crypto: fix to check feature status before get policy"

2019-10-31 Thread Eric Biggers
On Thu, Oct 31, 2019 at 10:52:19AM -0700, Doug Anderson wrote: > Hi, > > On Wed, Oct 30, 2019 at 2:59 PM Doug Anderson wrote: > > > > Hi, > > > > On Wed, Oct 30, 2019 at 1:57 PM Eric Biggers wrote: > > > > > > FWIW, from reading the Chrome OS code, I think the code you linked to > > > isn't >

Re: [f2fs-dev] [PATCH v5 7/9] fscrypt: add inline encryption support

2019-10-31 Thread Eric Biggers
On Thu, Oct 31, 2019 at 02:21:03PM -0700, Christoph Hellwig wrote: > On Thu, Oct 31, 2019 at 01:21:26PM -0700, Eric Biggers wrote: > > > > + /* The file must need contents encryption, not filenames > > > > encryption */ > > > > + if (!S_ISREG(inode->i_mode)) > > > > +

Re: [f2fs-dev] [RFC] errno.h: Provide EFSCORRUPTED for everybody

2019-10-31 Thread Theodore Y. Ts'o
On Wed, Oct 30, 2019 at 09:07:33PM -0400, Valdis Kletnieks wrote: > Three questions: (a) ACK/NAK on this patch, (b) should it be all in one > patch, or one to add to errno.h and 6 patches for 6 filesystems?), and > (c) if one patch, who gets to shepherd it through? Acked-by: Theodore Ts'o

Re: [f2fs-dev] [PATCH v5 3/9] block: blk-crypto for Inline Encryption

2019-10-31 Thread Christoph Hellwig
On Thu, Oct 31, 2019 at 04:50:45PM -0400, Theodore Y. Ts'o wrote: > One of the reasons I really want this is so I (as an upstream > maintainer of ext4 and fscrypt) can test the new code paths using > xfstests on GCE, without needing special pre-release hardware that has > the ICE support. > >

Re: [f2fs-dev] [PATCH v5 7/9] fscrypt: add inline encryption support

2019-10-31 Thread Christoph Hellwig
On Thu, Oct 31, 2019 at 01:21:26PM -0700, Eric Biggers wrote: > > > + /* The file must need contents encryption, not filenames encryption */ > > > + if (!S_ISREG(inode->i_mode)) > > > + return false; > > > > But that isn't really what the check checks for.. > > This is how fscrypt has

Re: [f2fs-dev] [PATCH v5 3/9] block: blk-crypto for Inline Encryption

2019-10-31 Thread Theodore Y. Ts'o
On Thu, Oct 31, 2019 at 10:57:13AM -0700, Christoph Hellwig wrote: > On Mon, Oct 28, 2019 at 12:20:26AM -0700, Satya Tangirala wrote: > > We introduce blk-crypto, which manages programming keyslots for struct > > bios. With blk-crypto, filesystems only need to call bio_crypt_set_ctx with > > the

Re: [f2fs-dev] [PATCH v5 7/9] fscrypt: add inline encryption support

2019-10-31 Thread Eric Biggers
Hi Christoph, thanks for reviewing this. On Thu, Oct 31, 2019 at 11:32:17AM -0700, Christoph Hellwig wrote: > > diff --git a/fs/crypto/bio.c b/fs/crypto/bio.c > > index 1f4b8a277060..956798debf71 100644 > > --- a/fs/crypto/bio.c > > +++ b/fs/crypto/bio.c > > @@ -46,26 +46,38 @@ int

Re: [f2fs-dev] [PATCH v5 7/9] fscrypt: add inline encryption support

2019-10-31 Thread Christoph Hellwig
> diff --git a/fs/crypto/bio.c b/fs/crypto/bio.c > index 1f4b8a277060..956798debf71 100644 > --- a/fs/crypto/bio.c > +++ b/fs/crypto/bio.c > @@ -46,26 +46,38 @@ int fscrypt_zeroout_range(const struct inode *inode, > pgoff_t lblk, > { > const unsigned int blockbits = inode->i_blkbits; >

Re: [f2fs-dev] [PATCH v5 6/9] scsi: ufs: Add inline encryption support to UFS

2019-10-31 Thread Christoph Hellwig
> /* Transfer request descriptor header fields */ > + if (lrbp->crypto_enable) { Maybe we want a little inline function so that we can use IS_ENABLED to make sure the compiler eliminates the dead code if crypt config option is not set. a) don't have to define the crypto_enable if the

Re: [f2fs-dev] [PATCH v5 5/9] scsi: ufs: UFS crypto API

2019-10-31 Thread Christoph Hellwig
> +static size_t get_keysize_bytes(enum ufs_crypto_key_size size) > +{ > + switch (size) { > + case UFS_CRYPTO_KEY_SIZE_128: return 16; > + case UFS_CRYPTO_KEY_SIZE_192: return 24; > + case UFS_CRYPTO_KEY_SIZE_256: return 32; > + case UFS_CRYPTO_KEY_SIZE_512: return 64; > +

Re: [f2fs-dev] [PATCH v5 2/9] block: Add encryption context to struct bio

2019-10-31 Thread Christoph Hellwig
> +static int num_prealloc_crypt_ctxs = 128; Where does that magic number come from? > +struct bio_crypt_ctx *bio_crypt_alloc_ctx(gfp_t gfp_mask) > +{ > + return mempool_alloc(bio_crypt_ctx_pool, gfp_mask); > +} > +EXPORT_SYMBOL(bio_crypt_alloc_ctx); This isn't used by an modular code. >

Re: [f2fs-dev] [PATCH v5 3/9] block: blk-crypto for Inline Encryption

2019-10-31 Thread Christoph Hellwig
On Mon, Oct 28, 2019 at 12:20:26AM -0700, Satya Tangirala wrote: > We introduce blk-crypto, which manages programming keyslots for struct > bios. With blk-crypto, filesystems only need to call bio_crypt_set_ctx with > the encryption key, algorithm and data_unit_num; they don't have to worry >

Re: [f2fs-dev] [PATCH] Revert "ext4 crypto: fix to check feature status before get policy"

2019-10-31 Thread Doug Anderson
Hi, On Wed, Oct 30, 2019 at 2:59 PM Doug Anderson wrote: > > Hi, > > On Wed, Oct 30, 2019 at 1:57 PM Eric Biggers wrote: > > > > FWIW, from reading the Chrome OS code, I think the code you linked to isn't > > where the breakage actually is. I think it's actually at > >

Re: [f2fs-dev] [PATCH v2] Revert "ext4 crypto: fix to check feature status before get policy"

2019-10-31 Thread Theodore Y. Ts'o
On Wed, Oct 30, 2019 at 02:51:38PM -0700, Eric Biggers wrote: > From: Douglas Anderson > > This reverts commit 0642ea2409f3 ("ext4 crypto: fix to check feature > status before get policy"). > > The commit made a clear and documented ABI change that is not backward > compatible. There exists

Re: [f2fs-dev] [RFC] errno.h: Provide EFSCORRUPTED for everybody

2019-10-31 Thread Jan Kara
On Wed 30-10-19 21:07:33, Valdis Kletnieks wrote: > Three questions: (a) ACK/NAK on this patch, (b) should it be all in one > patch, or one to add to errno.h and 6 patches for 6 filesystems?), and > (c) if one patch, who gets to shepherd it through? > > > There's currently 6 filesystems that

Re: [f2fs-dev] [RFC PATCH v2] f2fs: support data compression

2019-10-31 Thread Jaegeuk Kim
On 10/29, Chao Yu wrote: > This patch tries to support compression in f2fs. > > - New term named cluster is defined as basic unit of compression, file can > be divided into multiple clusters logically. One cluster includes 4 << n > (n >= 0) logical pages, compression size is also cluster size,

Re: [f2fs-dev] [PATCH 2/2] f2fs: support data compression

2019-10-31 Thread Jaegeuk Kim
Hi Chao, On 10/31, Chao Yu wrote: > On 2019/10/31 0:50, Eric Biggers wrote: > > No, just use kvmalloc(). The whole point of kvmalloc() is that it tries > > kmalloc() and then falls back to vmalloc() if it fails. > > Okay, it's fine to me, let me fix this in another patch. I've fixed some bugs.

Re: [f2fs-dev] [PATCH 1/2] f2fs: support aligned pinned file

2019-10-31 Thread Jaegeuk Kim
On 10/31, Chao Yu wrote: > On 2019/10/31 0:09, Jaegeuk Kim wrote: > > On 10/26, Chao Yu wrote: > >> On 2019/10/26 2:18, Jaegeuk Kim wrote: > >>> On 10/24, Chao Yu wrote: > Hi Jaegeuk, > > On 2019/10/23 1:16, Jaegeuk Kim wrote: > > This patch supports 2MB-aligned pinned file,

Re: [f2fs-dev] [PATCH] f2fs: bio_alloc should never fail

2019-10-31 Thread Chao Yu
On 2019/10/31 0:33, Jaegeuk Kim wrote: > On 10/30, Theodore Y. Ts'o wrote: >> On Wed, Oct 30, 2019 at 11:50:37PM +0800, Gao Xiang wrote: >>> >>> So I'm curious about the original issue in commit 740432f83560 >>> ("f2fs: handle failed bio allocation"). Since f2fs manages multiple write >>> bios