linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Theodore Y. Ts'o" <tytso@mit.edu>
To: Chandan Rajendra <chandan@linux.vnet.ibm.com>
Cc: Eric Biggers <ebiggers3@gmail.com>,
	linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	linux-fscrypt@vger.kernel.org
Subject: Re: [RFC PATCH V2 07/11] fscrypt_zeroout_range: Encrypt all zeroed out blocks of a page
Date: Thu, 5 Apr 2018 08:47:45 -0400	[thread overview]
Message-ID: <20180405124745.GA20556@thunk.org> (raw)
In-Reply-To: <3388885.zk0F4oSU7q@localhost.localdomain>

On Thu, Apr 05, 2018 at 12:33:26PM +0530, Chandan Rajendra wrote:
> 
> I encountered a problem when refactoring the code to get fscrypt layer to
> encrypt all the blocks of a page by internally calling
> fscrypt_encrypt_block().
> 
> It is the filesystem which knows which subset of blocks mapped by a page that
> needs to be encrypted.

That's not quite correct.  All blocks in a file are either always
encrypted, or not.  So that's not really the problem.

> For example, ext4_bio_write_page() marks such blocks
> with "Async Write" flag and later in another pass, it encrypts and also adds
> these blocks to a bio.

The tricky bits with ext4_bio_write_page() all are in handling the
case where page_size > block_size.  In that case, where there are multiple
file system blocks covering a page, we need to know the on-disk
block numbers are for the blocks covering the page, and the encryption
is intertwined with the I/O submission path, which is file system
specific -- mainly because how the completion callback and the
parameters which need to be passed *into* the the callback function is
file system specific.

However, none of that is needed or relevant to the encryption
operation.  It's an accident of code development history that
fscrypt_encrypt_page was placed where it was.

That is, none of work done in the first pass (starting with the
comment "In the first loop we prepare and mark buffers to submit....")
is needed to be done before we call fscrypt_encrypt_page().  That call:

	data_page = fscrypt_encrypt_page(inode, page, PAGE_SIZE, 0,
					page->index, gfp_flags);

... could easily be moved to the beginning of ext4_bio_write_page().

I can do that to make the function easier to understand, but that
particular cleanup is merely cosmetic.  It doesn't what you would need
to do order to make fscrypt_encrypt_page() iterate over the page as it
calls fscrypt_encrypt_buffer().

Regards,

						- Ted

  reply	other threads:[~2018-04-05 12:47 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-12  9:43 [RFC PATCH V2 00/11] Ext4 encryption support for blocksize < pagesize Chandan Rajendra
2018-02-12  9:43 ` [RFC PATCH V2 01/11] ext4: Clear BH_Uptodate flag on decryption error Chandan Rajendra
2018-02-12  9:43 ` [RFC PATCH V2 02/11] fs/buffer.c: Export end_buffer_async_read and create_page_buffers Chandan Rajendra
2018-02-12  9:43 ` [RFC PATCH V2 03/11] fs/crypto/: Rename functions to indicate that they operate on FS blocks Chandan Rajendra
2018-02-12  9:43 ` [RFC PATCH V2 04/11] completion_pages: Decrypt all contiguous blocks in a page Chandan Rajendra
2018-02-12  9:43 ` [RFC PATCH V2 05/11] ext4: Decrypt all boundary blocks when doing buffered write Chandan Rajendra
2018-02-21  1:01   ` Eric Biggers
2018-02-21  9:57     ` Chandan Rajendra
2018-02-12  9:43 ` [RFC PATCH V2 06/11] ext4: Decrypt the block that needs to be partially zeroed Chandan Rajendra
2018-02-12  9:43 ` [RFC PATCH V2 07/11] fscrypt_zeroout_range: Encrypt all zeroed out blocks of a page Chandan Rajendra
2018-02-21  1:16   ` Eric Biggers
2018-02-21  9:57     ` Chandan Rajendra
2018-03-26  6:05       ` Theodore Y. Ts'o
2018-03-26  8:22         ` Chandan Rajendra
2018-03-27 19:40           ` Theodore Y. Ts'o
2018-03-28 13:36             ` Chandan Rajendra
2018-04-05  7:03             ` Chandan Rajendra
2018-04-05 12:47               ` Theodore Y. Ts'o [this message]
2018-04-05 13:07                 ` Chandan Rajendra
2018-04-05 20:50                   ` Theodore Y. Ts'o
2018-02-12  9:43 ` [RFC PATCH V2 08/11] Enable reading encrypted files in blocksize less than pagesize setup Chandan Rajendra
2018-02-12  9:43 ` [RFC PATCH V2 09/11] fscrypt: Move completion_pages to crypto/readpage.c Chandan Rajendra
2018-02-12  9:43 ` [RFC PATCH V2 10/11] Enable writing encrypted files in blocksize less than pagesize setup Chandan Rajendra
2018-02-21  0:54   ` Eric Biggers
2018-02-21  9:57     ` Chandan Rajendra
2018-02-21 18:53       ` Eric Biggers
2018-02-12  9:43 ` [RFC PATCH V2 11/11] ext4: Enable encryption for blocksize less than page size Chandan Rajendra
2018-02-21  0:48 ` [RFC PATCH V2 00/11] Ext4 encryption support for blocksize < pagesize Eric Biggers
2018-02-21  9:57   ` Chandan Rajendra
2018-02-21 19:06     ` Eric Biggers
2018-02-22  8:50       ` 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=20180405124745.GA20556@thunk.org \
    --to=tytso@mit.edu \
    --cc=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 \
    /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).