linux-kernel - Re: [PATCH] KVM: arm: memcg awareness

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: <87h7lahwjx.wl-maz@kernel.org>
Date:   Wed, 17 Mar 2021 11:03:14 +0000
From:   Marc Zyngier <maz@...nel.org>
To:     Paolo Bonzini <pbonzini@...hat.com>
Cc:     Wanpeng Li <kernellwp@...il.com>, linux-kernel@...r.kernel.org,
        kvm@...r.kernel.org, Ben Gardon <bgardon@...gle.com>,
        Shakeel Butt <shakeelb@...gle.com>
Subject: Re: [PATCH] KVM: arm: memcg awareness

On Wed, 17 Mar 2021 10:55:00 +0000,
Paolo Bonzini <pbonzini@...hat.com> wrote:
> 
> On 17/03/21 11:53, Marc Zyngier wrote:
> > On Wed, 17 Mar 2021 10:40:23 +0000,
> > Paolo Bonzini <pbonzini@...hat.com> wrote:
> >> 
> >> On 17/03/21 10:10, Marc Zyngier wrote:
> >>>> @@ -366,7 +366,7 @@ static int hyp_map_walker(u64 addr, u64 end, u32 level, kvm_pte_t *ptep,
> >>>>    	if (WARN_ON(level == KVM_PGTABLE_MAX_LEVELS - 1))
> >>>>    		return -EINVAL;
> >>>>    -	childp = (kvm_pte_t *)get_zeroed_page(GFP_KERNEL);
> >>>> +	childp = (kvm_pte_t *)get_zeroed_page(GFP_KERNEL_ACCOUNT);
> >>> No, this is wrong.
> >>> 
> >>> You cannot account the hypervisor page tables to the guest because we
> >>> don't ever unmap them, and that we can't distinguish two data
> >>> structures from two different VMs occupying the same page.
> >> 
> >> If you never unmap them, there should at least be a shrinker to get
> >> rid of unused pages in the event of memory pressure.
> > 
> > We don't track where these pages are coming from or whether they can
> > safely be unmapped. Until we can track such ownership and deal with
> > page sharing, these mappings have to stay,
> > 
> > At most, this represent the amount of memory required to map the whole
> > of the linear mapping.
> 
> Ah, these are the EL2 pages, not the stage2 page tables, right?  If
> so, sorry for the noise.

Yes, EL2 page tables when running non-VHE. VHE doesn't have that
problem for obvious reasons. Stage-2 page tables can be completely
discarded at any point, and the MMU notifiers already deal with that.

	M.

-- 
Without deviation from the norm, progress is not possible.