linux-kernel - Re: Re: [PATCH v9 10/15] x86/sgx: Add EPC reclamation in cgroup try

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]

Date: Tue, 27 Feb 2024 10:26:03 +0100
From: Michal Koutný <mkoutny@...e.com>
To: Haitao Huang <haitao.huang@...ux.intel.com>
Cc: "Huang, Kai" <kai.huang@...el.com>, "tj@...nel.org" <tj@...nel.org>, 
	"jarkko@...nel.org" <jarkko@...nel.org>, "x86@...nel.org" <x86@...nel.org>, 
	"dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>, "cgroups@...r.kernel.org" <cgroups@...r.kernel.org>, 
	"hpa@...or.com" <hpa@...or.com>, "mingo@...hat.com" <mingo@...hat.com>, 
	"tim.c.chen@...ux.intel.com" <tim.c.chen@...ux.intel.com>, "Mehta, Sohil" <sohil.mehta@...el.com>, 
	"linux-sgx@...r.kernel.org" <linux-sgx@...r.kernel.org>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, 
	"tglx@...utronix.de" <tglx@...utronix.de>, "bp@...en8.de" <bp@...en8.de>, 
	Dave Hansen <dave.hansen@...el.com>, "mikko.ylinen@...ux.intel.com" <mikko.ylinen@...ux.intel.com>, 
	"seanjc@...gle.com" <seanjc@...gle.com>, "anakrish@...rosoft.com" <anakrish@...rosoft.com>, 
	"Zhang, Bo" <zhanb@...rosoft.com>, "kristen@...ux.intel.com" <kristen@...ux.intel.com>, 
	"yangjie@...rosoft.com" <yangjie@...rosoft.com>, "Li, Zhiquan1" <zhiquan1.li@...el.com>, 
	"chrisyan@...rosoft.com" <chrisyan@...rosoft.com>
Subject: Re: Re: [PATCH v9 10/15] x86/sgx: Add EPC reclamation in cgroup
 try_charge()

Hello.

On Mon, Feb 26, 2024 at 03:48:18PM -0600, Haitao Huang <haitao.huang@...ux.intel.com> wrote:
> In case of overcomitting, i.e., sum of limits greater than the EPC capacity,
> if one group has a fault, and its usage is not above its own limit
> (try_charge() passes), yet total usage of the system has exceeded the
> capacity, whether we do global reclaim or just reclaim pages in the current
> faulting group.
> 
> > Also, what does the core mm memcg code do?
> > 
> I'm not sure. I'll try to find out but it'd be appreciated if someone more
> knowledgeable can comment on this. memcg also has the protection mechanism
> (i.e., min, low settings) to guarantee some allocation per group so its
> approach might not be applicable to misc controller here.

I only follow the discussion superficially but it'd be nice to have
analogous mechanisms in memcg and sgx controller.

The memory limits are rather simple -- when allocating new memory, the
tightest limit of ancestor applies and reclaim is applied to whole
subtree of such an ancestor (not necessearily the originating cgroup of
the allocation). Overcommit is admited, competition among siblings is
resolved on the first comes, first served basis.

The memory protections are an additional (and in a sense orthogoal)
mechanism. They can be interpretted as limits that are enforced not at
the time of allocation but at the time of reclaim (and reclaim is
triggered independetly, either global or with the limits above). The
consequence is that the protection code must do some normalization to
evaluate overcommited values sensibly.

(Historically, there was also memory.soft_limit_in_bytes, which combined
"protection" and global reclaim but it turned out broken. I suggest
reading Documentation/admin-guide/cgroup-v2.rst section Controller
Issues and Remedies/Memory for more details and as cautionary example.)

HTH,
Michal

Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)