> 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?
