--- /dev/null
+From 4a75aeacda3c2455954596593d89187df5420d0a Mon Sep 17 00:00:00 2001
+From: James Morse <james.morse@arm.com>
+Date: Mon, 6 Nov 2017 18:44:27 +0000
+Subject: ACPI / APEI: Remove arch_apei_flush_tlb_one()
+
+From: James Morse <james.morse@arm.com>
+
+commit 4a75aeacda3c2455954596593d89187df5420d0a upstream.
+
+Nothing calls arch_apei_flush_tlb_one() anymore, instead relying on
+__set_pte_vaddr() to do the invalidation when called from clear_fixmap()
+Remove arch_apei_flush_tlb_one().
+
+Signed-off-by: James Morse <james.morse@arm.com>
+Reviewed-by: Borislav Petkov <bp@suse.de>
+Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/x86/kernel/acpi/apei.c | 5 -----
+ include/acpi/apei.h | 1 -
+ 2 files changed, 6 deletions(-)
+
+--- a/arch/x86/kernel/acpi/apei.c
++++ b/arch/x86/kernel/acpi/apei.c
+@@ -52,8 +52,3 @@ void arch_apei_report_mem_error(int sev,
+ apei_mce_report_mem_error(sev, mem_err);
+ #endif
+ }
+-
+-void arch_apei_flush_tlb_one(unsigned long addr)
+-{
+- __flush_tlb_one(addr);
+-}
+--- a/include/acpi/apei.h
++++ b/include/acpi/apei.h
+@@ -51,7 +51,6 @@ int erst_clear(u64 record_id);
+
+ int arch_apei_enable_cmcff(struct acpi_hest_header *hest_hdr, void *data);
+ void arch_apei_report_mem_error(int sev, struct cper_sec_mem_err *mem_err);
+-void arch_apei_flush_tlb_one(unsigned long addr);
+
+ #endif
+ #endif
--- /dev/null
+From 53c5eaabaea9a1b7a96f95ccc486d2ad721d95bb Mon Sep 17 00:00:00 2001
+From: Lv Zheng <lv.zheng@intel.com>
+Date: Tue, 26 Sep 2017 16:54:03 +0800
+Subject: ACPI / EC: Fix regression related to triggering source of EC event handling
+
+From: Lv Zheng <lv.zheng@intel.com>
+
+commit 53c5eaabaea9a1b7a96f95ccc486d2ad721d95bb upstream.
+
+Originally the Samsung quirks removed by commit 4c237371 can be covered
+by commit e923e8e7 and ec_freeze_events=Y mode. But commit 9c40f956
+changed ec_freeze_events=Y back to N, making this problem re-surface.
+
+Actually, if commit e923e8e7 is robust enough, we can freely change
+ec_freeze_events mode, so this patch fixes the issue by improving
+commit e923e8e7.
+
+Related commits listed in the merged order:
+
+ Commit: e923e8e79e18fd6be9162f1be6b99a002e9df2cb
+ Subject: ACPI / EC: Fix an issue that SCI_EVT cannot be detected
+ after event is enabled
+
+ Commit: 4c237371f290d1ed3b2071dd43554362137b1cce
+ Subject: ACPI / EC: Remove old CLEAR_ON_RESUME quirk
+
+ Commit: 9c40f956ce9b331493347d1b3cb7e384f7dc0581
+ Subject: Revert "ACPI / EC: Enable event freeze mode..." to fix
+ a regression
+
+This patch not only fixes the reported post-resume EC event triggering
+source issue, but also fixes an unreported similar issue related to the
+driver bind by adding EC event triggering source in ec_install_handlers().
+
+Fixes: e923e8e79e18 (ACPI / EC: Fix an issue that SCI_EVT cannot be detected after event is enabled)
+Fixes: 4c237371f290 (ACPI / EC: Remove old CLEAR_ON_RESUME quirk)
+Fixes: 9c40f956ce9b (Revert "ACPI / EC: Enable event freeze mode..." to fix a regression)
+Link: https://bugzilla.kernel.org/show_bug.cgi?id=196833
+Signed-off-by: Lv Zheng <lv.zheng@intel.com>
+Reported-by: Alistair Hamilton <ahpatent@gmail.com>
+Tested-by: Alistair Hamilton <ahpatent@gmail.com>
+Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/acpi/ec.c | 12 +++++++-----
+ 1 file changed, 7 insertions(+), 5 deletions(-)
+
+--- a/drivers/acpi/ec.c
++++ b/drivers/acpi/ec.c
+@@ -486,8 +486,11 @@ static inline void __acpi_ec_enable_even
+ {
+ if (!test_and_set_bit(EC_FLAGS_QUERY_ENABLED, &ec->flags))
+ ec_log_drv("event unblocked");
+- if (!test_bit(EC_FLAGS_QUERY_PENDING, &ec->flags))
+- advance_transaction(ec);
++ /*
++ * Unconditionally invoke this once after enabling the event
++ * handling mechanism to detect the pending events.
++ */
++ advance_transaction(ec);
+ }
+
+ static inline void __acpi_ec_disable_event(struct acpi_ec *ec)
+@@ -1456,11 +1459,10 @@ static int ec_install_handlers(struct ac
+ if (test_bit(EC_FLAGS_STARTED, &ec->flags) &&
+ ec->reference_count >= 1)
+ acpi_ec_enable_gpe(ec, true);
+-
+- /* EC is fully operational, allow queries */
+- acpi_ec_enable_event(ec);
+ }
+ }
++ /* EC is fully operational, allow queries */
++ acpi_ec_enable_event(ec);
+
+ return 0;
+ }
--- /dev/null
+From ff1656790b3a4caca94505c52fd0250f981ea187 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Ville=20Syrj=C3=A4l=C3=A4?= <ville.syrjala@linux.intel.com>
+Date: Tue, 7 Nov 2017 23:08:10 +0200
+Subject: ACPI / PM: Fix acpi_pm_notifier_lock vs flush_workqueue() deadlock
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Ville Syrjälä <ville.syrjala@linux.intel.com>
+
+commit ff1656790b3a4caca94505c52fd0250f981ea187 upstream.
+
+acpi_remove_pm_notifier() ends up calling flush_workqueue() while
+holding acpi_pm_notifier_lock, and that same lock is taken by
+by the work via acpi_pm_notify_handler(). This can deadlock.
+
+To fix the problem let's split the single lock into two: one to
+protect the dev->wakeup between the work vs. add/remove, and
+another one to handle notifier installation vs. removal.
+
+After commit a1d14934ea4b "workqueue/lockdep: 'Fix' flush_work()
+annotation" I was able to kill the machine (Intel Braswell)
+very easily with 'powertop --auto-tune', runtime suspending i915,
+and trying to wake it up via the USB keyboard. The cases when
+it didn't die are presumably explained by lockdep getting disabled
+by something else (cpu hotplug locking issues usually).
+
+Fortunately I still got a lockdep report over netconsole
+(trickling in very slowly), even though the machine was
+otherwise practically dead:
+
+[ 112.179806] ======================================================
+[ 114.670858] WARNING: possible circular locking dependency detected
+[ 117.155663] 4.13.0-rc6-bsw-bisect-00169-ga1d14934ea4b #119 Not tainted
+[ 119.658101] ------------------------------------------------------
+[ 121.310242] xhci_hcd 0000:00:14.0: xHCI host not responding to stop endpoint command.
+[ 121.313294] xhci_hcd 0000:00:14.0: xHCI host controller not responding, assume dead
+[ 121.313346] xhci_hcd 0000:00:14.0: HC died; cleaning up
+[ 121.313485] usb 1-6: USB disconnect, device number 3
+[ 121.313501] usb 1-6.2: USB disconnect, device number 4
+[ 134.747383] kworker/0:2/47 is trying to acquire lock:
+[ 137.220790] (acpi_pm_notifier_lock){+.+.}, at: [<ffffffff813cafdf>] acpi_pm_notify_handler+0x2f/0x80
+[ 139.721524]
+[ 139.721524] but task is already holding lock:
+[ 144.672922] ((&dpc->work)){+.+.}, at: [<ffffffff8109ce90>] process_one_work+0x160/0x720
+[ 147.184450]
+[ 147.184450] which lock already depends on the new lock.
+[ 147.184450]
+[ 154.604711]
+[ 154.604711] the existing dependency chain (in reverse order) is:
+[ 159.447888]
+[ 159.447888] -> #2 ((&dpc->work)){+.+.}:
+[ 164.183486] __lock_acquire+0x1255/0x13f0
+[ 166.504313] lock_acquire+0xb5/0x210
+[ 168.778973] process_one_work+0x1b9/0x720
+[ 171.030316] worker_thread+0x4c/0x440
+[ 173.257184] kthread+0x154/0x190
+[ 175.456143] ret_from_fork+0x27/0x40
+[ 177.624348]
+[ 177.624348] -> #1 ("kacpi_notify"){+.+.}:
+[ 181.850351] __lock_acquire+0x1255/0x13f0
+[ 183.941695] lock_acquire+0xb5/0x210
+[ 186.046115] flush_workqueue+0xdd/0x510
+[ 190.408153] acpi_os_wait_events_complete+0x31/0x40
+[ 192.625303] acpi_remove_notify_handler+0x133/0x188
+[ 194.820829] acpi_remove_pm_notifier+0x56/0x90
+[ 196.989068] acpi_dev_pm_detach+0x5f/0xa0
+[ 199.145866] dev_pm_domain_detach+0x27/0x30
+[ 201.285614] i2c_device_probe+0x100/0x210
+[ 203.411118] driver_probe_device+0x23e/0x310
+[ 205.522425] __driver_attach+0xa3/0xb0
+[ 207.634268] bus_for_each_dev+0x69/0xa0
+[ 209.714797] driver_attach+0x1e/0x20
+[ 211.778258] bus_add_driver+0x1bc/0x230
+[ 213.837162] driver_register+0x60/0xe0
+[ 215.868162] i2c_register_driver+0x42/0x70
+[ 217.869551] 0xffffffffa0172017
+[ 219.863009] do_one_initcall+0x45/0x170
+[ 221.843863] do_init_module+0x5f/0x204
+[ 223.817915] load_module+0x225b/0x29b0
+[ 225.757234] SyS_finit_module+0xc6/0xd0
+[ 227.661851] do_syscall_64+0x5c/0x120
+[ 229.536819] return_from_SYSCALL_64+0x0/0x7a
+[ 231.392444]
+[ 231.392444] -> #0 (acpi_pm_notifier_lock){+.+.}:
+[ 235.124914] check_prev_add+0x44e/0x8a0
+[ 237.024795] __lock_acquire+0x1255/0x13f0
+[ 238.937351] lock_acquire+0xb5/0x210
+[ 240.840799] __mutex_lock+0x75/0x940
+[ 242.709517] mutex_lock_nested+0x1c/0x20
+[ 244.551478] acpi_pm_notify_handler+0x2f/0x80
+[ 246.382052] acpi_ev_notify_dispatch+0x44/0x5c
+[ 248.194412] acpi_os_execute_deferred+0x14/0x30
+[ 250.003925] process_one_work+0x1ec/0x720
+[ 251.803191] worker_thread+0x4c/0x440
+[ 253.605307] kthread+0x154/0x190
+[ 255.387498] ret_from_fork+0x27/0x40
+[ 257.153175]
+[ 257.153175] other info that might help us debug this:
+[ 257.153175]
+[ 262.324392] Chain exists of:
+[ 262.324392] acpi_pm_notifier_lock --> "kacpi_notify" --> (&dpc->work)
+[ 262.324392]
+[ 267.391997] Possible unsafe locking scenario:
+[ 267.391997]
+[ 270.758262] CPU0 CPU1
+[ 272.431713] ---- ----
+[ 274.060756] lock((&dpc->work));
+[ 275.646532] lock("kacpi_notify");
+[ 277.260772] lock((&dpc->work));
+[ 278.839146] lock(acpi_pm_notifier_lock);
+[ 280.391902]
+[ 280.391902] *** DEADLOCK ***
+[ 280.391902]
+[ 284.986385] 2 locks held by kworker/0:2/47:
+[ 286.524895] #0: ("kacpi_notify"){+.+.}, at: [<ffffffff8109ce90>] process_one_work+0x160/0x720
+[ 288.112927] #1: ((&dpc->work)){+.+.}, at: [<ffffffff8109ce90>] process_one_work+0x160/0x720
+[ 289.727725]
+
+Fixes: c072530f391e (ACPI / PM: Revork the handling of ACPI device wakeup notifications)
+Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
+Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/acpi/device_pm.c | 21 ++++++++++++---------
+ 1 file changed, 12 insertions(+), 9 deletions(-)
+
+--- a/drivers/acpi/device_pm.c
++++ b/drivers/acpi/device_pm.c
+@@ -387,6 +387,7 @@ EXPORT_SYMBOL(acpi_bus_power_manageable)
+
+ #ifdef CONFIG_PM
+ static DEFINE_MUTEX(acpi_pm_notifier_lock);
++static DEFINE_MUTEX(acpi_pm_notifier_install_lock);
+
+ void acpi_pm_wakeup_event(struct device *dev)
+ {
+@@ -443,24 +444,25 @@ acpi_status acpi_add_pm_notifier(struct
+ if (!dev && !func)
+ return AE_BAD_PARAMETER;
+
+- mutex_lock(&acpi_pm_notifier_lock);
++ mutex_lock(&acpi_pm_notifier_install_lock);
+
+ if (adev->wakeup.flags.notifier_present)
+ goto out;
+
+- adev->wakeup.ws = wakeup_source_register(dev_name(&adev->dev));
+- adev->wakeup.context.dev = dev;
+- adev->wakeup.context.func = func;
+-
+ status = acpi_install_notify_handler(adev->handle, ACPI_SYSTEM_NOTIFY,
+ acpi_pm_notify_handler, NULL);
+ if (ACPI_FAILURE(status))
+ goto out;
+
++ mutex_lock(&acpi_pm_notifier_lock);
++ adev->wakeup.ws = wakeup_source_register(dev_name(&adev->dev));
++ adev->wakeup.context.dev = dev;
++ adev->wakeup.context.func = func;
+ adev->wakeup.flags.notifier_present = true;
++ mutex_unlock(&acpi_pm_notifier_lock);
+
+ out:
+- mutex_unlock(&acpi_pm_notifier_lock);
++ mutex_unlock(&acpi_pm_notifier_install_lock);
+ return status;
+ }
+
+@@ -472,7 +474,7 @@ acpi_status acpi_remove_pm_notifier(stru
+ {
+ acpi_status status = AE_BAD_PARAMETER;
+
+- mutex_lock(&acpi_pm_notifier_lock);
++ mutex_lock(&acpi_pm_notifier_install_lock);
+
+ if (!adev->wakeup.flags.notifier_present)
+ goto out;
+@@ -483,14 +485,15 @@ acpi_status acpi_remove_pm_notifier(stru
+ if (ACPI_FAILURE(status))
+ goto out;
+
++ mutex_lock(&acpi_pm_notifier_lock);
+ adev->wakeup.context.func = NULL;
+ adev->wakeup.context.dev = NULL;
+ wakeup_source_unregister(adev->wakeup.ws);
+-
+ adev->wakeup.flags.notifier_present = false;
++ mutex_unlock(&acpi_pm_notifier_lock);
+
+ out:
+- mutex_unlock(&acpi_pm_notifier_lock);
++ mutex_unlock(&acpi_pm_notifier_install_lock);
+ return status;
+ }
+
--- /dev/null
+From 5c50538752af7968f53924b22dede8ed4ce4cb3b Mon Sep 17 00:00:00 2001
+From: Heiko Carstens <heiko.carstens@de.ibm.com>
+Date: Tue, 26 Sep 2017 09:16:48 +0200
+Subject: s390/disassembler: add missing end marker for e7 table
+
+From: Heiko Carstens <heiko.carstens@de.ibm.com>
+
+commit 5c50538752af7968f53924b22dede8ed4ce4cb3b upstream.
+
+The e7 opcode table does not have an end marker. Hence when trying to
+find an unknown e7 instruction the code will access memory behind the
+table until it finds something that matches the opcode, or the kernel
+crashes, whatever comes first.
+
+This affects not only the in-kernel disassembler but also uprobes and
+kprobes which refuse to set a probe on unknown instructions, and
+therefore search the opcode tables to figure out if instructions are
+known or not.
+
+Fixes: 3585cb0280654 ("s390/disassembler: add vector instructions")
+Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
+Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/s390/kernel/dis.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/arch/s390/kernel/dis.c
++++ b/arch/s390/kernel/dis.c
+@@ -1548,6 +1548,7 @@ static struct s390_insn opcode_e7[] = {
+ { "vfsq", 0xce, INSTR_VRR_VV000MM },
+ { "vfs", 0xe2, INSTR_VRR_VVV00MM },
+ { "vftci", 0x4a, INSTR_VRI_VVIMM },
++ { "", 0, INSTR_INVALID }
+ };
+
+ static struct s390_insn opcode_eb[] = {
--- /dev/null
+From b192571d1ae375e0bbe0aa3ccfa1a3c3704454b9 Mon Sep 17 00:00:00 2001
+From: Vasily Gorbik <gor@linux.vnet.ibm.com>
+Date: Wed, 15 Nov 2017 14:15:36 +0100
+Subject: s390/disassembler: increase show_code buffer size
+
+From: Vasily Gorbik <gor@linux.vnet.ibm.com>
+
+commit b192571d1ae375e0bbe0aa3ccfa1a3c3704454b9 upstream.
+
+Current buffer size of 64 is too small. objdump shows that there are
+instructions which would require up to 75 bytes buffer (with current
+formating). 128 bytes "ought to be enough for anybody".
+
+Also replaces 8 spaces with a single tab to reduce the memory footprint.
+
+Fixes the following KASAN finding:
+
+BUG: KASAN: stack-out-of-bounds in number+0x3fe/0x538
+Write of size 1 at addr 000000005a4a75a0 by task bash/1282
+
+CPU: 1 PID: 1282 Comm: bash Not tainted 4.14.0+ #215
+Hardware name: IBM 2964 N96 702 (z/VM 6.4.0)
+Call Trace:
+([<000000000011eeb6>] show_stack+0x56/0x88)
+ [<0000000000e1ce1a>] dump_stack+0x15a/0x1b0
+ [<00000000004e2994>] print_address_description+0xf4/0x288
+ [<00000000004e2cf2>] kasan_report+0x13a/0x230
+ [<0000000000e38ae6>] number+0x3fe/0x538
+ [<0000000000e3dfe4>] vsnprintf+0x194/0x948
+ [<0000000000e3ea42>] sprintf+0xa2/0xb8
+ [<00000000001198dc>] print_insn+0x374/0x500
+ [<0000000000119346>] show_code+0x4ee/0x538
+ [<000000000011f234>] show_registers+0x34c/0x388
+ [<000000000011f2ae>] show_regs+0x3e/0xa8
+ [<000000000011f502>] die+0x1ea/0x2e8
+ [<0000000000138f0e>] do_no_context+0x106/0x168
+ [<0000000000139a1a>] do_protection_exception+0x4da/0x7d0
+ [<0000000000e55914>] pgm_check_handler+0x16c/0x1c0
+ [<000000000090639e>] sysrq_handle_crash+0x46/0x58
+([<0000000000000007>] 0x7)
+ [<00000000009073fa>] __handle_sysrq+0x102/0x218
+ [<0000000000907c06>] write_sysrq_trigger+0xd6/0x100
+ [<000000000061d67a>] proc_reg_write+0xb2/0x128
+ [<0000000000520be6>] __vfs_write+0xee/0x368
+ [<0000000000521222>] vfs_write+0x21a/0x278
+ [<000000000052156a>] SyS_write+0xda/0x178
+ [<0000000000e555cc>] system_call+0xc4/0x270
+
+The buggy address belongs to the page:
+page:000003d1016929c0 count:0 mapcount:0 mapping: (null) index:0x0
+flags: 0x0()
+raw: 0000000000000000 0000000000000000 0000000000000000 ffffffff00000000
+raw: 0000000000000100 0000000000000200 0000000000000000 0000000000000000
+page dumped because: kasan: bad access detected
+
+Memory state around the buggy address:
+ 000000005a4a7480: 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1
+ 000000005a4a7500: 00 00 00 00 00 00 00 00 f2 f2 f2 f2 00 00 00 00
+>000000005a4a7580: 00 00 00 00 f3 f3 f3 f3 00 00 00 00 00 00 00 00
+ ^
+ 000000005a4a7600: 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1 f8 f8
+ 000000005a4a7680: f2 f2 f2 f2 f2 f2 f8 f8 f2 f2 f3 f3 f3 f3 00 00
+==================================================================
+
+Signed-off-by: Vasily Gorbik <gor@linux.vnet.ibm.com>
+Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/s390/kernel/dis.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/arch/s390/kernel/dis.c
++++ b/arch/s390/kernel/dis.c
+@@ -1954,7 +1954,7 @@ void show_code(struct pt_regs *regs)
+ {
+ char *mode = user_mode(regs) ? "User" : "Krnl";
+ unsigned char code[64];
+- char buffer[64], *ptr;
++ char buffer[128], *ptr;
+ mm_segment_t old_fs;
+ unsigned long addr;
+ int start, end, opsize, hops, i;
+@@ -2017,7 +2017,7 @@ void show_code(struct pt_regs *regs)
+ start += opsize;
+ pr_cont("%s", buffer);
+ ptr = buffer;
+- ptr += sprintf(ptr, "\n ");
++ ptr += sprintf(ptr, "\n\t ");
+ hops++;
+ }
+ pr_cont("\n");
--- /dev/null
+From a1c5befc1c24eb9c1ee83f711e0f21ee79cbb556 Mon Sep 17 00:00:00 2001
+From: Heiko Carstens <heiko.carstens@de.ibm.com>
+Date: Thu, 9 Nov 2017 12:29:34 +0100
+Subject: s390: fix transactional execution control register handling
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Heiko Carstens <heiko.carstens@de.ibm.com>
+
+commit a1c5befc1c24eb9c1ee83f711e0f21ee79cbb556 upstream.
+
+Dan Horák reported the following crash related to transactional execution:
+
+User process fault: interruption code 0013 ilc:3 in libpthread-2.26.so[3ff93c00000+1b000]
+CPU: 2 PID: 1 Comm: /init Not tainted 4.13.4-300.fc27.s390x #1
+Hardware name: IBM 2827 H43 400 (z/VM 6.4.0)
+task: 00000000fafc8000 task.stack: 00000000fafc4000
+User PSW : 0705200180000000 000003ff93c14e70
+ R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:1 AS:0 CC:2 PM:0 RI:0 EA:3
+User GPRS: 0000000000000077 000003ff00000000 000003ff93144d48 000003ff93144d5e
+ 0000000000000000 0000000000000002 0000000000000000 000003ff00000000
+ 0000000000000000 0000000000000418 0000000000000000 000003ffcc9fe770
+ 000003ff93d28f50 000003ff9310acf0 000003ff92b0319a 000003ffcc9fe6d0
+User Code: 000003ff93c14e62: 60e0b030 std %f14,48(%r11)
+ 000003ff93c14e66: 60f0b038 std %f15,56(%r11)
+ #000003ff93c14e6a: e5600000ff0e tbegin 0,65294
+ >000003ff93c14e70: a7740006 brc 7,3ff93c14e7c
+ 000003ff93c14e74: a7080000 lhi %r0,0
+ 000003ff93c14e78: a7f40023 brc 15,3ff93c14ebe
+ 000003ff93c14e7c: b2220000 ipm %r0
+ 000003ff93c14e80: 8800001c srl %r0,28
+
+There are several bugs with control register handling with respect to
+transactional execution:
+
+- on task switch update_per_regs() is only called if the next task has
+ an mm (is not a kernel thread). This however is incorrect. This
+ breaks e.g. for user mode helper handling, where the kernel creates
+ a kernel thread and then execve's a user space program. Control
+ register contents related to transactional execution won't be
+ updated on execve. If the previous task ran with transactional
+ execution disabled then the new task will also run with
+ transactional execution disabled, which is incorrect. Therefore call
+ update_per_regs() unconditionally within switch_to().
+
+- on startup the transactional execution facility is not enabled for
+ the idle thread. This is not really a bug, but an inconsistency to
+ other facilities. Therefore enable the facility if it is available.
+
+- on fork the new thread's per_flags field is not cleared. This means
+ that a child process inherits the PER_FLAG_NO_TE flag. This flag can
+ be set with a ptrace request to disable transactional execution for
+ the current process. It should not be inherited by new child
+ processes in order to be consistent with the handling of all other
+ PER related debugging options. Therefore clear the per_flags field in
+ copy_thread_tls().
+
+Reported-and-tested-by: Dan Horák <dan@danny.cz>
+Fixes: d35339a42dd1 ("s390: add support for transactional memory")
+Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
+Reviewed-by: Christian Borntraeger <borntraeger@de.ibm.com>
+Reviewed-by: Hendrik Brueckner <brueckner@linux.vnet.ibm.com>
+Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/s390/include/asm/switch_to.h | 2 +-
+ arch/s390/kernel/early.c | 4 +++-
+ arch/s390/kernel/process.c | 1 +
+ 3 files changed, 5 insertions(+), 2 deletions(-)
+
+--- a/arch/s390/include/asm/switch_to.h
++++ b/arch/s390/include/asm/switch_to.h
+@@ -37,8 +37,8 @@ static inline void restore_access_regs(u
+ save_ri_cb(prev->thread.ri_cb); \
+ save_gs_cb(prev->thread.gs_cb); \
+ } \
++ update_cr_regs(next); \
+ if (next->mm) { \
+- update_cr_regs(next); \
+ set_cpu_flag(CIF_FPU); \
+ restore_access_regs(&next->thread.acrs[0]); \
+ restore_ri_cb(next->thread.ri_cb, prev->thread.ri_cb); \
+--- a/arch/s390/kernel/early.c
++++ b/arch/s390/kernel/early.c
+@@ -375,8 +375,10 @@ static __init void detect_machine_facili
+ S390_lowcore.machine_flags |= MACHINE_FLAG_IDTE;
+ if (test_facility(40))
+ S390_lowcore.machine_flags |= MACHINE_FLAG_LPP;
+- if (test_facility(50) && test_facility(73))
++ if (test_facility(50) && test_facility(73)) {
+ S390_lowcore.machine_flags |= MACHINE_FLAG_TE;
++ __ctl_set_bit(0, 55);
++ }
+ if (test_facility(51))
+ S390_lowcore.machine_flags |= MACHINE_FLAG_TLB_LC;
+ if (test_facility(129)) {
+--- a/arch/s390/kernel/process.c
++++ b/arch/s390/kernel/process.c
+@@ -100,6 +100,7 @@ int copy_thread_tls(unsigned long clone_
+ memset(&p->thread.per_user, 0, sizeof(p->thread.per_user));
+ memset(&p->thread.per_event, 0, sizeof(p->thread.per_event));
+ clear_tsk_thread_flag(p, TIF_SINGLE_STEP);
++ p->thread.per_flags = 0;
+ /* Initialize per thread user and system timer values */
+ p->thread.user_timer = 0;
+ p->thread.guest_timer = 0;
--- /dev/null
+From fa1edf3f63c05ca8eacafcd7048ed91e5360f1a8 Mon Sep 17 00:00:00 2001
+From: Heiko Carstens <heiko.carstens@de.ibm.com>
+Date: Mon, 11 Sep 2017 11:24:22 +0200
+Subject: s390/guarded storage: fix possible memory corruption
+
+From: Heiko Carstens <heiko.carstens@de.ibm.com>
+
+commit fa1edf3f63c05ca8eacafcd7048ed91e5360f1a8 upstream.
+
+For PREEMPT enabled kernels the guarded storage (GS) code contains a
+possible use-after-free bug. If a task that makes use of GS exits, it
+will execute do_exit() while still enabled for preemption.
+
+That function will call exit_thread_runtime_instr() via exit_thread().
+If exit_thread_gs() gets preempted after the GS control block of the
+task has been freed but before the pointer to it is set to NULL, then
+save_gs_cb(), called from switch_to(), will write to already freed
+memory.
+
+Avoid this and simply disable preemption while freeing the control
+block and setting the pointer to NULL.
+
+Fixes: 916cda1aa1b4 ("s390: add a system call for guarded storage")
+Reviewed-by: Christian Borntraeger <borntraeger@de.ibm.com>
+Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
+Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/s390/kernel/guarded_storage.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/arch/s390/kernel/guarded_storage.c
++++ b/arch/s390/kernel/guarded_storage.c
+@@ -14,9 +14,11 @@
+
+ void exit_thread_gs(void)
+ {
++ preempt_disable();
+ kfree(current->thread.gs_cb);
+ kfree(current->thread.gs_bc_cb);
+ current->thread.gs_cb = current->thread.gs_bc_cb = NULL;
++ preempt_enable();
+ }
+
+ static int gs_enable(void)
--- /dev/null
+From d0e810eeb3d326978f248b8f0233a2f30f58c72d Mon Sep 17 00:00:00 2001
+From: Heiko Carstens <heiko.carstens@de.ibm.com>
+Date: Thu, 9 Nov 2017 23:00:14 +0100
+Subject: s390/noexec: execute kexec datamover without DAT
+
+From: Heiko Carstens <heiko.carstens@de.ibm.com>
+
+commit d0e810eeb3d326978f248b8f0233a2f30f58c72d upstream.
+
+Rebooting into a new kernel with kexec fails (system dies) if tried on
+a machine that has no-execute support. Reason for this is that the so
+called datamover code gets executed with DAT on (MMU is active) and
+the page that contains the datamover is marked as non-executable.
+Therefore when branching into the datamover an unexpected program
+check happens and afterwards the machine is dead.
+
+This can be simply avoided by disabling DAT, which also disables any
+no-execute checks, just before the datamover gets executed.
+
+In fact the first thing done by the datamover is to disable DAT. The
+code in the datamover that disables DAT can be removed as well.
+
+Thanks to Michael Holzheu and Gerald Schaefer for tracking this down.
+
+Reviewed-by: Michael Holzheu <holzheu@linux.vnet.ibm.com>
+Reviewed-by: Philipp Rudo <prudo@linux.vnet.ibm.com>
+Cc: Gerald Schaefer <gerald.schaefer@de.ibm.com>
+Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
+Fixes: 57d7f939e7bd ("s390: add no-execute support")
+Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/s390/kernel/machine_kexec.c | 1 +
+ arch/s390/kernel/relocate_kernel.S | 3 ---
+ 2 files changed, 1 insertion(+), 3 deletions(-)
+
+--- a/arch/s390/kernel/machine_kexec.c
++++ b/arch/s390/kernel/machine_kexec.c
+@@ -269,6 +269,7 @@ static void __do_machine_kexec(void *dat
+ s390_reset_system();
+ data_mover = (relocate_kernel_t) page_to_phys(image->control_code_page);
+
++ __arch_local_irq_stnsm(0xfb); /* disable DAT - avoid no-execute */
+ /* Call the moving routine */
+ (*data_mover)(&image->head, image->start);
+
+--- a/arch/s390/kernel/relocate_kernel.S
++++ b/arch/s390/kernel/relocate_kernel.S
+@@ -29,7 +29,6 @@
+ ENTRY(relocate_kernel)
+ basr %r13,0 # base address
+ .base:
+- stnsm sys_msk-.base(%r13),0xfb # disable DAT
+ stctg %c0,%c15,ctlregs-.base(%r13)
+ stmg %r0,%r15,gprregs-.base(%r13)
+ lghi %r0,3
+@@ -103,8 +102,6 @@ ENTRY(relocate_kernel)
+ .align 8
+ load_psw:
+ .long 0x00080000,0x80000000
+- sys_msk:
+- .quad 0
+ ctlregs:
+ .rept 16
+ .quad 0
--- /dev/null
+From d6e646ad7cfa7034d280459b2b2546288f247144 Mon Sep 17 00:00:00 2001
+From: Heiko Carstens <heiko.carstens@de.ibm.com>
+Date: Mon, 11 Sep 2017 11:24:22 +0200
+Subject: s390/runtime instrumention: fix possible memory corruption
+
+From: Heiko Carstens <heiko.carstens@de.ibm.com>
+
+commit d6e646ad7cfa7034d280459b2b2546288f247144 upstream.
+
+For PREEMPT enabled kernels the runtime instrumentation (RI) code
+contains a possible use-after-free bug. If a task that makes use of RI
+exits, it will execute do_exit() while still enabled for preemption.
+
+That function will call exit_thread_runtime_instr() via
+exit_thread(). If exit_thread_runtime_instr() gets preempted after the
+RI control block of the task has been freed but before the pointer to
+it is set to NULL, then save_ri_cb(), called from switch_to(), will
+write to already freed memory.
+
+Avoid this and simply disable preemption while freeing the control
+block and setting the pointer to NULL.
+
+Fixes: e4b8b3f33fca ("s390: add support for runtime instrumentation")
+Reviewed-by: Christian Borntraeger <borntraeger@de.ibm.com>
+Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
+Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/s390/kernel/runtime_instr.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/arch/s390/kernel/runtime_instr.c
++++ b/arch/s390/kernel/runtime_instr.c
+@@ -50,11 +50,13 @@ void exit_thread_runtime_instr(void)
+ {
+ struct task_struct *task = current;
+
++ preempt_disable();
+ if (!task->thread.ri_cb)
+ return;
+ disable_runtime_instr();
+ kfree(task->thread.ri_cb);
+ task->thread.ri_cb = NULL;
++ preempt_enable();
+ }
+
+ SYSCALL_DEFINE1(s390_runtime_instr, int, command)
+@@ -65,9 +67,7 @@ SYSCALL_DEFINE1(s390_runtime_instr, int,
+ return -EOPNOTSUPP;
+
+ if (command == S390_RUNTIME_INSTR_STOP) {
+- preempt_disable();
+ exit_thread_runtime_instr();
+- preempt_enable();
+ return 0;
+ }
+
projects / thirdparty / kernel / stable-queue.git / commitdiff
