]> git.ipfire.org Git - thirdparty/kernel/stable-queue.git/commitdiff
3.10-stable patches
authorGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Fri, 12 Feb 2016 20:59:53 +0000 (12:59 -0800)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Fri, 12 Feb 2016 20:59:53 +0000 (12:59 -0800)
added patches:
kernel-signal.c-unexport-sigsuspend.patch
ocfs2-dlm-clear-refmap-bit-of-recovery-lock-while-doing-local-recovery-cleanup.patch
ocfs2-dlm-ignore-cleaning-the-migration-mle-that-is-inuse.patch
remoteproc-avoid-stack-overflow-in-debugfs-file.patch
sh64-fix-__nr_fgetxattr.patch

queue-3.10/kernel-signal.c-unexport-sigsuspend.patch [new file with mode: 0644]
queue-3.10/ocfs2-dlm-clear-refmap-bit-of-recovery-lock-while-doing-local-recovery-cleanup.patch [new file with mode: 0644]
queue-3.10/ocfs2-dlm-ignore-cleaning-the-migration-mle-that-is-inuse.patch [new file with mode: 0644]
queue-3.10/remoteproc-avoid-stack-overflow-in-debugfs-file.patch [new file with mode: 0644]
queue-3.10/series
queue-3.10/sh64-fix-__nr_fgetxattr.patch [new file with mode: 0644]

