On Mon, 10 Jun 2024 17:39:53 -0500, Huang, Kai <kai.huang@xxxxxxxxx> wrote:
--- 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.
vepc reclamation is not done by cgroup/ksgxd but try_charge() won't work
if user expecting cgroup to limit vepc allocation. Would it be more
consistent to just disable vepc, i.e., on system with MISC, sgx/vepc
always go with cgroup enabled?
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.
Yes agree we need do this.
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.
Sure. Thanks
Haitao
