[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aYvzUihKhMfM6agz@casper.infradead.org>
Date: Wed, 11 Feb 2026 03:11:14 +0000
From: Matthew Wilcox <willy@...radead.org>
To: Joanne Koong <joannelkoong@...il.com>
Cc: Wei Gao <wegao@...e.com>, Sasha Levin <sashal@...nel.org>,
linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH 1/1] iomap: fix race between iomap_set_range_uptodate
and folio_end_read
On Tue, Feb 10, 2026 at 02:18:06PM -0800, Joanne Koong wrote:
> spin_lock_irqsave(&ifs->state_lock, flags);
> - uptodate = ifs_set_range_uptodate(folio, ifs, off, len);
> + /*
> + * If a read is in progress, we must NOT call
> folio_mark_uptodate.
> + * The read completion path (iomap_finish_folio_read or
> + * iomap_read_end) will call folio_end_read() which uses XOR
> + * semantics to set the uptodate bit. If we set it here, the XOR
> + * in folio_end_read() will clear it, leaving the folio not
> + * uptodate.
> + */
> + uptodate = ifs_set_range_uptodate(folio, ifs, off, len) &&
> + !ifs->read_bytes_pending;
> spin_unlock_irqrestore(&ifs->state_lock, flags);
This can't possibly be the right fix. There's some horrible confusion
here. It should not be possible to have read bytes pending _and_ the
entire folio be uptodate. That's an invariant that should always be
maintained.
Powered by blists - more mailing lists