diff --git a/queue-3.10/kernel-signal.c-unexport-sigsuspend.patch b/queue-3.10/kernel-signal.c-unexport-sigsuspend.patch
new file mode 100644 (file)
index 0000000..d40b037
--- /dev/null
@@ -0,0 +1,64 @@
+From 9d8a765211335cfdad464b90fb19f546af5706ae Mon Sep 17 00:00:00 2001
+From: Richard Weinberger <richard@nod.at>
+Date: Fri, 20 Nov 2015 15:57:21 -0800
+Subject: kernel/signal.c: unexport sigsuspend()
+
+From: Richard Weinberger <richard@nod.at>
+
+commit 9d8a765211335cfdad464b90fb19f546af5706ae upstream.
+
+sigsuspend() is nowhere used except in signal.c itself, so we can mark it
+static do not pollute the global namespace.
+
+But this patch is more than a boring cleanup patch, it fixes a real issue
+on UserModeLinux.  UML has a special console driver to display ttys using
+xterm, or other terminal emulators, on the host side.  Vegard reported
+that sometimes UML is unable to spawn a xterm and he's facing the
+following warning:
+
+  WARNING: CPU: 0 PID: 908 at include/linux/thread_info.h:128 sigsuspend+0xab/0xc0()
+
+It turned out that this warning makes absolutely no sense as the UML
+xterm code calls sigsuspend() on the host side, at least it tries.  But
+as the kernel itself offers a sigsuspend() symbol the linker choose this
+one instead of the glibc wrapper.  Interestingly this code used to work
+since ever but always blocked signals on the wrong side.  Some recent
+kernel change made the WARN_ON() trigger and uncovered the bug.
+
+It is a wonderful example of how much works by chance on computers. :-)
+
+Fixes: 68f3f16d9ad0f1 ("new helper: sigsuspend()")
+Signed-off-by: Richard Weinberger <richard@nod.at>
+Reported-by: Vegard Nossum <vegard.nossum@oracle.com>
+Tested-by: Vegard Nossum <vegard.nossum@oracle.com>
+Acked-by: Oleg Nesterov <oleg@redhat.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>
+
+---
+ include/linux/signal.h |    1 -
+ kernel/signal.c        |    2 +-
+ 2 files changed, 1 insertion(+), 2 deletions(-)
+
+--- a/include/linux/signal.h
++++ b/include/linux/signal.h
+@@ -247,7 +247,6 @@ extern int sigprocmask(int, sigset_t *,
+ extern void set_current_blocked(sigset_t *);
+ extern void __set_current_blocked(const sigset_t *);
+ extern int show_unhandled_signals;
+-extern int sigsuspend(sigset_t *);
+ struct sigaction {
+ #ifndef __ARCH_HAS_IRIX_SIGACTION
+--- a/kernel/signal.c
++++ b/kernel/signal.c
+@@ -3551,7 +3551,7 @@ SYSCALL_DEFINE0(pause)
+ #endif
+-int sigsuspend(sigset_t *set)
++static int sigsuspend(sigset_t *set)
+ {
+       current->saved_sigmask = current->blocked;
+       set_current_blocked(set);
diff --git a/queue-3.10/ocfs2-dlm-clear-refmap-bit-of-recovery-lock-while-doing-local-recovery-cleanup.patch b/queue-3.10/ocfs2-dlm-clear-refmap-bit-of-recovery-lock-while-doing-local-recovery-cleanup.patch
new file mode 100644 (file)
index 0000000..90c9799
--- /dev/null
@@ -0,0 +1,38 @@
+From c95a51807b730e4681e2ecbdfd669ca52601959e Mon Sep 17 00:00:00 2001
+From: xuejiufei <xuejiufei@huawei.com>
+Date: Fri, 5 Feb 2016 15:36:47 -0800
+Subject: ocfs2/dlm: clear refmap bit of recovery lock while doing local recovery cleanup
+
+From: xuejiufei <xuejiufei@huawei.com>
+
+commit c95a51807b730e4681e2ecbdfd669ca52601959e upstream.
+
+When recovery master down, dlm_do_local_recovery_cleanup() only remove
+the $RECOVERY lock owned by dead node, but do not clear the refmap bit.
+Which will make umount thread falling in dead loop migrating $RECOVERY
+to the dead node.
+
+Signed-off-by: xuejiufei <xuejiufei@huawei.com>
+Reviewed-by: Joseph Qi <joseph.qi@huawei.com>
+Cc: Mark Fasheh <mfasheh@suse.de>
+Cc: Joel Becker <jlbec@evilplan.org>
+Cc: Junxiao Bi <junxiao.bi@oracle.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>
+
+---
+ fs/ocfs2/dlm/dlmrecovery.c |    2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/fs/ocfs2/dlm/dlmrecovery.c
++++ b/fs/ocfs2/dlm/dlmrecovery.c
+@@ -2326,6 +2326,8 @@ static void dlm_do_local_recovery_cleanu
+                                               break;
+                                       }
+                               }
++                              dlm_lockres_clear_refmap_bit(dlm, res,
++                                              dead_node);
+                               spin_unlock(&res->spinlock);
+                               continue;
+                       }
diff --git a/queue-3.10/ocfs2-dlm-ignore-cleaning-the-migration-mle-that-is-inuse.patch b/queue-3.10/ocfs2-dlm-ignore-cleaning-the-migration-mle-that-is-inuse.patch
new file mode 100644 (file)
index 0000000..165f023
--- /dev/null
@@ -0,0 +1,97 @@
+From bef5502de074b6f6fa647b94b73155d675694420 Mon Sep 17 00:00:00 2001
+From: xuejiufei <xuejiufei@huawei.com>
+Date: Thu, 14 Jan 2016 15:17:38 -0800
+Subject: ocfs2/dlm: ignore cleaning the migration mle that is inuse
+
+From: xuejiufei <xuejiufei@huawei.com>
+
+commit bef5502de074b6f6fa647b94b73155d675694420 upstream.
+
+We have found that migration source will trigger a BUG that the refcount
+of mle is already zero before put when the target is down during
+migration.  The situation is as follows:
+
+dlm_migrate_lockres
+  dlm_add_migration_mle
+  dlm_mark_lockres_migrating
+  dlm_get_mle_inuse
+  <<<<<< Now the refcount of the mle is 2.
+  dlm_send_one_lockres and wait for the target to become the
+  new master.
+  <<<<<< o2hb detect the target down and clean the migration
+  mle. Now the refcount is 1.
+
+dlm_migrate_lockres woken, and put the mle twice when found the target
+goes down which trigger the BUG with the following message:
+
+  "ERROR: bad mle: ".
+
+Signed-off-by: Jiufei Xue <xuejiufei@huawei.com>
+Reviewed-by: Joseph Qi <joseph.qi@huawei.com>
+Cc: Mark Fasheh <mfasheh@suse.de>
+Cc: Joel Becker <jlbec@evilplan.org>
+Cc: Junxiao Bi <junxiao.bi@oracle.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>
+
+---
+ fs/ocfs2/dlm/dlmmaster.c |   26 +++++++++++++++-----------
+ 1 file changed, 15 insertions(+), 11 deletions(-)
+
+--- a/fs/ocfs2/dlm/dlmmaster.c
++++ b/fs/ocfs2/dlm/dlmmaster.c
+@@ -2456,6 +2456,11 @@ static int dlm_migrate_lockres(struct dl
+       spin_lock(&dlm->master_lock);
+       ret = dlm_add_migration_mle(dlm, res, mle, &oldmle, name,
+                                   namelen, target, dlm->node_num);
++      /* get an extra reference on the mle.
++       * otherwise the assert_master from the new
++       * master will destroy this.
++       */
++      dlm_get_mle_inuse(mle);
+       spin_unlock(&dlm->master_lock);
+       spin_unlock(&dlm->spinlock);
+@@ -2491,6 +2496,7 @@ fail:
+               if (mle_added) {
+                       dlm_mle_detach_hb_events(dlm, mle);
+                       dlm_put_mle(mle);
++                      dlm_put_mle_inuse(mle);
+               } else if (mle) {
+                       kmem_cache_free(dlm_mle_cache, mle);
+                       mle = NULL;
+@@ -2508,17 +2514,6 @@ fail:
+        * ensure that all assert_master work is flushed. */
+       flush_workqueue(dlm->dlm_worker);
+-      /* get an extra reference on the mle.
+-       * otherwise the assert_master from the new
+-       * master will destroy this.
+-       * also, make sure that all callers of dlm_get_mle
+-       * take both dlm->spinlock and dlm->master_lock */
+-      spin_lock(&dlm->spinlock);
+-      spin_lock(&dlm->master_lock);
+-      dlm_get_mle_inuse(mle);
+-      spin_unlock(&dlm->master_lock);
+-      spin_unlock(&dlm->spinlock);
+-
+       /* notify new node and send all lock state */
+       /* call send_one_lockres with migration flag.
+        * this serves as notice to the target node that a
+@@ -3246,6 +3241,15 @@ top:
+                           mle->new_master != dead_node)
+                               continue;
++                      if (mle->new_master == dead_node && mle->inuse) {
++                              mlog(ML_NOTICE, "%s: target %u died during "
++                                              "migration from %u, the MLE is "
++                                              "still keep used, ignore it!\n",
++                                              dlm->name, dead_node,
++                                              mle->master);
++                              continue;
++                      }
++
+                       /* If we have reached this point, this mle needs to be
+                        * removed from the list and freed. */
+                       dlm_clean_migration_mle(dlm, mle);
diff --git a/queue-3.10/remoteproc-avoid-stack-overflow-in-debugfs-file.patch b/queue-3.10/remoteproc-avoid-stack-overflow-in-debugfs-file.patch
new file mode 100644 (file)
index 0000000..694732e
--- /dev/null
@@ -0,0 +1,40 @@
+From 92792e48e2ae6051af30468a87994b5432da2f06 Mon Sep 17 00:00:00 2001
+From: Arnd Bergmann <arnd@arndb.de>
+Date: Fri, 20 Nov 2015 18:26:07 +0100
+Subject: remoteproc: avoid stack overflow in debugfs file
+
+From: Arnd Bergmann <arnd@arndb.de>
+
+commit 92792e48e2ae6051af30468a87994b5432da2f06 upstream.
+
+Recent gcc versions warn about reading from a negative offset of
+an on-stack array:
+
+drivers/remoteproc/remoteproc_debugfs.c: In function 'rproc_recovery_write':
+drivers/remoteproc/remoteproc_debugfs.c:167:9: warning: 'buf[4294967295u]' may be used uninitialized in this function [-Wmaybe-uninitialized]
+
+I don't see anything in sys_write() that prevents us from
+being called with a zero 'count' argument, so we should
+add an extra check in rproc_recovery_write() to prevent the
+access and avoid the warning.
+
+Signed-off-by: Arnd Bergmann <arnd@arndb.de>
+Fixes: 2e37abb89a2e ("remoteproc: create a 'recovery' debugfs entry")
+Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/remoteproc/remoteproc_debugfs.c |    2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/remoteproc/remoteproc_debugfs.c
++++ b/drivers/remoteproc/remoteproc_debugfs.c
+@@ -156,7 +156,7 @@ rproc_recovery_write(struct file *filp,
+       char buf[10];
+       int ret;
+-      if (count > sizeof(buf))
++      if (count < 1 || count > sizeof(buf))
+               return count;
+       ret = copy_from_user(buf, user_buf, count);
index e6868474890ff806f4b419882eb3d352e44b00e9..dff47c627f7e7f79163bb7ade0960876d75ec3a0 100644 (file)
@@ -3,3 +3,8 @@ xhci-fix-placement-of-call-to-usb_disabled.patch
 crypto-algif_hash-only-export-and-import-on-sockets-with-data.patch
 dm-btree-fix-leak-of-bufio-backed-block-in-btree_split_sibling-error-path.patch
 hid-usbhid-fix-recursive-deadlock.patch
+remoteproc-avoid-stack-overflow-in-debugfs-file.patch
+kernel-signal.c-unexport-sigsuspend.patch
+ocfs2-dlm-ignore-cleaning-the-migration-mle-that-is-inuse.patch
+ocfs2-dlm-clear-refmap-bit-of-recovery-lock-while-doing-local-recovery-cleanup.patch
+sh64-fix-__nr_fgetxattr.patch
diff --git a/queue-3.10/sh64-fix-__nr_fgetxattr.patch b/queue-3.10/sh64-fix-__nr_fgetxattr.patch
new file mode 100644 (file)
index 0000000..b2d552c
--- /dev/null
@@ -0,0 +1,37 @@
+From 2d33fa1059da4c8e816627a688d950b613ec0474 Mon Sep 17 00:00:00 2001
+From: "Dmitry V. Levin" <ldv@altlinux.org>
+Date: Fri, 11 Dec 2015 13:41:06 -0800
+Subject: sh64: fix __NR_fgetxattr
+
+From: Dmitry V. Levin <ldv@altlinux.org>
+
+commit 2d33fa1059da4c8e816627a688d950b613ec0474 upstream.
+
+According to arch/sh/kernel/syscalls_64.S and common sense, __NR_fgetxattr
+has to be defined to 259, but it doesn't.  Instead, it's defined to 269,
+which is of course used by another syscall, __NR_sched_setaffinity in this
+case.
+
+This bug was found by strace test suite.
+
+Signed-off-by: Dmitry V. Levin <ldv@altlinux.org>
+Acked-by: Geert Uytterhoeven <geert+renesas@glider.be>
+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>
+
+---
+ arch/sh/include/uapi/asm/unistd_64.h |    2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/arch/sh/include/uapi/asm/unistd_64.h
++++ b/arch/sh/include/uapi/asm/unistd_64.h
+@@ -278,7 +278,7 @@
+ #define __NR_fsetxattr                256
+ #define __NR_getxattr         257
+ #define __NR_lgetxattr                258
+-#define __NR_fgetxattr                269
++#define __NR_fgetxattr                259
+ #define __NR_listxattr                260
+ #define __NR_llistxattr               261
+ #define __NR_flistxattr               262