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

On 21.10.25 11:33, Jan Kara wrote:

On Tue 21-10-25 09:57:08, David Hildenbrand wrote:

quoted

On 21.10.25 09: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.

Right, I think the rules could likely be

a) Don't start writeback to such devices if there may be GUP pins (o
writeble PTEs)

b) Don't allow FOLL_WRITE GUP pins if there is writeback to such a device

Regarding b), I would have thought that GUP would find the PTE to not be
writable and consequently trigger a page fault first to make it writable?
And I'd have thought that we cannot make such a PTE writable while there is
writeback to such a device going on (otherwise the CPU could just cause
trouble).

See some of the cases in my reply to Christoph. It is also stuff like:

c) Don't allow FOLL_WRITE GUP pins or writeable mapping if there are *any*
pins to the page.

And we'd have to write-protect the page in the page tables at the moment we
obtain the FOLL_WRITE GUP pin to make sure the pin owner is the only thread
able to modify that page contents while the DIO is running.

Oh that's nasty, but yeah I understood the problem now, thanks.

-- 
Cheers

David / dhildenb