Re: O_DIRECT vs BLK_FEAT_STABLE_WRITES, was Re: [PATCH] btrfs: never trust the bio from direct IO

On Tue 21-10-25 11:37:57, David Hildenbrand wrote:

On 21.10.25 11:22, Jan Kara wrote:

quoted

On Tue 21-10-25 00:49:49, Christoph Hellwig wrote:

quoted

On Mon, Oct 20, 2025 at 09:00:50PM +0200, David Hildenbrand wrote:

quoted

Just FYI, because it might be interesting in this context.

For anonymous memory we have this working by only writing the folio out if
it is completely unmapped and there are no unexpected folio references/pins
(see pageout()), and only allowing to write to such a folio ("reuse") if
SWP_STABLE_WRITES is not set (see do_swap_page()).

So once we start writeback the folio has no writable page table mappings
(unmapped) and no GUP pins. Consequently, when trying to write to it we can
just fallback to creating a page copy without causing trouble with GUP pins.

Yeah.  But anonymous is the easy case, the pain is direct I/O to file
mappings.  Mapping the right answer is to just fail pinning them and fall
back to (dontcache) buffered I/O.

I agree file mappings are more painful but we can also have interesting
cases with anon pages:

P - anon page

Thread 1				Thread 2
setup DIO read to P			setup DIO write from P

Ah, I was talking about the interaction between GUP and having
BLK_FEAT_STABLE_WRITES set on the swap backend.

I guess what you mean here is: GUP from/to anon pages to/from a device that
has BLK_FEAT_STABLE_WRITES?

Correct.

So while we are writing to the device using the anon page as a source, the
anon page will get modified.

I did not expect that to trigger checksum failures, but I can see the
problem now.

Sadly it can because the checksum computation may end up using different
data than the DMA will send to the device a bit later. After all this is
why BLK_FEAT_STABLE_WRITES was invented...

								Honza
-- 
Jan Kara [off-list ref]
SUSE Labs, CR