All of lore.kernel.org
 help / color / mirror / Atom feed
From: Brian Foster <bfoster@redhat.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: linux-xfs@vger.kernel.org, linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH] iomap: support partial page discard on writeback block mapping failure
Date: Wed, 28 Oct 2020 07:32:00 -0400	[thread overview]
Message-ID: <20201028113200.GC1610972@bfoster> (raw)
In-Reply-To: <20201028073127.GA32068@infradead.org>

On Wed, Oct 28, 2020 at 07:31:27AM +0000, Christoph Hellwig wrote:
> >  	if (unlikely(error)) {
> > +		unsigned int	pageoff = offset_in_page(file_offset);
> > +		/*
> > +		 * Let the filesystem know what portion of the current page
> > +		 * failed to map. If the page wasn't been added to ioend, it
> > +		 * won't be affected by I/O completion and we must unlock it
> > +		 * now.
> > +		 */
> > +		if (wpc->ops->discard_page)
> > +			wpc->ops->discard_page(page, pageoff);
> 
> I don't think we need the pageoff variable here.   Also it would
> seem more natural to pass the full file_offset offset instead of
> having to recreate it in the file system.
> 

I used the variable just to avoid having to split the function call into
multiple lines. I.e., it just looked more readable to me than:

               if (wpc->ops->discard_page)
                        wpc->ops->discard_page(page,
                                               offset_in_page(file_offset));

I can change it back if that is preferred (or possibly use a function
pointer variable instead). I suppose that's also avoided by passing
file_offset directly, but that seems a little odd to me for a page
oriented callback.

Brian


  reply	other threads:[~2020-10-29  2:44 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-26 18:20 [PATCH] iomap: support partial page discard on writeback block mapping failure Brian Foster
2020-10-27 16:47 ` Brian Foster
2020-10-28  7:31 ` Christoph Hellwig
2020-10-28 11:32   ` Brian Foster [this message]
2020-10-28 14:04     ` Christoph Hellwig
2020-10-28 14:15       ` Brian Foster

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=20201028113200.GC1610972@bfoster \
    --to=bfoster@redhat.com \
    --cc=hch@infradead.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-xfs@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.