linux-kernel - Re: [PATCH v14 02/14] cgroup/misc: Add per resource callbacks for CSS events

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Fri, 7 Jun 2024 09:53:11 +0800
From: chenridong <chenridong@...wei.com>
To: Haitao Huang <haitao.huang@...ux.intel.com>, <jarkko@...nel.org>,
	<dave.hansen@...ux.intel.com>, <kai.huang@...el.com>, <tj@...nel.org>,
	<mkoutny@...e.com>, <linux-kernel@...r.kernel.org>,
	<linux-sgx@...r.kernel.org>, <x86@...nel.org>, <cgroups@...r.kernel.org>,
	<tglx@...utronix.de>, <mingo@...hat.com>, <bp@...en8.de>, <hpa@...or.com>,
	<sohil.mehta@...el.com>, <tim.c.chen@...ux.intel.com>
CC: <zhiquan1.li@...el.com>, <kristen@...ux.intel.com>, <seanjc@...gle.com>,
	<zhanb@...rosoft.com>, <anakrish@...rosoft.com>,
	<mikko.ylinen@...ux.intel.com>, <yangjie@...rosoft.com>,
	<chrisyan@...rosoft.com>
Subject: Re: [PATCH v14 02/14] cgroup/misc: Add per resource callbacks for CSS
 events

I think it is better when _misc_cg_res_alloc fails, it just calls 
_misc_cg_res_free(cg, index)(add index parameter, it means ending of 
iterator), so it can avoid calling ->free() that do not call ->alloc().

And in misc_cg_free, just call _misc_cg_res_free(cg, MISC_CG_RES_TYPES)  
to free all.


Thanks

Ridong


On 2024/6/6 22:51, Haitao Huang wrote:
> On Thu, 06 Jun 2024 08:37:31 -0500, chenridong <chenridong@...wei.com> 
> wrote:
>
>>
>>   If _misc_cg_res_alloc fails, maybe some types do not call 
>> ->alloc(), but all types ->free() callback >will be called, is that ok?
>>
> Not sure I understand. Are you suggesting we ignore failures from 
> ->alloc() callback in _misc_cg_res_alloc() as it is per-resource, and 
> have ->free() callback and resource provider of the failing type to 
> handle the failure internally?
>
> IIUC, this failure only happens when a specific subcgroup is created 
> (memory running out for allocation) so failing that subcgroup as a 
> whole seems fine to me. Note the root node is static and no 
> pre-resource callbacks invoked by misc. And resource provider handles 
> its own allocations for root. In SGX case we too declare a static 
> object for corresponding root sgx_cgroup struct.
>
> Note also misc cgroup (except for setting capacity[res] = 0 at root) 
> is all or nothing so no mechanism to tell user "this resource does not 
> work but others are fine in this particular cgroup."
>
> Thanks
> Haitao
>