From: Christoph Hellwig <hch@lst.de>
To: Dave Chinner <david@fromorbit.com>
Cc: Christoph Hellwig <hch@lst.de>,
linux-xfs@vger.kernel.org, linux-fsdevel@vger.kernel.org,
linux-mm@kvack.org
Subject: Re: [PATCH 11/13] iomap: add an iomap-based readpage and readpages implementation
Date: Thu, 31 May 2018 08:13:15 +0200 [thread overview]
Message-ID: <20180531061315.GB31350@lst.de> (raw)
In-Reply-To: <20180530234557.GI10363@dastard>
On Thu, May 31, 2018 at 09:45:57AM +1000, Dave Chinner wrote:
> sentence ends with a ".". :)
Ok. This was intended to point to the WARN_ON calls below, but a "."
is fine with me, too.
>
> > + WARN_ON_ONCE(pos != page_offset(page));
> > + WARN_ON_ONCE(plen != PAGE_SIZE);
> > +
> > + if (iomap->type != IOMAP_MAPPED || pos >= i_size_read(inode)) {
>
> In what situation do we get a read request completely beyond EOF?
> (comment, please!)
This is generally to cover a racing read beyond EOF. That being said
I'd have to look up if it can really happen for blocksize == pagesize.
All this becomes moot once small block size support is added, so I think
I'd rather skip the comment and research here for now.
> > + if (ctx.bio) {
> > + submit_bio(ctx.bio);
> > + WARN_ON_ONCE(!ctx.cur_page_in_bio);
> > + } else {
> > + WARN_ON_ONCE(ctx.cur_page_in_bio);
> > + unlock_page(page);
> > + }
> > + return 0;
>
> Hmmm. If we had an error from iomap_apply, shouldn't we be returning
> it here instead just throwing it away? some ->readpage callers
> appear to ignore the PageError() state on return but do expect
> errors to be returned.
Both mpage_readpage and block_read_full_page always return 0, so for
now I'd like to stay compatible to them. Might be worth a full audit
later.
> > + loff_t pos = page_offset(list_entry(pages->prev, struct page, lru));
> > + loff_t last = page_offset(list_entry(pages->next, struct page, lru));
> > + loff_t length = last - pos + PAGE_SIZE, ret = 0;
>
> Two lines, please.
I really like it that way, though..
> > +done:
> > + if (ctx.bio)
> > + submit_bio(ctx.bio);
> > + if (ctx.cur_page) {
> > + if (!ctx.cur_page_in_bio)
> > + unlock_page(ctx.cur_page);
> > + put_page(ctx.cur_page);
> > + }
> > + WARN_ON_ONCE(!ret && !list_empty(ctx.pages));
>
> What error condition is this warning about?
Not finishing all pages without an error. Which wasn't too hard to get
wrong given the arance readpages calling convention.
next prev parent reply other threads:[~2018-05-31 6:06 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-30 9:58 iomap based buffered reads & iomap cleanups v4 Christoph Hellwig
2018-05-30 9:58 ` [PATCH 01/13] block: add a lower-level bio_add_page interface Christoph Hellwig
2018-05-30 10:12 ` Ming Lei
2018-05-30 9:58 ` [PATCH 02/13] mm: give the 'ret' variable a better name __do_page_cache_readahead Christoph Hellwig
2018-05-30 23:01 ` Dave Chinner
2018-05-30 9:58 ` [PATCH 03/13] mm: return an unsigned int from __do_page_cache_readahead Christoph Hellwig
2018-05-30 23:02 ` Dave Chinner
2018-05-30 9:58 ` [PATCH 04/13] mm: split ->readpages calls to avoid non-contiguous pages lists Christoph Hellwig
2018-05-30 23:02 ` Dave Chinner
2018-05-30 9:58 ` [PATCH 05/13] iomap: inline data should be an iomap type, not a flag Christoph Hellwig
2018-05-30 23:05 ` Dave Chinner
2018-05-30 9:58 ` [PATCH 06/13] iomap: fix the comment describing IOMAP_NOWAIT Christoph Hellwig
2018-05-30 23:05 ` Dave Chinner
2018-05-30 9:58 ` [PATCH 07/13] iomap: move IOMAP_F_BOUNDARY to gfs2 Christoph Hellwig
2018-05-30 23:08 ` Dave Chinner
2018-05-30 9:58 ` [PATCH 08/13] iomap: use __bio_add_page in iomap_dio_zero Christoph Hellwig
2018-05-30 23:09 ` Dave Chinner
2018-05-30 9:58 ` [PATCH 09/13] iomap: add a iomap_sector helper Christoph Hellwig
2018-05-30 23:10 ` Dave Chinner
2018-05-30 9:58 ` [PATCH 10/13] iomap: add an iomap-based bmap implementation Christoph Hellwig
2018-05-30 23:11 ` Dave Chinner
2018-05-31 6:07 ` Christoph Hellwig
2018-05-30 9:58 ` [PATCH 11/13] iomap: add an iomap-based readpage and readpages implementation Christoph Hellwig
2018-05-30 16:22 ` Darrick J. Wong
2018-05-30 23:45 ` Dave Chinner
2018-05-31 6:13 ` Christoph Hellwig [this message]
2018-05-31 11:59 ` Dave Chinner
2018-05-30 9:58 ` [PATCH 12/13] xfs: use iomap_bmap Christoph Hellwig
2018-05-30 23:46 ` Dave Chinner
2018-05-30 9:58 ` [PATCH 13/13] xfs: use iomap for blocksize == PAGE_SIZE readpage and readpages Christoph Hellwig
2018-05-30 23:47 ` Dave Chinner
-- strict thread matches above, loose matches on Subject: below --
2018-05-31 18:06 iomap based buffered reads & iomap cleanups v5 Christoph Hellwig
2018-05-31 18:06 ` [PATCH 11/13] iomap: add an iomap-based readpage and readpages implementation Christoph Hellwig
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=20180531061315.GB31350@lst.de \
--to=hch@lst.de \
--cc=david@fromorbit.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-mm@kvack.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 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).