linux-f2fs-devel.lists.sourceforge.net archive mirror
 help / color / mirror / Atom feed
From: Eric Biggers via Linux-f2fs-devel <linux-f2fs-devel@lists.sourceforge.net>
To: Chao Yu <yuchao0@huawei.com>
Cc: "Theodore Y . Ts'o" <tytso@mit.edu>,
	Michael Halcrow <mhalcrow@google.com>,
	linux-f2fs-devel@lists.sourceforge.net,
	linux-fscrypt@vger.kernel.org, Jaegeuk Kim <jaegeuk@kernel.org>,
	Victor Hsieh <victorhsieh@google.com>
Subject: Re: [PATCH 2/2] f2fs: refactor read path to allow multiple postprocessing steps
Date: Tue, 17 Apr 2018 10:42:21 -0700	[thread overview]
Message-ID: <20180417174221.GB7428@google.com> (raw)
In-Reply-To: <2ccf62e8-070a-7ddc-77a3-cb5ba9347bba@huawei.com>

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 bio_post_read_ctx, work);
> > +
> > +	fscrypt_decrypt_bio(ctx->bio);
> > +
> > +	bio_post_read_processing(ctx);
> > +}
> > +
> > +static void bio_post_read_processing(struct bio_post_read_ctx *ctx)
> > +{
> > +	switch (++ctx->cur_step) {
> > +	case STEP_DECRYPT:
> > +		if (ctx->enabled_steps & (1 << STEP_DECRYPT)) {
> > +			INIT_WORK(&ctx->work, decrypt_work);
> > +			fscrypt_enqueue_decrypt_work(&ctx->work);
> > +			return;
> > +		}
> > +		ctx->cur_step++;
> > +		/* fall-through */
> > +	default:
> > +		__read_end_io(ctx->bio);
> > +	}
> 
> How about introducing __bio_post_read_processing()
> 
> switch (step) {
> case STEP_DECRYPT:
> 	...
> 	break;
> case STEP_COMPRESS:
> 	...
> 	break;
> case STEP_GENERIC:
> 	__read_end_io;
> 	break;
> ...
> }
> 
> Then we can customize flexible read processes like:
> 
> bio_post_read_processing()
> {
> 	if (encrypt_enabled)
> 		__bio_post_read_processing(, STEP_DECRYPT);
> 	if (compress_enabled)
> 		__bio_post_read_processing(, STEP_COMPRESS);
> 	__bio_post_read_processing(, STEP_GENERIC);
> }
> 
> Or other flow.

If I understand correctly, you're suggesting that all the steps be done in a
single workqueue item?  The problem with that is that the verity work will
require I/O to the file to read hashes, which may need STEP_DECRYPT.  Hence,
decryption and verity will need separate workqueues.

> > @@ -481,29 +537,33 @@ static struct bio *f2fs_grab_read_bio(struct inode *inode, block_t blkaddr,
> >  							 unsigned nr_pages)
> >  {
> >  	struct f2fs_sb_info *sbi = F2FS_I_SB(inode);
> > -	struct fscrypt_ctx *ctx = NULL;
> >  	struct bio *bio;
> > -
> > -	if (f2fs_encrypted_file(inode)) {
> > -		ctx = fscrypt_get_ctx(inode, GFP_NOFS);
> > -		if (IS_ERR(ctx))
> > -			return ERR_CAST(ctx);
> > -
> > -		/* wait the page to be moved by cleaning */
> > -		f2fs_wait_on_block_writeback(sbi, blkaddr);
> > -	}
> > +	struct bio_post_read_ctx *ctx;
> > +	unsigned int post_read_steps = 0;
> >  
> >  	bio = f2fs_bio_alloc(sbi, min_t(int, nr_pages, BIO_MAX_PAGES), false);
> > -	if (!bio) {
> > -		if (ctx)
> > -			fscrypt_release_ctx(ctx);
> > +	if (!bio)
> >  		return ERR_PTR(-ENOMEM);
> > -	}
> >  	f2fs_target_device(sbi, blkaddr, bio);
> >  	bio->bi_end_io = f2fs_read_end_io;
> > -	bio->bi_private = ctx;
> 
> bio->bi_private = NULL;
> 

I don't see why.  ->bi_private is NULL by default.

> > +	bio_post_read_ctx_pool =
> > +		mempool_create_slab_pool(128, bio_post_read_ctx_cache);
> 
> #define MAX_POST_READ_CACHE_SIZE	128
> 

Yes, that makes sense.

- Eric

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot

  reply	other threads:[~2018-04-17 17:42 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-16 19:31 [PATCH 0/2] fscrypt / f2fs: prepare I/O path for fs-verity Eric Biggers via Linux-f2fs-devel
2018-04-16 19:31 ` [PATCH 1/2] fscrypt: allow synchronous bio decryption Eric Biggers via Linux-f2fs-devel
2018-04-18  4:22   ` Jaegeuk Kim
2018-04-16 19:31 ` [PATCH 2/2] f2fs: refactor read path to allow multiple postprocessing steps Eric Biggers via Linux-f2fs-devel
2018-04-16 22:15   ` Michael Halcrow via Linux-f2fs-devel
2018-04-17 17:31     ` Eric Biggers via Linux-f2fs-devel
2018-04-17  9:13   ` Chao Yu
2018-04-17 17:42     ` Eric Biggers via Linux-f2fs-devel [this message]
2018-04-18  6:27       ` Chao Yu
2018-04-18 17:18         ` Eric Biggers via Linux-f2fs-devel
2018-04-18 17:37           ` Jaegeuk Kim
2018-04-19 14:41           ` Chao Yu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180417174221.GB7428@google.com \
    --to=linux-f2fs-devel@lists.sourceforge.net \
    --cc=ebiggers@google.com \
    --cc=jaegeuk@kernel.org \
    --cc=linux-fscrypt@vger.kernel.org \
    --cc=mhalcrow@google.com \
    --cc=tytso@mit.edu \
    --cc=victorhsieh@google.com \
    --cc=yuchao0@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).