All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Pankaj Raghav (Samsung)" <pankaj.raghav@linux.dev>
To: Ojaswin Mujoo <ojaswin@linux.ibm.com>
Cc: Christian Brauner <brauner@kernel.org>,
	linux-fsdevel@vger.kernel.org,
	 "Darrick J . Wong" <djwong@kernel.org>,
	Carlos Maiolino <cem@kernel.org>,
	 Alexander Viro <viro@zeniv.linux.org.uk>,
	Jan Kara <jack@suse.cz>, Matthew Wilcox <willy@infradead.org>,
	 Andrew Morton <akpm@linux-foundation.org>,
	Ritesh Harjani <ritesh.list@gmail.com>,
	 Zhang Yi <yi.zhang@huawei.com>, Christoph Hellwig <hch@lst.de>,
	 Dave Chinner <dchinner@redhat.com>,
	Daniel Gomez <da.gomez@kernel.org>, Theodore Tso <tytso@mit.edu>,
	 linux-xfs@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-mm@kvack.org,  Andres Freund <andres@anarazel.de>,
	Dave Chinner <dgc@kernel.org>
Subject: Re: [RFC PATCH v4 05/12] iomap: Add initial support for buffered RWF_WRITETHROUGH
Date: Thu, 15 Oct 2026 16:09:50 +0200	[thread overview]
Message-ID: <as-BQAbk7U43vkqs@quentin> (raw)
In-Reply-To: <c76f9babf1b00f4574e37db156621edc6c078969.1790596383.git.ojaswin@linux.ibm.com>

Hi Ojaswin,

I was comparing normal buffered IO scenario and writethrough.

In a normal buffered IO scenario, for unwritten extents or CoW extents,
we first convert them before ending the writeback on the folio.
xfs_end_io calls xfs_end_ioend_write().

static void
xfs_end_ioend_write(
        struct iomap_ioend      *ioend)
{
<snip>
       /*
         * Success: commit the COW or unwritten blocks if needed.
         */
        if (is_zoned)
                error = xfs_zoned_end_io(ip, offset, size, ioend->io_sector,
                                ioend->io_private, NULLFSBLOCK);
        else if (ioend->io_flags & IOMAP_IOEND_SHARED)
                error = xfs_reflink_end_cow(ip, offset, size);
        else if (ioend->io_flags & IOMAP_IOEND_UNWRITTEN)
                error = xfs_iomap_write_unwritten(ip, offset, size, false);

        if (!error &&
            !(ioend->io_flags & IOMAP_IOEND_DIRECT) &&
            xfs_ioend_is_append(ioend))
                error = xfs_setfilesize(ip, offset, size);
done:
        if (is_zoned)
                xfs_ioend_put_open_zones(ioend);
        iomap_finish_ioends(ioend, error); // #1
        memalloc_nofs_restore(nofs_flag);
}

#1
iomap_finish_ioends()
  iomap_finish_ioend_buffered_write()
    iomap_finish_folio_write()
      folio_end_writeback()


