4.9-stable patches

added patches:
	mm-memcontrol-return-1-from-cgroup.memory-__setup-handler.patch
	mm-mmap-return-1-from-stack_guard_gap-__setup-handler.patch

diff --git a/queue-4.9/mm-memcontrol-return-1-from-cgroup.memory-__setup-handler.patch b/queue-4.9/mm-memcontrol-return-1-from-cgroup.memory-__setup-handler.patch
new file mode 100644 (file)
index 0000000..38eb068
--- /dev/null
+++ b/queue-4.9/mm-memcontrol-return-1-from-cgroup.memory-__setup-handler.patch
@@ -0,0 +1,58 @@
+From 460a79e18842caca6fa0c415de4a3ac1e671ac50 Mon Sep 17 00:00:00 2001
+From: Randy Dunlap <rdunlap@infradead.org>
+Date: Tue, 22 Mar 2022 14:40:31 -0700
+Subject: mm/memcontrol: return 1 from cgroup.memory __setup() handler
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Randy Dunlap <rdunlap@infradead.org>
+
+commit 460a79e18842caca6fa0c415de4a3ac1e671ac50 upstream.
+
+__setup() handlers should return 1 if the command line option is handled
+and 0 if not (or maybe never return 0; it just pollutes init's
+environment).
+
+The only reason that this particular __setup handler does not pollute
+init's environment is that the setup string contains a '.', as in
+"cgroup.memory".  This causes init/main.c::unknown_boottoption() to
+consider it to be an "Unused module parameter" and ignore it.  (This is
+for parsing of loadable module parameters any time after kernel init.)
+Otherwise the string "cgroup.memory=whatever" would be added to init's
+environment strings.
+
+Instead of relying on this '.' quirk, just return 1 to indicate that the
+boot option has been handled.
+
+Note that there is no warning message if someone enters:
+       cgroup.memory=anything_invalid
+
+Link: https://lkml.kernel.org/r/20220222005811.10672-1-rdunlap@infradead.org
+Fixes: f7e1cb6ec51b0 ("mm: memcontrol: account socket memory in unified hierarchy memory controller")
+Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
+Reported-by: Igor Zhbanov <i.zhbanov@omprussia.ru>
+Link: lore.kernel.org/r/64644a2f-4a20-bab3-1e15-3b2cdd0defe3@omprussia.ru
+Reviewed-by: Michal Koutný <mkoutny@suse.com>
+Cc: Johannes Weiner <hannes@cmpxchg.org>
+Cc: Michal Hocko <mhocko@kernel.org>
+Cc: Vladimir Davydov <vdavydov.dev@gmail.com>
+Cc: Roman Gushchin <roman.gushchin@linux.dev>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ mm/memcontrol.c |    2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/mm/memcontrol.c
++++ b/mm/memcontrol.c
+@@ -5840,7 +5840,7 @@ static int __init cgroup_memory(char *s)
+               if (!strcmp(token, "nokmem"))
+                       cgroup_memory_nokmem = true;
+       }
+-      return 0;
++      return 1;
+ }
+ __setup("cgroup.memory=", cgroup_memory);
+ 

diff --git a/queue-4.9/mm-mmap-return-1-from-stack_guard_gap-__setup-handler.patch b/queue-4.9/mm-mmap-return-1-from-stack_guard_gap-__setup-handler.patch
new file mode 100644 (file)
index 0000000..a2bd202
--- /dev/null
+++ b/queue-4.9/mm-mmap-return-1-from-stack_guard_gap-__setup-handler.patch
@@ -0,0 +1,61 @@
+From e6d094936988910ce6e8197570f2753898830081 Mon Sep 17 00:00:00 2001
+From: Randy Dunlap <rdunlap@infradead.org>
+Date: Tue, 22 Mar 2022 14:42:27 -0700
+Subject: mm/mmap: return 1 from stack_guard_gap __setup() handler
+
+From: Randy Dunlap <rdunlap@infradead.org>
+
+commit e6d094936988910ce6e8197570f2753898830081 upstream.
+
+__setup() handlers should return 1 if the command line option is handled
+and 0 if not (or maybe never return 0; it just pollutes init's
+environment).  This prevents:
+
+  Unknown kernel command line parameters \
+  "BOOT_IMAGE=/boot/bzImage-517rc5 stack_guard_gap=100", will be \
+  passed to user space.
+
+  Run /sbin/init as init process
+   with arguments:
+     /sbin/init
+   with environment:
+     HOME=/
+     TERM=linux
+     BOOT_IMAGE=/boot/bzImage-517rc5
+     stack_guard_gap=100
+
+Return 1 to indicate that the boot option has been handled.
+
+Note that there is no warning message if someone enters:
+       stack_guard_gap=anything_invalid
+and 'val' and stack_guard_gap are both set to 0 due to the use of
+simple_strtoul(). This could be improved by using kstrtoxxx() and
+checking for an error.
+
+It appears that having stack_guard_gap == 0 is valid (if unexpected) since
+using "stack_guard_gap=0" on the kernel command line does that.
+
+Link: https://lkml.kernel.org/r/20220222005817.11087-1-rdunlap@infradead.org
+Link: lore.kernel.org/r/64644a2f-4a20-bab3-1e15-3b2cdd0defe3@omprussia.ru
+Fixes: 1be7107fbe18e ("mm: larger stack guard gap, between vmas")
+Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
+Reported-by: Igor Zhbanov <i.zhbanov@omprussia.ru>
+Cc: Hugh Dickins <hughd@google.com>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ mm/mmap.c |    2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/mm/mmap.c
++++ b/mm/mmap.c
+@@ -2425,7 +2425,7 @@ static int __init cmdline_parse_stack_gu
+       if (!*endptr)
+               stack_guard_gap = val << PAGE_SHIFT;
+ 
+-      return 0;
++      return 1;
+ }
+ __setup("stack_guard_gap=", cmdline_parse_stack_guard_gap);
+ 

diff --git a/queue-4.9/series b/queue-4.9/series
index ba296b1ac99ec80823e14f448966adece4927364..33edab03a4009fad41454b1c9bc988329b044b65 100644 (file)
--- a/queue-4.9/series
+++ b/queue-4.9/series
@@ -153,3 +153,5 @@ ubifs-setflags-make-dirtied_ino_d-8-bytes-aligned.patch
 gfs2-make-sure-fitrim-minlen-is-rounded-up-to-fs-block-size.patch
 pinctrl-pinconf-generic-print-arguments-for-bias-pull.patch
 acpi-cppc-avoid-out-of-bounds-access-when-parsing-_cpc-data.patch
+mm-mmap-return-1-from-stack_guard_gap-__setup-handler.patch
+mm-memcontrol-return-1-from-cgroup.memory-__setup-handler.patch