linux-kernel - Re: Known and unfixed active data loss bug in MM + XFS with large folios since Dec 2021 (any kernel from 6.1 upwards)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <ZvsQmJM2q7zMf69e@casper.infradead.org>
Date: Mon, 30 Sep 2024 21:56:56 +0100
From: Matthew Wilcox <willy@...radead.org>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Christian Theune <ct@...ingcircus.io>,
	Dave Chinner <david@...morbit.com>, Chris Mason <clm@...a.com>,
	Jens Axboe <axboe@...nel.dk>, linux-mm@...ck.org,
	"linux-xfs@...r.kernel.org" <linux-xfs@...r.kernel.org>,
	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
	Daniel Dao <dqminh@...udflare.com>, regressions@...ts.linux.dev,
	regressions@...mhuis.info
Subject: Re: Known and unfixed active data loss bug in MM + XFS with large
 folios since Dec 2021 (any kernel from 6.1 upwards)

On Mon, Sep 30, 2024 at 01:12:37PM -0700, Linus Torvalds wrote:
> It's basically been that way forever. The code has changed many times,
> but we've basically always had that "wait on bit will wait not until
> the next wakeup, but until it actually sees the bit being clear".
> 
> And by "always" I mean "going back at least to before the git tree". I
> didn't search further. It's not new.
> 
> The only reason I pointed at that (relatively recent) commit from 2021
> is that when we rewrote the page bit waiting logic (for some unrelated
> horrendous scalability issues with tens of thousands of pages on wait
> queues), the rewritten code _tried_ to not do it, and instead go "we
> were woken up by a bit clear op, so now we've waited enough".
> 
> And that then caused problems as explained in that commit c2407cf7d22d
> ("mm: make wait_on_page_writeback() wait for multiple pending
> writebacks") because the wakeups aren't atomic wrt the actual bit
> setting/clearing/testing.

Could we break out if folio->mapping has changed?  Clearly if it has,
we're no longer waiting for the folio we thought we were waiting for,
but for a folio which now belongs to a different file.

maybe this:

+void __folio_wait_writeback(struct address_space *mapping, struct folio *folio)
+{
+       while (folio_test_writeback(folio) && folio->mapping == mapping) {
+               trace_folio_wait_writeback(folio, mapping);
+               folio_wait_bit(folio, PG_writeback);
+       }
+}

[...]

 void folio_wait_writeback(struct folio *folio)
 {
-       while (folio_test_writeback(folio)) {
-               trace_folio_wait_writeback(folio, folio_mapping(folio));
-               folio_wait_bit(folio, PG_writeback);
-       }
+       __folio_wait_writeback(folio->mapping, folio);
 }