--- /dev/null
+From 76ed0b803a2ab793a1b27d1dfe0de7955282cd34 Mon Sep 17 00:00:00 2001
+From: David Rivshin <DRivshin@allworx.com>
+Date: Wed, 25 Apr 2018 21:15:01 +0100
+Subject: ARM: 8764/1: kgdb: fix NUMREGBYTES so that gdb_regs[] is the correct size
+
+From: David Rivshin <DRivshin@allworx.com>
+
+commit 76ed0b803a2ab793a1b27d1dfe0de7955282cd34 upstream.
+
+NUMREGBYTES (which is used as the size for gdb_regs[]) is incorrectly
+based on DBG_MAX_REG_NUM instead of GDB_MAX_REGS. DBG_MAX_REG_NUM
+is the number of total registers, while GDB_MAX_REGS is the number
+of 'unsigned longs' it takes to serialize those registers. Since
+FP registers require 3 'unsigned longs' each, DBG_MAX_REG_NUM is
+smaller than GDB_MAX_REGS.
+
+This causes GDB 8.0 give the following error on connect:
+"Truncated register 19 in remote 'g' packet"
+
+This also causes the register serialization/deserialization logic
+to overflow gdb_regs[], overwriting whatever follows.
+
+Fixes: 834b2964b7ab ("kgdb,arm: fix register dump")
+Cc: <stable@vger.kernel.org> # 2.6.37+
+Signed-off-by: David Rivshin <drivshin@allworx.com>
+Acked-by: Rabin Vincent <rabin@rab.in>
+Tested-by: Daniel Thompson <daniel.thompson@linaro.org>
+Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/arm/include/asm/kgdb.h | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/arch/arm/include/asm/kgdb.h
++++ b/arch/arm/include/asm/kgdb.h
+@@ -76,7 +76,7 @@ extern int kgdb_fault_expected;
+
+ #define KGDB_MAX_NO_CPUS 1
+ #define BUFMAX 400
+-#define NUMREGBYTES (DBG_MAX_REG_NUM << 2)
++#define NUMREGBYTES (GDB_MAX_REGS << 2)
+ #define NUMCRITREGBYTES (32 << 2)
+
+ #define _R0 0
--- /dev/null
+From 2026d35741f2c3ece73c11eb7e4a15d7c2df9ebe Mon Sep 17 00:00:00 2001
+From: Mikulas Patocka <mpatocka@redhat.com>
+Date: Wed, 30 May 2018 08:19:22 -0400
+Subject: branch-check: fix long->int truncation when profiling branches
+
+From: Mikulas Patocka <mpatocka@redhat.com>
+
+commit 2026d35741f2c3ece73c11eb7e4a15d7c2df9ebe upstream.
+
+The function __builtin_expect returns long type (see the gcc
+documentation), and so do macros likely and unlikely. Unfortunatelly, when
+CONFIG_PROFILE_ANNOTATED_BRANCHES is selected, the macros likely and
+unlikely expand to __branch_check__ and __branch_check__ truncates the
+long type to int. This unintended truncation may cause bugs in various
+kernel code (we found a bug in dm-writecache because of it), so it's
+better to fix __branch_check__ to return long.
+
+Link: http://lkml.kernel.org/r/alpine.LRH.2.02.1805300818140.24812@file01.intranet.prod.int.rdu2.redhat.com
+
+Cc: Ingo Molnar <mingo@redhat.com>
+Cc: stable@vger.kernel.org
+Fixes: 1f0d69a9fc815 ("tracing: profile likely and unlikely annotations")
+Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
+Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ include/linux/compiler.h | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/include/linux/compiler.h
++++ b/include/linux/compiler.h
+@@ -105,7 +105,7 @@ void ftrace_likely_update(struct ftrace_
+ #define unlikely_notrace(x) __builtin_expect(!!(x), 0)
+
+ #define __branch_check__(x, expect) ({ \
+- int ______r; \
++ long ______r; \
+ static struct ftrace_branch_data \
+ __attribute__((__aligned__(4))) \
+ __attribute__((section("_ftrace_annotated_branch"))) \
--- /dev/null
+From df0e91d488276086bc07da2e389986cae0048c37 Mon Sep 17 00:00:00 2001
+From: Miklos Szeredi <mszeredi@redhat.com>
+Date: Thu, 8 Feb 2018 15:17:38 +0100
+Subject: fuse: atomic_o_trunc should truncate pagecache
+
+From: Miklos Szeredi <mszeredi@redhat.com>
+
+commit df0e91d488276086bc07da2e389986cae0048c37 upstream.
+
+Fuse has an "atomic_o_trunc" mode, where userspace filesystem uses the
+O_TRUNC flag in the OPEN request to truncate the file atomically with the
+open.
+
+In this mode there's no need to send a SETATTR request to userspace after
+the open, so fuse_do_setattr() checks this mode and returns. But this
+misses the important step of truncating the pagecache.
+
+Add the missing parts of truncation to the ATTR_OPEN branch.
+
+Reported-by: Chad Austin <chadaustin@fb.com>
+Fixes: 6ff958edbf39 ("fuse: add atomic open+truncate support")
+Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/fuse/dir.c | 13 ++++++++++++-
+ 1 file changed, 12 insertions(+), 1 deletion(-)
+
+--- a/fs/fuse/dir.c
++++ b/fs/fuse/dir.c
+@@ -1717,8 +1717,19 @@ int fuse_do_setattr(struct dentry *dentr
+ return err;
+
+ if (attr->ia_valid & ATTR_OPEN) {
+- if (fc->atomic_o_trunc)
++ /* This is coming from open(..., ... | O_TRUNC); */
++ WARN_ON(!(attr->ia_valid & ATTR_SIZE));
++ WARN_ON(attr->ia_size != 0);
++ if (fc->atomic_o_trunc) {
++ /*
++ * No need to send request to userspace, since actual
++ * truncation has already been done by OPEN. But still
++ * need to truncate page cache.
++ */
++ i_size_write(inode, 0);
++ truncate_pagecache(inode, 0);
+ return 0;
++ }
+ file = NULL;
+ }
+
--- /dev/null
+From 543b8f8662fe6d21f19958b666ab0051af9db21a Mon Sep 17 00:00:00 2001
+From: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
+Date: Tue, 1 May 2018 13:12:14 +0900
+Subject: fuse: don't keep dead fuse_conn at fuse_fill_super().
+
+From: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
+
+commit 543b8f8662fe6d21f19958b666ab0051af9db21a upstream.
+
+syzbot is reporting use-after-free at fuse_kill_sb_blk() [1].
+Since sb->s_fs_info field is not cleared after fc was released by
+fuse_conn_put() when initialization failed, fuse_kill_sb_blk() finds
+already released fc and tries to hold the lock. Fix this by clearing
+sb->s_fs_info field after calling fuse_conn_put().
+
+[1] https://syzkaller.appspot.com/bug?id=a07a680ed0a9290585ca424546860464dd9658db
+
+Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
+Reported-by: syzbot <syzbot+ec3986119086fe4eec97@syzkaller.appspotmail.com>
+Fixes: 3b463ae0c626 ("fuse: invalidation reverse calls")
+Cc: John Muir <john@jmuir.com>
+Cc: Csaba Henk <csaba@gluster.com>
+Cc: Anand Avati <avati@redhat.com>
+Cc: <stable@vger.kernel.org> # v2.6.31
+Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/fuse/inode.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/fs/fuse/inode.c
++++ b/fs/fuse/inode.c
+@@ -1125,6 +1125,7 @@ static int fuse_fill_super(struct super_
+ err_put_conn:
+ fuse_bdi_destroy(fc);
+ fuse_conn_put(fc);
++ sb->s_fs_info = NULL;
+ err_fput:
+ fput(file);
+ err:
--- /dev/null
+From fe50a7d0393a552e4539da2d31261a59d6415950 Mon Sep 17 00:00:00 2001
+From: Corey Minyard <cminyard@mvista.com>
+Date: Tue, 22 May 2018 08:14:51 -0500
+Subject: ipmi:bt: Set the timeout before doing a capabilities check
+
+From: Corey Minyard <cminyard@mvista.com>
+
+commit fe50a7d0393a552e4539da2d31261a59d6415950 upstream.
+
+There was one place where the timeout value for an operation was
+not being set, if a capabilities request was done from idle. Move
+the timeout value setting to before where that change might be
+requested.
+
+IMHO the cause here is the invisible returns in the macros. Maybe
+that's a job for later, though.
+
+Reported-by: Nordmark Claes <Claes.Nordmark@tieto.com>
+Signed-off-by: Corey Minyard <cminyard@mvista.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/char/ipmi/ipmi_bt_sm.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/drivers/char/ipmi/ipmi_bt_sm.c
++++ b/drivers/char/ipmi/ipmi_bt_sm.c
+@@ -522,11 +522,12 @@ static enum si_sm_result bt_event(struct
+ if (status & BT_H_BUSY) /* clear a leftover H_BUSY */
+ BT_CONTROL(BT_H_BUSY);
+
++ bt->timeout = bt->BT_CAP_req2rsp;
++
+ /* Read BT capabilities if it hasn't been done yet */
+ if (!bt->BT_CAP_outreqs)
+ BT_STATE_CHANGE(BT_STATE_CAPABILITIES_BEGIN,
+ SI_SM_CALL_WITHOUT_DELAY);
+- bt->timeout = bt->BT_CAP_req2rsp;
+ BT_SI_SM_RETURN(SI_SM_IDLE);
+
+ case BT_STATE_XACTION_START:
--- /dev/null
+From 722cde76d68e8cc4f3de42e71c82fd40dea4f7b9 Mon Sep 17 00:00:00 2001
+From: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
+Date: Fri, 27 Apr 2018 11:53:18 +0530
+Subject: powerpc/fadump: Unregister fadump on kexec down path.
+
+From: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
+
+commit 722cde76d68e8cc4f3de42e71c82fd40dea4f7b9 upstream.
+
+Unregister fadump on kexec down path otherwise the fadump registration
+in new kexec-ed kernel complains that fadump is already registered.
+This makes new kernel to continue using fadump registered by previous
+kernel which may lead to invalid vmcore generation. Hence this patch
+fixes this issue by un-registering fadump in fadump_cleanup() which is
+called during kexec path so that new kernel can register fadump with
+new valid values.
+
+Fixes: b500afff11f6 ("fadump: Invalidate registration and release reserved memory for general use.")
+Cc: stable@vger.kernel.org # v3.4+
+Signed-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
+Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/powerpc/kernel/fadump.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/arch/powerpc/kernel/fadump.c
++++ b/arch/powerpc/kernel/fadump.c
+@@ -1025,6 +1025,9 @@ void fadump_cleanup(void)
+ init_fadump_mem_struct(&fdm,
+ be64_to_cpu(fdm_active->cpu_state_data.destination_address));
+ fadump_invalidate_dump(&fdm);
++ } else if (fw_dump.dump_registered) {
++ /* Un-register Firmware-assisted dump if it was registered. */
++ fadump_unregister_dump(&fdm);
+ }
+ }
+
--- /dev/null
+From 91d06971881f71d945910de128658038513d1b24 Mon Sep 17 00:00:00 2001
+From: "Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com>
+Date: Wed, 30 May 2018 18:48:04 +0530
+Subject: powerpc/mm/hash: Add missing isync prior to kernel stack SLB switch
+
+From: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
+
+commit 91d06971881f71d945910de128658038513d1b24 upstream.
+
+Currently we do not have an isync, or any other context synchronizing
+instruction prior to the slbie/slbmte in _switch() that updates the
+SLB entry for the kernel stack.
+
+However that is not correct as outlined in the ISA.
+
+From Power ISA Version 3.0B, Book III, Chapter 11, page 1133:
+
+ "Changing the contents of ... the contents of SLB entries ... can
+ have the side effect of altering the context in which data
+ addresses and instruction addresses are interpreted, and in which
+ instructions are executed and data accesses are performed.
+ ...
+ These side effects need not occur in program order, and therefore
+ may require explicit synchronization by software.
+ ...
+ The synchronizing instruction before the context-altering
+ instruction ensures that all instructions up to and including that
+ synchronizing instruction are fetched and executed in the context
+ that existed before the alteration."
+
+And page 1136:
+
+ "For data accesses, the context synchronizing instruction before the
+ slbie, slbieg, slbia, slbmte, tlbie, or tlbiel instruction ensures
+ that all preceding instructions that access data storage have
+ completed to a point at which they have reported all exceptions
+ they will cause."
+
+We're not aware of any bugs caused by this, but it should be fixed
+regardless.
+
+Add the missing isync when updating kernel stack SLB entry.
+
+Cc: stable@vger.kernel.org
+Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
+[mpe: Flesh out change log with more ISA text & explanation]
+Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/powerpc/kernel/entry_64.S | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/arch/powerpc/kernel/entry_64.S
++++ b/arch/powerpc/kernel/entry_64.S
+@@ -521,6 +521,7 @@ END_MMU_FTR_SECTION_IFSET(MMU_FTR_1T_SEG
+ * actually hit this code path.
+ */
+
++ isync
+ slbie r6
+ slbie r6 /* Workaround POWER5 < DD2.1 issue */
+ slbmte r7,r0
--- /dev/null
+From cd6ef7eebf171bfcba7dc2df719c2a4958775040 Mon Sep 17 00:00:00 2001
+From: Michael Neuling <mikey@neuling.org>
+Date: Thu, 17 May 2018 15:37:14 +1000
+Subject: powerpc/ptrace: Fix enforcement of DAWR constraints
+
+From: Michael Neuling <mikey@neuling.org>
+
+commit cd6ef7eebf171bfcba7dc2df719c2a4958775040 upstream.
+
+Back when we first introduced the DAWR, in commit 4ae7ebe9522a
+("powerpc: Change hardware breakpoint to allow longer ranges"), we
+screwed up the constraint making it a 1024 byte boundary rather than a
+512. This makes the check overly permissive. Fortunately GDB is the
+only real user and it always did they right thing, so we never
+noticed.
+
+This fixes the constraint to 512 bytes.
+
+Fixes: 4ae7ebe9522a ("powerpc: Change hardware breakpoint to allow longer ranges")
+Cc: stable@vger.kernel.org # v3.9+
+Signed-off-by: Michael Neuling <mikey@neuling.org>
+Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/powerpc/kernel/hw_breakpoint.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/arch/powerpc/kernel/hw_breakpoint.c
++++ b/arch/powerpc/kernel/hw_breakpoint.c
+@@ -174,8 +174,8 @@ int arch_validate_hwbkpt_settings(struct
+ if (cpu_has_feature(CPU_FTR_DAWR)) {
+ length_max = 512 ; /* 64 doublewords */
+ /* DAWR region can't cross 512 boundary */
+- if ((bp->attr.bp_addr >> 10) !=
+- ((bp->attr.bp_addr + bp->attr.bp_len - 1) >> 10))
++ if ((bp->attr.bp_addr >> 9) !=
++ ((bp->attr.bp_addr + bp->attr.bp_len - 1) >> 9))
+ return -EINVAL;
+ }
+ if (info->len >
--- /dev/null
+From 4f7c06e26ec9cf7fe9f0c54dc90079b6a4f4b2c3 Mon Sep 17 00:00:00 2001
+From: Michael Neuling <mikey@neuling.org>
+Date: Thu, 17 May 2018 15:37:15 +1000
+Subject: powerpc/ptrace: Fix setting 512B aligned breakpoints with PTRACE_SET_DEBUGREG
+
+From: Michael Neuling <mikey@neuling.org>
+
+commit 4f7c06e26ec9cf7fe9f0c54dc90079b6a4f4b2c3 upstream.
+
+In commit e2a800beaca1 ("powerpc/hw_brk: Fix off by one error when
+validating DAWR region end") we fixed setting the DAWR end point to
+its max value via PPC_PTRACE_SETHWDEBUG. Unfortunately we broke
+PTRACE_SET_DEBUGREG when setting a 512 byte aligned breakpoint.
+
+PTRACE_SET_DEBUGREG currently sets the length of the breakpoint to
+zero (memset() in hw_breakpoint_init()). This worked with
+arch_validate_hwbkpt_settings() before the above patch was applied but
+is now broken if the breakpoint is 512byte aligned.
+
+This sets the length of the breakpoint to 8 bytes when using
+PTRACE_SET_DEBUGREG.
+
+Fixes: e2a800beaca1 ("powerpc/hw_brk: Fix off by one error when validating DAWR region end")
+Cc: stable@vger.kernel.org # v3.11+
+Signed-off-by: Michael Neuling <mikey@neuling.org>
+Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/powerpc/kernel/ptrace.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/arch/powerpc/kernel/ptrace.c
++++ b/arch/powerpc/kernel/ptrace.c
+@@ -1004,6 +1004,7 @@ static int ptrace_set_debugreg(struct ta
+ /* Create a new breakpoint request if one doesn't exist already */
+ hw_breakpoint_init(&attr);
+ attr.bp_addr = hw_brk.address;
++ attr.bp_len = 8;
+ arch_bp_generic_fields(hw_brk.type,
+ &attr.bp_type);
+
asoc-cirrus-i2s-fix-lrclk-configuration.patch
asoc-cirrus-i2s-fix-tx-rx-linctrldata-setup.patch
mips-ftrace-fix-static-function-graph-tracing.patch
+branch-check-fix-long-int-truncation-when-profiling-branches.patch
+ipmi-bt-set-the-timeout-before-doing-a-capabilities-check.patch
+fuse-atomic_o_trunc-should-truncate-pagecache.patch
+fuse-don-t-keep-dead-fuse_conn-at-fuse_fill_super.patch
+powerpc-mm-hash-add-missing-isync-prior-to-kernel-stack-slb-switch.patch
+powerpc-ptrace-fix-setting-512b-aligned-breakpoints-with-ptrace_set_debugreg.patch
+powerpc-ptrace-fix-enforcement-of-dawr-constraints.patch
+powerpc-fadump-unregister-fadump-on-kexec-down-path.patch
+arm-8764-1-kgdb-fix-numregbytes-so-that-gdb_regs-is-the-correct-size.patch
projects / thirdparty / kernel / stable-queue.git / commitdiff
