linux-kernel - Re: [PATCH AUTOSEL 3.18 8/9] mm/vmstat.c: assert that vmstat_text is in sync with stat_items

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: <20181115140810.e3292c83467544f6a1d82686@linux-foundation.org>
Date:   Thu, 15 Nov 2018 14:08:10 -0800
From:   Andrew Morton <akpm@...ux-foundation.org>
To:     Sasha Levin <sashal@...nel.org>
Cc:     stable@...r.kernel.org, linux-kernel@...r.kernel.org,
        Jann Horn <jannh@...gle.com>,
        Davidlohr Bueso <dave@...olabs.net>,
        Oleg Nesterov <oleg@...hat.com>,
        Christoph Lameter <clameter@....com>,
        Kemi Wang <kemi.wang@...el.com>,
        Andy Lutomirski <luto@...nel.org>,
        Ingo Molnar <mingo@...nel.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        linux-mm@...ck.org
Subject: Re: [PATCH AUTOSEL 3.18 8/9] mm/vmstat.c: assert that vmstat_text
 is in sync with stat_items_size

On Tue, 13 Nov 2018 00:52:51 -0500 Sasha Levin <sashal@...nel.org> wrote:

> From: Jann Horn <jannh@...gle.com>
> 
> [ Upstream commit f0ecf25a093fc0589f0a6bc4c1ea068bbb67d220 ]
> 
> Having two gigantic arrays that must manually be kept in sync, including
> ifdefs, isn't exactly robust.  To make it easier to catch such issues in
> the future, add a BUILD_BUG_ON().
>
> ...
>
> --- a/mm/vmstat.c
> +++ b/mm/vmstat.c
> @@ -1189,6 +1189,8 @@ static void *vmstat_start(struct seq_file *m, loff_t *pos)
>  	stat_items_size += sizeof(struct vm_event_state);
>  #endif
>  
> +	BUILD_BUG_ON(stat_items_size !=
> +		     ARRAY_SIZE(vmstat_text) * sizeof(unsigned long));
>  	v = kmalloc(stat_items_size, GFP_KERNEL);
>  	m->private = v;
>  	if (!v)

I don't think there's any way in which this can make a -stable kernel
more stable!


Generally, I consider -stable in every patch I merge, so for each patch
which doesn't have cc:stable, that tag is missing for a reason.

In other words, your criteria for -stable addition are different from
mine.

And I think your criteria differ from those described in
Documentation/process/stable-kernel-rules.rst.

So... what is your overall thinking on patch selection?