Re: [PATCH v13 0/5] UFFD write-tracking migration/snapshots

[David Hildenbrand]

> > Hi,
> >
> > just stumbled over this, quick question:
> >
> > I recently played with UFFD_WP and notices that write protection is
> > only effective on pages/ranges that have already pages populated (IOW:
> > !pte_none() in the kernel).
> >
> > In case memory was never populated (or was discarded using e.g.,
> > madvice(DONTNEED)), write-protection will be skipped silently and you
> > won't get WP events for applicable pages.
> >
> > So if someone writes to a yet unpoupulated page ("zero"), you won't
> > get WP events.
> >
> > I can spot that you do a single uffd_change_protection() on the whole
> > RAMBlock.
> >
> > How are you handling that scenario, or why don't you have to handle
> > that scenario?
> Hi David,
>
> I really wonder if such a problem exists.. If we are talking about a

I immediately ran into this issue with my simplest test cases. :)

> write to an unpopulated page, we should get first page fault on
> non-present page and populate it with protection bits from respective vma.
> For UFFD_WP vma's  page will be populated non-writable. So we'll get
> another page fault on present but read-only page and go to handle_userfault.

See the attached test program. Triggers for me on 5.11.0-rc6+ and 
5.9.13-200.fc33

gcc -lpthread uffdio_wp.c -o uffdio_wp
./uffdio_wp
WP did not fire

Uncomment the placement of the zeropage just before registering to make 
the WP actually trigger. If there is no PTE, there is nothing to protect.


And it makes sense: How should the fault handler know which ranges you 
wp-ed, if there is no place to store that information (the PTEs!). The 
VMA cannot tell that story, it only knows that someone registered 
UFFD_WP to selectively wp some parts.

You might have to register also for MISSING faults and place zero pages.

--
Thanks,

David / dhildenb

uffdio_wp.c
Description: Text Data