mm/mmap: return 1 from stack_guard_gap __setup() handler

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

 



From: Randy Dunlap <rdunlap@xxxxxxxxxxxxx>

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@xxxxxxxxxxxxx
Link: lore.kernel.org/r/64644a2f-4a20-bab3-1e15-3b2cdd0defe3@xxxxxxxxxxxx
Fixes: 1be7107fbe18e ("mm: larger stack guard gap, between vmas")
Signed-off-by: Randy Dunlap <rdunlap@xxxxxxxxxxxxx>
Reported-by: Igor Zhbanov <i.zhbanov@xxxxxxxxxxxx>
Cc: Hugh Dickins <hughd@xxxxxxxxxx>
Signed-off-by: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
Signed-off-by: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
Signed-off-by: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
---
 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);
 


Patches currently in stable-queue which might be from rdunlap@xxxxxxxxxxxxx are

queue-4.9/tomoyo-fix-__setup-handlers-return-values.patch
queue-4.9/mm-mmap-return-1-from-stack_guard_gap-__setup-handler.patch
queue-4.9/tty-hvc-fix-return-value-of-__setup-handler.patch
queue-4.9/pm-suspend-fix-return-value-of-__setup-handler.patch
queue-4.9/clocksource-acpi_pm-fix-return-value-of-__setup-hand.patch
queue-4.9/mips-rb532-fix-return-value-of-__setup-handler.patch
queue-4.9/printk-fix-return-value-of-printk.devkmsg-__setup-ha.patch
queue-4.9/pm-hibernate-fix-__setup-handler-error-handling.patch
queue-4.9/kgdboc-fix-return-value-of-__setup-handler.patch
queue-4.9/mm-memcontrol-return-1-from-cgroup.memory-__setup-handler.patch
queue-4.9/kgdbts-fix-return-value-of-__setup-handler.patch



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux