--- /dev/null
+From 8ed8ab40047a570fdd8043a40c104a57248dd3fd Mon Sep 17 00:00:00 2001
+From: Hari Bathini <hbathini@linux.vnet.ibm.com>
+Date: Fri, 15 Apr 2016 22:48:02 +1000
+Subject: powerpc/book3s64: Fix branching to OOL handlers in relocatable kernel
+
+From: Hari Bathini <hbathini@linux.vnet.ibm.com>
+
+commit 8ed8ab40047a570fdd8043a40c104a57248dd3fd upstream.
+
+Some of the interrupt vectors on 64-bit POWER server processors are only
+32 bytes long (8 instructions), which is not enough for the full
+first-level interrupt handler. For these we need to branch to an
+out-of-line (OOL) handler. But when we are running a relocatable kernel,
+interrupt vectors till __end_interrupts marker are copied down to real
+address 0x100. So, branching to labels (ie. OOL handlers) outside this
+section must be handled differently (see LOAD_HANDLER()), considering
+relocatable kernel, which would need at least 4 instructions.
+
+However, branching from interrupt vector means that we corrupt the
+CFAR (come-from address register) on POWER7 and later processors as
+mentioned in commit 1707dd16. So, EXCEPTION_PROLOG_0 (6 instructions)
+that contains the part up to the point where the CFAR is saved in the
+PACA should be part of the short interrupt vectors before we branch out
+to OOL handlers.
+
+But as mentioned already, there are interrupt vectors on 64-bit POWER
+server processors that are only 32 bytes long (like vectors 0x4f00,
+0x4f20, etc.), which cannot accomodate the above two cases at the same
+time owing to space constraint. Currently, in these interrupt vectors,
+we simply branch out to OOL handlers, without using LOAD_HANDLER(),
+which leaves us vulnerable when running a relocatable kernel (eg. kdump
+case). While this has been the case for sometime now and kdump is used
+widely, we were fortunate not to see any problems so far, for three
+reasons:
+
+ 1. In almost all cases, production kernel (relocatable) is used for
+ kdump as well, which would mean that crashed kernel's OOL handler
+ would be at the same place where we end up branching to, from short
+ interrupt vector of kdump kernel.
+ 2. Also, OOL handler was unlikely the reason for crash in almost all
+ the kdump scenarios, which meant we had a sane OOL handler from
+ crashed kernel that we branched to.
+ 3. On most 64-bit POWER server processors, page size is large enough
+ that marking interrupt vector code as executable (see commit
+ 429d2e83) leads to marking OOL handler code from crashed kernel,
+ that sits right below interrupt vector code from kdump kernel, as
+ executable as well.
+
+Let us fix this by moving the __end_interrupts marker down past OOL
+handlers to make sure that we also copy OOL handlers to real address
+0x100 when running a relocatable kernel.
+
+This fix has been tested successfully in kdump scenario, on an LPAR with
+4K page size by using different default/production kernel and kdump
+kernel.
+
+Also tested by manually corrupting the OOL handlers in the first kernel
+and then kdump'ing, and then causing the OOL handlers to fire - mpe.
+
+Fixes: c1fb6816fb1b ("powerpc: Add relocation on exception vector handlers")
+Signed-off-by: Hari Bathini <hbathini@linux.vnet.ibm.com>
+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/exceptions-64s.S | 16 +++++++++++-----
+ 1 file changed, 11 insertions(+), 5 deletions(-)
+
+--- a/arch/powerpc/kernel/exceptions-64s.S
++++ b/arch/powerpc/kernel/exceptions-64s.S
+@@ -946,11 +946,6 @@ hv_facility_unavailable_relon_trampoline
+ #endif
+ STD_RELON_EXCEPTION_PSERIES(0x5700, 0x1700, altivec_assist)
+
+- /* Other future vectors */
+- .align 7
+- .globl __end_interrupts
+-__end_interrupts:
+-
+ .align 7
+ system_call_entry_direct:
+ #if defined(CONFIG_RELOCATABLE)
+@@ -1304,6 +1299,17 @@ __end_handlers:
+ STD_RELON_EXCEPTION_PSERIES_OOL(0xf60, facility_unavailable)
+ STD_RELON_EXCEPTION_HV_OOL(0xf80, hv_facility_unavailable)
+
++ /*
++ * The __end_interrupts marker must be past the out-of-line (OOL)
++ * handlers, so that they are copied to real address 0x100 when running
++ * a relocatable kernel. This ensures they can be reached from the short
++ * trampoline handlers (like 0x4f00, 0x4f20, etc.) which branch
++ * directly, without using LOAD_HANDLER().
++ */
++ .align 7
++ .globl __end_interrupts
++__end_interrupts:
++
+ #if defined(CONFIG_PPC_PSERIES) || defined(CONFIG_PPC_POWERNV)
+ /*
+ * Data area reserved for FWNMI option.
pci-disable-all-bar-sizing-for-devices-with-non-compliant-bars.patch
rtlwifi-fix-logic-error-in-enter-exit-power-save-mode.patch
pipe-fix-buffer-offset-after-partially-failed-read.patch
+powerpc-book3s64-fix-branching-to-ool-handlers-in-relocatable-kernel.patch
+xen-events-don-t-move-disabled-irqs.patch
+sunrpc-fix-stripping-of-padded-mic-tokens.patch
--- /dev/null
+From c0cb8bf3a8e4bd82e640862cdd8891400405cb89 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Tom=C3=A1=C5=A1=20Trnka?= <ttrnka@mail.muni.cz>
+Date: Fri, 20 May 2016 16:41:10 +0200
+Subject: sunrpc: fix stripping of padded MIC tokens
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Tomáš Trnka <ttrnka@mail.muni.cz>
+
+commit c0cb8bf3a8e4bd82e640862cdd8891400405cb89 upstream.
+
+The length of the GSS MIC token need not be a multiple of four bytes.
+It is then padded by XDR to a multiple of 4 B, but unwrap_integ_data()
+would previously only trim mic.len + 4 B. The remaining up to three
+bytes would then trigger a check in nfs4svc_decode_compoundargs(),
+leading to a "garbage args" error and mount failure:
+
+nfs4svc_decode_compoundargs: compound not properly padded!
+nfsd: failed to decode arguments!
+
+This would prevent older clients using the pre-RFC 4121 MIC format
+(37-byte MIC including a 9-byte OID) from mounting exports from v3.9+
+servers using krb5i.
+
+The trimming was introduced by commit 4c190e2f913f ("sunrpc: trim off
+trailing checksum before returning decrypted or integrity authenticated
+buffer").
+
+Fixes: 4c190e2f913f "unrpc: trim off trailing checksum..."
+Signed-off-by: Tomáš Trnka <ttrnka@mail.muni.cz>
+Acked-by: Jeff Layton <jlayton@poochiereds.net>
+Signed-off-by: J. Bruce Fields <bfields@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ net/sunrpc/auth_gss/svcauth_gss.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/net/sunrpc/auth_gss/svcauth_gss.c
++++ b/net/sunrpc/auth_gss/svcauth_gss.c
+@@ -855,8 +855,8 @@ unwrap_integ_data(struct svc_rqst *rqstp
+ goto out;
+ if (svc_getnl(&buf->head[0]) != seq)
+ goto out;
+- /* trim off the mic at the end before returning */
+- xdr_buf_trim(buf, mic.len + 4);
++ /* trim off the mic and padding at the end before returning */
++ xdr_buf_trim(buf, round_up_to_quad(mic.len) + 4);
+ stat = 0;
+ out:
+ kfree(mic.data);
--- /dev/null
+From f0f393877c71ad227d36705d61d1e4062bc29cf5 Mon Sep 17 00:00:00 2001
+From: Ross Lagerwall <ross.lagerwall@citrix.com>
+Date: Tue, 10 May 2016 16:11:00 +0100
+Subject: xen/events: Don't move disabled irqs
+
+From: Ross Lagerwall <ross.lagerwall@citrix.com>
+
+commit f0f393877c71ad227d36705d61d1e4062bc29cf5 upstream.
+
+Commit ff1e22e7a638 ("xen/events: Mask a moving irq") open-coded
+irq_move_irq() but left out checking if the IRQ is disabled. This broke
+resuming from suspend since it tries to move a (disabled) irq without
+holding the IRQ's desc->lock. Fix it by adding in a check for disabled
+IRQs.
+
+The resulting stacktrace was:
+kernel BUG at /build/linux-UbQGH5/linux-4.4.0/kernel/irq/migration.c:31!
+invalid opcode: 0000 [#1] SMP
+Modules linked in: xenfs xen_privcmd ...
+CPU: 0 PID: 9 Comm: migration/0 Not tainted 4.4.0-22-generic #39-Ubuntu
+Hardware name: Xen HVM domU, BIOS 4.6.1-xs125180 05/04/2016
+task: ffff88003d75ee00 ti: ffff88003d7bc000 task.ti: ffff88003d7bc000
+RIP: 0010:[<ffffffff810e26e2>] [<ffffffff810e26e2>] irq_move_masked_irq+0xd2/0xe0
+RSP: 0018:ffff88003d7bfc50 EFLAGS: 00010046
+RAX: 0000000000000000 RBX: ffff88003d40ba00 RCX: 0000000000000001
+RDX: 0000000000000001 RSI: 0000000000000100 RDI: ffff88003d40bad8
+RBP: ffff88003d7bfc68 R08: 0000000000000000 R09: ffff88003d000000
+R10: 0000000000000000 R11: 000000000000023c R12: ffff88003d40bad0
+R13: ffffffff81f3a4a0 R14: 0000000000000010 R15: 00000000ffffffff
+FS: 0000000000000000(0000) GS:ffff88003da00000(0000) knlGS:0000000000000000
+CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
+CR2: 00007fd4264de624 CR3: 0000000037922000 CR4: 00000000003406f0
+DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
+DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
+Stack:
+ ffff88003d40ba38 0000000000000024 0000000000000000 ffff88003d7bfca0
+ ffffffff814c8d92 00000010813ef89d 00000000805ea732 0000000000000009
+ 0000000000000024 ffff88003cc39b80 ffff88003d7bfce0 ffffffff814c8f66
+Call Trace:
+ [<ffffffff814c8d92>] eoi_pirq+0xb2/0xf0
+ [<ffffffff814c8f66>] __startup_pirq+0xe6/0x150
+ [<ffffffff814ca659>] xen_irq_resume+0x319/0x360
+ [<ffffffff814c7e75>] xen_suspend+0xb5/0x180
+ [<ffffffff81120155>] multi_cpu_stop+0xb5/0xe0
+ [<ffffffff811200a0>] ? cpu_stop_queue_work+0x80/0x80
+ [<ffffffff811203d0>] cpu_stopper_thread+0xb0/0x140
+ [<ffffffff810a94e6>] ? finish_task_switch+0x76/0x220
+ [<ffffffff810ca731>] ? __raw_callee_save___pv_queued_spin_unlock+0x11/0x20
+ [<ffffffff810a3935>] smpboot_thread_fn+0x105/0x160
+ [<ffffffff810a3830>] ? sort_range+0x30/0x30
+ [<ffffffff810a0588>] kthread+0xd8/0xf0
+ [<ffffffff810a04b0>] ? kthread_create_on_node+0x1e0/0x1e0
+ [<ffffffff8182568f>] ret_from_fork+0x3f/0x70
+ [<ffffffff810a04b0>] ? kthread_create_on_node+0x1e0/0x1e0
+
+Signed-off-by: Ross Lagerwall <ross.lagerwall@citrix.com>
+Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
+Signed-off-by: David Vrabel <david.vrabel@citrix.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/xen/events/events_base.c | 6 ++++--
+ 1 file changed, 4 insertions(+), 2 deletions(-)
+
+--- a/drivers/xen/events/events_base.c
++++ b/drivers/xen/events/events_base.c
+@@ -506,7 +506,8 @@ static void eoi_pirq(struct irq_data *da
+ if (!VALID_EVTCHN(evtchn))
+ return;
+
+- if (unlikely(irqd_is_setaffinity_pending(data))) {
++ if (unlikely(irqd_is_setaffinity_pending(data)) &&
++ likely(!irqd_irq_disabled(data))) {
+ int masked = test_and_set_mask(evtchn);
+
+ clear_evtchn(evtchn);
+@@ -1408,7 +1409,8 @@ static void ack_dynirq(struct irq_data *
+ if (!VALID_EVTCHN(evtchn))
+ return;
+
+- if (unlikely(irqd_is_setaffinity_pending(data))) {
++ if (unlikely(irqd_is_setaffinity_pending(data)) &&
++ likely(!irqd_irq_disabled(data))) {
+ int masked = test_and_set_mask(evtchn);
+
+ clear_evtchn(evtchn);
projects / thirdparty / kernel / stable-queue.git / commitdiff
