From: Greg Kroah-Hartman Date: Fri, 12 Feb 2016 20:59:53 +0000 (-0800) Subject: 3.10-stable patches X-Git-Tag: v4.4.2~45 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=81753cb66a0a4feb0d60bd90fc63d8beccd974db;p=thirdparty%2Fkernel%2Fstable-queue.git 3.10-stable patches 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 --- 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 index 00000000000..d40b03761e7 --- /dev/null +++ b/queue-3.10/kernel-signal.c-unexport-sigsuspend.patch @@ -0,0 +1,64 @@ +From 9d8a765211335cfdad464b90fb19f546af5706ae Mon Sep 17 00:00:00 2001 +From: Richard Weinberger +Date: Fri, 20 Nov 2015 15:57:21 -0800 +Subject: kernel/signal.c: unexport sigsuspend() + +From: Richard Weinberger + +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 +Reported-by: Vegard Nossum +Tested-by: Vegard Nossum +Acked-by: Oleg Nesterov +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman + +--- + 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 index 00000000000..90c9799b781 --- /dev/null +++ b/queue-3.10/ocfs2-dlm-clear-refmap-bit-of-recovery-lock-while-doing-local-recovery-cleanup.patch @@ -0,0 +1,38 @@ +From c95a51807b730e4681e2ecbdfd669ca52601959e Mon Sep 17 00:00:00 2001 +From: xuejiufei +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 + +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 +Reviewed-by: Joseph Qi +Cc: Mark Fasheh +Cc: Joel Becker +Cc: Junxiao Bi +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman + +--- + 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 index 00000000000..165f0236985 --- /dev/null +++ b/queue-3.10/ocfs2-dlm-ignore-cleaning-the-migration-mle-that-is-inuse.patch @@ -0,0 +1,97 @@ +From bef5502de074b6f6fa647b94b73155d675694420 Mon Sep 17 00:00:00 2001 +From: xuejiufei +Date: Thu, 14 Jan 2016 15:17:38 -0800 +Subject: ocfs2/dlm: ignore cleaning the migration mle that is inuse + +From: xuejiufei + +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 +Reviewed-by: Joseph Qi +Cc: Mark Fasheh +Cc: Joel Becker +Cc: Junxiao Bi +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman + +--- + 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 index 00000000000..694732e8e39 --- /dev/null +++ b/queue-3.10/remoteproc-avoid-stack-overflow-in-debugfs-file.patch @@ -0,0 +1,40 @@ +From 92792e48e2ae6051af30468a87994b5432da2f06 Mon Sep 17 00:00:00 2001 +From: Arnd Bergmann +Date: Fri, 20 Nov 2015 18:26:07 +0100 +Subject: remoteproc: avoid stack overflow in debugfs file + +From: Arnd Bergmann + +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 +Fixes: 2e37abb89a2e ("remoteproc: create a 'recovery' debugfs entry") +Signed-off-by: Ohad Ben-Cohen +Signed-off-by: Greg Kroah-Hartman + +--- + 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); diff --git a/queue-3.10/series b/queue-3.10/series index e6868474890..dff47c627f7 100644 --- a/queue-3.10/series +++ b/queue-3.10/series @@ -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 index 00000000000..b2d552c69df --- /dev/null +++ b/queue-3.10/sh64-fix-__nr_fgetxattr.patch @@ -0,0 +1,37 @@ +From 2d33fa1059da4c8e816627a688d950b613ec0474 Mon Sep 17 00:00:00 2001 +From: "Dmitry V. Levin" +Date: Fri, 11 Dec 2015 13:41:06 -0800 +Subject: sh64: fix __NR_fgetxattr + +From: Dmitry V. Levin + +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 +Acked-by: Geert Uytterhoeven +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman + +--- + 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