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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-Id: <FD483CC3-26F1-4CEE-899E-7EB77C4D3277@redhat.com>
Date:   Mon, 9 Mar 2020 16:06:54 -0400 (EDT)
From:   David Hildenbrand <dhildenb@...hat.com>
To:     Peter Xu <peterx@...hat.com>,
        Andrea Arcangeli <aarcange@...hat.com>
Cc:     David Hildenbrand <david@...hat.com>, linux-mm@...ck.org,
        linux-kernel@...r.kernel.org,
        Andrea Arcangeli <aarcange@...hat.com>,
        Martin Cracauer <cracauer@...s.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Mike Rapoport <rppt@...ux.vnet.ibm.com>,
        "Kirill A . Shutemov" <kirill@...temov.name>,
        Johannes Weiner <hannes@...xchg.org>,
        "Dr . David Alan Gilbert" <dgilbert@...hat.com>,
        Bobby Powers <bobbypowers@...il.com>,
        Maya Gokhale <gokhale2@...l.gov>,
        Jerome Glisse <jglisse@...hat.com>,
        Mike Kravetz <mike.kravetz@...cle.com>,
        Matthew Wilcox <willy@...radead.org>,
        Marty McFadden <mcfadden8@...l.gov>,
        Mel Gorman <mgorman@...e.de>, Hugh Dickins <hughd@...gle.com>,
        Brian Geffon <bgeffon@...gle.com>,
        Denis Plotnikov <dplotnikov@...tuozzo.com>,
        Pavel Emelyanov <xemul@...tuozzo.com>
Subject: Re: [PATCH RESEND v6 00/16] mm: Page fault enhancements



> Am 09.03.2020 um 20:51 schrieb Peter Xu <peterx@...hat.com>:
> 
> 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?