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: <eb36980a-2a81-426b-82fb-7f598f7a0037@intel.com>
Date: Tue, 11 Jun 2024 10:39:53 +1200
From: "Huang, Kai" <kai.huang@...el.com>
To: Haitao Huang <haitao.huang@...ux.intel.com>, "dave.hansen@...ux.intel.com"
	<dave.hansen@...ux.intel.com>, "tj@...nel.org" <tj@...nel.org>,
	"mkoutny@...e.com" <mkoutny@...e.com>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, "linux-sgx@...r.kernel.org"
	<linux-sgx@...r.kernel.org>, "x86@...nel.org" <x86@...nel.org>,
	"cgroups@...r.kernel.org" <cgroups@...r.kernel.org>, "tglx@...utronix.de"
	<tglx@...utronix.de>, "mingo@...hat.com" <mingo@...hat.com>, "bp@...en8.de"
	<bp@...en8.de>, "hpa@...or.com" <hpa@...or.com>, "Mehta, Sohil"
	<sohil.mehta@...el.com>, "tim.c.chen@...ux.intel.com"
	<tim.c.chen@...ux.intel.com>, Jarkko Sakkinen <jarkko@...nel.org>
CC: "Li, Zhiquan1" <zhiquan1.li@...el.com>, "kristen@...ux.intel.com"
	<kristen@...ux.intel.com>, "seanjc@...gle.com" <seanjc@...gle.com>, "Zhang,
 Bo" <zhanb@...rosoft.com>, "anakrish@...rosoft.com" <anakrish@...rosoft.com>,
	"mikko.ylinen@...ux.intel.com" <mikko.ylinen@...ux.intel.com>,
	"yangjie@...rosoft.com" <yangjie@...rosoft.com>, "chrisyan@...rosoft.com"
	<chrisyan@...rosoft.com>
Subject: Re: [PATCH v14 14/14] selftests/sgx: Add scripts for EPC cgroup
 testing


> --- a/arch/x86/kernel/cpu/sgx/main.c
> +++ b/arch/x86/kernel/cpu/sgx/main.c
> @@ -1045,7 +1045,7 @@ static int __init sgx_init(void)
>        if (!sgx_page_cache_init())
>            return -ENOMEM;
> 
> -    if (!sgx_page_reclaimer_init()) {
> +    if (!sgx_page_reclaimer_init() || !sgx_cgroup_init()) {
>            ret = -ENOMEM;
>            goto err_page_cache;
>        }

Does it make more sense to move the sgx_cgroup_init() to the 
sgx_drv_init()?  The SGX cgroup only works for the driver side anyway. 
In this case, if something went wrong in sgx_cgroup_init(), the 
sgx_vepc_init() could still have a chance to work.

And IIUC we need to reset the "capacity" to 0 if sgx_cgroup_init() 
fails, no matter it is called inside sgx_drv_init() or sgx_init(), 
otherwise the "epc" would appear in the cgroup hierarchy as a misc 
cgroup resource.

Another option is to defer setting the capacity to the point where we 
have made sure sgx_drv_init() and sgx_cgroup_init() cannot fail.

Btw, I plan to review the rest from late of this week or next week 
because this week I have some other staff needs to be finished first.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