linux-kernel - Re: [PATCH -next] KVM: SVM: Remove unnecessary GFP_KERNEL_ACCOUNT in svm_set_nested

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: <e21beaa7c31639f9e8836f963f16c23ee982329f.camel@intel.com>
Date: Sat, 24 Aug 2024 09:33:40 +0000
From: "Huang, Kai" <kai.huang@...el.com>
To: "seanjc@...gle.com" <seanjc@...gle.com>
CC: "x86@...nel.org" <x86@...nel.org>, "dave.hansen@...ux.intel.com"
	<dave.hansen@...ux.intel.com>, "hpa@...or.com" <hpa@...or.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"mingo@...hat.com" <mingo@...hat.com>, "bp@...en8.de" <bp@...en8.de>,
	"kvm@...r.kernel.org" <kvm@...r.kernel.org>, "zhangxiaoxu5@...wei.com"
	<zhangxiaoxu5@...wei.com>, "liuyongqiang13@...wei.com"
	<liuyongqiang13@...wei.com>, "pbonzini@...hat.com" <pbonzini@...hat.com>,
	"tglx@...utronix.de" <tglx@...utronix.de>
Subject: Re: [PATCH -next] KVM: SVM: Remove unnecessary GFP_KERNEL_ACCOUNT in
 svm_set_nested_state()

On Fri, 2024-08-23 at 17:00 -0700, Sean Christopherson wrote:
> On Fri, Aug 23, 2024, Kai Huang wrote:
> > 
> > 
> > On 21/08/2024 11:27 pm, Yongqiang Liu wrote:
> > > The fixed size temporary variables vmcb_control_area and vmcb_save_area
> > > allocated in svm_set_nested_state() are released when the function exits.
> > > Meanwhile, svm_set_nested_state() also have vcpu mutex held to avoid
> > > massive concurrency allocation, so we don't need to set GFP_KERNEL_ACCOUNT.
> > 
> > Hi Sean/Paolo,
> > 
> > Seems more patches are popping up regarding to whether to use _ACCOUNT for
> > temporary memory allocation.  Could we have a definitive guide on this?
> 
> If the allocations are temporary, e.g. scoped to exactly one function, not massive
> (use best judgment), and can't be used in any kind of novel DDoS attack, e.g. are
> limited to one per vCPU or so, then they don't need to be accounted.
> 
> At least, that's my take on things.

That makes sense.  Thanks.