linux-kernel - Re: [PATCH 1/2] KVM: MMU: Do not treat ZONE

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <e6637be8-7890-579b-8131-6fdbbd791fa0@redhat.com>
Date:   Tue, 12 Nov 2019 11:19:44 +0100
From:   Paolo Bonzini <pbonzini@...hat.com>
To:     Dan Williams <dan.j.williams@...el.com>,
        Sean Christopherson <sean.j.christopherson@...el.com>
Cc:     Radim Krčmář <rkrcmar@...hat.com>,
        Vitaly Kuznetsov <vkuznets@...hat.com>,
        Wanpeng Li <wanpengli@...cent.com>,
        Jim Mattson <jmattson@...gle.com>,
        Joerg Roedel <joro@...tes.org>, KVM list <kvm@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Adam Borowski <kilobyte@...band.pl>,
        David Hildenbrand <david@...hat.com>
Subject: Re: [PATCH 1/2] KVM: MMU: Do not treat ZONE_DEVICE pages as being
 reserved

On 12/11/19 01:51, Dan Williams wrote:
> An elevated page reference count for file mapped pages causes the
> filesystem (for a dax mode file) to wait for that reference count to
> drop to 1 before allowing the truncate to proceed. For a page cache
> backed file mapping (non-dax) the reference count is not considered in
> the truncate path. It does prevent the page from getting freed in the
> page cache case, but the association to the file is lost for truncate.

KVM support for file-backed guest memory is limited.  It is not
completely broken, in fact cases such as hugetlbfs are in use routinely,
but corner cases such as truncate aren't covered well indeed.

Paolo

> As long as any memory the guest expects to be persistent is backed by
> mmu-notifier coordination we're all good, otherwise an elevated
> reference count does not coordinate with truncate in a reliable way.
>