On Mon, Sep 28, 2026 at 05:33:06PM +0530, Ojaswin Mujoo wrote:
> @@ -1185,6 +1186,384 @@ static bool iomap_write_end(struct iomap_iter *iter, size_t len, size_t copied,
>  	return __iomap_write_end(iter->inode, pos, len, copied, folio);
>  }
>  
> +static ssize_t iomap_writethrough_complete(struct iomap_writethrough_ctx *wt_ctx)
> +{
> +	struct kiocb *iocb	= wt_ctx->iocb;
> +	struct inode *inode	= wt_ctx->inode;
> +	ssize_t ret		= wt_ctx->error;
> +
> +	if (wt_ctx->end_io) {
> +		int err = wt_ctx->end_io(wt_ctx, wt_ctx->written,
> +					 wt_ctx->error,
> +					 wt_ctx->flags);
> +		if (err)
> +			ret = err;
> +	}
> +

<snip>

> +static void iomap_writethrough_bio_end_io(struct bio *bio)
> +{
> +	struct iomap_writethrough_ctx *wt_ctx = bio->bi_private;
> +	struct folio_iter fi;
> +
> +	if (bio->bi_status)
> +		cmpxchg(&wt_ctx->error, 0,
> +			blk_status_to_errno(bio->bi_status));
> +	bio_for_each_folio_all(fi, bio)
> +		folio_end_writeback(fi.folio);
> +
> +	bio_put(bio);
> +	if (atomic_dec_and_test(&wt_ctx->ref))
> +		iomap_writethrough_done(wt_ctx);
> +}
> +

But in the writethrough patches, we first end the writeback on the folio
and then call xfs_dio_write_end_io(), which converts unwritten or CoW
extents.

Is there a race possible as we are doing the other way? What if folios
are reclaimed between ending the writeback and conversion? A new read in
that area will return zero filled folios as XFS still sees IOMAP_UNWRITTEN?

I don't have a reproducer, but my hunch says we can run into this if we
have a lot of AIO as the end_io will be run via a workqueue?

Do we do something similar to buffered IO where we do
folio_end_writeback after extents conversion?

--
Pankaj

  parent reply	other threads:[~2026-10-15 14:10 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-28 12:03 [RFC PATCH v4 00/13] Add RWF_WRITETHROUGH support to iomap & xfs Ojaswin Mujoo
2026-09-28 12:03 ` [RFC PATCH v4 01/12] xfs: reexpand iter to original count when upgrading to excl ILOCK Ojaswin Mujoo
2026-09-28 12:03 ` [RFC PATCH v4 02/12] fs: Add counter to track inflight writes that need stable pages Ojaswin Mujoo
2026-09-28 12:03 ` [RFC PATCH v4 03/12] mm: Refactor folio_clear_dirty_for_io() Ojaswin Mujoo
2026-09-28 12:03 ` [RFC PATCH v4 04/12] iomap: Add helper to revert iomap iter Ojaswin Mujoo
2026-09-28 12:03 ` [RFC PATCH v4 05/12] iomap: Add initial support for buffered RWF_WRITETHROUGH Ojaswin Mujoo
2026-10-07  9:32   ` Pankaj Raghav (Samsung)
2026-10-07 14:04     ` Ojaswin Mujoo
2026-10-15 14:09   ` Pankaj Raghav (Samsung) [this message]
2026-09-28 12:03 ` [RFC PATCH v4 06/12] xfs: Add RWF_WRITETHROUGH support to xfs Ojaswin Mujoo
2026-09-28 12:03 ` [RFC PATCH v4 07/12] iomap: Add aio support to RWF_WRITETHROUGH Ojaswin Mujoo
2026-09-28 12:03 ` [RFC PATCH v4 08/12] iomap: Add DSYNC " Ojaswin Mujoo
2026-09-29 14:00   ` Ojaswin Mujoo
2026-09-28 12:03 ` [RFC PATCH v4 09/12] fs: Introduce RWF_NOSERIAL flag to indicate parallel reads/writes Ojaswin Mujoo
2026-09-28 12:03 ` [RFC PATCH v4 10/12] xfs: Implement RWF_NOSERIAL to parallelize RWF_WRITETHROUGH writes Ojaswin Mujoo
2026-09-28 12:03 ` [RFC PATCH v4 11/12] iomap: Avoid folio dirtying in case of RWF_WRITETHROUGH Ojaswin Mujoo
2026-09-28 12:03 ` [RFC PATCH v4 12/12] iomap: Handle deadlock due to repeating folios in RWF_WRITETHROUGH Ojaswin Mujoo
2026-10-13  8:40   ` Pankaj Raghav (Samsung)

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=as-BQAbk7U43vkqs@quentin \
    --to=pankaj.raghav@linux.dev \
    --cc=akpm@linux-foundation.org \
    --cc=andres@anarazel.de \
    --cc=brauner@kernel.org \
    --cc=cem@kernel.org \
    --cc=da.gomez@kernel.org \
    --cc=dchinner@redhat.com \
    --cc=dgc@kernel.org \
    --cc=djwong@kernel.org \
    --cc=hch@lst.de \
    --cc=jack@suse.cz \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-xfs@vger.kernel.org \
    --cc=ojaswin@linux.ibm.com \
    --cc=ritesh.list@gmail.com \
    --cc=tytso@mit.edu \
    --cc=viro@zeniv.linux.org.uk \
    --cc=willy@infradead.org \
    --cc=yi.zhang@huawei.com \
    /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.