From 916479ad9d7e9f16a91f8e380b53ca509d4a9590 Mon Sep 17 00:00:00 2001 From: Greg Kroah-Hartman Date: Mon, 26 Mar 2012 14:50:14 -0700 Subject: [PATCH] 3.0-stable patches added patches: hwmon-fam15h_power-correct-sign-extension-of-running_avg_capture.patch proc-ns-use-d_set_d_op-api-to-set-dentry-ops-in-proc_ns_instantiate.patch x86-32-fix-endless-loop-when-processing-signals-for-kernel-tasks.patch --- ...ign-extension-of-running_avg_capture.patch | 33 ++++++++ ...et-dentry-ops-in-proc_ns_instantiate.patch | 46 +++++++++++ queue-3.0/series | 3 + ...-processing-signals-for-kernel-tasks.patch | 82 +++++++++++++++++++ 4 files changed, 164 insertions(+) create mode 100644 queue-3.0/hwmon-fam15h_power-correct-sign-extension-of-running_avg_capture.patch create mode 100644 queue-3.0/proc-ns-use-d_set_d_op-api-to-set-dentry-ops-in-proc_ns_instantiate.patch create mode 100644 queue-3.0/x86-32-fix-endless-loop-when-processing-signals-for-kernel-tasks.patch diff --git a/queue-3.0/hwmon-fam15h_power-correct-sign-extension-of-running_avg_capture.patch b/queue-3.0/hwmon-fam15h_power-correct-sign-extension-of-running_avg_capture.patch new file mode 100644 index 00000000000..8868f3abf3e --- /dev/null +++ b/queue-3.0/hwmon-fam15h_power-correct-sign-extension-of-running_avg_capture.patch @@ -0,0 +1,33 @@ +From fc0900cbda9243957d812cd6b4cc87965f9fe75f Mon Sep 17 00:00:00 2001 +From: Andreas Herrmann +Date: Fri, 23 Mar 2012 10:02:17 +0100 +Subject: hwmon: (fam15h_power) Correct sign extension of running_avg_capture + +From: Andreas Herrmann + +commit fc0900cbda9243957d812cd6b4cc87965f9fe75f upstream. + +Wrong bit was used for sign extension which caused wrong end results. +Thanks to Andre for spotting this bug. + +Reported-by: Andre Przywara +Signed-off-by: Andreas Herrmann +Acked-by: Guenter Roeck +Signed-off-by: Jean Delvare +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/hwmon/fam15h_power.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/hwmon/fam15h_power.c ++++ b/drivers/hwmon/fam15h_power.c +@@ -60,7 +60,7 @@ static ssize_t show_power(struct device + pci_bus_read_config_dword(f4->bus, PCI_DEVFN(PCI_SLOT(f4->devfn), 5), + REG_TDP_RUNNING_AVERAGE, &val); + running_avg_capture = (val >> 4) & 0x3fffff; +- running_avg_capture = sign_extend32(running_avg_capture, 22); ++ running_avg_capture = sign_extend32(running_avg_capture, 21); + running_avg_range = val & 0xf; + + pci_bus_read_config_dword(f4->bus, PCI_DEVFN(PCI_SLOT(f4->devfn), 5), diff --git a/queue-3.0/proc-ns-use-d_set_d_op-api-to-set-dentry-ops-in-proc_ns_instantiate.patch b/queue-3.0/proc-ns-use-d_set_d_op-api-to-set-dentry-ops-in-proc_ns_instantiate.patch new file mode 100644 index 00000000000..f8e18a55304 --- /dev/null +++ b/queue-3.0/proc-ns-use-d_set_d_op-api-to-set-dentry-ops-in-proc_ns_instantiate.patch @@ -0,0 +1,46 @@ +From 1b26c9b334044cff6d1d2698f2be41bc7d9a0864 Mon Sep 17 00:00:00 2001 +From: Pravin B Shelar +Date: Fri, 23 Mar 2012 15:02:55 -0700 +Subject: proc-ns: use d_set_d_op() API to set dentry ops in proc_ns_instantiate(). + +From: Pravin B Shelar + +commit 1b26c9b334044cff6d1d2698f2be41bc7d9a0864 upstream. + +The namespace cleanup path leaks a dentry which holds a reference count +on a network namespace. Keeping that network namespace from being freed +when the last user goes away. Leaving things like vlan devices in the +leaked network namespace. + +If you use ip netns add for much real work this problem becomes apparent +pretty quickly. It light testing the problem hides because frequently +you simply don't notice the leak. + +Use d_set_d_op() so that DCACHE_OP_* flags are set correctly. + +This issue exists back to 3.0. + +Acked-by: "Eric W. Biederman" +Reported-by: Justin Pettit +Signed-off-by: Pravin B Shelar +Signed-off-by: Jesse Gross +Cc: David Miller +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman + +--- + fs/proc/namespaces.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/fs/proc/namespaces.c ++++ b/fs/proc/namespaces.c +@@ -54,7 +54,7 @@ static struct dentry *proc_ns_instantiat + ei->ns_ops = ns_ops; + ei->ns = ns; + +- dentry->d_op = &pid_dentry_operations; ++ d_set_d_op(dentry, &pid_dentry_operations); + d_add(dentry, inode); + /* Close the race of the process dying before we return the dentry */ + if (pid_revalidate(dentry, NULL)) diff --git a/queue-3.0/series b/queue-3.0/series index 52077b6a437..0d3a308c907 100644 --- a/queue-3.0/series +++ b/queue-3.0/series @@ -71,3 +71,6 @@ ubi-fix-eraseblock-picking-criteria.patch sunrpc-we-must-not-use-list_for_each_entry_safe-in-rpc_wake_up.patch usbnet-increase-urb-reference-count-before-usb_unlink_urb.patch usbnet-don-t-clear-urb-dev-in-tx_complete.patch +x86-32-fix-endless-loop-when-processing-signals-for-kernel-tasks.patch +proc-ns-use-d_set_d_op-api-to-set-dentry-ops-in-proc_ns_instantiate.patch +hwmon-fam15h_power-correct-sign-extension-of-running_avg_capture.patch diff --git a/queue-3.0/x86-32-fix-endless-loop-when-processing-signals-for-kernel-tasks.patch b/queue-3.0/x86-32-fix-endless-loop-when-processing-signals-for-kernel-tasks.patch new file mode 100644 index 00000000000..8f448d547f1 --- /dev/null +++ b/queue-3.0/x86-32-fix-endless-loop-when-processing-signals-for-kernel-tasks.patch @@ -0,0 +1,82 @@ +From 29a2e2836ff9ea65a603c89df217f4198973a74f Mon Sep 17 00:00:00 2001 +From: Dmitry Adamushko +Date: Thu, 22 Mar 2012 21:39:25 +0100 +Subject: x86-32: Fix endless loop when processing signals for kernel tasks + +From: Dmitry Adamushko + +commit 29a2e2836ff9ea65a603c89df217f4198973a74f upstream. + +The problem occurs on !CONFIG_VM86 kernels [1] when a kernel-mode task +returns from a system call with a pending signal. + +A real-life scenario is a child of 'khelper' returning from a failed +kernel_execve() in ____call_usermodehelper() [ kernel/kmod.c ]. +kernel_execve() fails due to a pending SIGKILL, which is the result of +"kill -9 -1" (at least, busybox's init does it upon reboot). + +The loop is as follows: + +* syscall_exit_work: + - work_pending: // start_of_the_loop + - work_notify_sig: + - do_notify_resume() + - do_signal() + - if (!user_mode(regs)) return; + - resume_userspace // TIF_SIGPENDING is still set + - work_pending // so we call work_pending => goto + // start_of_the_loop + +More information can be found in another LKML thread: +http://www.serverphorums.com/read.php?12,457826 + +[1] the problem was also seen on MIPS. + +Signed-off-by: Dmitry Adamushko +Link: http://lkml.kernel.org/r/1332448765.2299.68.camel@dimm +Cc: Oleg Nesterov +Cc: Roland McGrath +Cc: Andrew Morton +Signed-off-by: H. Peter Anvin +Signed-off-by: Greg Kroah-Hartman + +--- + arch/x86/kernel/entry_32.S | 17 ++++++++++------- + 1 file changed, 10 insertions(+), 7 deletions(-) + +--- a/arch/x86/kernel/entry_32.S ++++ b/arch/x86/kernel/entry_32.S +@@ -98,12 +98,6 @@ + #endif + .endm + +-#ifdef CONFIG_VM86 +-#define resume_userspace_sig check_userspace +-#else +-#define resume_userspace_sig resume_userspace +-#endif +- + /* + * User gs save/restore + * +@@ -327,10 +321,19 @@ ret_from_exception: + preempt_stop(CLBR_ANY) + ret_from_intr: + GET_THREAD_INFO(%ebp) +-check_userspace: ++resume_userspace_sig: ++#ifdef CONFIG_VM86 + movl PT_EFLAGS(%esp), %eax # mix EFLAGS and CS + movb PT_CS(%esp), %al + andl $(X86_EFLAGS_VM | SEGMENT_RPL_MASK), %eax ++#else ++ /* ++ * We can be coming here from a syscall done in the kernel space, ++ * e.g. a failed kernel_execve(). ++ */ ++ movl PT_CS(%esp), %eax ++ andl $SEGMENT_RPL_MASK, %eax ++#endif + cmpl $USER_RPL, %eax + jb resume_kernel # not returning to v8086 or userspace + -- 2.47.3