From: Greg Kroah-Hartman Date: Sat, 3 May 2014 18:30:25 +0000 (-0400) Subject: 3.4-stable patches X-Git-Tag: v3.4.89~13 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=90cafd1dc6ed4207e643ca4a159f044c84a4ed31;p=thirdparty%2Fkernel%2Fstable-queue.git 3.4-stable patches added patches: hung_task-check-the-value-of-sysctl_hung_task_timeout_sec.patch mm-hugetlb-fix-softlockup-when-a-large-number-of-hugepages-are-freed.patch sh-fix-format-string-bug-in-stack-tracer.patch --- diff --git a/queue-3.4/hung_task-check-the-value-of-sysctl_hung_task_timeout_sec.patch b/queue-3.4/hung_task-check-the-value-of-sysctl_hung_task_timeout_sec.patch new file mode 100644 index 00000000000..8e85c8a26b1 --- /dev/null +++ b/queue-3.4/hung_task-check-the-value-of-sysctl_hung_task_timeout_sec.patch @@ -0,0 +1,55 @@ +From 80df28476505ed4e6701c3448c63c9229a50c655 Mon Sep 17 00:00:00 2001 +From: Liu Hua +Date: Mon, 7 Apr 2014 15:38:57 -0700 +Subject: hung_task: check the value of "sysctl_hung_task_timeout_sec" + +From: Liu Hua + +commit 80df28476505ed4e6701c3448c63c9229a50c655 upstream. + +As sysctl_hung_task_timeout_sec is unsigned long, when this value is +larger then LONG_MAX/HZ, the function schedule_timeout_interruptible in +watchdog will return immediately without sleep and with print : + + schedule_timeout: wrong timeout value ffffffffffffff83 + +and then the funtion watchdog will call schedule_timeout_interruptible +again and again. The screen will be filled with + + "schedule_timeout: wrong timeout value ffffffffffffff83" + +This patch does some check and correction in sysctl, to let the function +schedule_timeout_interruptible allways get the valid parameter. + +Signed-off-by: Liu Hua +Tested-by: Satoru Takeuchi +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman + +--- + kernel/sysctl.c | 6 ++++++ + 1 file changed, 6 insertions(+) + +--- a/kernel/sysctl.c ++++ b/kernel/sysctl.c +@@ -142,6 +142,11 @@ static int min_percpu_pagelist_fract = 8 + static int ngroups_max = NGROUPS_MAX; + static const int cap_last_cap = CAP_LAST_CAP; + ++/*this is needed for proc_doulongvec_minmax of sysctl_hung_task_timeout_secs */ ++#ifdef CONFIG_DETECT_HUNG_TASK ++static unsigned long hung_task_timeout_max = (LONG_MAX/HZ); ++#endif ++ + #ifdef CONFIG_INOTIFY_USER + #include + #endif +@@ -897,6 +902,7 @@ static struct ctl_table kern_table[] = { + .maxlen = sizeof(unsigned long), + .mode = 0644, + .proc_handler = proc_dohung_task_timeout_secs, ++ .extra2 = &hung_task_timeout_max, + }, + { + .procname = "hung_task_warnings", diff --git a/queue-3.4/mm-hugetlb-fix-softlockup-when-a-large-number-of-hugepages-are-freed.patch b/queue-3.4/mm-hugetlb-fix-softlockup-when-a-large-number-of-hugepages-are-freed.patch new file mode 100644 index 00000000000..e265c7ee5ce --- /dev/null +++ b/queue-3.4/mm-hugetlb-fix-softlockup-when-a-large-number-of-hugepages-are-freed.patch @@ -0,0 +1,89 @@ +From 55f67141a8927b2be3e51840da37b8a2320143ed Mon Sep 17 00:00:00 2001 +From: "Mizuma, Masayoshi" +Date: Mon, 7 Apr 2014 15:37:54 -0700 +Subject: mm: hugetlb: fix softlockup when a large number of hugepages are freed. + +From: "Mizuma, Masayoshi" + +commit 55f67141a8927b2be3e51840da37b8a2320143ed upstream. + +When I decrease the value of nr_hugepage in procfs a lot, softlockup +happens. It is because there is no chance of context switch during this +process. + +On the other hand, when I allocate a large number of hugepages, there is +some chance of context switch. Hence softlockup doesn't happen during +this process. So it's necessary to add the context switch in the +freeing process as same as allocating process to avoid softlockup. + +When I freed 12 TB hugapages with kernel-2.6.32-358.el6, the freeing +process occupied a CPU over 150 seconds and following softlockup message +appeared twice or more. + +$ echo 6000000 > /proc/sys/vm/nr_hugepages +$ cat /proc/sys/vm/nr_hugepages +6000000 +$ grep ^Huge /proc/meminfo +HugePages_Total: 6000000 +HugePages_Free: 6000000 +HugePages_Rsvd: 0 +HugePages_Surp: 0 +Hugepagesize: 2048 kB +$ echo 0 > /proc/sys/vm/nr_hugepages + +BUG: soft lockup - CPU#16 stuck for 67s! [sh:12883] ... +Pid: 12883, comm: sh Not tainted 2.6.32-358.el6.x86_64 #1 +Call Trace: + free_pool_huge_page+0xb8/0xd0 + set_max_huge_pages+0x128/0x190 + hugetlb_sysctl_handler_common+0x113/0x140 + hugetlb_sysctl_handler+0x1e/0x20 + proc_sys_call_handler+0x97/0xd0 + proc_sys_write+0x14/0x20 + vfs_write+0xb8/0x1a0 + sys_write+0x51/0x90 + __audit_syscall_exit+0x265/0x290 + system_call_fastpath+0x16/0x1b + +I have not confirmed this problem with upstream kernels because I am not +able to prepare the machine equipped with 12TB memory now. However I +confirmed that the amount of decreasing hugepages was directly +proportional to the amount of required time. + +I measured required times on a smaller machine. It showed 130-145 +hugepages decreased in a millisecond. + + Amount of decreasing Required time Decreasing rate + hugepages (msec) (pages/msec) + ------------------------------------------------------------ + 10,000 pages == 20GB 70 - 74 135-142 + 30,000 pages == 60GB 208 - 229 131-144 + +It means decrement of 6TB hugepages will trigger softlockup with the +default threshold 20sec, in this decreasing rate. + +Signed-off-by: Masayoshi Mizuma +Cc: Joonsoo Kim +Cc: Michal Hocko +Cc: Wanpeng Li +Cc: Aneesh Kumar +Cc: KOSAKI Motohiro +Cc: Naoya Horiguchi +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman + +--- + mm/hugetlb.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/mm/hugetlb.c ++++ b/mm/hugetlb.c +@@ -1451,6 +1451,7 @@ static unsigned long set_max_huge_pages( + while (min_count < persistent_huge_pages(h)) { + if (!free_pool_huge_page(h, nodes_allowed, 0)) + break; ++ cond_resched_lock(&hugetlb_lock); + } + while (count < persistent_huge_pages(h)) { + if (!adjust_pool_surplus(h, nodes_allowed, 1)) diff --git a/queue-3.4/series b/queue-3.4/series index bbb1787e875..c4c4aba0e37 100644 --- a/queue-3.4/series +++ b/queue-3.4/series @@ -34,3 +34,6 @@ usb-xhci-fix-compilation-warning-when-config_pci-config_pm.patch usb-dwc3-fix-wrong-bit-mask-in-dwc3_event_devt.patch hvc-ensure-hvc_init-is-only-ever-called-once-in-hvc_console.c.patch usb-unbind-all-interfaces-before-rebinding-any.patch +sh-fix-format-string-bug-in-stack-tracer.patch +mm-hugetlb-fix-softlockup-when-a-large-number-of-hugepages-are-freed.patch +hung_task-check-the-value-of-sysctl_hung_task_timeout_sec.patch diff --git a/queue-3.4/sh-fix-format-string-bug-in-stack-tracer.patch b/queue-3.4/sh-fix-format-string-bug-in-stack-tracer.patch new file mode 100644 index 00000000000..d8902a71167 --- /dev/null +++ b/queue-3.4/sh-fix-format-string-bug-in-stack-tracer.patch @@ -0,0 +1,40 @@ +From a0c32761e73c9999cbf592b702f284221fea8040 Mon Sep 17 00:00:00 2001 +From: Matt Fleming +Date: Thu, 3 Apr 2014 14:46:20 -0700 +Subject: sh: fix format string bug in stack tracer + +From: Matt Fleming + +commit a0c32761e73c9999cbf592b702f284221fea8040 upstream. + +Kees reported the following error: + + arch/sh/kernel/dumpstack.c: In function 'print_trace_address': + arch/sh/kernel/dumpstack.c:118:2: error: format not a string literal and no format arguments [-Werror=format-security] + +Use the "%s" format so that it's impossible to interpret 'data' as a +format string. + +Signed-off-by: Matt Fleming +Reported-by: Kees Cook +Acked-by: Kees Cook +Cc: Paul Mundt +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman + +--- + arch/sh/kernel/dumpstack.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/arch/sh/kernel/dumpstack.c ++++ b/arch/sh/kernel/dumpstack.c +@@ -80,7 +80,7 @@ static int print_trace_stack(void *data, + */ + static void print_trace_address(void *data, unsigned long addr, int reliable) + { +- printk(data); ++ printk("%s", (char *)data); + printk_address(addr, reliable); + } +