[Bug 269330] fusefs: data corruption with mmap and either o_direct or fspacectl

From: <bugzilla-noreply_at_freebsd.org>
Date: Sat, 04 Feb 2023 23:15:19 UTC

Konstantin Belousov <kib@FreeBSD.org> changed:

           What    |Removed                     |Added
                 CC|                            |kib@FreeBSD.org

--- Comment #1 from Konstantin Belousov <kib@FreeBSD.org> ---
I am confused by your question, quite possibly because you are confused
by buffer cache vs. page cache difference.

B_CACHE is the flag for buffers (as in struct buf). For vnodes which have
non-NULL vp->v_object AKA VMIO buffers, the buffer is only a header referencing
some number of pages belonging to v_object.  It is not necessary for a buffer
to exist for each page on the object queue. In fact, since number of buffers
is fixed, it is usual for buffers to be deconstructed shortly after all i/o
requested through the buffer finished.

Dirty pages (pages which have the dirty/PG_M bits set) are converted into
dirty buffers by vm_object_page_clean() when page clean is requested in async
mode.  Then the dirty buffers are written out by buffer daemon.  This is
significant simplification, but it catches the intent.

Hopefully this answers the question 1.

For question 2, what do you mean by 'finding' the dirty pages? If there is
a possibility that vnode has a dirty page on its queue, then
vm_object_mightbedirty() returns true.  To find actual dirty pages, you
must iterate over the page queue for the object and see which page is dirty,
either from PoV of MI VM layer (m->dirty) or pmap (PG_M etc).  Note that since
writable mappings could exist accessed by other threads, some exercises are
needed to have PG_M reading not racy, like pmap_remove_write() call which
invalidates all managed writable mappings.  See vm_object_page_clean() for all
the details.

And note that the fact that the page is clean from VM PoV (either MI or pmap)
does not mean that the page data really hit the storage.  As I wrote above,
page daemon only converts dirty pages into dirty buffers, clearing the dirty
bits in vm_page.  The content is still dirty but now tracked by the buffer

You are receiving this mail because:
You are the assignee for the bug.