On Tue, May 21, 2024 at 03:44:21PM +0100, Matthew Wilcox wrote:
> On Tue, May 21, 2024 at 09:15:56PM +0800, Kefeng Wang wrote:
> > The page_memcg() only called by mod_memcg_page_state(), so squash it to
> > cleanup page_memcg().
>
> This isn't wrong, except that the entire usage of memcg is wrong in the
> only two callers of mod_memcg_page_state():
>
> $ git grep mod_memcg_page_state
> include/linux/memcontrol.h:static inline void mod_memcg_page_state(struct page *page,
> include/linux/memcontrol.h:static inline void mod_memcg_page_state(struct page *page,
> mm/vmalloc.c: mod_memcg_page_state(page, MEMCG_VMALLOC, -1);
> mm/vmalloc.c: mod_memcg_page_state(area->pages[i], MEMCG_VMALLOC, 1);
>
> The memcg should not be attached to the individual pages that make up a
> vmalloc allocation. Rather, it should be managed by the vmalloc
> allocation itself. I don't have the knowledge to poke around inside
> vmalloc right now, but maybe somebody else could take that on.
Are you concerned about accessing just memcg or any field of the
sub-page? There are drivers accessing fields of pages allocated through
vmalloc. Some details at 3b8000ae185c ("mm/vmalloc: huge vmalloc backing
pages should be split rather than compound").
