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>
Subject: Re: [RFC PATCH v4 12/12] iomap: Handle deadlock due to repeating folios in RWF_WRITETHROUGH
Date: Tue, 13 Oct 2026 10:40:32 +0200 [thread overview]
Message-ID: <as3t7j3P3mQhsr7p@quentin> (raw)
In-Reply-To: <5159efdec832e8179e9f689a9292f9bf47d9a0fa.1790596383.git.ojaswin@linux.ibm.com>
On Mon, Sep 28, 2026 at 05:33:13PM +0530, Ojaswin Mujoo wrote:
> In iomap_writethrough_iter() we might encounter repeating folios across
> multiple iterations. Repeating folios can occur if, example,
> copy_folio_from_iter_atomic() does a short copy due to userspace pages
> not faulted in. This is an issue because a previous loop might have
> started writeback on them but not yet issued the IO. In the next
> iteration trying to get the same folio with FGP_STABLE will result in a
> deadlock. Since repeating folios will always be encountered back to
> back, we can just use a simple cur != prev check to detect them.
>
> Use this to avoid waiting for writeback or starting writeback on folios
> we have already processed. Note that in ->endio() we might end up
> calling folio_end_writethrough() twice on the same folio which can cause
> issues with folio_xor_flags_has_waiters(). For simplicity, just change
> the folio_xor_flags_has_waiters() call to an idempotent variant.
Is this an outdated comment?
>
> Reported-by: Pankaj Raghav <pankaj.raghav@linux.dev>
Thanks for fixing it. I think I was able to trigger this in a VM with
limited memory where the chances of short copy is probably higher. The
fixes makes sense to me.
I will run some tests this week and report back if there is an issue.
--
Pankaj
prev parent reply other threads:[~2026-10-13 8:40 UTC|newest]
Thread overview: 17+ 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-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) [this message]
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=as3t7j3P3mQhsr7p@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=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.