linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@infradead.org>
To: Dave Chinner <david@fromorbit.com>
Cc: Andreas Gruenbacher <agruenba@redhat.com>,
	Christoph Hellwig <hch@infradead.org>,
	"Darrick J . Wong" <djwong@kernel.org>,
	Alexander Viro <viro@zeniv.linux.org.uk>,
	Matthew Wilcox <willy@infradead.org>,
	linux-xfs@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	linux-ext4@vger.kernel.org, cluster-devel@redhat.com
Subject: Re: [RFC v6 08/10] iomap/xfs: Eliminate the iomap_valid handler
Date: Tue, 10 Jan 2023 00:51:45 -0800	[thread overview]
Message-ID: <Y70nIXBagWukaRVk@infradead.org> (raw)
In-Reply-To: <20230108215911.GP1971568@dread.disaster.area>

On Mon, Jan 09, 2023 at 08:59:11AM +1100, Dave Chinner wrote:
> Indeed, we also have this same "iomap valid check" functionality in the
> writeback code as cached iomaps can become stale due to racing
> writeback, truncated, etc. But you wouldn't know it by looking at the iomap
> writeback code - this is currently hidden by XFS by embedding
> the checks into the iomap writeback ->map_blocks function.

And that's in many ways a good thing, as it avoids various callouts
that are expensive and confusing.  Just like how this patch gets it
right by not having a mess of badly interacting callbacks, but
one that ensures that the page is ready.

> Hence I think removing ->iomap_valid is a big step backwards for the
> iomap core code - the iomap core needs to be able to formally verify
> the iomap is valid at any point in time, not just at the point in
> time a folio in the page cache has been locked...

For using it anywhere else but the buffered write path it is in the
wrong place to start with, and nonwithstanding my above concern I
can't relaly think of a good place and prototype for such a valid
callback to actually cover all use cases.

  parent reply	other threads:[~2023-01-10  8:52 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-08 19:40 [RFC v6 00/10] Turn iomap_page_ops into iomap_folio_ops Andreas Gruenbacher
2023-01-08 19:40 ` [RFC v6 01/10] iomap: Add __iomap_put_folio helper Andreas Gruenbacher
2023-01-08 19:40 ` [RFC v6 02/10] iomap/gfs2: Unlock and put folio in page_done handler Andreas Gruenbacher
2023-01-08 19:40 ` [RFC v6 03/10] iomap: Rename page_done handler to put_folio Andreas Gruenbacher
2023-01-08 19:40 ` [RFC v6 04/10] iomap: Add iomap_get_folio helper Andreas Gruenbacher
2023-01-08 21:33   ` Dave Chinner
2023-01-09 12:46   ` Andreas Gruenbacher
2023-01-10  8:46     ` Christoph Hellwig
2023-01-10  9:07       ` Andreas Grünbacher
2023-01-10 13:34       ` Matthew Wilcox
2023-01-10 15:24         ` Christoph Hellwig
2023-01-11 19:36           ` Matthew Wilcox
2023-01-11 20:52             ` Dave Chinner
2023-01-12  8:41               ` Christoph Hellwig
2023-01-15 17:01         ` Darrick J. Wong
2023-01-15 17:06           ` Darrick J. Wong
2023-01-16  5:46             ` Matthew Wilcox
2023-01-16  7:34               ` Christoph Hellwig
2023-01-16 13:18                 ` Matthew Wilcox
2023-01-16 16:02                   ` Christoph Hellwig
2023-01-08 19:40 ` [RFC v6 05/10] iomap/gfs2: Get page in page_prepare handler Andreas Gruenbacher
2023-01-31 19:37   ` Matthew Wilcox
2023-01-31 21:33     ` Andreas Gruenbacher
2023-01-08 19:40 ` [RFC v6 06/10] iomap: Add __iomap_get_folio helper Andreas Gruenbacher
2023-01-10  8:48   ` Christoph Hellwig
2023-01-08 19:40 ` [RFC v6 07/10] iomap: Rename page_prepare handler to get_folio Andreas Gruenbacher
2023-01-08 19:40 ` [RFC v6 08/10] iomap/xfs: Eliminate the iomap_valid handler Andreas Gruenbacher
2023-01-08 21:59   ` Dave Chinner
2023-01-09 18:45     ` Andreas Gruenbacher
2023-01-09 22:54       ` Dave Chinner
2023-01-10  1:09         ` Andreas Grünbacher
2023-01-15 17:29           ` Darrick J. Wong
2023-01-18  7:21             ` Christoph Hellwig
2023-01-18  9:11               ` Damien Le Moal
2023-01-18 19:04               ` Darrick J. Wong
2023-01-18 19:57                 ` Andreas Grünbacher
2023-01-18 21:42             ` Dave Chinner
2023-01-10  8:51     ` Christoph Hellwig [this message]
2023-01-10  8:52   ` Christoph Hellwig
2023-01-08 19:40 ` [RFC v6 09/10] iomap: Rename page_ops to folio_ops Andreas Gruenbacher
2023-01-08 19:40 ` [RFC v6 10/10] xfs: Make xfs_iomap_folio_ops static Andreas Gruenbacher

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=Y70nIXBagWukaRVk@infradead.org \
    --to=hch@infradead.org \
    --cc=agruenba@redhat.com \
    --cc=cluster-devel@redhat.com \
    --cc=david@fromorbit.com \
    --cc=djwong@kernel.org \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-xfs@vger.kernel.org \
    --cc=viro@zeniv.linux.org.uk \
    --cc=willy@infradead.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).