linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Chandan Rajendra <chandan@linux.vnet.ibm.com>
To: "Theodore Y. Ts'o" <tytso@mit.edu>
Cc: linux-fscrypt@vger.kernel.org, ebiggers3@gmail.com,
	linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org
Subject: Re: [RFC PATCH V3 07/12] mpage_readpage[s]: Introduce post process callback parameters
Date: Tue, 29 May 2018 08:34:21 +0530	[thread overview]
Message-ID: <1832647.byIzkSnT1k@localhost.localdomain> (raw)
In-Reply-To: <20180528193437.GC3572@thunk.org>

On Tuesday, May 29, 2018 1:04:37 AM IST Theodore Y. Ts'o wrote:
> On Mon, May 28, 2018 at 11:05:52AM +0530, Chandan Rajendra wrote:
> > > Can you describe more of what you are doing here; specifically, you
> > > deleted all of fs/ext4/readpage.c --- was this because you moved
> > > functionality back into fs/mpage.c?  Did you make sure all of the
> > > local changes in fs/ext4/readpage was moved back to fs/mpage.c?
> > > 
> > > If the goal is to refactor code to remove the need for
> > > fs/ext4/readpage.c, you should probably make that be the first patch
> > > as a prerequisite patch.  And we then need to make sure we don't
> > > accidentally break anyone else who might be using fs/mpage.c.  Saying
> > > a bit more about why you think the refactor is a good thing would also
> > > be useful.
> > 
> > I will split this patch into two as suggested by you. Also, I will update 
> > the commit messages.
> 
> Note that I was planning on making changes to fs/ext4/readpage.c as
> part of integrating fsverity[1][2] support into ext4.  Basically, I
> need to do something like [3] to fs/ext4/readpage.c.
> 
> [1] https://www.spinics.net/lists/linux-fsdevel/msg121182.html
> [2] https://www.youtube.com/watch?v=GlEWcVuRbNA
> [3] https://git.kernel.org/pub/scm/linux/kernel/git/mhalcrow/linux.git/commit/?h=fs-verity-dev&id=827faba05972517f49fa2f2aaf272150f5766af2
> 
> Which is why I'm really interested in your reasoning for why you
> propose to drop fs/ext4/readpage.c.  :-)
> 

The first patchset to support encryption in subpage-blocksize scenario copied
the block_read_full_page() from fs/buffer.c to ext4/readpage.c and had made
changes required to support encryption in that function. However, the
conclusion was to not create copies of existing code but rather add support
for decryption inside generic mpage_readpage[s] functions. Hence this patchset
implements the required decryption logic in the generic mpage_readpage[s]
functions. Since this makes the code in ext4/readpage.c redundant, I had
decided to delete the ext4/readpage.c.

-- 
chandan

  reply	other threads:[~2018-05-29  3:02 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-22 16:00 [RFC PATCH V3 00/12] Ext4 encryption support for blocksize < pagesize Chandan Rajendra
2018-05-22 16:00 ` [RFC PATCH V3 01/12] ext4: Clear BH_Uptodate flag on decryption error Chandan Rajendra
2018-05-22 16:01 ` [RFC PATCH V3 02/12] Rename fscrypt_do_page_crypto to fscrypt_do_block_crypto Chandan Rajendra
2018-05-22 16:01 ` [RFC PATCH V3 03/12] fscrypt_decrypt_page: Decrypt all blocks in a page Chandan Rajendra
2018-05-22 16:01 ` [RFC PATCH V3 04/12] __fscrypt_decrypt_bio: Fix page offset and len args to fscrypt_decrypt_page Chandan Rajendra
2018-05-22 16:01 ` [RFC PATCH V3 05/12] ext4: Decrypt all boundary blocks when doing buffered write Chandan Rajendra
2018-05-22 16:01 ` [RFC PATCH V3 06/12] ext4: Decrypt the block that needs to be partially zeroed Chandan Rajendra
2018-05-22 16:01 ` [RFC PATCH V3 07/12] mpage_readpage[s]: Introduce post process callback parameters Chandan Rajendra
2018-05-25 20:01   ` Theodore Y. Ts'o
2018-05-28  5:35     ` Chandan Rajendra
2018-05-28 19:34       ` Theodore Y. Ts'o
2018-05-29  3:04         ` Chandan Rajendra [this message]
2018-05-29 17:53           ` Eric Biggers
2018-05-30  3:09             ` Chandan Rajendra
2018-05-30  5:06               ` Theodore Y. Ts'o
2018-05-30 11:33                 ` Chandan Rajendra
2018-05-30 16:02                   ` Theodore Y. Ts'o
2018-06-04 10:09                 ` Chandan Rajendra
2018-05-22 16:01 ` [RFC PATCH V3 08/12] fscrypt_zeroout_range: Encrypt all zeroed out blocks of a page Chandan Rajendra
2018-05-22 16:01 ` [RFC PATCH V3 09/12] fscrypt_encrypt_page: Encrypt all blocks mapped by " Chandan Rajendra
2018-05-22 16:01 ` [RFC PATCH V3 10/12] ext4: Fix block number passed to fscrypt_encrypt_page Chandan Rajendra
2018-05-22 16:01 ` [RFC PATCH V3 11/12] ext4: Move encryption code into its own function Chandan Rajendra
2018-05-22 16:01 ` [RFC PATCH V3 12/12] ext4: Enable encryption for blocksize less than page size Chandan Rajendra

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=1832647.byIzkSnT1k@localhost.localdomain \
    --to=chandan@linux.vnet.ibm.com \
    --cc=ebiggers3@gmail.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-fscrypt@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=tytso@mit.edu \
    /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).