On 04.06.24 06:43, Byungchul Park wrote:
On Tue, Jun 04, 2024 at 10:53:48AM +0900, Byungchul Park wrote:
On Mon, Jun 03, 2024 at 06:23:46AM -0700, Dave Hansen wrote:
On 6/3/24 02:35, Byungchul Park wrote:
...> In luf's point of view, the points where the deferred flush should be
performed are simply:
1. when changing the vma maps, that might be luf'ed.
2. when updating data of the pages, that might be luf'ed.
It's simple, but the devil is in the details as always.
Agree with that.
All we need to do is to indentify the points:
1. when changing the vma maps, that might be luf'ed.
a) mmap and munmap e.i. fault handler or unmap_region().
b) permission to writable e.i. mprotect or fault handler.
c) what I'm missing.
I'd say it even more generally: anything that installs a PTE which is
inconsistent with the original PTE. That, of course, includes writes.
But it also includes crazy things that we do like uprobes. Take a look
at __replace_page().
I think the page_vma_mapped_walk() checks plus the ptl keep LUF at bay
there. But it needs some really thorough review.
But the bigger concern is that, if there was a problem, I can't think of
a systematic way to find it.
2. when updating data of the pages, that might be luf'ed.
a) updating files through vfs e.g. file_end_write().
b) updating files through writable maps e.i. 1-a) or 1-b).
c) what I'm missing.
Filesystems or block devices that change content without a "write" from
the local system. Network filesystems and block devices come to mind.
AFAIK, every network filesystem eventully "updates" its connected local
filesystem. It could be still handled at the point where updating the
local file system.
I honestly don't know what all the rules are around these, but they
could certainly be troublesome.
There appear to be some interactions for NFS between file locking and
page cache flushing.
But, stepping back ...
I'd honestly be a lot more comfortable if there was even a debugging LUF
I'd better provide a method for better debugging. Lemme know whatever
it is we need.
mode that enforced a rule that said:
Do you means a debugging mode that can WARN or inform the situation that
we don't want? If yes, sure. Now that I get this, I will re-read all
you guys' talk.
In my opinion either for debugging, or for actually enforcing it at
runtime. Whatever the cost of that would be needs to be determined.
--
Cheers,
David / dhildenb
