linux-kernel - Re: [PATCH 2/2] memcg/hugetlb: Deprecate hugetlb memcg try-commit-cancel charging

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: <CAN+CAwNSMXP-Z5PVL_Q129nN-aP80XB0Y-Sm+C-XdHBinvWoxw@mail.gmail.com>
Date: Thu, 7 Nov 2024 13:27:53 -0500
From: Joshua Hahn <joshua.hahnjy@...il.com>
To: Shakeel Butt <shakeel.butt@...ux.dev>
Cc: hannes@...xchg.org, mhocko@...nel.org, roman.gushchin@...ux.dev, 
	muchun.song@...ux.dev, akpm@...ux-foundation.org, cgroups@...r.kernel.org, 
	linux-mm@...ck.org, linux-kernel@...r.kernel.org, kernel-team@...a.com
Subject: Re: [PATCH 2/2] memcg/hugetlb: Deprecate hugetlb memcg
 try-commit-cancel charging

On Wed, Nov 6, 2024 at 6:50 PM Shakeel Butt <shakeel.butt@...ux.dev> wrote:
>
> Please cleanup mem_cgroup_cancel_charge() and mem_cgroup_commit_charge()
> as well as there will be no users after this patch.
>

Hi Shakeel,

Thank you for your feedback. Unfortunately, it seems like even after this
patch removes the references from hugetlb.c, there are still some
references from other files.

mem_cgroup_cancel_charge:
  - memcontrol-v1.c~__mem_cgroup_clear_mc(void)

mem_cgroup_commit_charge:
  - memcontrol.c~charge_memcg(struct folio *folio, struct mem_cgroup...)

In fact, in my patch, I add an extra call to charge_memcg. I think for this
case, it makes sense to just extract out the functionality from
mem_cgroup_commit_charge (3 lines) and expand it out inside charge_memcg,
and get rid of mem_cgroup_commit_charge.

On the other hand, handling mem_cgroup_cancel_charge seems to be a bit
different. Now, all of its references are purely in memcontrol-v1.c.
I think in this case, it makes sense to migrate the function declaration
& definition into memcontrol-v1.c, and remove it from memcontrol.c.
Perhaps at a later date, a cleanup in memcontrol-v1 may find that it makes
sense to remove the function, but for now, I think we should just move it.

I hope this makes sense. Thank you again for your feedback!
Joshua