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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Nov 15, 2018 at 02:08:10PM -0800, Andrew Morton wrote:
On Tue, 13 Nov 2018 00:52:51 -0500 Sasha Levin <sashal@xxxxxxxxxx> wrote:

From: Jann Horn <jannh@xxxxxxxxxx>

[ 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?

Indeed, this doesn't fix anything.

My concern is that in the future, we will pull a patch that will cause
the issue described here, and that issue will only be relevant on
stable. It is very hard to debug this, and I suspect that stable kernels
will still pass all their tests with flying colors.

As an example, consider the case where commit 28e2c4bb99aa ("mm/vmstat.c:
fix outdated vmstat_text") is backported to a kernel that doesn't have
commit 7a9cdebdcc17 ("mm: get rid of vmacache_flush_all() entirely").

I also felt safe with this patch since it adds a single BUILD_BUG_ON()
which does nothing during runtime, so the chances it introduces anything
beyond a build regression seemed to be slim to none.

--
Thanks,
Sasha



[Index of Archives]     [Linux Kernel]     [Kernel Development Newbies]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Hiking]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux