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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox