On 2019/8/19 21:33, Chandan Rajendra wrote: > On Sunday, August 18, 2019 7:15:42 PM IST Chao Yu wrote: >> Hi Chandan, >> >> On 2019-8-16 14:18, Chandan Rajendra wrote: >>> F2FS has a copy of "post read processing" code using which encrypted >>> file data is decrypted. This commit replaces it to make use of the >>> generic read_callbacks facility. >> >> I remember that previously Jaegeuk had mentioned f2fs will support compression >> later, and it needs to reuse 'post read processing' fwk. >> >> There is very initial version of compression feature in below link: >> >> https://git.kernel.org/pub/scm/linux/kernel/git/chao/linux.git/log/?h=compression >> >> So my concern is how can we uplift the most common parts of this fwk into vfs, >> and meanwhile keeping the ability and flexibility when introducing private >> feature/step in specified filesytem(now f2fs)? >> >> According to current f2fs compression's requirement, maybe we can expand to >> >> - support callback to let filesystem set the function for the flow in >> decompression/verity/decryption step. >> - support to use individual/common workqueue according the parameter. >> >> Any thoughts? >> > > Hi, > > F2FS can be made to use fscrypt's queue for decryption and hence can reuse > "read callbacks" code for decrypting data. > > For decompression, we could have a STEP_MISC where we invoke a FS provided > callback function for FS specific post read processing? > > Something like the following can be implemented in read_callbacks(), > case STEP_MISC: > if (ctx->enabled_steps & (1 << STEP_MISC)) { > /* > ctx->fs_misc() must process bio in a workqueue > and later invoke read_callbacks() with > bio->bi_private's value as an argument. > */ > ctx->fs_misc(ctx->bio); > return; > } > ctx->cur_step++; > > The fs_misc() callback can be passed in by the filesystem when invoking > read_callbacks_setup_bio(). Hi, Yes, something like this, can we just use STEP_DECOMPRESS and fs_decompress(), not sure, I doubt this interface may has potential user which has compression feature. One more concern is that to avoid more context switch, maybe we can merge all background works into one workqueue if there is no conflict when call wants to. 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)) { ... if (ctx->separated_wq) return; } ctx->cur_step++; /* fall-through */ case STEP_DECOMPRESS: ... default: __read_end_io(ctx->bio); >
