All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chandan Rajendra <chandan@linux.vnet.ibm.com>
To: Eric Biggers <ebiggers3@gmail.com>
Cc: linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	linux-fscrypt@vger.kernel.org, tytso@mit.edu
Subject: Re: [RFC PATCH V2 05/11] ext4: Decrypt all boundary blocks when doing buffered write
Date: Wed, 21 Feb 2018 15:27:18 +0530	[thread overview]
Message-ID: <11341004.sBrkMnv4Fk@localhost.localdomain> (raw)
In-Reply-To: <20180221010155.GC252219@gmail.com>

On Wednesday, February 21, 2018 6:31:55 AM IST Eric Biggers wrote:
> Hi Chandan,
> 
> On Mon, Feb 12, 2018 at 03:13:41PM +0530, Chandan Rajendra wrote:
> > With block size < page size, ext4_block_write_begin() can have up to two
> > blocks to decrypt. Hence this commit invokes fscrypt_decrypt_block() for
> > each of those blocks.
> > 
> > Signed-off-by: Chandan Rajendra <chandan@linux.vnet.ibm.com>
> > ---
> >  fs/ext4/inode.c | 33 +++++++++++++++++++++++----------
> >  1 file changed, 23 insertions(+), 10 deletions(-)
> > 
> > diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
> > index 69a4fd6..180dd2d 100644
> > --- a/fs/ext4/inode.c
> > +++ b/fs/ext4/inode.c
> > @@ -1158,12 +1158,13 @@ static int ext4_block_write_begin(struct page *page, loff_t pos, unsigned len,
> >  	unsigned to = from + len;
> >  	struct inode *inode = page->mapping->host;
> >  	unsigned block_start, block_end;
> > -	sector_t block;
> > +	sector_t block, page_blk_nr;
> >  	int err = 0;
> >  	unsigned blocksize = inode->i_sb->s_blocksize;
> >  	unsigned bbits;
> >  	struct buffer_head *bh, *head, *wait[2], **wait_bh = wait;
> >  	bool decrypt = false;
> > +	int i;
> >  
> >  	BUG_ON(!PageLocked(page));
> >  	BUG_ON(from > PAGE_SIZE);
> > @@ -1224,18 +1225,30 @@ static int ext4_block_write_begin(struct page *page, loff_t pos, unsigned len,
> >  	/*
> >  	 * If we issued read requests, let them complete.
> >  	 */
> > -	while (wait_bh > wait) {
> > -		wait_on_buffer(*--wait_bh);
> > -		if (!buffer_uptodate(*wait_bh))
> > +	for (i = 0; &wait[i] < wait_bh; i++) {
> > +		wait_on_buffer(wait[i]);
> > +		if (!buffer_uptodate(wait[i]))
> >  			err = -EIO;
> > 	}
> 
> [...]
> 
> > +		for (i = 0; &wait[i] < wait_bh; i++) {
> > +			int err2;
> > +
> > +			--wait_bh;
> > +			block = page_blk_nr + (bh_offset(wait[i]) >> bbits);
> > +			err2 = fscrypt_decrypt_block(page->mapping->host, page,
> > +						wait[i]->b_size,
> > +						bh_offset(wait[i]),
> > +						block);
> > +			if (err2) {
> > +				clear_buffer_uptodate(wait[i]);
> > +				err = err2;
> > +			}
> > +		}
> 
> These are very confusing ways to iterate through an array, especially the second
> loop which is actually going in reverse order (why?).  Why not just use a
> variable like 'nr_wait' for the number of valid buffer_head's like I had
> suggested?  Then you can just do 'for (i = 0; i < nr_wait; i++)'.
> 

Sorry, the "--wait_bh;" part was a remanent from the "RFC PATCH V1". Without
that statement, we loop in increasing order of elements in wait[] array. I
will use the 'nr_wait' counter approach and post the next version of the
patchset.  I misunderstood your advice to mean that the code should use
similar looping order in both loops.

-- 
chandan

  reply	other threads:[~2018-02-21  9:57 UTC|newest]

Thread overview: 32+ 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 [this message]
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
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-12  9:43   ` 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=11341004.sBrkMnv4Fk@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.