All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matthew Bobrowski <mbobrowski@mbobrowski.org>
To: Jan Kara <jack@suse.cz>
Cc: "Darrick J. Wong" <darrick.wong@oracle.com>,
	Christoph Hellwig <hch@infradead.org>,
	linux-fsdevel@vger.kernel.org, Eric Biggers <ebiggers@kernel.org>
Subject: Re: [PATCH] iomap: Do not create fake iter in iomap_dio_bio_actor()
Date: Tue, 26 Nov 2019 08:11:50 +1100	[thread overview]
Message-ID: <20191125211149.GC3748@bobrowski> (raw)
In-Reply-To: <20191125111901.11910-1-jack@suse.cz>

On Mon, Nov 25, 2019 at 12:18:57PM +0100, Jan Kara wrote:
> iomap_dio_bio_actor() copies iter to a local variable and then limits it
> to a file extent we have mapped. When IO is submitted,
> iomap_dio_bio_actor() advances the original iter while the copied iter
> is advanced inside bio_iov_iter_get_pages(). This logic is non-obvious
> especially because both iters still point to same shared structures
> (such as pipe info) so if iov_iter_advance() changes anything in the
> shared structure, this scheme breaks. Let's just truncate and reexpand
> the original iter as needed instead of playing games with copying iters
> and keeping them in sync.

Looks good. Just one minor nit below which is eating me. I guess
Darrick can fix it up when applying it to his tree, if deemed
necessary to fix up.

Feel free to add:

Reviewed-by: Matthew Bobrowski <mbobrowski@mbobrowski.org>

>  	/*
> -	 * Operate on a partial iter trimmed to the extent we were called for.
> -	 * We'll update the iter in the dio once we're done with this extent.
> +	 * Save the original count and trim the iter to just the extent we
> +	 * are operating on right now.  The iter will be re-expanded once
  	       		    	      ^^
				      Extra whitespace here.

IMO, I think we can word the last sentence a little better too i.e.

/*                                                                               
 * Save the original count and trim the iter to the extent that we're            
 * currently operating on right now. The iter will then again be                 
 * expanded out once we're done.                                                 
 */

/M

  parent reply	other threads:[~2019-11-25 21:11 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-25 11:18 [PATCH 0/2 v2] iomap: Cleanup of iomap_dio_rw() Jan Kara
2019-11-25 11:18 ` [PATCH] iomap: Do not create fake iter in iomap_dio_bio_actor() Jan Kara
2019-11-25 17:53   ` Christoph Hellwig
2019-11-25 21:11   ` Matthew Bobrowski [this message]
2019-11-26 15:12     ` Matthew Wilcox
2019-11-26 21:47       ` Matthew Bobrowski
2019-11-26 16:31   ` Christoph Hellwig
2019-11-26 17:47   ` Darrick J. Wong

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=20191125211149.GC3748@bobrowski \
    --to=mbobrowski@mbobrowski.org \
    --cc=darrick.wong@oracle.com \
    --cc=ebiggers@kernel.org \
    --cc=hch@infradead.org \
    --cc=jack@suse.cz \
    --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 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.