linux-kernel - Re: [PATCH] mm/vmstat: Fix build with MEMCG=y and VM_EVENT

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]

Message-ID: <7lakc6hxbimvkgakpocj3aa65sdhmskm5p6hlurbwzyps33gfb@2z2eoz253hs4>
Date: Thu, 5 Jun 2025 14:53:59 +0300
From: "Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>
To: Vlastimil Babka <vbabka@...e.cz>
Cc: Andrew Morton <akpm@...ux-foundation.org>, 
	David Hildenbrand <david@...hat.com>, lorenzo.stoakes@...cle.com, Liam.Howlett@...cle.com, 
	rppt@...nel.org, surenb@...gle.com, mhocko@...e.com, hannes@...xchg.org, 
	shakeel.butt@...ux.dev, muchun.song@...ux.dev, linux-mm@...ck.org, 
	linux-kernel@...r.kernel.org, Randy Dunlap <rdunlap@...radead.org>, 
	Konstantin Khlebnikov <koct9i@...il.com>
Subject: Re: [PATCH] mm/vmstat: Fix build with MEMCG=y and VM_EVENT_COUNTERS=n

On Thu, Jun 05, 2025 at 08:19:28AM +0200, Vlastimil Babka wrote:
> On 6/4/25 23:20, Andrew Morton wrote:
> > On Wed, 4 Jun 2025 11:56:42 +0200 Vlastimil Babka <vbabka@...e.cz> wrote:
> > 
> >> > There is no need to backport this fix to stable trees. Without the
> >> > strict BUILD_BUG_ON(), the issue is not harmful. The elements in
> >> > question would only be read by the memcg code, not by /proc/vmstat.
> >> > 
> >> > Signed-off-by: Kirill A. Shutemov <kirill.shutemov@...ux.intel.com>
> >> > Reported-by: Randy Dunlap <rdunlap@...radead.org>
> >> > Fixes: ebc5d83d0443 ("mm/memcontrol: use vmstat names for printing statistics")
> >> 
> >> Well in that case I think we should put Fixes: to the BUILD_BUG_ON() change.
> >> And if it's not yet a stable sha1, squash that together with this?
> >> It doesn't seem ebc5d83d0443 alone needs this fix.
> > 
> > I shuffled things around.
> > 
> > I moved "mm: strictly check vmstat_text array size" from mm-hotfixes
> > and back into mm-new for the next cycle.
> > 
> > I reworked "mm/vmstat: fix build with MEMCG=y and VM_EVENT_COUNTERS=n"
> > so it precedes "mm: strictly check vmstat_text array size".
> > 
> > I reworked "mm/vmstat: utilize designated initializers for the
> > vmstat_text array" so it comes last.
> > 
> > 
> > So the applying order is now
> 
> I checked and in general it looks good, except a nit below.
> 
> > mm-hotfixes:
> > mm-fix-vmstat-after-removing-nr_bounce.patch
> > 
> > mm-new:
> > mm-vmstat-fix-build-with-memcg=y-and-vm_event_counters=n.patch
> > mm-strictly-check-vmstat_text-array-size.patch
> 
> The changelogs of these two don't reflect the new ordering though, maybe
> Kirill can provide updated ones?

Maybe something like this, for the first patch?


mm/vmstat: Make MEMCG select VM_EVENT_COUNTERS

The vmstat_text array contains labels for counters displayed in /proc/vmstat.
It is important to keep the labels in sync with the counters.

There is a BUILD_BUG_ON() check in vmstat_start() that ensures the size of the
vmstat_text is not smaller than VM_EVENT_COUNTERS. This helps to catch cases
where a new counter is added but the label is not. However, it does not help if
a counter is removed but the label remains.

It would be nice to make the BUILD_BUG_ON() check more strict to catch such
cases. However, when compiling with MEMCG enabled but VM_EVENT_COUNTERS
disabled, the vmstat_text array is larger than NR_VMSTAT_ITEMS.

This issue arises because some elements of the vmstat_text array are present
when either MEMCG or VM_EVENT_COUNTERS is enabled, but NR_VMSTAT_ITEMS only
accounts for these elements if VM_EVENT_COUNTERS is enabled.

Instead of adjusting the NR_VMSTAT_ITEMS definition to account for MEMCG, make
MEMCG select VM_EVENT_COUNTERS. VM_EVENT_COUNTERS is enabled in most
configurations anyway.

-- 
  Kiryl Shutsemau / Kirill A. Shutemov