Re: [PATCH RESEND v6 00/16] mm: Page fault enhancements

[David Hildenbrand]

> Am 09.03.2020 um 20:51 schrieb Peter Xu <peterx@xxxxxxxxxx>:
> 
> ïOn Sun, Mar 08, 2020 at 01:12:34PM +0100, David Hildenbrand wrote:
>> [...]
>> 
>>> Yes, IIUC the race can happen like this in your below test:
>>> 
>>>     main thread          uffd thread             disgard thread
>>>     ===========          ===========             ==============
>>>     access page
>>>       uffd page fault
>>>         wait for page
>>>                          UFFDIO_ZEROCOPY
>>>                            put a page P there
>>>                                                  MADV_DONTNEED on P
>>>                            wakeup main thread
>>>         return from fault
>>>       page still missing
>>>       uffd page fault again
>>>       (without ALLOW_RETRY)
>>>       --> SIGBUS.
>> 
>> Exactly!
>> 
>>>> Can we please have a way to identify that this "feature" is available?
>>>> I'd appreciate a new read-only UFFD_FEAT_ , so we can detect this from
>>>> user space easily and use concurrent discards without crashing our applications.
>>> 
>>> I'm not sure how others think about it, but to me this still fells
>>> into the bucket of "solving an existing problem" rather than a
>>> feature.  Also note that this should change the behavior for the page
>>> fault logic in general, rather than an uffd-only change. So I'm also
>>> not sure whether UFFD_FEAT_* suites here even if we want it.
>> 
>> So, are we planning on backporting this to stable kernels?
> 
> I don't have a plan so far.  I'm still at the phase to only worry
> about whether it can be at least merged in master.. :)
> 
> I would think it won't worth it to backport this to stables though,
> considering that it could potentially change quite a bit for faulting
> procedures, and after all the issues we're fixing shouldn't be common
> to general users.
> 
>> 
>> Imagine using this in QEMU/KVM to allow discards (e.g., balloon
>> inflation) while postcopy is active . You certainly don't want random
>> guest crashes. So either, we treat this as a fix (and backport) or as a
>> change in behavior/feature.
> 
> I think we don't need to worry on that - QEMU will prohibit ballooning
> during postcopy starting from the first day.  Feel free to see QEMU
> commit 371ff5a3f04cd7 ("Inhibit ballooning during postcopy").

Imagine I want to change that or imagine I have another user that heavily depends on such races to never happen.

IOW I want to know for sure if my application can crash or not.

@Andrea what are your thoughts on a new feature flag to identify this behavior?