From: Christoph Hellwig <hch@infradead.org>
To: Joanne Koong <joannelkoong@gmail.com>
Cc: brauner@kernel.org, bfoster@redhat.com, hch@infradead.org,
djwong@kernel.org, linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH] iomap: fix race when reading in all bytes of a folio
Date: Mon, 27 Oct 2025 00:02:23 -0700 [thread overview]
Message-ID: <aP8Y_xT94THF-ZeL@infradead.org> (raw)
In-Reply-To: <20251024215008.3844068-1-joannelkoong@gmail.com>
On Fri, Oct 24, 2025 at 02:50:08PM -0700, Joanne Koong wrote:
> There is a race where if all bytes in a folio need to get read in and
> the filesystem finishes reading the bytes in before the call to
> iomap_read_end(), then bytes_accounted in iomap_read_end() will be 0 and
> the following "ifs->read_bytes_pending -= bytes_accounting" will also be
> 0 which will trigger an extra folio_end_read() call. This extra
> folio_end_read() unlocks the folio for the 2nd time, which sets the lock
> bit on the folio, resulting in a permanent lockup.
>
> Fix this by returning from iomap_read_end() early if all bytes are read
> in by the filesystem.
>
> Additionally, add some comments to clarify how this accounting logic works.
>
> Signed-off-by: Joanne Koong <joannelkoong@gmail.com>
> Fixes: 51311f045375 ("iomap: track pending read bytes more optimally")
> Reported-by: Brian Foster <bfoster@redhat.com>
Looks good:
Reviewed-by: Christoph Hellwig <hch@lst.de>
> This is a fix for commit 51311f045375 in the 'vfs-6.19.iomap' branch. It
> would be great if this could get folded up into that original commit, if it's
> not too logistically messy to do so.
Agreed!
next prev parent reply other threads:[~2025-10-27 7:02 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-24 21:50 [PATCH] iomap: fix race when reading in all bytes of a folio Joanne Koong
2025-10-27 7:02 ` Christoph Hellwig [this message]
2025-10-27 12:20 ` Brian Foster
2025-10-27 16:43 ` Joanne Koong
2025-10-28 11:20 ` Brian Foster
2025-10-28 17:11 ` Joanne Koong
2025-10-28 17:31 ` Joanne Koong
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=aP8Y_xT94THF-ZeL@infradead.org \
--to=hch@infradead.org \
--cc=bfoster@redhat.com \
--cc=brauner@kernel.org \
--cc=djwong@kernel.org \
--cc=joannelkoong@gmail.com \
--cc=linux-fsdevel@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 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.