--- /dev/null
+From fc0900cbda9243957d812cd6b4cc87965f9fe75f Mon Sep 17 00:00:00 2001
+From: Andreas Herrmann <andreas.herrmann3@amd.com>
+Date: Fri, 23 Mar 2012 10:02:17 +0100
+Subject: hwmon: (fam15h_power) Correct sign extension of running_avg_capture
+
+From: Andreas Herrmann <andreas.herrmann3@amd.com>
+
+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 <andre.przywara@amd.com>
+Signed-off-by: Andreas Herrmann <andreas.herrmann3@amd.com>
+Acked-by: Guenter Roeck <guenter.roeck@ericsson.com>
+Signed-off-by: Jean Delvare <khali@linux-fr.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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),
--- /dev/null
+From 1b26c9b334044cff6d1d2698f2be41bc7d9a0864 Mon Sep 17 00:00:00 2001
+From: Pravin B Shelar <pshelar@nicira.com>
+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 <pshelar@nicira.com>
+
+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" <ebiederm@xmission.com>
+Reported-by: Justin Pettit <jpettit@nicira.com>
+Signed-off-by: Pravin B Shelar <pshelar@nicira.com>
+Signed-off-by: Jesse Gross <jesse@nicira.com>
+Cc: David Miller <davem@davemloft.net>
+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>
+
+---
+ 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))
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
--- /dev/null
+From 29a2e2836ff9ea65a603c89df217f4198973a74f Mon Sep 17 00:00:00 2001
+From: Dmitry Adamushko <dmitry.adamushko@gmail.com>
+Date: Thu, 22 Mar 2012 21:39:25 +0100
+Subject: x86-32: Fix endless loop when processing signals for kernel tasks
+
+From: Dmitry Adamushko <dmitry.adamushko@gmail.com>
+
+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 <dmitry.adamushko@gmail.com>
+Link: http://lkml.kernel.org/r/1332448765.2299.68.camel@dimm
+Cc: Oleg Nesterov <oleg@redhat.com>
+Cc: Roland McGrath <roland@hack.frob.com>
+Cc: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: H. Peter Anvin <hpa@zytor.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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
+