linux-kernel - Re: [PATCH v5 09/11] mm: memcontrol: use obj

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:   Thu, 2 Jun 2022 12:14:06 +0800
From:   Muchun Song <songmuchun@...edance.com>
To:     Michal Koutný <mkoutny@...e.com>
Cc:     hannes@...xchg.org, mhocko@...nel.org, roman.gushchin@...ux.dev,
        shakeelb@...gle.com, akpm@...ux-foundation.org,
        cgroups@...r.kernel.org, linux-mm@...ck.org,
        linux-kernel@...r.kernel.org, duanxiongchun@...edance.com,
        longman@...hat.com
Subject: Re: [PATCH v5 09/11] mm: memcontrol: use obj_cgroup APIs to charge
 the LRU pages

On Wed, Jun 01, 2022 at 07:34:38PM +0200, Michal Koutný wrote:
> Hello Muchun.
> 
> On Mon, May 30, 2022 at 03:49:17PM +0800, Muchun Song <songmuchun@...edance.com> wrote:
> > +static inline bool obj_cgroup_is_root(struct obj_cgroup *objcg)
> > +{
> > +	return objcg == root_obj_cgroup;
> > +}
> 
> Admittedly, this predicate alone caught my eye, why it did not also
> check root_mem_cgroup->objcg_list.
> However, deeper look reveals it's purpose is to avoid missing uncharges
> of pages that were charged in non-root memcg and later re-associated
> upwards after reparenting.

Right.

> So it's like obj_cgroup_root_origin() (I'm not suggesting a rename, just
> illustrating the understanding).
> 
> get_obj_cgroup_from_current() gains some complexity but it still holds
> that in root memcg neither kernel objects nor LRU pages are charged.
> At the same time, reparented kernel objects or LRU pages are properly
> uncharged.
> 
> These parts are 
> Reviewed-by: Michal Koutný <mkoutny@...e.com>
> 

Thanks Michal.

> (I did not look into the locking guarantees with the new API though.)
> 
>