--- /dev/null
+From 21ffceda1c8b3807615c40d440d7815e0c85d366 Mon Sep 17 00:00:00 2001
+From: Mikulas Patocka <mpatocka@redhat.com>
+Date: Tue, 2 Jan 2018 14:01:34 -0500
+Subject: alpha: fix crash if pthread_create races with signal delivery
+
+From: Mikulas Patocka <mpatocka@redhat.com>
+
+commit 21ffceda1c8b3807615c40d440d7815e0c85d366 upstream.
+
+On alpha, a process will crash if it attempts to start a thread and a
+signal is delivered at the same time. The crash can be reproduced with
+this program: https://cygwin.com/ml/cygwin/2014-11/msg00473.html
+
+The reason for the crash is this:
+* we call the clone syscall
+* we go to the function copy_process
+* copy process calls copy_thread_tls, it is a wrapper around copy_thread
+* copy_thread sets the tls pointer: childti->pcb.unique = regs->r20
+* copy_thread sets regs->r20 to zero
+* we go back to copy_process
+* copy process checks "if (signal_pending(current))" and returns
+ -ERESTARTNOINTR
+* the clone syscall is restarted, but this time, regs->r20 is zero, so
+ the new thread is created with zero tls pointer
+* the new thread crashes in start_thread when attempting to access tls
+
+The comment in the code says that setting the register r20 is some
+compatibility with OSF/1. But OSF/1 doesn't use the CLONE_SETTLS flag, so
+we don't have to zero r20 if CLONE_SETTLS is set. This patch fixes the bug
+by zeroing regs->r20 only if CLONE_SETTLS is not set.
+
+Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
+Signed-off-by: Matt Turner <mattst88@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/alpha/kernel/process.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/arch/alpha/kernel/process.c
++++ b/arch/alpha/kernel/process.c
+@@ -269,12 +269,13 @@ copy_thread(unsigned long clone_flags, u
+ application calling fork. */
+ if (clone_flags & CLONE_SETTLS)
+ childti->pcb.unique = regs->r20;
++ else
++ regs->r20 = 0; /* OSF/1 has some strange fork() semantics. */
+ childti->pcb.usp = usp ?: rdusp();
+ *childregs = *regs;
+ childregs->r0 = 0;
+ childregs->r19 = 0;
+ childregs->r20 = 1; /* OSF/1 has some strange fork() semantics. */
+- regs->r20 = 0;
+ stack = ((struct switch_stack *) regs) - 1;
+ *childstack = *stack;
+ childstack->r26 = (unsigned long) ret_from_fork;
--- /dev/null
+From 4b01abdb32fc36abe877503bfbd33019159fad71 Mon Sep 17 00:00:00 2001
+From: Mikulas Patocka <mpatocka@redhat.com>
+Date: Tue, 2 Jan 2018 14:00:32 -0500
+Subject: alpha: fix formating of stack content
+
+From: Mikulas Patocka <mpatocka@redhat.com>
+
+commit 4b01abdb32fc36abe877503bfbd33019159fad71 upstream.
+
+Since version 4.9, the kernel automatically breaks printk calls into
+multiple newlines unless pr_cont is used. Fix the alpha stacktrace code,
+so that it prints stack trace in four columns, as it was initially
+intended.
+
+Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
+Signed-off-by: Matt Turner <mattst88@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/alpha/kernel/traps.c | 13 +++++++++----
+ 1 file changed, 9 insertions(+), 4 deletions(-)
+
+--- a/arch/alpha/kernel/traps.c
++++ b/arch/alpha/kernel/traps.c
+@@ -160,11 +160,16 @@ void show_stack(struct task_struct *task
+ for(i=0; i < kstack_depth_to_print; i++) {
+ if (((long) stack & (THREAD_SIZE-1)) == 0)
+ break;
+- if (i && ((i % 4) == 0))
+- printk("\n ");
+- printk("%016lx ", *stack++);
++ if ((i % 4) == 0) {
++ if (i)
++ pr_cont("\n");
++ printk(" ");
++ } else {
++ pr_cont(" ");
++ }
++ pr_cont("%016lx", *stack++);
+ }
+- printk("\n");
++ pr_cont("\n");
+ dik_show_trace(sp);
+ }
+
--- /dev/null
+From 84e455361ec97ea6037d31d42a2955628ea2094b Mon Sep 17 00:00:00 2001
+From: Michael Cree <mcree@orcon.net.nz>
+Date: Fri, 24 Nov 2017 21:25:01 +1300
+Subject: alpha: Fix mixed up args in EXC macro in futex operations
+
+From: Michael Cree <mcree@orcon.net.nz>
+
+commit 84e455361ec97ea6037d31d42a2955628ea2094b upstream.
+
+Fix the typo (mixed up arguments) in the EXC macro in the futex
+definitions introduced by commit ca282f697381 (alpha: add a
+helper for emitting exception table entries).
+
+Signed-off-by: Michael Cree <mcree@orcon.net.nz>
+Signed-off-by: Matt Turner <mattst88@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/alpha/include/asm/futex.h | 8 ++++----
+ 1 file changed, 4 insertions(+), 4 deletions(-)
+
+--- a/arch/alpha/include/asm/futex.h
++++ b/arch/alpha/include/asm/futex.h
+@@ -20,8 +20,8 @@
+ "3: .subsection 2\n" \
+ "4: br 1b\n" \
+ " .previous\n" \
+- EXC(1b,3b,%1,$31) \
+- EXC(2b,3b,%1,$31) \
++ EXC(1b,3b,$31,%1) \
++ EXC(2b,3b,$31,%1) \
+ : "=&r" (oldval), "=&r"(ret) \
+ : "r" (uaddr), "r"(oparg) \
+ : "memory")
+@@ -82,8 +82,8 @@ futex_atomic_cmpxchg_inatomic(u32 *uval,
+ "3: .subsection 2\n"
+ "4: br 1b\n"
+ " .previous\n"
+- EXC(1b,3b,%0,$31)
+- EXC(2b,3b,%0,$31)
++ EXC(1b,3b,$31,%0)
++ EXC(2b,3b,$31,%0)
+ : "+r"(ret), "=&r"(prev), "=&r"(cmp)
+ : "r"(uaddr), "r"((long)(int)oldval), "r"(newval)
+ : "memory");
--- /dev/null
+From 55fc633c41a08ce9244ff5f528f420b16b1e04d6 Mon Sep 17 00:00:00 2001
+From: Mikulas Patocka <mpatocka@redhat.com>
+Date: Tue, 2 Jan 2018 13:59:54 -0500
+Subject: alpha: fix reboot on Avanti platform
+
+From: Mikulas Patocka <mpatocka@redhat.com>
+
+commit 55fc633c41a08ce9244ff5f528f420b16b1e04d6 upstream.
+
+We need to define NEED_SRM_SAVE_RESTORE on the Avanti, otherwise we get
+machine check exception when attempting to reboot the machine.
+
+Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
+Signed-off-by: Matt Turner <mattst88@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/alpha/kernel/pci_impl.h | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/arch/alpha/kernel/pci_impl.h
++++ b/arch/alpha/kernel/pci_impl.h
+@@ -144,7 +144,8 @@ struct pci_iommu_arena
+ };
+
+ #if defined(CONFIG_ALPHA_SRM) && \
+- (defined(CONFIG_ALPHA_CIA) || defined(CONFIG_ALPHA_LCA))
++ (defined(CONFIG_ALPHA_CIA) || defined(CONFIG_ALPHA_LCA) || \
++ defined(CONFIG_ALPHA_AVANTI))
+ # define NEED_SRM_SAVE_RESTORE
+ #else
+ # undef NEED_SRM_SAVE_RESTORE
--- /dev/null
+From 47669fb6b5951d0e09fc99719653e0ac92b50b99 Mon Sep 17 00:00:00 2001
+From: Arnd Bergmann <arnd@arndb.de>
+Date: Wed, 8 Nov 2017 16:02:13 +0100
+Subject: alpha: osf_sys.c: fix put_tv32 regression
+
+From: Arnd Bergmann <arnd@arndb.de>
+
+commit 47669fb6b5951d0e09fc99719653e0ac92b50b99 upstream.
+
+There was a typo in the new version of put_tv32() that caused an unguarded
+access of a user space pointer, and failed to return the correct result in
+gettimeofday(), wait4(), usleep_thread() and old_adjtimex().
+
+This fixes it to give the correct behavior again.
+
+Fixes: 1cc6c4635e9f ("osf_sys.c: switch handling of timeval32/itimerval32 to copy_{to,from}_user()")
+Signed-off-by: Arnd Bergmann <arnd@arndb.de>
+Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/alpha/kernel/osf_sys.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/arch/alpha/kernel/osf_sys.c
++++ b/arch/alpha/kernel/osf_sys.c
+@@ -964,8 +964,8 @@ static inline long
+ put_tv32(struct timeval32 __user *o, struct timeval *i)
+ {
+ return copy_to_user(o, &(struct timeval32){
+- .tv_sec = o->tv_sec,
+- .tv_usec = o->tv_usec},
++ .tv_sec = i->tv_sec,
++ .tv_usec = i->tv_usec},
+ sizeof(struct timeval32));
+ }
+
--- /dev/null
+From 20e8175d246e9f9deb377f2784b3e7dfb2ad3e86 Mon Sep 17 00:00:00 2001
+From: Marc Zyngier <marc.zyngier@arm.com>
+Date: Tue, 6 Feb 2018 17:56:06 +0000
+Subject: arm: KVM: Fix SMCCC handling of unimplemented SMC/HVC calls
+
+From: Marc Zyngier <marc.zyngier@arm.com>
+
+commit 20e8175d246e9f9deb377f2784b3e7dfb2ad3e86 upstream.
+
+KVM doesn't follow the SMCCC when it comes to unimplemented calls,
+and inject an UNDEF instead of returning an error. Since firmware
+calls are now used for security mitigation, they are becoming more
+common, and the undef is counter productive.
+
+Instead, let's follow the SMCCC which states that -1 must be returned
+to the caller when getting an unknown function number.
+
+Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
+Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
+Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/arm/kvm/handle_exit.c | 13 +++++++++++--
+ 1 file changed, 11 insertions(+), 2 deletions(-)
+
+--- a/arch/arm/kvm/handle_exit.c
++++ b/arch/arm/kvm/handle_exit.c
+@@ -38,7 +38,7 @@ static int handle_hvc(struct kvm_vcpu *v
+
+ ret = kvm_hvc_call_handler(vcpu);
+ if (ret < 0) {
+- kvm_inject_undefined(vcpu);
++ vcpu_set_reg(vcpu, 0, ~0UL);
+ return 1;
+ }
+
+@@ -47,7 +47,16 @@ static int handle_hvc(struct kvm_vcpu *v
+
+ static int handle_smc(struct kvm_vcpu *vcpu, struct kvm_run *run)
+ {
+- kvm_inject_undefined(vcpu);
++ /*
++ * "If an SMC instruction executed at Non-secure EL1 is
++ * trapped to EL2 because HCR_EL2.TSC is 1, the exception is a
++ * Trap exception, not a Secure Monitor Call exception [...]"
++ *
++ * We need to advance the PC after the trap, as it would
++ * otherwise return to the same address...
++ */
++ vcpu_set_reg(vcpu, 0, ~0UL);
++ kvm_skip_instr(vcpu, kvm_vcpu_trap_il_is32bit(vcpu));
+ return 1;
+ }
+
--- /dev/null
+From c66234cfedfc3e6e3b62563a5f2c1562be09a35d Mon Sep 17 00:00:00 2001
+From: John Keeping <john@metanate.com>
+Date: Mon, 8 Jan 2018 16:01:04 +0000
+Subject: ASoC: rockchip: i2s: fix playback after runtime resume
+
+From: John Keeping <john@metanate.com>
+
+commit c66234cfedfc3e6e3b62563a5f2c1562be09a35d upstream.
+
+When restoring registers during runtime resume, we must not write to
+I2S_TXDR which is the transmit FIFO as this queues up a sample to be
+output and pushes all of the output channels down by one.
+
+This can be demonstrated with the speaker-test utility:
+
+ for i in a b c; do speaker-test -c 2 -s 1; done
+
+which should play a test through the left speaker three times but if the
+I2S hardware starts runtime suspended the first sample will be played
+through the right speaker.
+
+Fix this by marking I2S_TXDR as volatile (which also requires marking it
+as readble, even though it technically isn't). This seems to be the
+most robust fix, the alternative of giving I2S_TXDR a default value is
+more fragile since it does not prevent regcache writing to the register
+in all circumstances.
+
+While here, also fix the configuration of I2S_RXDR and I2S_FIFOLR; these
+are not writable so they do not suffer from the same problem as I2S_TXDR
+but reading from I2S_RXDR does suffer from a similar problem.
+
+Fixes: f0447f6cbb20 ("ASoC: rockchip: i2s: restore register during runtime_suspend/resume cycle", 2016-09-07)
+Signed-off-by: John Keeping <john@metanate.com>
+Signed-off-by: Mark Brown <broonie@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ sound/soc/rockchip/rockchip_i2s.c | 6 ++++++
+ 1 file changed, 6 insertions(+)
+
+--- a/sound/soc/rockchip/rockchip_i2s.c
++++ b/sound/soc/rockchip/rockchip_i2s.c
+@@ -504,6 +504,7 @@ static bool rockchip_i2s_rd_reg(struct d
+ case I2S_INTCR:
+ case I2S_XFER:
+ case I2S_CLR:
++ case I2S_TXDR:
+ case I2S_RXDR:
+ case I2S_FIFOLR:
+ case I2S_INTSR:
+@@ -518,6 +519,9 @@ static bool rockchip_i2s_volatile_reg(st
+ switch (reg) {
+ case I2S_INTSR:
+ case I2S_CLR:
++ case I2S_FIFOLR:
++ case I2S_TXDR:
++ case I2S_RXDR:
+ return true;
+ default:
+ return false;
+@@ -527,6 +531,8 @@ static bool rockchip_i2s_volatile_reg(st
+ static bool rockchip_i2s_precious_reg(struct device *dev, unsigned int reg)
+ {
+ switch (reg) {
++ case I2S_RXDR:
++ return true;
+ default:
+ return false;
+ }
--- /dev/null
+From 20a1ea2222e7cbf96e9bf8579362e971491e6aea Mon Sep 17 00:00:00 2001
+From: Takashi Iwai <tiwai@suse.de>
+Date: Wed, 3 Jan 2018 16:38:46 +0100
+Subject: ASoC: skl: Fix kernel warning due to zero NHTL entry
+
+From: Takashi Iwai <tiwai@suse.de>
+
+commit 20a1ea2222e7cbf96e9bf8579362e971491e6aea upstream.
+
+I got the following kernel warning when loading snd-soc-skl module on
+Dell Latitude 7270 laptop:
+ memremap attempted on mixed range 0x0000000000000000 size: 0x0
+ WARNING: CPU: 0 PID: 484 at kernel/memremap.c:98 memremap+0x8a/0x180
+ Call Trace:
+ skl_nhlt_init+0x82/0xf0 [snd_soc_skl]
+ skl_probe+0x2ee/0x7c0 [snd_soc_skl]
+ ....
+
+It seems that the machine doesn't support the SKL DSP gives the empty
+NHLT entry, and it triggers the warning. For avoiding it, let do the
+zero check before calling memremap().
+
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Mark Brown <broonie@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ sound/soc/intel/skylake/skl-nhlt.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/sound/soc/intel/skylake/skl-nhlt.c
++++ b/sound/soc/intel/skylake/skl-nhlt.c
+@@ -41,7 +41,8 @@ struct nhlt_acpi_table *skl_nhlt_init(st
+ obj = acpi_evaluate_dsm(handle, &osc_guid, 1, 1, NULL);
+ if (obj && obj->type == ACPI_TYPE_BUFFER) {
+ nhlt_ptr = (struct nhlt_resource_desc *)obj->buffer.pointer;
+- nhlt_table = (struct nhlt_acpi_table *)
++ if (nhlt_ptr->length)
++ nhlt_table = (struct nhlt_acpi_table *)
+ memremap(nhlt_ptr->min_addr, nhlt_ptr->length,
+ MEMREMAP_WB);
+ ACPI_FREE(obj);
--- /dev/null
+From c2856ae2f315d754a0b6a268e4c6745b332b42e7 Mon Sep 17 00:00:00 2001
+From: Ming Lei <ming.lei@redhat.com>
+Date: Sat, 6 Jan 2018 16:27:37 +0800
+Subject: blk-mq: quiesce queue before freeing queue
+
+From: Ming Lei <ming.lei@redhat.com>
+
+commit c2856ae2f315d754a0b6a268e4c6745b332b42e7 upstream.
+
+After queue is frozen, dispatch still may happen, for example:
+
+1) requests are submitted from several contexts
+2) requests from all these contexts are inserted to queue, but may dispatch
+to LLD in one of these paths, but other paths sill need to move on even all
+these requests are completed(that means blk_mq_freeze_queue_wait() returns
+at that time)
+3) dispatch after queue freezing still moves on and causes use-after-free,
+because request queue is freed
+
+This patch quiesces queue after it is frozen, and makes sure all
+in-progress dispatch are completed.
+
+This patch fixes the following kernel crash when running heavy IOs vs.
+deleting device:
+
+[ 36.719251] BUG: unable to handle kernel NULL pointer dereference at 0000000000000008
+[ 36.720318] IP: kyber_has_work+0x14/0x40
+[ 36.720847] PGD 254bf5067 P4D 254bf5067 PUD 255e6a067 PMD 0
+[ 36.721584] Oops: 0000 [#1] PREEMPT SMP
+[ 36.722105] Dumping ftrace buffer:
+[ 36.722570] (ftrace buffer empty)
+[ 36.723057] Modules linked in: scsi_debug ebtable_filter ebtables ip6table_filter ip6_tables tcm_loop iscsi_target_mod target_core_file target_core_iblock target_core_pscsi target_core_mod xt_CHECKSUM iptable_mangle ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack libcrc32c bridge stp llc fuse iptable_filter ip_tables sd_mod sg btrfs xor zstd_decompress zstd_compress xxhash raid6_pq mptsas mptscsih bcache crc32c_intel ahci mptbase libahci serio_raw scsi_transport_sas nvme libata shpchp lpc_ich virtio_scsi nvme_core binfmt_misc dm_mod iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi null_blk configs
+[ 36.733438] CPU: 2 PID: 2374 Comm: fio Not tainted 4.15.0-rc2.blk_mq_quiesce+ #714
+[ 36.735143] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.9.3-1.fc25 04/01/2014
+[ 36.736688] RIP: 0010:kyber_has_work+0x14/0x40
+[ 36.737515] RSP: 0018:ffffc9000209bca0 EFLAGS: 00010202
+[ 36.738431] RAX: 0000000000000008 RBX: ffff88025578bfc8 RCX: ffff880257bf4ed0
+[ 36.739581] RDX: 0000000000000038 RSI: ffffffff81a98c6d RDI: ffff88025578bfc8
+[ 36.740730] RBP: ffff880253cebfc8 R08: ffffc9000209bda0 R09: ffff8802554f3480
+[ 36.741885] R10: ffffc9000209be60 R11: ffff880263f72538 R12: ffff88025573e9e8
+[ 36.743036] R13: ffff88025578bfd0 R14: 0000000000000001 R15: 0000000000000000
+[ 36.744189] FS: 00007f9b9bee67c0(0000) GS:ffff88027fc80000(0000) knlGS:0000000000000000
+[ 36.746617] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
+[ 36.748483] CR2: 0000000000000008 CR3: 0000000254bf4001 CR4: 00000000003606e0
+[ 36.750164] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
+[ 36.751455] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
+[ 36.752796] Call Trace:
+[ 36.753992] blk_mq_do_dispatch_sched+0x7f/0xe0
+[ 36.755110] blk_mq_sched_dispatch_requests+0x119/0x190
+[ 36.756179] __blk_mq_run_hw_queue+0x83/0x90
+[ 36.757144] __blk_mq_delay_run_hw_queue+0xaf/0x110
+[ 36.758046] blk_mq_run_hw_queue+0x24/0x70
+[ 36.758845] blk_mq_flush_plug_list+0x1e7/0x270
+[ 36.759676] blk_flush_plug_list+0xd6/0x240
+[ 36.760463] blk_finish_plug+0x27/0x40
+[ 36.761195] do_io_submit+0x19b/0x780
+[ 36.761921] ? entry_SYSCALL_64_fastpath+0x1a/0x7d
+[ 36.762788] entry_SYSCALL_64_fastpath+0x1a/0x7d
+[ 36.763639] RIP: 0033:0x7f9b9699f697
+[ 36.764352] RSP: 002b:00007ffc10f991b8 EFLAGS: 00000206 ORIG_RAX: 00000000000000d1
+[ 36.765773] RAX: ffffffffffffffda RBX: 00000000008f6f00 RCX: 00007f9b9699f697
+[ 36.766965] RDX: 0000000000a5e6c0 RSI: 0000000000000001 RDI: 00007f9b8462a000
+[ 36.768377] RBP: 0000000000000000 R08: 0000000000000001 R09: 00000000008f6420
+[ 36.769649] R10: 00007f9b846e5000 R11: 0000000000000206 R12: 00007f9b795d6a70
+[ 36.770807] R13: 00007f9b795e4140 R14: 00007f9b795e3fe0 R15: 0000000100000000
+[ 36.771955] Code: 83 c7 10 e9 3f 68 d1 ff 0f 1f 44 00 00 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 8b 97 b0 00 00 00 48 8d 42 08 48 83 c2 38 <48> 3b 00 74 06 b8 01 00 00 00 c3 48 3b 40 08 75 f4 48 83 c0 10
+[ 36.775004] RIP: kyber_has_work+0x14/0x40 RSP: ffffc9000209bca0
+[ 36.776012] CR2: 0000000000000008
+[ 36.776690] ---[ end trace 4045cbce364ff2a4 ]---
+[ 36.777527] Kernel panic - not syncing: Fatal exception
+[ 36.778526] Dumping ftrace buffer:
+[ 36.779313] (ftrace buffer empty)
+[ 36.780081] Kernel Offset: disabled
+[ 36.780877] ---[ end Kernel panic - not syncing: Fatal exception
+
+Reviewed-by: Christoph Hellwig <hch@lst.de>
+Tested-by: Yi Zhang <yi.zhang@redhat.com>
+Signed-off-by: Ming Lei <ming.lei@redhat.com>
+Signed-off-by: Jens Axboe <axboe@kernel.dk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ block/blk-core.c | 9 +++++++++
+ 1 file changed, 9 insertions(+)
+
+--- a/block/blk-core.c
++++ b/block/blk-core.c
+@@ -660,6 +660,15 @@ void blk_cleanup_queue(struct request_qu
+ queue_flag_set(QUEUE_FLAG_DEAD, q);
+ spin_unlock_irq(lock);
+
++ /*
++ * make sure all in-progress dispatch are completed because
++ * blk_freeze_queue() can only complete all requests, and
++ * dispatch may still be in-progress since we dispatch requests
++ * from more than one contexts
++ */
++ if (q->mq_ops)
++ blk_mq_quiesce_queue(q);
++
+ /* for synchronous bio-based driver finish in-flight integrity i/o */
+ blk_flush_integrity();
+
--- /dev/null
+From b4cdaba274247c9c841c6a682c08fa91fb3aa549 Mon Sep 17 00:00:00 2001
+From: Hans de Goede <hdegoede@redhat.com>
+Date: Wed, 29 Nov 2017 20:29:07 +0100
+Subject: Bluetooth: btsdio: Do not bind to non-removable BCM43341
+
+From: Hans de Goede <hdegoede@redhat.com>
+
+commit b4cdaba274247c9c841c6a682c08fa91fb3aa549 upstream.
+
+BCM43341 devices soldered onto the PCB (non-removable) always (AFAICT)
+use an UART connection for bluetooth. But they also advertise btsdio
+support on their 3th sdio function, this causes 2 problems:
+
+1) A non functioning BT HCI getting registered
+
+2) Since the btsdio driver does not have suspend/resume callbacks,
+mmc_sdio_pre_suspend will return -ENOSYS, causing mmc_pm_notify()
+to react as if the SDIO-card is removed and since the slot is
+marked as non-removable it will never get detected as inserted again.
+Which results in wifi no longer working after a suspend/resume.
+
+This commit fixes both by making btsdio ignore BCM43341 devices
+when connected to a slot which is marked non-removable.
+
+Signed-off-by: Hans de Goede <hdegoede@redhat.com>
+Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/bluetooth/btsdio.c | 9 +++++++++
+ 1 file changed, 9 insertions(+)
+
+--- a/drivers/bluetooth/btsdio.c
++++ b/drivers/bluetooth/btsdio.c
+@@ -31,6 +31,7 @@
+ #include <linux/errno.h>
+ #include <linux/skbuff.h>
+
++#include <linux/mmc/host.h>
+ #include <linux/mmc/sdio_ids.h>
+ #include <linux/mmc/sdio_func.h>
+
+@@ -292,6 +293,14 @@ static int btsdio_probe(struct sdio_func
+ tuple = tuple->next;
+ }
+
++ /* BCM43341 devices soldered onto the PCB (non-removable) use an
++ * uart connection for bluetooth, ignore the BT SDIO interface.
++ */
++ if (func->vendor == SDIO_VENDOR_ID_BROADCOM &&
++ func->device == SDIO_DEVICE_ID_BROADCOM_43341 &&
++ !mmc_card_is_removable(func->card->host))
++ return -ENODEV;
++
+ data = devm_kzalloc(&func->dev, sizeof(*data), GFP_KERNEL);
+ if (!data)
+ return -ENOMEM;
--- /dev/null
+From 61f5acea8737d9b717fcc22bb6679924f3c82b98 Mon Sep 17 00:00:00 2001
+From: Hans de Goede <hdegoede@redhat.com>
+Date: Mon, 8 Jan 2018 10:44:16 +0100
+Subject: Bluetooth: btusb: Restore QCA Rome suspend/resume fix with a "rewritten" version
+
+From: Hans de Goede <hdegoede@redhat.com>
+
+commit 61f5acea8737d9b717fcc22bb6679924f3c82b98 upstream.
+
+Commit 7d06d5895c15 ("Revert "Bluetooth: btusb: fix QCA...suspend/resume"")
+removed the setting of the BTUSB_RESET_RESUME quirk for QCA Rome devices,
+instead favoring adding USB_QUIRK_RESET_RESUME quirks in usb/core/quirks.c.
+
+This was done because the DIY BTUSB_RESET_RESUME reset-resume handling
+has several issues (see the original commit message). An added advantage
+of moving over to the USB-core reset-resume handling is that it also
+disables autosuspend for these devices, which is similarly broken on these.
+
+But there are 2 issues with this approach:
+1) It leaves the broken DIY BTUSB_RESET_RESUME code in place for Realtek
+ devices.
+2) Sofar only 2 of the 10 QCA devices known to the btusb code have been
+ added to usb/core/quirks.c and if we fix the Realtek case the same way
+ we need to add an additional 14 entries. So in essence we need to
+ duplicate a large part of the usb_device_id table in btusb.c in
+ usb/core/quirks.c and manually keep them in sync.
+
+This commit instead restores setting a reset-resume quirk for QCA devices
+in the btusb.c code, avoiding the duplicate usb_device_id table problem.
+
+This commit avoids the problems with the original DIY BTUSB_RESET_RESUME
+code by simply setting the USB_QUIRK_RESET_RESUME quirk directly on the
+usb_device.
+
+This commit also moves the BTUSB_REALTEK case over to directly setting the
+USB_QUIRK_RESET_RESUME on the usb_device and removes the now unused
+BTUSB_RESET_RESUME code.
+
+BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1514836
+Fixes: 7d06d5895c15 ("Revert "Bluetooth: btusb: fix QCA...suspend/resume"")
+Cc: Leif Liddy <leif.linux@gmail.com>
+Cc: Matthias Kaehlcke <mka@chromium.org>
+Cc: Brian Norris <briannorris@chromium.org>
+Cc: Daniel Drake <drake@endlessm.com>
+Cc: Kai-Heng Feng <kai.heng.feng@canonical.com>
+Signed-off-by: Hans de Goede <hdegoede@redhat.com>
+Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/bluetooth/btusb.c | 22 ++++++++++------------
+ 1 file changed, 10 insertions(+), 12 deletions(-)
+
+--- a/drivers/bluetooth/btusb.c
++++ b/drivers/bluetooth/btusb.c
+@@ -23,6 +23,7 @@
+
+ #include <linux/module.h>
+ #include <linux/usb.h>
++#include <linux/usb/quirks.h>
+ #include <linux/firmware.h>
+ #include <linux/of_device.h>
+ #include <linux/of_irq.h>
+@@ -392,9 +393,8 @@ static const struct usb_device_id blackl
+ #define BTUSB_FIRMWARE_LOADED 7
+ #define BTUSB_FIRMWARE_FAILED 8
+ #define BTUSB_BOOTING 9
+-#define BTUSB_RESET_RESUME 10
+-#define BTUSB_DIAG_RUNNING 11
+-#define BTUSB_OOB_WAKE_ENABLED 12
++#define BTUSB_DIAG_RUNNING 10
++#define BTUSB_OOB_WAKE_ENABLED 11
+
+ struct btusb_data {
+ struct hci_dev *hdev;
+@@ -3099,6 +3099,12 @@ static int btusb_probe(struct usb_interf
+ if (id->driver_info & BTUSB_QCA_ROME) {
+ data->setup_on_usb = btusb_setup_qca;
+ hdev->set_bdaddr = btusb_set_bdaddr_ath3012;
++
++ /* QCA Rome devices lose their updated firmware over suspend,
++ * but the USB hub doesn't notice any status change.
++ * explicitly request a device reset on resume.
++ */
++ interface_to_usbdev(intf)->quirks |= USB_QUIRK_RESET_RESUME;
+ }
+
+ #ifdef CONFIG_BT_HCIBTUSB_RTL
+@@ -3109,7 +3115,7 @@ static int btusb_probe(struct usb_interf
+ * but the USB hub doesn't notice any status change.
+ * Explicitly request a device reset on resume.
+ */
+- set_bit(BTUSB_RESET_RESUME, &data->flags);
++ interface_to_usbdev(intf)->quirks |= USB_QUIRK_RESET_RESUME;
+ }
+ #endif
+
+@@ -3274,14 +3280,6 @@ static int btusb_suspend(struct usb_inte
+ enable_irq(data->oob_wake_irq);
+ }
+
+- /* Optionally request a device reset on resume, but only when
+- * wakeups are disabled. If wakeups are enabled we assume the
+- * device will stay powered up throughout suspend.
+- */
+- if (test_bit(BTUSB_RESET_RESUME, &data->flags) &&
+- !device_may_wakeup(&data->udev->dev))
+- data->udev->reset_resume = 1;
+-
+ return 0;
+ }
+
--- /dev/null
+From 0198e5b707cfeb5defbd1b71b1ec6e71580d7db9 Mon Sep 17 00:00:00 2001
+From: Liu Bo <bo.li.liu@oracle.com>
+Date: Fri, 12 Jan 2018 18:07:01 -0700
+Subject: Btrfs: raid56: iterate raid56 internal bio with bio_for_each_segment_all
+
+From: Liu Bo <bo.li.liu@oracle.com>
+
+commit 0198e5b707cfeb5defbd1b71b1ec6e71580d7db9 upstream.
+
+Bio iterated by set_bio_pages_uptodate() is raid56 internal one, so it
+will never be a BIO_CLONED bio, and since this is called by end_io
+functions, bio->bi_iter.bi_size is zero, we mustn't use
+bio_for_each_segment() as that is a no-op if bi_size is zero.
+
+Fixes: 6592e58c6b68e61f003a01ba29a3716e7e2e9484 ("Btrfs: fix write corruption due to bio cloning on raid5/6")
+Signed-off-by: Liu Bo <bo.li.liu@oracle.com>
+Signed-off-by: David Sterba <dsterba@suse.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/btrfs/raid56.c | 11 +++++------
+ 1 file changed, 5 insertions(+), 6 deletions(-)
+
+--- a/fs/btrfs/raid56.c
++++ b/fs/btrfs/raid56.c
+@@ -1432,14 +1432,13 @@ static int fail_bio_stripe(struct btrfs_
+ */
+ static void set_bio_pages_uptodate(struct bio *bio)
+ {
+- struct bio_vec bvec;
+- struct bvec_iter iter;
++ struct bio_vec *bvec;
++ int i;
+
+- if (bio_flagged(bio, BIO_CLONED))
+- bio->bi_iter = btrfs_io_bio(bio)->iter;
++ ASSERT(!bio_flagged(bio, BIO_CLONED));
+
+- bio_for_each_segment(bvec, bio, iter)
+- SetPageUptodate(bvec.bv_page);
++ bio_for_each_segment_all(bvec, bio, i)
++ SetPageUptodate(bvec->bv_page);
+ }
+
+ /*
--- /dev/null
+From e0aeca3d8cbaea514eb98df1149faa918f9ec42d Mon Sep 17 00:00:00 2001
+From: Daniel Lezcano <daniel.lezcano@linaro.org>
+Date: Mon, 8 Jan 2018 14:28:50 +0100
+Subject: clocksource/drivers/stm32: Fix kernel panic with multiple timers
+
+From: Daniel Lezcano <daniel.lezcano@linaro.org>
+
+commit e0aeca3d8cbaea514eb98df1149faa918f9ec42d upstream.
+
+The current code hides a couple of bugs:
+
+ - The global variable 'clock_event_ddata' is overwritten each time the
+ init function is invoked.
+
+This is fixed with a kmemdup() instead of assigning the global variable. That
+prevents a memory corruption when several timers are defined in the DT.
+
+ - The clockevent's event_handler is NULL if the time framework does
+ not select the clockevent when registering it, this is fine but the init
+ code generates in any case an interrupt leading to dereference this
+ NULL pointer.
+
+The stm32 timer works with shadow registers, a mechanism to cache the
+registers. When a change is done in one buffered register, we need to
+artificially generate an event to force the timer to copy the content
+of the register to the shadowed register.
+
+The auto-reload register (ARR) is one of the shadowed register as well as
+the prescaler register (PSC), so in order to force the copy, we issue an
+event which in turn leads to an interrupt and the NULL dereference.
+
+This is fixed by inverting two lines where we clear the status register
+before enabling the update event interrupt.
+
+As this kernel crash is resulting from the combination of these two bugs,
+the fixes are grouped into a single patch.
+
+Tested-by: Benjamin Gaignard <benjamin.gaignard@st.com>
+Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
+Acked-by: Benjamin Gaignard <benjamin.gaignard@st.com>
+Cc: Alexandre Torgue <alexandre.torgue@st.com>
+Cc: Linus Torvalds <torvalds@linux-foundation.org>
+Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com>
+Cc: Peter Zijlstra <peterz@infradead.org>
+Cc: Thomas Gleixner <tglx@linutronix.de>
+Link: http://lkml.kernel.org/r/1515418139-23276-11-git-send-email-daniel.lezcano@linaro.org
+Signed-off-by: Ingo Molnar <mingo@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/clocksource/timer-stm32.c | 7 ++++++-
+ 1 file changed, 6 insertions(+), 1 deletion(-)
+
+--- a/drivers/clocksource/timer-stm32.c
++++ b/drivers/clocksource/timer-stm32.c
+@@ -106,6 +106,10 @@ static int __init stm32_clockevent_init(
+ unsigned long rate, max_delta;
+ int irq, ret, bits, prescaler = 1;
+
++ data = kmemdup(&clock_event_ddata, sizeof(*data), GFP_KERNEL);
++ if (!data)
++ return -ENOMEM;
++
+ clk = of_clk_get(np, 0);
+ if (IS_ERR(clk)) {
+ ret = PTR_ERR(clk);
+@@ -156,8 +160,8 @@ static int __init stm32_clockevent_init(
+
+ writel_relaxed(prescaler - 1, data->base + TIM_PSC);
+ writel_relaxed(TIM_EGR_UG, data->base + TIM_EGR);
+- writel_relaxed(TIM_DIER_UIE, data->base + TIM_DIER);
+ writel_relaxed(0, data->base + TIM_SR);
++ writel_relaxed(TIM_DIER_UIE, data->base + TIM_DIER);
+
+ data->periodic_top = DIV_ROUND_CLOSEST(rate, prescaler * HZ);
+
+@@ -184,6 +188,7 @@ err_iomap:
+ err_clk_enable:
+ clk_put(clk);
+ err_clk_get:
++ kfree(data);
+ return ret;
+ }
+
--- /dev/null
+From 225ece3e7dad4cfc44cca38ce7a3a80f255ea8f1 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Horia=20Geant=C4=83?= <horia.geanta@nxp.com>
+Date: Mon, 5 Feb 2018 11:15:52 +0200
+Subject: crypto: caam - fix endless loop when DECO acquire fails
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Horia Geantă <horia.geanta@nxp.com>
+
+commit 225ece3e7dad4cfc44cca38ce7a3a80f255ea8f1 upstream.
+
+In case DECO0 cannot be acquired - i.e. run_descriptor_deco0() fails
+with -ENODEV, caam_probe() enters an endless loop:
+
+run_descriptor_deco0
+ ret -ENODEV
+ -> instantiate_rng
+ -ENODEV, overwritten by -EAGAIN
+ ret -EAGAIN
+ -> caam_probe
+ -EAGAIN results in endless loop
+
+It turns out the error path in instantiate_rng() is incorrect,
+the checks are done in the wrong order.
+
+Fixes: 1005bccd7a4a6 ("crypto: caam - enable instantiation of all RNG4 state handles")
+Reported-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
+Suggested-by: Auer Lukas <lukas.auer@aisec.fraunhofer.de>
+Signed-off-by: Horia Geantă <horia.geanta@nxp.com>
+Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/crypto/caam/ctrl.c | 8 ++++++--
+ 1 file changed, 6 insertions(+), 2 deletions(-)
+
+--- a/drivers/crypto/caam/ctrl.c
++++ b/drivers/crypto/caam/ctrl.c
+@@ -228,12 +228,16 @@ static int instantiate_rng(struct device
+ * without any error (HW optimizations for later
+ * CAAM eras), then try again.
+ */
++ if (ret)
++ break;
++
+ rdsta_val = rd_reg32(&ctrl->r4tst[0].rdsta) & RDSTA_IFMASK;
+ if ((status && status != JRSTA_SSRC_JUMP_HALT_CC) ||
+- !(rdsta_val & (1 << sh_idx)))
++ !(rdsta_val & (1 << sh_idx))) {
+ ret = -EAGAIN;
+- if (ret)
+ break;
++ }
++
+ dev_info(ctrldev, "Instantiated RNG4 SH%d\n", sh_idx);
+ /* Clear the contents before recreating the descriptor */
+ memset(desc, 0x00, CAAM_CMD_SZ * 7);
--- /dev/null
+From eff84b379089cd8b4e83599639c1f5f6e34ef7bf Mon Sep 17 00:00:00 2001
+From: Eric Biggers <ebiggers@google.com>
+Date: Wed, 24 Jan 2018 00:31:27 -0800
+Subject: crypto: sha512-mb - initialize pending lengths correctly
+
+From: Eric Biggers <ebiggers@google.com>
+
+commit eff84b379089cd8b4e83599639c1f5f6e34ef7bf upstream.
+
+The SHA-512 multibuffer code keeps track of the number of blocks pending
+in each lane. The minimum of these values is used to identify the next
+lane that will be completed. Unused lanes are set to a large number
+(0xFFFFFFFF) so that they don't affect this calculation.
+
+However, it was forgotten to set the lengths to this value in the
+initial state, where all lanes are unused. As a result it was possible
+for sha512_mb_mgr_get_comp_job_avx2() to select an unused lane, causing
+a NULL pointer dereference. Specifically this could happen in the case
+where ->update() was passed fewer than SHA512_BLOCK_SIZE bytes of data,
+so it then called sha_complete_job() without having actually submitted
+any blocks to the multi-buffer code. This hit a NULL pointer
+dereference if another task happened to have submitted blocks
+concurrently to the same CPU and the flush timer had not yet expired.
+
+Fix this by initializing sha512_mb_mgr->lens correctly.
+
+As usual, this bug was found by syzkaller.
+
+Fixes: 45691e2d9b18 ("crypto: sha512-mb - submit/flush routines for AVX2")
+Reported-by: syzbot <syzkaller@googlegroups.com>
+Signed-off-by: Eric Biggers <ebiggers@google.com>
+Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/x86/crypto/sha512-mb/sha512_mb_mgr_init_avx2.c | 10 ++++++----
+ 1 file changed, 6 insertions(+), 4 deletions(-)
+
+--- a/arch/x86/crypto/sha512-mb/sha512_mb_mgr_init_avx2.c
++++ b/arch/x86/crypto/sha512-mb/sha512_mb_mgr_init_avx2.c
+@@ -57,10 +57,12 @@ void sha512_mb_mgr_init_avx2(struct sha5
+ {
+ unsigned int j;
+
+- state->lens[0] = 0;
+- state->lens[1] = 1;
+- state->lens[2] = 2;
+- state->lens[3] = 3;
++ /* initially all lanes are unused */
++ state->lens[0] = 0xFFFFFFFF00000000;
++ state->lens[1] = 0xFFFFFFFF00000001;
++ state->lens[2] = 0xFFFFFFFF00000002;
++ state->lens[3] = 0xFFFFFFFF00000003;
++
+ state->unused_lanes = 0xFF03020100;
+ for (j = 0; j < 4; j++)
+ state->ldata[j].job_in_lane = NULL;
--- /dev/null
+From 87a81dce53b1ea61acaeefa5191a0376a2d1d721 Mon Sep 17 00:00:00 2001
+From: LEROY Christophe <christophe.leroy@c-s.fr>
+Date: Fri, 26 Jan 2018 17:09:59 +0100
+Subject: crypto: talitos - fix Kernel Oops on hashing an empty file
+
+From: LEROY Christophe <christophe.leroy@c-s.fr>
+
+commit 87a81dce53b1ea61acaeefa5191a0376a2d1d721 upstream.
+
+Performing the hash of an empty file leads to a kernel Oops
+
+[ 44.504600] Unable to handle kernel paging request for data at address 0x0000000c
+[ 44.512819] Faulting instruction address: 0xc02d2be8
+[ 44.524088] Oops: Kernel access of bad area, sig: 11 [#1]
+[ 44.529171] BE PREEMPT CMPC885
+[ 44.532232] CPU: 0 PID: 491 Comm: md5sum Not tainted 4.15.0-rc8-00211-g3a968610b6ea #81
+[ 44.540814] NIP: c02d2be8 LR: c02d2984 CTR: 00000000
+[ 44.545812] REGS: c6813c90 TRAP: 0300 Not tainted (4.15.0-rc8-00211-g3a968610b6ea)
+[ 44.554223] MSR: 00009032 <EE,ME,IR,DR,RI> CR: 48222822 XER: 20000000
+[ 44.560855] DAR: 0000000c DSISR: c0000000
+[ 44.560855] GPR00: c02d28fc c6813d40 c6828000 c646fa40 00000001 00000001 00000001 00000000
+[ 44.560855] GPR08: 0000004c 00000000 c000bfcc 00000000 28222822 100280d4 00000000 10020008
+[ 44.560855] GPR16: 00000000 00000020 00000000 00000000 10024008 00000000 c646f9f0 c6179a10
+[ 44.560855] GPR24: 00000000 00000001 c62f0018 c6179a10 00000000 c6367a30 c62f0000 c646f9c0
+[ 44.598542] NIP [c02d2be8] ahash_process_req+0x448/0x700
+[ 44.603751] LR [c02d2984] ahash_process_req+0x1e4/0x700
+[ 44.608868] Call Trace:
+[ 44.611329] [c6813d40] [c02d28fc] ahash_process_req+0x15c/0x700 (unreliable)
+[ 44.618302] [c6813d90] [c02060c4] hash_recvmsg+0x11c/0x210
+[ 44.623716] [c6813db0] [c0331354] ___sys_recvmsg+0x98/0x138
+[ 44.629226] [c6813eb0] [c03332c0] __sys_recvmsg+0x40/0x84
+[ 44.634562] [c6813f10] [c03336c0] SyS_socketcall+0xb8/0x1d4
+[ 44.640073] [c6813f40] [c000d1ac] ret_from_syscall+0x0/0x38
+[ 44.645530] Instruction dump:
+[ 44.648465] 38c00001 7f63db78 4e800421 7c791b78 54690ffe 0f090000 80ff0190 2f870000
+[ 44.656122] 40befe50 2f990001 409e0210 813f01bc <8129000c> b39e003a 7d29c214 913e003c
+
+This patch fixes that Oops by checking if src is NULL.
+
+Fixes: 6a1e8d14156d4 ("crypto: talitos - making mapping helpers more generic")
+Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
+Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/crypto/talitos.c | 4 ++++
+ 1 file changed, 4 insertions(+)
+
+--- a/drivers/crypto/talitos.c
++++ b/drivers/crypto/talitos.c
+@@ -1127,6 +1127,10 @@ int talitos_sg_map(struct device *dev, s
+ to_talitos_ptr_len(ptr, len, is_sec1);
+ to_talitos_ptr_ext_set(ptr, 0, is_sec1);
+
++ if (!src) {
++ to_talitos_ptr(ptr, 0, 0, is_sec1);
++ return 1;
++ }
+ if (sg_count == 1) {
+ to_talitos_ptr(ptr, sg_dma_address(src) + offset, is_sec1);
+ return sg_count;
--- /dev/null
+From 544e92581a2ac44607d7cc602c6b54d18656f56d Mon Sep 17 00:00:00 2001
+From: James Hogan <jhogan@kernel.org>
+Date: Mon, 13 Nov 2017 16:12:06 +0000
+Subject: EDAC, octeon: Fix an uninitialized variable warning
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: James Hogan <jhogan@kernel.org>
+
+commit 544e92581a2ac44607d7cc602c6b54d18656f56d upstream.
+
+Fix an uninitialized variable warning in the Octeon EDAC driver, as seen
+in MIPS cavium_octeon_defconfig builds since v4.14 with Codescape GNU
+Tools 2016.05-03:
+
+ drivers/edac/octeon_edac-lmc.c In function ‘octeon_lmc_edac_poll_o2’:
+ drivers/edac/octeon_edac-lmc.c:87:24: warning: ‘((long unsigned int*)&int_reg)[1]’ may \
+ be used uninitialized in this function [-Wmaybe-uninitialized]
+ if (int_reg.s.sec_err || int_reg.s.ded_err) {
+ ^
+Iinitialise the whole int_reg variable to zero before the conditional
+assignments in the error injection case.
+
+Signed-off-by: James Hogan <jhogan@kernel.org>
+Acked-by: David Daney <david.daney@cavium.com>
+Cc: linux-edac <linux-edac@vger.kernel.org>
+Cc: linux-mips@linux-mips.org
+Fixes: 1bc021e81565 ("EDAC: Octeon: Add error injection support")
+Link: http://lkml.kernel.org/r/20171113161206.20990-1-james.hogan@mips.com
+Signed-off-by: Borislav Petkov <bp@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/edac/octeon_edac-lmc.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/edac/octeon_edac-lmc.c
++++ b/drivers/edac/octeon_edac-lmc.c
+@@ -78,6 +78,7 @@ static void octeon_lmc_edac_poll_o2(stru
+ if (!pvt->inject)
+ int_reg.u64 = cvmx_read_csr(CVMX_LMCX_INT(mci->mc_idx));
+ else {
++ int_reg.u64 = 0;
+ if (pvt->error_type == 1)
+ int_reg.s.sec_err = 1;
+ if (pvt->error_type == 2)
--- /dev/null
+From d0290bc20d4739b7a900ae37eb5d4cc3be2b393f Mon Sep 17 00:00:00 2001
+From: Heiko Carstens <heiko.carstens@de.ibm.com>
+Date: Tue, 6 Feb 2018 15:37:13 -0800
+Subject: fs/proc/kcore.c: use probe_kernel_read() instead of memcpy()
+
+From: Heiko Carstens <heiko.carstens@de.ibm.com>
+
+commit d0290bc20d4739b7a900ae37eb5d4cc3be2b393f upstream.
+
+Commit df04abfd181a ("fs/proc/kcore.c: Add bounce buffer for ktext
+data") added a bounce buffer to avoid hardened usercopy checks. Copying
+to the bounce buffer was implemented with a simple memcpy() assuming
+that it is always valid to read from kernel memory iff the
+kern_addr_valid() check passed.
+
+A simple, but pointless, test case like "dd if=/proc/kcore of=/dev/null"
+now can easily crash the kernel, since the former execption handling on
+invalid kernel addresses now doesn't work anymore.
+
+Also adding a kern_addr_valid() implementation wouldn't help here. Most
+architectures simply return 1 here, while a couple implemented a page
+table walk to figure out if something is mapped at the address in
+question.
+
+With DEBUG_PAGEALLOC active mappings are established and removed all the
+time, so that relying on the result of kern_addr_valid() before
+executing the memcpy() also doesn't work.
+
+Therefore simply use probe_kernel_read() to copy to the bounce buffer.
+This also allows to simplify read_kcore().
+
+At least on s390 this fixes the observed crashes and doesn't introduce
+warnings that were removed with df04abfd181a ("fs/proc/kcore.c: Add
+bounce buffer for ktext data"), even though the generic
+probe_kernel_read() implementation uses uaccess functions.
+
+While looking into this I'm also wondering if kern_addr_valid() could be
+completely removed...(?)
+
+Link: http://lkml.kernel.org/r/20171202132739.99971-1-heiko.carstens@de.ibm.com
+Fixes: df04abfd181a ("fs/proc/kcore.c: Add bounce buffer for ktext data")
+Fixes: f5509cc18daa ("mm: Hardened usercopy")
+Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
+Acked-by: Kees Cook <keescook@chromium.org>
+Cc: Jiri Olsa <jolsa@kernel.org>
+Cc: Al Viro <viro@ZenIV.linux.org.uk>
+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/proc/kcore.c | 18 +++++-------------
+ 1 file changed, 5 insertions(+), 13 deletions(-)
+
+--- a/fs/proc/kcore.c
++++ b/fs/proc/kcore.c
+@@ -512,23 +512,15 @@ read_kcore(struct file *file, char __use
+ return -EFAULT;
+ } else {
+ if (kern_addr_valid(start)) {
+- unsigned long n;
+-
+ /*
+ * Using bounce buffer to bypass the
+ * hardened user copy kernel text checks.
+ */
+- memcpy(buf, (char *) start, tsz);
+- n = copy_to_user(buffer, buf, tsz);
+- /*
+- * We cannot distinguish between fault on source
+- * and fault on destination. When this happens
+- * we clear too and hope it will trigger the
+- * EFAULT again.
+- */
+- if (n) {
+- if (clear_user(buffer + tsz - n,
+- n))
++ if (probe_kernel_read(buf, (void *) start, tsz)) {
++ if (clear_user(buffer, tsz))
++ return -EFAULT;
++ } else {
++ if (copy_to_user(buffer, buf, tsz))
+ return -EFAULT;
+ }
+ } else {
--- /dev/null
+From edfc3722cfef4217c7fe92b272cbe0288ba1ff57 Mon Sep 17 00:00:00 2001
+From: Hans de Goede <hdegoede@redhat.com>
+Date: Wed, 17 Jan 2018 21:05:55 +0100
+Subject: HID: quirks: Fix keyboard + touchpad on Toshiba Click Mini not working
+
+From: Hans de Goede <hdegoede@redhat.com>
+
+commit edfc3722cfef4217c7fe92b272cbe0288ba1ff57 upstream.
+
+The Toshiba Click Mini uses an i2c attached keyboard/touchpad combo
+(single i2c_hid device for both) which has a vid:pid of 04F3:0401,
+which is also used by a bunch of Elan touchpads which are handled by the
+drivers/input/mouse/elan_i2c driver, but that driver deals with pure
+touchpads and does not work for a combo device such as the one on the
+Toshiba Click Mini.
+
+The combo on the Mini has an ACPI id of ELAN0800, which is not claimed
+by the elan_i2c driver, so check for that and if it is found do not ignore
+the device. This fixes the keyboard/touchpad combo on the Mini not working
+(although with the touchpad in mouse emulation mode).
+
+Signed-off-by: Hans de Goede <hdegoede@redhat.com>
+Signed-off-by: Jiri Kosina <jkosina@suse.cz>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/hid/hid-core.c | 12 +++++++++++-
+ 1 file changed, 11 insertions(+), 1 deletion(-)
+
+--- a/drivers/hid/hid-core.c
++++ b/drivers/hid/hid-core.c
+@@ -2638,7 +2638,6 @@ static const struct hid_device_id hid_ig
+ { HID_USB_DEVICE(USB_VENDOR_ID_DELORME, USB_DEVICE_ID_DELORME_EARTHMATE) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_DELORME, USB_DEVICE_ID_DELORME_EM_LT20) },
+ { HID_I2C_DEVICE(USB_VENDOR_ID_ELAN, 0x0400) },
+- { HID_I2C_DEVICE(USB_VENDOR_ID_ELAN, 0x0401) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_ESSENTIAL_REALITY, USB_DEVICE_ID_ESSENTIAL_REALITY_P5) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_ETT, USB_DEVICE_ID_TC5UH) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_ETT, USB_DEVICE_ID_TC4UM) },
+@@ -2908,6 +2907,17 @@ bool hid_ignore(struct hid_device *hdev)
+ strncmp(hdev->name, "www.masterkit.ru MA901", 22) == 0)
+ return true;
+ break;
++ case USB_VENDOR_ID_ELAN:
++ /*
++ * Many Elan devices have a product id of 0x0401 and are handled
++ * by the elan_i2c input driver. But the ACPI HID ELAN0800 dev
++ * is not (and cannot be) handled by that driver ->
++ * Ignore all 0x0401 devs except for the ELAN0800 dev.
++ */
++ if (hdev->product == 0x0401 &&
++ strncmp(hdev->name, "ELAN0800", 8) != 0)
++ return true;
++ break;
+ }
+
+ if (hdev->type == HID_TYPE_USBMOUSE &&
--- /dev/null
+From 5516e21a1e95e9b9f39985598431a25477d91643 Mon Sep 17 00:00:00 2001
+From: John Garry <john.garry@huawei.com>
+Date: Thu, 18 Jan 2018 00:36:57 +0800
+Subject: ipmi: use dynamic memory for DMI driver override
+
+From: John Garry <john.garry@huawei.com>
+
+commit 5516e21a1e95e9b9f39985598431a25477d91643 upstream.
+
+Currently a crash can be seen if we reach the "err"
+label in dmi_add_platform_ipmi(), calling
+platform_device_put(), like here:
+[ 7.270584] (null): ipmi:dmi: Unable to add resources: -16
+[ 7.330229] ------------[ cut here ]------------
+[ 7.334889] kernel BUG at mm/slub.c:3894!
+[ 7.338936] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
+[ 7.344475] Modules linked in:
+[ 7.347556] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 4.15.0-rc2-00004-gbe9cb7b-dirty #114
+[ 7.355907] Hardware name: Huawei Taishan 2280 /D05, BIOS Hisilicon D05 IT17 Nemo 2.0 RC0 11/29/2017
+[ 7.365137] task: 00000000c211f6d3 task.stack: 00000000f276e9af
+[ 7.371116] pstate: 60000005 (nZCv daif -PAN -UAO)
+[ 7.375957] pc : kfree+0x194/0x1b4
+[ 7.379389] lr : platform_device_release+0xcc/0xd8
+[ 7.384225] sp : ffff0000092dba90
+[ 7.387567] x29: ffff0000092dba90 x28: ffff000008a83000
+[ 7.392933] x27: ffff0000092dbc10 x26: 00000000000000e6
+[ 7.398297] x25: 0000000000000003 x24: ffff0000085b51e8
+[ 7.403662] x23: 0000000000000100 x22: ffff7e0000234cc0
+[ 7.409027] x21: ffff000008af3660 x20: ffff8017d21acc10
+[ 7.414392] x19: ffff8017d21acc00 x18: 0000000000000002
+[ 7.419757] x17: 0000000000000001 x16: 0000000000000008
+[ 7.425121] x15: 0000000000000001 x14: 6666666678303d65
+[ 7.430486] x13: 6469727265766f5f x12: 7265766972642e76
+[ 7.435850] x11: 6564703e2d617020 x10: 6530326435373638
+[ 7.441215] x9 : 3030303030303030 x8 : 3d76656420657361
+[ 7.446580] x7 : ffff000008f59df8 x6 : ffff8017fbe0ea50
+[ 7.451945] x5 : 0000000000000000 x4 : 0000000000000000
+[ 7.457309] x3 : ffffffffffffffff x2 : 0000000000000000
+[ 7.462674] x1 : 0fffc00000000800 x0 : ffff7e0000234ce0
+[ 7.468039] Process swapper/0 (pid: 1, stack limit = 0x00000000f276e9af)
+[ 7.474809] Call trace:
+[ 7.477272] kfree+0x194/0x1b4
+[ 7.480351] platform_device_release+0xcc/0xd8
+[ 7.484837] device_release+0x34/0x90
+[ 7.488531] kobject_put+0x70/0xcc
+[ 7.491961] put_device+0x14/0x1c
+[ 7.495304] platform_device_put+0x14/0x1c
+[ 7.499439] dmi_add_platform_ipmi+0x348/0x3ac
+[ 7.503923] scan_for_dmi_ipmi+0xfc/0x10c
+[ 7.507970] do_one_initcall+0x38/0x124
+[ 7.511840] kernel_init_freeable+0x188/0x228
+[ 7.516238] kernel_init+0x10/0x100
+[ 7.519756] ret_from_fork+0x10/0x18
+[ 7.523362] Code: f94002c0 37780080 f94012c0 37000040 (d4210000)
+[ 7.529552] ---[ end trace 11750e4787deef9e ]---
+[ 7.534228] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
+[ 7.534228]
+
+This is because when the device is released in
+platform_device_release(), we try to free
+pdev.driver_override. This is a const string, hence
+the crash.
+Fix by using dynamic memory for pdev->driver_override.
+
+Signed-off-by: John Garry <john.garry@huawei.com>
+[Removed the free of driver_override from ipmi_si_remove_by_dev(). The
+ free is done in platform_device_release(), and would result in a double
+ free, and ipmi_si_remove_by_dev() is called by non-platform devices.]
+Signed-off-by: Corey Minyard <cminyard@mvista.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/char/ipmi/ipmi_dmi.c | 5 ++++-
+ 1 file changed, 4 insertions(+), 1 deletion(-)
+
+--- a/drivers/char/ipmi/ipmi_dmi.c
++++ b/drivers/char/ipmi/ipmi_dmi.c
+@@ -81,7 +81,10 @@ static void __init dmi_add_platform_ipmi
+ pr_err("ipmi:dmi: Error allocation IPMI platform device");
+ return;
+ }
+- pdev->driver_override = override;
++ pdev->driver_override = kasprintf(GFP_KERNEL, "%s",
++ override);
++ if (!pdev->driver_override)
++ goto err;
+
+ if (type == IPMI_DMI_TYPE_SSIF)
+ goto add_properties;
--- /dev/null
+From 0e410e158e5baa1300bdf678cea4f4e0cf9d8b94 Mon Sep 17 00:00:00 2001
+From: Andrey Konovalov <andreyknvl@google.com>
+Date: Tue, 6 Feb 2018 15:36:00 -0800
+Subject: kasan: don't emit builtin calls when sanitization is off
+
+From: Andrey Konovalov <andreyknvl@google.com>
+
+commit 0e410e158e5baa1300bdf678cea4f4e0cf9d8b94 upstream.
+
+With KASAN enabled the kernel has two different memset() functions, one
+with KASAN checks (memset) and one without (__memset). KASAN uses some
+macro tricks to use the proper version where required. For example
+memset() calls in mm/slub.c are without KASAN checks, since they operate
+on poisoned slab object metadata.
+
+The issue is that clang emits memset() calls even when there is no
+memset() in the source code. They get linked with improper memset()
+implementation and the kernel fails to boot due to a huge amount of KASAN
+reports during early boot stages.
+
+The solution is to add -fno-builtin flag for files with KASAN_SANITIZE :=
+n marker.
+
+Link: http://lkml.kernel.org/r/8ffecfffe04088c52c42b92739c2bd8a0bcb3f5e.1516384594.git.andreyknvl@google.com
+Signed-off-by: Andrey Konovalov <andreyknvl@google.com>
+Acked-by: Nick Desaulniers <ndesaulniers@google.com>
+Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
+Cc: Michal Marek <michal.lkml@markovi.net>
+Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
+Cc: Alexander Potapenko <glider@google.com>
+Cc: Dmitry Vyukov <dvyukov@google.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>
+
+---
+ Makefile | 3 ++-
+ scripts/Makefile.kasan | 3 +++
+ scripts/Makefile.lib | 2 +-
+ 3 files changed, 6 insertions(+), 2 deletions(-)
+
+--- a/Makefile
++++ b/Makefile
+@@ -416,7 +416,8 @@ export MAKE AWK GENKSYMS INSTALLKERNEL P
+ export HOSTCXX HOSTCXXFLAGS LDFLAGS_MODULE CHECK CHECKFLAGS
+
+ export KBUILD_CPPFLAGS NOSTDINC_FLAGS LINUXINCLUDE OBJCOPYFLAGS LDFLAGS
+-export KBUILD_CFLAGS CFLAGS_KERNEL CFLAGS_MODULE CFLAGS_KASAN CFLAGS_UBSAN
++export KBUILD_CFLAGS CFLAGS_KERNEL CFLAGS_MODULE
++export CFLAGS_KASAN CFLAGS_KASAN_NOSANITIZE CFLAGS_UBSAN
+ export KBUILD_AFLAGS AFLAGS_KERNEL AFLAGS_MODULE
+ export KBUILD_AFLAGS_MODULE KBUILD_CFLAGS_MODULE KBUILD_LDFLAGS_MODULE
+ export KBUILD_AFLAGS_KERNEL KBUILD_CFLAGS_KERNEL
+--- a/scripts/Makefile.kasan
++++ b/scripts/Makefile.kasan
+@@ -31,4 +31,7 @@ else
+ endif
+
+ CFLAGS_KASAN += $(call cc-option, -fsanitize-address-use-after-scope)
++
++CFLAGS_KASAN_NOSANITIZE := -fno-builtin
++
+ endif
+--- a/scripts/Makefile.lib
++++ b/scripts/Makefile.lib
+@@ -128,7 +128,7 @@ endif
+ ifeq ($(CONFIG_KASAN),y)
+ _c_flags += $(if $(patsubst n%,, \
+ $(KASAN_SANITIZE_$(basetarget).o)$(KASAN_SANITIZE)y), \
+- $(CFLAGS_KASAN))
++ $(CFLAGS_KASAN), $(CFLAGS_KASAN_NOSANITIZE))
+ endif
+
+ ifeq ($(CONFIG_UBSAN),y)
--- /dev/null
+From e7c52b84fb18f08ce49b6067ae6285aca79084a8 Mon Sep 17 00:00:00 2001
+From: Arnd Bergmann <arnd@arndb.de>
+Date: Tue, 6 Feb 2018 15:41:41 -0800
+Subject: kasan: rework Kconfig settings
+
+From: Arnd Bergmann <arnd@arndb.de>
+
+commit e7c52b84fb18f08ce49b6067ae6285aca79084a8 upstream.
+
+We get a lot of very large stack frames using gcc-7.0.1 with the default
+-fsanitize-address-use-after-scope --param asan-stack=1 options, which can
+easily cause an overflow of the kernel stack, e.g.
+
+ drivers/gpu/drm/i915/gvt/handlers.c:2434:1: warning: the frame size of 46176 bytes is larger than 3072 bytes
+ drivers/net/wireless/ralink/rt2x00/rt2800lib.c:5650:1: warning: the frame size of 23632 bytes is larger than 3072 bytes
+ lib/atomic64_test.c:250:1: warning: the frame size of 11200 bytes is larger than 3072 bytes
+ drivers/gpu/drm/i915/gvt/handlers.c:2621:1: warning: the frame size of 9208 bytes is larger than 3072 bytes
+ drivers/media/dvb-frontends/stv090x.c:3431:1: warning: the frame size of 6816 bytes is larger than 3072 bytes
+ fs/fscache/stats.c:287:1: warning: the frame size of 6536 bytes is larger than 3072 bytes
+
+To reduce this risk, -fsanitize-address-use-after-scope is now split out
+into a separate CONFIG_KASAN_EXTRA Kconfig option, leading to stack
+frames that are smaller than 2 kilobytes most of the time on x86_64. An
+earlier version of this patch also prevented combining KASAN_EXTRA with
+KASAN_INLINE, but that is no longer necessary with gcc-7.0.1.
+
+All patches to get the frame size below 2048 bytes with CONFIG_KASAN=y
+and CONFIG_KASAN_EXTRA=n have been merged by maintainers now, so we can
+bring back that default now. KASAN_EXTRA=y still causes lots of
+warnings but now defaults to !COMPILE_TEST to disable it in
+allmodconfig, and it remains disabled in all other defconfigs since it
+is a new option. I arbitrarily raise the warning limit for KASAN_EXTRA
+to 3072 to reduce the noise, but an allmodconfig kernel still has around
+50 warnings on gcc-7.
+
+I experimented a bit more with smaller stack frames and have another
+follow-up series that reduces the warning limit for 64-bit architectures
+to 1280 bytes (without CONFIG_KASAN).
+
+With earlier versions of this patch series, I also had patches to address
+the warnings we get with KASAN and/or KASAN_EXTRA, using a
+"noinline_if_stackbloat" annotation.
+
+That annotation now got replaced with a gcc-8 bugfix (see
+https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81715) and a workaround for
+older compilers, which means that KASAN_EXTRA is now just as bad as
+before and will lead to an instant stack overflow in a few extreme
+cases.
+
+This reverts parts of commit 3f181b4d8652 ("lib/Kconfig.debug: disable
+-Wframe-larger-than warnings with KASAN=y"). Two patches in linux-next
+should be merged first to avoid introducing warnings in an allmodconfig
+build:
+ 3cd890dbe2a4 ("media: dvb-frontends: fix i2c access helpers for KASAN")
+ 16c3ada89cff ("media: r820t: fix r820t_write_reg for KASAN")
+
+Do we really need to backport this?
+
+I think we do: without this patch, enabling KASAN will lead to
+unavoidable kernel stack overflow in certain device drivers when built
+with gcc-7 or higher on linux-4.10+ or any version that contains a
+backport of commit c5caf21ab0cf8. Most people are probably still on
+older compilers, but it will get worse over time as they upgrade their
+distros.
+
+The warnings we get on kernels older than this should all be for code
+that uses dangerously large stack frames, though most of them do not
+cause an actual stack overflow by themselves.The asan-stack option was
+added in linux-4.0, and commit 3f181b4d8652 ("lib/Kconfig.debug:
+disable -Wframe-larger-than warnings with KASAN=y") effectively turned
+off the warning for allmodconfig kernels, so I would like to see this
+fix backported to any kernels later than 4.0.
+
+I have done dozens of fixes for individual functions with stack frames
+larger than 2048 bytes with asan-stack, and I plan to make sure that
+all those fixes make it into the stable kernels as well (most are
+already there).
+
+Part of the complication here is that asan-stack (from 4.0) was
+originally assumed to always require much larger stacks, but that
+turned out to be a combination of multiple gcc bugs that we have now
+worked around and fixed, but sanitize-address-use-after-scope (from
+v4.10) has a much higher inherent stack usage and also suffers from at
+least three other problems that we have analyzed but not yet fixed
+upstream, each of them makes the stack usage more severe than it should
+be.
+
+Link: http://lkml.kernel.org/r/20171221134744.2295529-1-arnd@arndb.de
+Signed-off-by: Arnd Bergmann <arnd@arndb.de>
+Acked-by: Andrey Ryabinin <aryabinin@virtuozzo.com>
+Cc: Mauro Carvalho Chehab <mchehab@kernel.org>
+Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
+Cc: Alexander Potapenko <glider@google.com>
+Cc: Dmitry Vyukov <dvyukov@google.com>
+Cc: Andrey Konovalov <andreyknvl@google.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>
+
+---
+ lib/Kconfig.debug | 2 +-
+ lib/Kconfig.kasan | 11 +++++++++++
+ scripts/Makefile.kasan | 2 ++
+ 3 files changed, 14 insertions(+), 1 deletion(-)
+
+--- a/lib/Kconfig.debug
++++ b/lib/Kconfig.debug
+@@ -217,7 +217,7 @@ config ENABLE_MUST_CHECK
+ config FRAME_WARN
+ int "Warn for stack frames larger than (needs gcc 4.4)"
+ range 0 8192
+- default 0 if KASAN
++ default 3072 if KASAN_EXTRA
+ default 2048 if GCC_PLUGIN_LATENT_ENTROPY
+ default 1280 if (!64BIT && PARISC)
+ default 1024 if (!64BIT && !PARISC)
+--- a/lib/Kconfig.kasan
++++ b/lib/Kconfig.kasan
+@@ -20,6 +20,17 @@ config KASAN
+ Currently CONFIG_KASAN doesn't work with CONFIG_DEBUG_SLAB
+ (the resulting kernel does not boot).
+
++config KASAN_EXTRA
++ bool "KAsan: extra checks"
++ depends on KASAN && DEBUG_KERNEL && !COMPILE_TEST
++ help
++ This enables further checks in the kernel address sanitizer, for now
++ it only includes the address-use-after-scope check that can lead
++ to excessive kernel stack usage, frame size warnings and longer
++ compile time.
++ https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81715 has more
++
++
+ choice
+ prompt "Instrumentation type"
+ depends on KASAN
+--- a/scripts/Makefile.kasan
++++ b/scripts/Makefile.kasan
+@@ -30,7 +30,9 @@ else
+ endif
+ endif
+
++ifdef CONFIG_KASAN_EXTRA
+ CFLAGS_KASAN += $(call cc-option, -fsanitize-address-use-after-scope)
++endif
+
+ CFLAGS_KASAN_NOSANITIZE := -fno-builtin
+
--- /dev/null
+From 4f7e988e63e336827f4150de48163bed05d653bd Mon Sep 17 00:00:00 2001
+From: Rasmus Villemoes <linux@rasmusvillemoes.dk>
+Date: Tue, 6 Feb 2018 15:37:55 -0800
+Subject: kernel/async.c: revert "async: simplify lowest_in_progress()"
+
+From: Rasmus Villemoes <linux@rasmusvillemoes.dk>
+
+commit 4f7e988e63e336827f4150de48163bed05d653bd upstream.
+
+This reverts commit 92266d6ef60c ("async: simplify lowest_in_progress()")
+which was simply wrong: In the case where domain is NULL, we now use the
+wrong offsetof() in the list_first_entry macro, so we don't actually
+fetch the ->cookie value, but rather the eight bytes located
+sizeof(struct list_head) further into the struct async_entry.
+
+On 64 bit, that's the data member, while on 32 bit, that's a u64 built
+from func and data in some order.
+
+I think the bug happens to be harmless in practice: It obviously only
+affects callers which pass a NULL domain, and AFAICT the only such
+caller is
+
+ async_synchronize_full() ->
+ async_synchronize_full_domain(NULL) ->
+ async_synchronize_cookie_domain(ASYNC_COOKIE_MAX, NULL)
+
+and the ASYNC_COOKIE_MAX means that in practice we end up waiting for
+the async_global_pending list to be empty - but it would break if
+somebody happened to pass (void*)-1 as the data element to
+async_schedule, and of course also if somebody ever does a
+async_synchronize_cookie_domain(, NULL) with a "finite" cookie value.
+
+Maybe the "harmless in practice" means this isn't -stable material. But
+I'm not completely confident my quick git grep'ing is enough, and there
+might be affected code in one of the earlier kernels that has since been
+removed, so I'll leave the decision to the stable guys.
+
+Link: http://lkml.kernel.org/r/20171128104938.3921-1-linux@rasmusvillemoes.dk
+Fixes: 92266d6ef60c "async: simplify lowest_in_progress()"
+Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
+Acked-by: Tejun Heo <tj@kernel.org>
+Cc: Arjan van de Ven <arjan@linux.intel.com>
+Cc: Adam Wallis <awallis@codeaurora.org>
+Cc: Lai Jiangshan <laijs@cn.fujitsu.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>
+
+---
+ kernel/async.c | 20 ++++++++++++--------
+ 1 file changed, 12 insertions(+), 8 deletions(-)
+
+--- a/kernel/async.c
++++ b/kernel/async.c
+@@ -84,20 +84,24 @@ static atomic_t entry_count;
+
+ static async_cookie_t lowest_in_progress(struct async_domain *domain)
+ {
+- struct list_head *pending;
++ struct async_entry *first = NULL;
+ async_cookie_t ret = ASYNC_COOKIE_MAX;
+ unsigned long flags;
+
+ spin_lock_irqsave(&async_lock, flags);
+
+- if (domain)
+- pending = &domain->pending;
+- else
+- pending = &async_global_pending;
++ if (domain) {
++ if (!list_empty(&domain->pending))
++ first = list_first_entry(&domain->pending,
++ struct async_entry, domain_list);
++ } else {
++ if (!list_empty(&async_global_pending))
++ first = list_first_entry(&async_global_pending,
++ struct async_entry, global_list);
++ }
+
+- if (!list_empty(pending))
+- ret = list_first_entry(pending, struct async_entry,
+- domain_list)->cookie;
++ if (first)
++ ret = first->cookie;
+
+ spin_unlock_irqrestore(&async_lock, flags);
+ return ret;
--- /dev/null
+From a1be1f3931bfe0a42b46fef77a04593c2b136e7f Mon Sep 17 00:00:00 2001
+From: Eric Biggers <ebiggers@google.com>
+Date: Tue, 6 Feb 2018 15:40:24 -0800
+Subject: kernel/relay.c: revert "kernel/relay.c: fix potential memory leak"
+
+From: Eric Biggers <ebiggers@google.com>
+
+commit a1be1f3931bfe0a42b46fef77a04593c2b136e7f upstream.
+
+This reverts commit ba62bafe942b ("kernel/relay.c: fix potential memory leak").
+
+This commit introduced a double free bug, because 'chan' is already
+freed by the line:
+
+ kref_put(&chan->kref, relay_destroy_channel);
+
+This bug was found by syzkaller, using the BLKTRACESETUP ioctl.
+
+Link: http://lkml.kernel.org/r/20180127004759.101823-1-ebiggers3@gmail.com
+Fixes: ba62bafe942b ("kernel/relay.c: fix potential memory leak")
+Signed-off-by: Eric Biggers <ebiggers@google.com>
+Reported-by: syzbot <syzkaller@googlegroups.com>
+Reviewed-by: Andrew Morton <akpm@linux-foundation.org>
+Cc: Zhouyi Zhou <yizhouzhou@ict.ac.cn>
+Cc: Jens Axboe <axboe@kernel.dk>
+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>
+
+---
+ kernel/relay.c | 1 -
+ 1 file changed, 1 deletion(-)
+
+--- a/kernel/relay.c
++++ b/kernel/relay.c
+@@ -611,7 +611,6 @@ free_bufs:
+
+ kref_put(&chan->kref, relay_destroy_channel);
+ mutex_unlock(&relay_channels_mutex);
+- kfree(chan);
+ return NULL;
+ }
+ EXPORT_SYMBOL_GPL(relay_open);
--- /dev/null
+From 58d6b15e9da5042a99c9c30ad725792e4569150e Mon Sep 17 00:00:00 2001
+From: James Morse <james.morse@arm.com>
+Date: Mon, 22 Jan 2018 18:19:06 +0000
+Subject: KVM: arm/arm64: Handle CPU_PM_ENTER_FAILED
+
+From: James Morse <james.morse@arm.com>
+
+commit 58d6b15e9da5042a99c9c30ad725792e4569150e upstream.
+
+cpu_pm_enter() calls the pm notifier chain with CPU_PM_ENTER, then if
+there is a failure: CPU_PM_ENTER_FAILED.
+
+When KVM receives CPU_PM_ENTER it calls cpu_hyp_reset() which will
+return us to the hyp-stub. If we subsequently get a CPU_PM_ENTER_FAILED,
+KVM does nothing, leaving the CPU running with the hyp-stub, at odds
+with kvm_arm_hardware_enabled.
+
+Add CPU_PM_ENTER_FAILED as a fallthrough for CPU_PM_EXIT, this reloads
+KVM based on kvm_arm_hardware_enabled. This is safe even if CPU_PM_ENTER
+never gets as far as KVM, as cpu_hyp_reinit() calls cpu_hyp_reset()
+to make sure the hyp-stub is loaded before reloading KVM.
+
+Fixes: 67f691976662 ("arm64: kvm: allows kvm cpu hotplug")
+CC: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
+Reviewed-by: Christoffer Dall <christoffer.dall@linaro.org>
+Signed-off-by: James Morse <james.morse@arm.com>
+Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ virt/kvm/arm/arm.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/virt/kvm/arm/arm.c
++++ b/virt/kvm/arm/arm.c
+@@ -1220,6 +1220,7 @@ static int hyp_init_cpu_pm_notifier(stru
+ cpu_hyp_reset();
+
+ return NOTIFY_OK;
++ case CPU_PM_ENTER_FAILED:
+ case CPU_PM_EXIT:
+ if (__this_cpu_read(kvm_arm_hardware_enabled))
+ /* The hardware was enabled before suspend. */
--- /dev/null
+From 5c7d4f9ad39d980728b39752304ce10bb2960cbf Mon Sep 17 00:00:00 2001
+From: Liran Alon <liran.alon@oracle.com>
+Date: Sun, 19 Nov 2017 18:25:43 +0200
+Subject: KVM: nVMX: Fix bug of injecting L2 exception into L1
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Liran Alon <liran.alon@oracle.com>
+
+commit 5c7d4f9ad39d980728b39752304ce10bb2960cbf upstream.
+
+kvm_clear_exception_queue() should clear pending exception.
+This also includes exceptions which were only marked pending but not
+yet injected. This is because exception.pending is used for both L1
+and L2 to determine if an exception should be raised to guest.
+Note that an exception which is pending but not yet injected will
+be raised again once the guest will be resumed.
+
+Consider the following scenario:
+1) L0 KVM with ignore_msrs=false.
+2) L1 prepare vmcs12 with the following:
+ a) No intercepts on MSR (MSR_BITMAP exist and is filled with 0).
+ b) No intercept for #GP.
+ c) vmx-preemption-timer is configured.
+3) L1 enters into L2.
+4) L2 reads an unhandled MSR that exists in MSR_BITMAP
+(such as 0x1fff).
+
+L2 RDMSR could be handled as described below:
+1) L2 exits to L0 on RDMSR and calls handle_rdmsr().
+2) handle_rdmsr() calls kvm_inject_gp() which sets
+KVM_REQ_EVENT, exception.pending=true and exception.injected=false.
+3) vcpu_enter_guest() consumes KVM_REQ_EVENT and calls
+inject_pending_event() which calls vmx_check_nested_events()
+which sees that exception.pending=true but
+nested_vmx_check_exception() returns 0 and therefore does nothing at
+this point. However let's assume it later sees vmx-preemption-timer
+expired and therefore exits from L2 to L1 by calling
+nested_vmx_vmexit().
+4) nested_vmx_vmexit() calls prepare_vmcs12()
+which calls vmcs12_save_pending_event() but it does nothing as
+exception.injected is false. Also prepare_vmcs12() calls
+kvm_clear_exception_queue() which does nothing as
+exception.injected is already false.
+5) We now return from vmx_check_nested_events() with 0 while still
+having exception.pending=true!
+6) Therefore inject_pending_event() continues
+and we inject L2 exception to L1!...
+
+This commit will fix above issue by changing step (4) to
+clear exception.pending in kvm_clear_exception_queue().
+
+Fixes: 664f8e26b00c ("KVM: X86: Fix loss of exception which has not yet been injected")
+Signed-off-by: Liran Alon <liran.alon@oracle.com>
+Reviewed-by: Nikita Leshenko <nikita.leshchenko@oracle.com>
+Reviewed-by: Krish Sadhukhan <krish.sadhukhan@oracle.com>
+Signed-off-by: Krish Sadhukhan <krish.sadhukhan@oracle.com>
+Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
+Signed-off-by: Radim Krčmář <rkrcmar@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/x86/kvm/vmx.c | 1 -
+ arch/x86/kvm/x86.h | 1 +
+ 2 files changed, 1 insertion(+), 1 deletion(-)
+
+--- a/arch/x86/kvm/vmx.c
++++ b/arch/x86/kvm/vmx.c
+@@ -11246,7 +11246,6 @@ static int vmx_check_nested_events(struc
+ if (block_nested_events)
+ return -EBUSY;
+ nested_vmx_inject_exception_vmexit(vcpu, exit_qual);
+- vcpu->arch.exception.pending = false;
+ return 0;
+ }
+
+--- a/arch/x86/kvm/x86.h
++++ b/arch/x86/kvm/x86.h
+@@ -12,6 +12,7 @@
+
+ static inline void kvm_clear_exception_queue(struct kvm_vcpu *vcpu)
+ {
++ vcpu->arch.exception.pending = false;
+ vcpu->arch.exception.injected = false;
+ }
+
--- /dev/null
+From 6b6977117f50d60455ace86b2d256f6fb4f3de05 Mon Sep 17 00:00:00 2001
+From: Liran Alon <liran.alon@oracle.com>
+Date: Thu, 9 Nov 2017 20:27:20 +0200
+Subject: KVM: nVMX: Fix races when sending nested PI while dest enters/leaves L2
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Liran Alon <liran.alon@oracle.com>
+
+commit 6b6977117f50d60455ace86b2d256f6fb4f3de05 upstream.
+
+Consider the following scenario:
+1. CPU A calls vmx_deliver_nested_posted_interrupt() to send an IPI
+to CPU B via virtual posted-interrupt mechanism.
+2. CPU B is currently executing L2 guest.
+3. vmx_deliver_nested_posted_interrupt() calls
+kvm_vcpu_trigger_posted_interrupt() which will note that
+vcpu->mode == IN_GUEST_MODE.
+4. Assume that before CPU A sends the physical POSTED_INTR_NESTED_VECTOR
+IPI, CPU B exits from L2 to L0 during event-delivery
+(valid IDT-vectoring-info).
+5. CPU A now sends the physical IPI. The IPI is received in host and
+it's handler (smp_kvm_posted_intr_nested_ipi()) does nothing.
+6. Assume that before CPU A sets pi_pending=true and KVM_REQ_EVENT,
+CPU B continues to run in L0 and reach vcpu_enter_guest(). As
+KVM_REQ_EVENT is not set yet, vcpu_enter_guest() will continue and resume
+L2 guest.
+7. At this point, CPU A sets pi_pending=true and KVM_REQ_EVENT but
+it's too late! CPU B already entered L2 and KVM_REQ_EVENT will only be
+consumed at next L2 entry!
+
+Another scenario to consider:
+1. CPU A calls vmx_deliver_nested_posted_interrupt() to send an IPI
+to CPU B via virtual posted-interrupt mechanism.
+2. Assume that before CPU A calls kvm_vcpu_trigger_posted_interrupt(),
+CPU B is at L0 and is about to resume into L2. Further assume that it is
+in vcpu_enter_guest() after check for KVM_REQ_EVENT.
+3. At this point, CPU A calls kvm_vcpu_trigger_posted_interrupt() which
+will note that vcpu->mode != IN_GUEST_MODE. Therefore, do nothing and
+return false. Then, will set pi_pending=true and KVM_REQ_EVENT.
+4. Now CPU B continue and resumes into L2 guest without processing
+the posted-interrupt until next L2 entry!
+
+To fix both issues, we just need to change
+vmx_deliver_nested_posted_interrupt() to set pi_pending=true and
+KVM_REQ_EVENT before calling kvm_vcpu_trigger_posted_interrupt().
+
+It will fix the first scenario by chaging step (6) to note that
+KVM_REQ_EVENT and pi_pending=true and therefore process
+nested posted-interrupt.
+
+It will fix the second scenario by two possible ways:
+1. If kvm_vcpu_trigger_posted_interrupt() is called while CPU B has changed
+vcpu->mode to IN_GUEST_MODE, physical IPI will be sent and will be received
+when CPU resumes into L2.
+2. If kvm_vcpu_trigger_posted_interrupt() is called while CPU B hasn't yet
+changed vcpu->mode to IN_GUEST_MODE, then after CPU B will change
+vcpu->mode it will call kvm_request_pending() which will return true and
+therefore force another round of vcpu_enter_guest() which will note that
+KVM_REQ_EVENT and pi_pending=true and therefore process nested
+posted-interrupt.
+
+Fixes: 705699a13994 ("KVM: nVMX: Enable nested posted interrupt processing")
+Signed-off-by: Liran Alon <liran.alon@oracle.com>
+Reviewed-by: Nikita Leshenko <nikita.leshchenko@oracle.com>
+Reviewed-by: Krish Sadhukhan <krish.sadhukhan@oracle.com>
+[Add kvm_vcpu_kick to also handle the case where L1 doesn't intercept L2 HLT
+ and L2 executes HLT instruction. - Paolo]
+Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
+Signed-off-by: Radim Krčmář <rkrcmar@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/x86/kvm/vmx.c | 5 +++--
+ 1 file changed, 3 insertions(+), 2 deletions(-)
+
+--- a/arch/x86/kvm/vmx.c
++++ b/arch/x86/kvm/vmx.c
+@@ -5322,14 +5322,15 @@ static int vmx_deliver_nested_posted_int
+
+ if (is_guest_mode(vcpu) &&
+ vector == vmx->nested.posted_intr_nv) {
+- /* the PIR and ON have been set by L1. */
+- kvm_vcpu_trigger_posted_interrupt(vcpu, true);
+ /*
+ * If a posted intr is not recognized by hardware,
+ * we will accomplish it in the next vmentry.
+ */
+ vmx->nested.pi_pending = true;
+ kvm_make_request(KVM_REQ_EVENT, vcpu);
++ /* the PIR and ON have been set by L1. */
++ if (!kvm_vcpu_trigger_posted_interrupt(vcpu, true))
++ kvm_vcpu_kick(vcpu);
+ return 0;
+ }
+ return -1;
--- /dev/null
+From 36ee41d161c67a6fcf696d4817a0da31f778938c Mon Sep 17 00:00:00 2001
+From: Paul Mackerras <paulus@ozlabs.org>
+Date: Tue, 30 Jan 2018 10:51:32 +1100
+Subject: KVM: PPC: Book3S HV: Drop locks before reading guest memory
+
+From: Paul Mackerras <paulus@ozlabs.org>
+
+commit 36ee41d161c67a6fcf696d4817a0da31f778938c upstream.
+
+Running with CONFIG_DEBUG_ATOMIC_SLEEP reveals that HV KVM tries to
+read guest memory, in order to emulate guest instructions, while
+preempt is disabled and a vcore lock is held. This occurs in
+kvmppc_handle_exit_hv(), called from post_guest_process(), when
+emulating guest doorbell instructions on POWER9 systems, and also
+when checking whether we have hit a hypervisor breakpoint.
+Reading guest memory can cause a page fault and thus cause the
+task to sleep, so we need to avoid reading guest memory while
+holding a spinlock or when preempt is disabled.
+
+To fix this, we move the preempt_enable() in kvmppc_run_core() to
+before the loop that calls post_guest_process() for each vcore that
+has just run, and we drop and re-take the vcore lock around the calls
+to kvmppc_emulate_debug_inst() and kvmppc_emulate_doorbell_instr().
+
+Dropping the lock is safe with respect to the iteration over the
+runnable vcpus in post_guest_process(); for_each_runnable_thread
+is actually safe to use locklessly. It is possible for a vcpu
+to become runnable and add itself to the runnable_threads array
+(code near the beginning of kvmppc_run_vcpu()) and then get included
+in the iteration in post_guest_process despite the fact that it
+has not just run. This is benign because vcpu->arch.trap and
+vcpu->arch.ceded will be zero.
+
+Fixes: 579006944e0d ("KVM: PPC: Book3S HV: Virtualize doorbell facility on POWER9")
+Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/powerpc/kvm/book3s_hv.c | 16 ++++++++++++----
+ 1 file changed, 12 insertions(+), 4 deletions(-)
+
+--- a/arch/powerpc/kvm/book3s_hv.c
++++ b/arch/powerpc/kvm/book3s_hv.c
+@@ -999,8 +999,6 @@ static int kvmppc_emulate_doorbell_instr
+ struct kvm *kvm = vcpu->kvm;
+ struct kvm_vcpu *tvcpu;
+
+- if (!cpu_has_feature(CPU_FTR_ARCH_300))
+- return EMULATE_FAIL;
+ if (kvmppc_get_last_inst(vcpu, INST_GENERIC, &inst) != EMULATE_DONE)
+ return RESUME_GUEST;
+ if (get_op(inst) != 31)
+@@ -1050,6 +1048,7 @@ static int kvmppc_emulate_doorbell_instr
+ return RESUME_GUEST;
+ }
+
++/* Called with vcpu->arch.vcore->lock held */
+ static int kvmppc_handle_exit_hv(struct kvm_run *run, struct kvm_vcpu *vcpu,
+ struct task_struct *tsk)
+ {
+@@ -1169,7 +1168,10 @@ static int kvmppc_handle_exit_hv(struct
+ swab32(vcpu->arch.emul_inst) :
+ vcpu->arch.emul_inst;
+ if (vcpu->guest_debug & KVM_GUESTDBG_USE_SW_BP) {
++ /* Need vcore unlocked to call kvmppc_get_last_inst */
++ spin_unlock(&vcpu->arch.vcore->lock);
+ r = kvmppc_emulate_debug_inst(run, vcpu);
++ spin_lock(&vcpu->arch.vcore->lock);
+ } else {
+ kvmppc_core_queue_program(vcpu, SRR1_PROGILL);
+ r = RESUME_GUEST;
+@@ -1184,8 +1186,13 @@ static int kvmppc_handle_exit_hv(struct
+ */
+ case BOOK3S_INTERRUPT_H_FAC_UNAVAIL:
+ r = EMULATE_FAIL;
+- if ((vcpu->arch.hfscr >> 56) == FSCR_MSGP_LG)
++ if (((vcpu->arch.hfscr >> 56) == FSCR_MSGP_LG) &&
++ cpu_has_feature(CPU_FTR_ARCH_300)) {
++ /* Need vcore unlocked to call kvmppc_get_last_inst */
++ spin_unlock(&vcpu->arch.vcore->lock);
+ r = kvmppc_emulate_doorbell_instr(vcpu);
++ spin_lock(&vcpu->arch.vcore->lock);
++ }
+ if (r == EMULATE_FAIL) {
+ kvmppc_core_queue_program(vcpu, SRR1_PROGILL);
+ r = RESUME_GUEST;
+@@ -2889,13 +2896,14 @@ static noinline void kvmppc_run_core(str
+ /* make sure updates to secondary vcpu structs are visible now */
+ smp_mb();
+
++ preempt_enable();
++
+ for (sub = 0; sub < core_info.n_subcores; ++sub) {
+ pvc = core_info.vc[sub];
+ post_guest_process(pvc, pvc == vc);
+ }
+
+ spin_lock(&vc->lock);
+- preempt_enable();
+
+ out:
+ vc->vcore_state = VCORE_INACTIVE;
--- /dev/null
+From 43ff3f65234061e08d234bdef5a9aadc19832b74 Mon Sep 17 00:00:00 2001
+From: Paul Mackerras <paulus@ozlabs.org>
+Date: Thu, 11 Jan 2018 14:31:43 +1100
+Subject: KVM: PPC: Book3S HV: Make sure we don't re-enter guest without XIVE loaded
+
+From: Paul Mackerras <paulus@ozlabs.org>
+
+commit 43ff3f65234061e08d234bdef5a9aadc19832b74 upstream.
+
+This fixes a bug where it is possible to enter a guest on a POWER9
+system without having the XIVE (interrupt controller) context loaded.
+This can happen because we unload the XIVE context from the CPU
+before doing the real-mode handling for machine checks. After the
+real-mode handler runs, it is possible that we re-enter the guest
+via a fast path which does not load the XIVE context.
+
+To fix this, we move the unloading of the XIVE context to come after
+the real-mode machine check handler is called.
+
+Fixes: 5af50993850a ("KVM: PPC: Book3S HV: Native usage of the XIVE interrupt controller")
+Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/powerpc/kvm/book3s_hv_rmhandlers.S | 40 ++++++++++++++++----------------
+ 1 file changed, 20 insertions(+), 20 deletions(-)
+
+--- a/arch/powerpc/kvm/book3s_hv_rmhandlers.S
++++ b/arch/powerpc/kvm/book3s_hv_rmhandlers.S
+@@ -1387,6 +1387,26 @@ END_FTR_SECTION_IFSET(CPU_FTR_ARCH_300)
+ blt deliver_guest_interrupt
+
+ guest_exit_cont: /* r9 = vcpu, r12 = trap, r13 = paca */
++ /* Save more register state */
++ mfdar r6
++ mfdsisr r7
++ std r6, VCPU_DAR(r9)
++ stw r7, VCPU_DSISR(r9)
++ /* don't overwrite fault_dar/fault_dsisr if HDSI */
++ cmpwi r12,BOOK3S_INTERRUPT_H_DATA_STORAGE
++ beq mc_cont
++ std r6, VCPU_FAULT_DAR(r9)
++ stw r7, VCPU_FAULT_DSISR(r9)
++
++ /* See if it is a machine check */
++ cmpwi r12, BOOK3S_INTERRUPT_MACHINE_CHECK
++ beq machine_check_realmode
++mc_cont:
++#ifdef CONFIG_KVM_BOOK3S_HV_EXIT_TIMING
++ addi r3, r9, VCPU_TB_RMEXIT
++ mr r4, r9
++ bl kvmhv_accumulate_time
++#endif
+ #ifdef CONFIG_KVM_XICS
+ /* We are exiting, pull the VP from the XIVE */
+ lwz r0, VCPU_XIVE_PUSHED(r9)
+@@ -1424,26 +1444,6 @@ guest_exit_cont: /* r9 = vcpu, r12 = tr
+ eieio
+ 1:
+ #endif /* CONFIG_KVM_XICS */
+- /* Save more register state */
+- mfdar r6
+- mfdsisr r7
+- std r6, VCPU_DAR(r9)
+- stw r7, VCPU_DSISR(r9)
+- /* don't overwrite fault_dar/fault_dsisr if HDSI */
+- cmpwi r12,BOOK3S_INTERRUPT_H_DATA_STORAGE
+- beq mc_cont
+- std r6, VCPU_FAULT_DAR(r9)
+- stw r7, VCPU_FAULT_DSISR(r9)
+-
+- /* See if it is a machine check */
+- cmpwi r12, BOOK3S_INTERRUPT_MACHINE_CHECK
+- beq machine_check_realmode
+-mc_cont:
+-#ifdef CONFIG_KVM_BOOK3S_HV_EXIT_TIMING
+- addi r3, r9, VCPU_TB_RMEXIT
+- mr r4, r9
+- bl kvmhv_accumulate_time
+-#endif
+
+ mr r3, r12
+ /* Increment exit count, poke other threads to exit */
--- /dev/null
+From 57ea5f161a7de5b1913c212d04f57a175b159fdf Mon Sep 17 00:00:00 2001
+From: Ulf Magnusson <ulfalizer@gmail.com>
+Date: Mon, 5 Feb 2018 02:21:14 +0100
+Subject: KVM: PPC: Book3S PR: Fix broken select due to misspelling
+
+From: Ulf Magnusson <ulfalizer@gmail.com>
+
+commit 57ea5f161a7de5b1913c212d04f57a175b159fdf upstream.
+
+Commit 76d837a4c0f9 ("KVM: PPC: Book3S PR: Don't include SPAPR TCE code
+on non-pseries platforms") added a reference to the globally undefined
+symbol PPC_SERIES. Looking at the rest of the commit, PPC_PSERIES was
+probably intended.
+
+Change PPC_SERIES to PPC_PSERIES.
+
+Discovered with the
+https://github.com/ulfalizer/Kconfiglib/blob/master/examples/list_undefined.py
+script.
+
+Fixes: 76d837a4c0f9 ("KVM: PPC: Book3S PR: Don't include SPAPR TCE code on non-pseries platforms")
+Signed-off-by: Ulf Magnusson <ulfalizer@gmail.com>
+Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/powerpc/kvm/Kconfig | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/arch/powerpc/kvm/Kconfig
++++ b/arch/powerpc/kvm/Kconfig
+@@ -68,7 +68,7 @@ config KVM_BOOK3S_64
+ select KVM_BOOK3S_64_HANDLER
+ select KVM
+ select KVM_BOOK3S_PR_POSSIBLE if !KVM_BOOK3S_HV_POSSIBLE
+- select SPAPR_TCE_IOMMU if IOMMU_SUPPORT && (PPC_SERIES || PPC_POWERNV)
++ select SPAPR_TCE_IOMMU if IOMMU_SUPPORT && (PPC_PSERIES || PPC_POWERNV)
+ ---help---
+ Support running unmodified book3s_64 and book3s_32 guest kernels
+ in virtual machines on book3s_64 host processors.
--- /dev/null
+From 9893b905e743ded332575ca04486bd586c0772f7 Mon Sep 17 00:00:00 2001
+From: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
+Date: Wed, 24 Jan 2018 06:01:57 -0500
+Subject: media: cxusb, dib0700: ignore XC2028_I2C_FLUSH
+
+From: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
+
+commit 9893b905e743ded332575ca04486bd586c0772f7 upstream.
+
+The XC2028_I2C_FLUSH only needs to be implemented on a few
+devices. Others can safely ignore it.
+
+That prevents filling the dmesg with lots of messages like:
+
+ dib0700: stk7700ph_xc3028_callback: unknown command 2, arg 0
+
+Fixes: 4d37ece757a8 ("[media] tuner/xc2028: Add I2C flush callback")
+Reported-by: Enrico Mioso <mrkiko.rs@gmail.com>
+Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/media/usb/dvb-usb/cxusb.c | 2 ++
+ drivers/media/usb/dvb-usb/dib0700_devices.c | 1 +
+ 2 files changed, 3 insertions(+)
+
+--- a/drivers/media/usb/dvb-usb/cxusb.c
++++ b/drivers/media/usb/dvb-usb/cxusb.c
+@@ -677,6 +677,8 @@ static int dvico_bluebird_xc2028_callbac
+ case XC2028_RESET_CLK:
+ deb_info("%s: XC2028_RESET_CLK %d\n", __func__, arg);
+ break;
++ case XC2028_I2C_FLUSH:
++ break;
+ default:
+ deb_info("%s: unknown command %d, arg %d\n", __func__,
+ command, arg);
+--- a/drivers/media/usb/dvb-usb/dib0700_devices.c
++++ b/drivers/media/usb/dvb-usb/dib0700_devices.c
+@@ -430,6 +430,7 @@ static int stk7700ph_xc3028_callback(voi
+ state->dib7000p_ops.set_gpio(adap->fe_adap[0].fe, 8, 0, 1);
+ break;
+ case XC2028_RESET_CLK:
++ case XC2028_I2C_FLUSH:
+ break;
+ default:
+ err("%s: unknown command %d, arg %d\n", __func__,
--- /dev/null
+From 3cd890dbe2a4f14cc44c85bb6cf37e5e22d4dd0e Mon Sep 17 00:00:00 2001
+From: Arnd Bergmann <arnd@arndb.de>
+Date: Thu, 30 Nov 2017 11:55:46 -0500
+Subject: media: dvb-frontends: fix i2c access helpers for KASAN
+
+From: Arnd Bergmann <arnd@arndb.de>
+
+commit 3cd890dbe2a4f14cc44c85bb6cf37e5e22d4dd0e upstream.
+
+A typical code fragment was copied across many dvb-frontend drivers and
+causes large stack frames when built with with CONFIG_KASAN on gcc-5/6/7:
+
+drivers/media/dvb-frontends/cxd2841er.c:3225:1: error: the frame size of 3992 bytes is larger than 3072 bytes [-Werror=frame-larger-than=]
+drivers/media/dvb-frontends/cxd2841er.c:3404:1: error: the frame size of 3136 bytes is larger than 3072 bytes [-Werror=frame-larger-than=]
+drivers/media/dvb-frontends/stv0367.c:3143:1: error: the frame size of 4016 bytes is larger than 3072 bytes [-Werror=frame-larger-than=]
+drivers/media/dvb-frontends/stv090x.c:3430:1: error: the frame size of 5312 bytes is larger than 3072 bytes [-Werror=frame-larger-than=]
+drivers/media/dvb-frontends/stv090x.c:4248:1: error: the frame size of 4872 bytes is larger than 3072 bytes [-Werror=frame-larger-than=]
+
+gcc-8 now solves this by consolidating the stack slots for the argument
+variables, but on older compilers we can get the same behavior by taking
+the pointer of a local variable rather than the inline function argument.
+
+Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81715
+
+Signed-off-by: Arnd Bergmann <arnd@arndb.de>
+Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/media/dvb-frontends/ascot2e.c | 4 +++-
+ drivers/media/dvb-frontends/cxd2841er.c | 4 +++-
+ drivers/media/dvb-frontends/helene.c | 4 +++-
+ drivers/media/dvb-frontends/horus3a.c | 4 +++-
+ drivers/media/dvb-frontends/itd1000.c | 5 +++--
+ drivers/media/dvb-frontends/mt312.c | 5 ++++-
+ drivers/media/dvb-frontends/stb0899_drv.c | 3 ++-
+ drivers/media/dvb-frontends/stb6100.c | 6 ++++--
+ drivers/media/dvb-frontends/stv0367.c | 4 +++-
+ drivers/media/dvb-frontends/stv090x.c | 4 +++-
+ drivers/media/dvb-frontends/stv6110x.c | 4 +++-
+ drivers/media/dvb-frontends/zl10039.c | 4 +++-
+ 12 files changed, 37 insertions(+), 14 deletions(-)
+
+--- a/drivers/media/dvb-frontends/ascot2e.c
++++ b/drivers/media/dvb-frontends/ascot2e.c
+@@ -155,7 +155,9 @@ static int ascot2e_write_regs(struct asc
+
+ static int ascot2e_write_reg(struct ascot2e_priv *priv, u8 reg, u8 val)
+ {
+- return ascot2e_write_regs(priv, reg, &val, 1);
++ u8 tmp = val; /* see gcc.gnu.org/bugzilla/show_bug.cgi?id=81715 */
++
++ return ascot2e_write_regs(priv, reg, &tmp, 1);
+ }
+
+ static int ascot2e_read_regs(struct ascot2e_priv *priv,
+--- a/drivers/media/dvb-frontends/cxd2841er.c
++++ b/drivers/media/dvb-frontends/cxd2841er.c
+@@ -257,7 +257,9 @@ static int cxd2841er_write_regs(struct c
+ static int cxd2841er_write_reg(struct cxd2841er_priv *priv,
+ u8 addr, u8 reg, u8 val)
+ {
+- return cxd2841er_write_regs(priv, addr, reg, &val, 1);
++ u8 tmp = val; /* see gcc.gnu.org/bugzilla/show_bug.cgi?id=81715 */
++
++ return cxd2841er_write_regs(priv, addr, reg, &tmp, 1);
+ }
+
+ static int cxd2841er_read_regs(struct cxd2841er_priv *priv,
+--- a/drivers/media/dvb-frontends/helene.c
++++ b/drivers/media/dvb-frontends/helene.c
+@@ -331,7 +331,9 @@ static int helene_write_regs(struct hele
+
+ static int helene_write_reg(struct helene_priv *priv, u8 reg, u8 val)
+ {
+- return helene_write_regs(priv, reg, &val, 1);
++ u8 tmp = val; /* see gcc.gnu.org/bugzilla/show_bug.cgi?id=81715 */
++
++ return helene_write_regs(priv, reg, &tmp, 1);
+ }
+
+ static int helene_read_regs(struct helene_priv *priv,
+--- a/drivers/media/dvb-frontends/horus3a.c
++++ b/drivers/media/dvb-frontends/horus3a.c
+@@ -89,7 +89,9 @@ static int horus3a_write_regs(struct hor
+
+ static int horus3a_write_reg(struct horus3a_priv *priv, u8 reg, u8 val)
+ {
+- return horus3a_write_regs(priv, reg, &val, 1);
++ u8 tmp = val; /* see gcc.gnu.org/bugzilla/show_bug.cgi?id=81715 */
++
++ return horus3a_write_regs(priv, reg, &tmp, 1);
+ }
+
+ static int horus3a_enter_power_save(struct horus3a_priv *priv)
+--- a/drivers/media/dvb-frontends/itd1000.c
++++ b/drivers/media/dvb-frontends/itd1000.c
+@@ -95,8 +95,9 @@ static int itd1000_read_reg(struct itd10
+
+ static inline int itd1000_write_reg(struct itd1000_state *state, u8 r, u8 v)
+ {
+- int ret = itd1000_write_regs(state, r, &v, 1);
+- state->shadow[r] = v;
++ u8 tmp = v; /* see gcc.gnu.org/bugzilla/show_bug.cgi?id=81715 */
++ int ret = itd1000_write_regs(state, r, &tmp, 1);
++ state->shadow[r] = tmp;
+ return ret;
+ }
+
+--- a/drivers/media/dvb-frontends/mt312.c
++++ b/drivers/media/dvb-frontends/mt312.c
+@@ -142,7 +142,10 @@ static inline int mt312_readreg(struct m
+ static inline int mt312_writereg(struct mt312_state *state,
+ const enum mt312_reg_addr reg, const u8 val)
+ {
+- return mt312_write(state, reg, &val, 1);
++ u8 tmp = val; /* see gcc.gnu.org/bugzilla/show_bug.cgi?id=81715 */
++
++
++ return mt312_write(state, reg, &tmp, 1);
+ }
+
+ static inline u32 mt312_div(u32 a, u32 b)
+--- a/drivers/media/dvb-frontends/stb0899_drv.c
++++ b/drivers/media/dvb-frontends/stb0899_drv.c
+@@ -539,7 +539,8 @@ int stb0899_write_regs(struct stb0899_st
+
+ int stb0899_write_reg(struct stb0899_state *state, unsigned int reg, u8 data)
+ {
+- return stb0899_write_regs(state, reg, &data, 1);
++ u8 tmp = data;
++ return stb0899_write_regs(state, reg, &tmp, 1);
+ }
+
+ /*
+--- a/drivers/media/dvb-frontends/stb6100.c
++++ b/drivers/media/dvb-frontends/stb6100.c
+@@ -226,12 +226,14 @@ static int stb6100_write_reg_range(struc
+
+ static int stb6100_write_reg(struct stb6100_state *state, u8 reg, u8 data)
+ {
++ u8 tmp = data; /* see gcc.gnu.org/bugzilla/show_bug.cgi?id=81715 */
++
+ if (unlikely(reg >= STB6100_NUMREGS)) {
+ dprintk(verbose, FE_ERROR, 1, "Invalid register offset 0x%x", reg);
+ return -EREMOTEIO;
+ }
+- data = (data & stb6100_template[reg].mask) | stb6100_template[reg].set;
+- return stb6100_write_reg_range(state, &data, reg, 1);
++ tmp = (tmp & stb6100_template[reg].mask) | stb6100_template[reg].set;
++ return stb6100_write_reg_range(state, &tmp, reg, 1);
+ }
+
+
+--- a/drivers/media/dvb-frontends/stv0367.c
++++ b/drivers/media/dvb-frontends/stv0367.c
+@@ -166,7 +166,9 @@ int stv0367_writeregs(struct stv0367_sta
+
+ static int stv0367_writereg(struct stv0367_state *state, u16 reg, u8 data)
+ {
+- return stv0367_writeregs(state, reg, &data, 1);
++ u8 tmp = data; /* see gcc.gnu.org/bugzilla/show_bug.cgi?id=81715 */
++
++ return stv0367_writeregs(state, reg, &tmp, 1);
+ }
+
+ static u8 stv0367_readreg(struct stv0367_state *state, u16 reg)
+--- a/drivers/media/dvb-frontends/stv090x.c
++++ b/drivers/media/dvb-frontends/stv090x.c
+@@ -755,7 +755,9 @@ static int stv090x_write_regs(struct stv
+
+ static int stv090x_write_reg(struct stv090x_state *state, unsigned int reg, u8 data)
+ {
+- return stv090x_write_regs(state, reg, &data, 1);
++ u8 tmp = data; /* see gcc.gnu.org/bugzilla/show_bug.cgi?id=81715 */
++
++ return stv090x_write_regs(state, reg, &tmp, 1);
+ }
+
+ static int stv090x_i2c_gate_ctrl(struct stv090x_state *state, int enable)
+--- a/drivers/media/dvb-frontends/stv6110x.c
++++ b/drivers/media/dvb-frontends/stv6110x.c
+@@ -97,7 +97,9 @@ static int stv6110x_write_regs(struct st
+
+ static int stv6110x_write_reg(struct stv6110x_state *stv6110x, u8 reg, u8 data)
+ {
+- return stv6110x_write_regs(stv6110x, reg, &data, 1);
++ u8 tmp = data; /* see gcc.gnu.org/bugzilla/show_bug.cgi?id=81715 */
++
++ return stv6110x_write_regs(stv6110x, reg, &tmp, 1);
+ }
+
+ static int stv6110x_init(struct dvb_frontend *fe)
+--- a/drivers/media/dvb-frontends/zl10039.c
++++ b/drivers/media/dvb-frontends/zl10039.c
+@@ -134,7 +134,9 @@ static inline int zl10039_writereg(struc
+ const enum zl10039_reg_addr reg,
+ const u8 val)
+ {
+- return zl10039_write(state, reg, &val, 1);
++ const u8 tmp = val; /* see gcc.gnu.org/bugzilla/show_bug.cgi?id=81715 */
++
++ return zl10039_write(state, reg, &tmp, 1);
+ }
+
+ static int zl10039_init(struct dvb_frontend *fe)
--- /dev/null
+From 81742be14b6a90c9fd0ff6eb4218bdf696ad8e46 Mon Sep 17 00:00:00 2001
+From: Mauro Carvalho Chehab <mchehab@s-opensource.com>
+Date: Wed, 10 Jan 2018 07:20:39 -0500
+Subject: media: ts2020: avoid integer overflows on 32 bit machines
+
+From: Mauro Carvalho Chehab <mchehab@s-opensource.com>
+
+commit 81742be14b6a90c9fd0ff6eb4218bdf696ad8e46 upstream.
+
+Before this patch, when compiled for arm32, the signal strength
+were reported as:
+
+Lock (0x1f) Signal= 4294908.66dBm C/N= 12.79dB
+
+Because of a 32 bit integer overflow. After it, it is properly
+reported as:
+
+ Lock (0x1f) Signal= -58.64dBm C/N= 12.79dB
+
+Fixes: 0f91c9d6bab9 ("[media] TS2020: Calculate tuner gain correctly")
+Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/media/dvb-frontends/ts2020.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/drivers/media/dvb-frontends/ts2020.c
++++ b/drivers/media/dvb-frontends/ts2020.c
+@@ -368,7 +368,7 @@ static int ts2020_read_tuner_gain(struct
+ gain2 = clamp_t(long, gain2, 0, 13);
+ v_agc = clamp_t(long, v_agc, 400, 1100);
+
+- *_gain = -(gain1 * 2330 +
++ *_gain = -((__s64)gain1 * 2330 +
+ gain2 * 3500 +
+ v_agc * 24 / 10 * 10 +
+ 10000);
+@@ -386,7 +386,7 @@ static int ts2020_read_tuner_gain(struct
+ gain3 = clamp_t(long, gain3, 0, 6);
+ v_agc = clamp_t(long, v_agc, 600, 1600);
+
+- *_gain = -(gain1 * 2650 +
++ *_gain = -((__s64)gain1 * 2650 +
+ gain2 * 3380 +
+ gain3 * 2850 +
+ v_agc * 176 / 100 * 10 -
--- /dev/null
+From f5a26acf0162477af6ee4c11b4fb9cffe5d3e257 Mon Sep 17 00:00:00 2001
+From: Mika Westerberg <mika.westerberg@linux.intel.com>
+Date: Wed, 29 Nov 2017 16:25:44 +0300
+Subject: pinctrl: intel: Initialize GPIO properly when used through irqchip
+
+From: Mika Westerberg <mika.westerberg@linux.intel.com>
+
+commit f5a26acf0162477af6ee4c11b4fb9cffe5d3e257 upstream.
+
+When a GPIO is requested using gpiod_get_* APIs the intel pinctrl driver
+switches the pin to GPIO mode and makes sure interrupts are routed to
+the GPIO hardware instead of IOAPIC. However, if the GPIO is used
+directly through irqchip, as is the case with many I2C-HID devices where
+I2C core automatically configures interrupt for the device, the pin is
+not initialized as GPIO. Instead we rely that the BIOS configures the
+pin accordingly which seems not to be the case at least in Asus X540NA
+SKU3 with Focaltech touchpad.
+
+When the pin is not properly configured it might result weird behaviour
+like interrupts suddenly stop firing completely and the touchpad stops
+responding to user input.
+
+Fix this by properly initializing the pin to GPIO mode also when it is
+used directly through irqchip.
+
+Fixes: 7981c0015af2 ("pinctrl: intel: Add Intel Sunrisepoint pin controller and GPIO support")
+Reported-by: Daniel Drake <drake@endlessm.com>
+Reported-and-tested-by: Chris Chiu <chiu@endlessm.com>
+Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
+Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/pinctrl/intel/pinctrl-intel.c | 23 +++++++++++++++--------
+ 1 file changed, 15 insertions(+), 8 deletions(-)
+
+--- a/drivers/pinctrl/intel/pinctrl-intel.c
++++ b/drivers/pinctrl/intel/pinctrl-intel.c
+@@ -427,6 +427,18 @@ static void __intel_gpio_set_direction(v
+ writel(value, padcfg0);
+ }
+
++static void intel_gpio_set_gpio_mode(void __iomem *padcfg0)
++{
++ u32 value;
++
++ /* Put the pad into GPIO mode */
++ value = readl(padcfg0) & ~PADCFG0_PMODE_MASK;
++ /* Disable SCI/SMI/NMI generation */
++ value &= ~(PADCFG0_GPIROUTIOXAPIC | PADCFG0_GPIROUTSCI);
++ value &= ~(PADCFG0_GPIROUTSMI | PADCFG0_GPIROUTNMI);
++ writel(value, padcfg0);
++}
++
+ static int intel_gpio_request_enable(struct pinctrl_dev *pctldev,
+ struct pinctrl_gpio_range *range,
+ unsigned pin)
+@@ -434,7 +446,6 @@ static int intel_gpio_request_enable(str
+ struct intel_pinctrl *pctrl = pinctrl_dev_get_drvdata(pctldev);
+ void __iomem *padcfg0;
+ unsigned long flags;
+- u32 value;
+
+ raw_spin_lock_irqsave(&pctrl->lock, flags);
+
+@@ -444,13 +455,7 @@ static int intel_gpio_request_enable(str
+ }
+
+ padcfg0 = intel_get_padcfg(pctrl, pin, PADCFG0);
+- /* Put the pad into GPIO mode */
+- value = readl(padcfg0) & ~PADCFG0_PMODE_MASK;
+- /* Disable SCI/SMI/NMI generation */
+- value &= ~(PADCFG0_GPIROUTIOXAPIC | PADCFG0_GPIROUTSCI);
+- value &= ~(PADCFG0_GPIROUTSMI | PADCFG0_GPIROUTNMI);
+- writel(value, padcfg0);
+-
++ intel_gpio_set_gpio_mode(padcfg0);
+ /* Disable TX buffer and enable RX (this will be input) */
+ __intel_gpio_set_direction(padcfg0, true);
+
+@@ -935,6 +940,8 @@ static int intel_gpio_irq_type(struct ir
+
+ raw_spin_lock_irqsave(&pctrl->lock, flags);
+
++ intel_gpio_set_gpio_mode(reg);
++
+ value = readl(reg);
+
+ value &= ~(PADCFG0_RXEVCFG_MASK | PADCFG0_RXINV);
--- /dev/null
+From 02e389e63e3523828fc3832f27e0341885f60f6f Mon Sep 17 00:00:00 2001
+From: Dmitry Mastykin <mastichi@gmail.com>
+Date: Thu, 28 Dec 2017 18:19:24 +0300
+Subject: pinctrl: mcp23s08: fix irq setup order
+
+From: Dmitry Mastykin <mastichi@gmail.com>
+
+commit 02e389e63e3523828fc3832f27e0341885f60f6f upstream.
+
+When using mcp23s08 module with gpio-keys, often (50% of boots)
+it fails to get irq numbers with message:
+"gpio-keys keys: Unable to get irq number for GPIO 0, error -6".
+Seems that irqs must be setup before devm_gpiochip_add_data().
+
+Signed-off-by: Dmitry Mastykin <mastichi@gmail.com>
+Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/pinctrl/pinctrl-mcp23s08.c | 8 ++++----
+ 1 file changed, 4 insertions(+), 4 deletions(-)
+
+--- a/drivers/pinctrl/pinctrl-mcp23s08.c
++++ b/drivers/pinctrl/pinctrl-mcp23s08.c
+@@ -891,16 +891,16 @@ static int mcp23s08_probe_one(struct mcp
+ goto fail;
+ }
+
+- ret = devm_gpiochip_add_data(dev, &mcp->chip, mcp);
+- if (ret < 0)
+- goto fail;
+-
+ if (mcp->irq && mcp->irq_controller) {
+ ret = mcp23s08_irq_setup(mcp);
+ if (ret)
+ goto fail;
+ }
+
++ ret = devm_gpiochip_add_data(dev, &mcp->chip, mcp);
++ if (ret < 0)
++ goto fail;
++
+ mcp->pinctrl_desc.name = "mcp23xxx-pinctrl";
+ mcp->pinctrl_desc.pctlops = &mcp_pinctrl_ops;
+ mcp->pinctrl_desc.confops = &mcp_pinconf_ops;
--- /dev/null
+From b930151e5b55a0e62a3aad06876de891ac980471 Mon Sep 17 00:00:00 2001
+From: Peter Rosin <peda@axentia.se>
+Date: Wed, 17 Jan 2018 14:34:23 +0100
+Subject: pinctrl: sx150x: Add a static gpio/pinctrl pin range mapping
+
+From: Peter Rosin <peda@axentia.se>
+
+commit b930151e5b55a0e62a3aad06876de891ac980471 upstream.
+
+Without such a range, gpiolib fails with -EPROBE_DEFER, pending the
+addition of the range. So, without a range, gpiolib will keep
+deferring indefinitely.
+
+Fixes: 9e80f9064e73 ("pinctrl: Add SX150X GPIO Extender Pinctrl Driver")
+Fixes: e10f72bf4b3e ("gpio: gpiolib: Generalise state persistence beyond sleep")
+Suggested-by: Linus Walleij <linus.walleij@linaro.org>
+Signed-off-by: Peter Rosin <peda@axentia.se>
+Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/pinctrl/pinctrl-sx150x.c | 5 +++++
+ 1 file changed, 5 insertions(+)
+
+--- a/drivers/pinctrl/pinctrl-sx150x.c
++++ b/drivers/pinctrl/pinctrl-sx150x.c
+@@ -1193,6 +1193,11 @@ static int sx150x_probe(struct i2c_clien
+ if (ret)
+ return ret;
+
++ ret = gpiochip_add_pin_range(&pctl->gpio, dev_name(dev),
++ 0, 0, pctl->data->npins);
++ if (ret)
++ return ret;
++
+ /* Add Interrupt support if an irq is specified */
+ if (client->irq > 0) {
+ pctl->irq_chip.name = devm_kstrdup(dev, client->name,
--- /dev/null
+From 1a1d39e1b8dd1d0f92a79da4fcc1ab0be3ae9bfc Mon Sep 17 00:00:00 2001
+From: Peter Rosin <peda@axentia.se>
+Date: Wed, 17 Jan 2018 14:34:22 +0100
+Subject: pinctrl: sx150x: Register pinctrl before adding the gpiochip
+
+From: Peter Rosin <peda@axentia.se>
+
+commit 1a1d39e1b8dd1d0f92a79da4fcc1ab0be3ae9bfc upstream.
+
+Various gpiolib activity depend on the pinctrl to be up and kicking.
+Therefore, register the pinctrl before adding a gpiochip.
+
+Suggested-by: Linus Walleij <linus.walleij@linaro.org>
+Signed-off-by: Peter Rosin <peda@axentia.se>
+Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/pinctrl/pinctrl-sx150x.c | 35 +++++++++++++++++++++--------------
+ 1 file changed, 21 insertions(+), 14 deletions(-)
+
+--- a/drivers/pinctrl/pinctrl-sx150x.c
++++ b/drivers/pinctrl/pinctrl-sx150x.c
+@@ -1144,6 +1144,27 @@ static int sx150x_probe(struct i2c_clien
+ if (ret)
+ return ret;
+
++ /* Pinctrl_desc */
++ pctl->pinctrl_desc.name = "sx150x-pinctrl";
++ pctl->pinctrl_desc.pctlops = &sx150x_pinctrl_ops;
++ pctl->pinctrl_desc.confops = &sx150x_pinconf_ops;
++ pctl->pinctrl_desc.pins = pctl->data->pins;
++ pctl->pinctrl_desc.npins = pctl->data->npins;
++ pctl->pinctrl_desc.owner = THIS_MODULE;
++
++ ret = devm_pinctrl_register_and_init(dev, &pctl->pinctrl_desc,
++ pctl, &pctl->pctldev);
++ if (ret) {
++ dev_err(dev, "Failed to register pinctrl device\n");
++ return ret;
++ }
++
++ ret = pinctrl_enable(pctl->pctldev);
++ if (ret) {
++ dev_err(dev, "Failed to enable pinctrl device\n");
++ return ret;
++ }
++
+ /* Register GPIO controller */
+ pctl->gpio.label = devm_kstrdup(dev, client->name, GFP_KERNEL);
+ pctl->gpio.base = -1;
+@@ -1217,20 +1238,6 @@ static int sx150x_probe(struct i2c_clien
+ client->irq);
+ }
+
+- /* Pinctrl_desc */
+- pctl->pinctrl_desc.name = "sx150x-pinctrl";
+- pctl->pinctrl_desc.pctlops = &sx150x_pinctrl_ops;
+- pctl->pinctrl_desc.confops = &sx150x_pinconf_ops;
+- pctl->pinctrl_desc.pins = pctl->data->pins;
+- pctl->pinctrl_desc.npins = pctl->data->npins;
+- pctl->pinctrl_desc.owner = THIS_MODULE;
+-
+- pctl->pctldev = devm_pinctrl_register(dev, &pctl->pinctrl_desc, pctl);
+- if (IS_ERR(pctl->pctldev)) {
+- dev_err(dev, "Failed to register pinctrl device\n");
+- return PTR_ERR(pctl->pctldev);
+- }
+-
+ return 0;
+ }
+
--- /dev/null
+From 0657cb50b5a75abd92956028727dc255d690a4a6 Mon Sep 17 00:00:00 2001
+From: Peter Rosin <peda@axentia.se>
+Date: Wed, 17 Jan 2018 14:34:21 +0100
+Subject: pinctrl: sx150x: Unregister the pinctrl on release
+
+From: Peter Rosin <peda@axentia.se>
+
+commit 0657cb50b5a75abd92956028727dc255d690a4a6 upstream.
+
+There is no matching call to pinctrl_unregister, so switch to the
+managed devm_pinctrl_register to clean up properly when done.
+
+Fixes: 9e80f9064e73 ("pinctrl: Add SX150X GPIO Extender Pinctrl Driver")
+Signed-off-by: Peter Rosin <peda@axentia.se>
+Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/pinctrl/pinctrl-sx150x.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/pinctrl/pinctrl-sx150x.c
++++ b/drivers/pinctrl/pinctrl-sx150x.c
+@@ -1225,7 +1225,7 @@ static int sx150x_probe(struct i2c_clien
+ pctl->pinctrl_desc.npins = pctl->data->npins;
+ pctl->pinctrl_desc.owner = THIS_MODULE;
+
+- pctl->pctldev = pinctrl_register(&pctl->pinctrl_desc, dev, pctl);
++ pctl->pctldev = devm_pinctrl_register(dev, &pctl->pinctrl_desc, pctl);
+ if (IS_ERR(pctl->pctldev)) {
+ dev_err(dev, "Failed to register pinctrl device\n");
+ return PTR_ERR(pctl->pctldev);
--- /dev/null
+From 85c2dd5473b2718b4b63e74bfeb1ca876868e11f Mon Sep 17 00:00:00 2001
+From: Eric Biggers <ebiggers@google.com>
+Date: Tue, 6 Feb 2018 15:41:53 -0800
+Subject: pipe: actually allow root to exceed the pipe buffer limits
+
+From: Eric Biggers <ebiggers@google.com>
+
+commit 85c2dd5473b2718b4b63e74bfeb1ca876868e11f upstream.
+
+pipe-user-pages-hard and pipe-user-pages-soft are only supposed to apply
+to unprivileged users, as documented in both Documentation/sysctl/fs.txt
+and the pipe(7) man page.
+
+However, the capabilities are actually only checked when increasing a
+pipe's size using F_SETPIPE_SZ, not when creating a new pipe. Therefore,
+if pipe-user-pages-hard has been set, the root user can run into it and be
+unable to create pipes. Similarly, if pipe-user-pages-soft has been set,
+the root user can run into it and have their pipes limited to 1 page each.
+
+Fix this by allowing the privileged override in both cases.
+
+Link: http://lkml.kernel.org/r/20180111052902.14409-4-ebiggers3@gmail.com
+Fixes: 759c01142a5d ("pipe: limit the per-user amount of pages allocated in pipes")
+Signed-off-by: Eric Biggers <ebiggers@google.com>
+Acked-by: Kees Cook <keescook@chromium.org>
+Acked-by: Joe Lawrence <joe.lawrence@redhat.com>
+Cc: Alexander Viro <viro@zeniv.linux.org.uk>
+Cc: "Luis R . Rodriguez" <mcgrof@kernel.org>
+Cc: Michael Kerrisk <mtk.manpages@gmail.com>
+Cc: Mikulas Patocka <mpatocka@redhat.com>
+Cc: Willy Tarreau <w@1wt.eu>
+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/pipe.c | 11 ++++++++---
+ 1 file changed, 8 insertions(+), 3 deletions(-)
+
+--- a/fs/pipe.c
++++ b/fs/pipe.c
+@@ -618,6 +618,11 @@ static bool too_many_pipe_buffers_hard(u
+ return pipe_user_pages_hard && user_bufs >= pipe_user_pages_hard;
+ }
+
++static bool is_unprivileged_user(void)
++{
++ return !capable(CAP_SYS_RESOURCE) && !capable(CAP_SYS_ADMIN);
++}
++
+ struct pipe_inode_info *alloc_pipe_info(void)
+ {
+ struct pipe_inode_info *pipe;
+@@ -634,12 +639,12 @@ struct pipe_inode_info *alloc_pipe_info(
+
+ user_bufs = account_pipe_buffers(user, 0, pipe_bufs);
+
+- if (too_many_pipe_buffers_soft(user_bufs)) {
++ if (too_many_pipe_buffers_soft(user_bufs) && is_unprivileged_user()) {
+ user_bufs = account_pipe_buffers(user, pipe_bufs, 1);
+ pipe_bufs = 1;
+ }
+
+- if (too_many_pipe_buffers_hard(user_bufs))
++ if (too_many_pipe_buffers_hard(user_bufs) && is_unprivileged_user())
+ goto out_revert_acct;
+
+ pipe->bufs = kcalloc(pipe_bufs, sizeof(struct pipe_buffer),
+@@ -1069,7 +1074,7 @@ static long pipe_set_size(struct pipe_in
+ if (nr_pages > pipe->buffers &&
+ (too_many_pipe_buffers_hard(user_bufs) ||
+ too_many_pipe_buffers_soft(user_bufs)) &&
+- !capable(CAP_SYS_RESOURCE) && !capable(CAP_SYS_ADMIN)) {
++ is_unprivileged_user()) {
+ ret = -EPERM;
+ goto out_revert_acct;
+ }
--- /dev/null
+From 9903a91c763ecdae333a04a9d89d79d2b8966503 Mon Sep 17 00:00:00 2001
+From: Eric Biggers <ebiggers@google.com>
+Date: Tue, 6 Feb 2018 15:41:56 -0800
+Subject: pipe: fix off-by-one error when checking buffer limits
+
+From: Eric Biggers <ebiggers@google.com>
+
+commit 9903a91c763ecdae333a04a9d89d79d2b8966503 upstream.
+
+With pipe-user-pages-hard set to 'N', users were actually only allowed up
+to 'N - 1' buffers; and likewise for pipe-user-pages-soft.
+
+Fix this to allow up to 'N' buffers, as would be expected.
+
+Link: http://lkml.kernel.org/r/20180111052902.14409-5-ebiggers3@gmail.com
+Fixes: b0b91d18e2e9 ("pipe: fix limit checking in pipe_set_size()")
+Signed-off-by: Eric Biggers <ebiggers@google.com>
+Acked-by: Willy Tarreau <w@1wt.eu>
+Acked-by: Kees Cook <keescook@chromium.org>
+Acked-by: Joe Lawrence <joe.lawrence@redhat.com>
+Cc: Alexander Viro <viro@zeniv.linux.org.uk>
+Cc: "Luis R . Rodriguez" <mcgrof@kernel.org>
+Cc: Michael Kerrisk <mtk.manpages@gmail.com>
+Cc: Mikulas Patocka <mpatocka@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>
+
+---
+ fs/pipe.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/fs/pipe.c
++++ b/fs/pipe.c
+@@ -610,12 +610,12 @@ static unsigned long account_pipe_buffer
+
+ static bool too_many_pipe_buffers_soft(unsigned long user_bufs)
+ {
+- return pipe_user_pages_soft && user_bufs >= pipe_user_pages_soft;
++ return pipe_user_pages_soft && user_bufs > pipe_user_pages_soft;
+ }
+
+ static bool too_many_pipe_buffers_hard(unsigned long user_bufs)
+ {
+- return pipe_user_pages_hard && user_bufs >= pipe_user_pages_hard;
++ return pipe_user_pages_hard && user_bufs > pipe_user_pages_hard;
+ }
+
+ static bool is_unprivileged_user(void)
--- /dev/null
+From 882d4171a8950646413b1a3cbe0e4a6a612fe82e Mon Sep 17 00:00:00 2001
+From: Bart Van Assche <bart.vanassche@wdc.com>
+Date: Tue, 2 Jan 2018 11:39:48 -0800
+Subject: pktcdvd: Fix a recently introduced NULL pointer dereference
+
+From: Bart Van Assche <bart.vanassche@wdc.com>
+
+commit 882d4171a8950646413b1a3cbe0e4a6a612fe82e upstream.
+
+Call bdev_get_queue(bdev) after bdev->bd_disk has been initialized
+instead of just before that pointer has been initialized. This patch
+avoids that the following command
+
+pktsetup 1 /dev/sr0
+
+triggers the following kernel crash:
+
+BUG: unable to handle kernel NULL pointer dereference at 0000000000000548
+IP: pkt_setup_dev+0x2db/0x670 [pktcdvd]
+CPU: 2 PID: 724 Comm: pktsetup Not tainted 4.15.0-rc4-dbg+ #1
+Call Trace:
+ pkt_ctl_ioctl+0xce/0x1c0 [pktcdvd]
+ do_vfs_ioctl+0x8e/0x670
+ SyS_ioctl+0x3c/0x70
+ entry_SYSCALL_64_fastpath+0x23/0x9a
+
+Reported-by: Maciej S. Szmigiero <mail@maciej.szmigiero.name>
+Fixes: commit ca18d6f769d2 ("block: Make most scsi_req_init() calls implicit")
+Signed-off-by: Bart Van Assche <bart.vanassche@wdc.com>
+Tested-by: Maciej S. Szmigiero <mail@maciej.szmigiero.name>
+Cc: Maciej S. Szmigiero <mail@maciej.szmigiero.name>
+Signed-off-by: Jens Axboe <axboe@kernel.dk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/block/pktcdvd.c | 8 ++++----
+ 1 file changed, 4 insertions(+), 4 deletions(-)
+
+--- a/drivers/block/pktcdvd.c
++++ b/drivers/block/pktcdvd.c
+@@ -2579,14 +2579,14 @@ static int pkt_new_dev(struct pktcdvd_de
+ bdev = bdget(dev);
+ if (!bdev)
+ return -ENOMEM;
++ ret = blkdev_get(bdev, FMODE_READ | FMODE_NDELAY, NULL);
++ if (ret)
++ return ret;
+ if (!blk_queue_scsi_passthrough(bdev_get_queue(bdev))) {
+ WARN_ONCE(true, "Attempt to register a non-SCSI queue\n");
+- bdput(bdev);
++ blkdev_put(bdev, FMODE_READ | FMODE_NDELAY);
+ return -EINVAL;
+ }
+- ret = blkdev_get(bdev, FMODE_READ | FMODE_NDELAY, NULL);
+- if (ret)
+- return ret;
+
+ /* This is safe, since we have a reference from open(). */
+ __module_get(THIS_MODULE);
--- /dev/null
+From 5a0ec388ef0f6e33841aeb810d7fa23f049ec4cd Mon Sep 17 00:00:00 2001
+From: Bart Van Assche <bart.vanassche@wdc.com>
+Date: Tue, 2 Jan 2018 11:39:47 -0800
+Subject: pktcdvd: Fix pkt_setup_dev() error path
+
+From: Bart Van Assche <bart.vanassche@wdc.com>
+
+commit 5a0ec388ef0f6e33841aeb810d7fa23f049ec4cd upstream.
+
+Commit 523e1d399ce0 ("block: make gendisk hold a reference to its queue")
+modified add_disk() and disk_release() but did not update any of the
+error paths that trigger a put_disk() call after disk->queue has been
+assigned. That introduced the following behavior in the pktcdvd driver
+if pkt_new_dev() fails:
+
+Kernel BUG at 00000000e98fd882 [verbose debug info unavailable]
+
+Since disk_release() calls blk_put_queue() anyway if disk->queue != NULL,
+fix this by removing the blk_cleanup_queue() call from the pkt_setup_dev()
+error path.
+
+Fixes: commit 523e1d399ce0 ("block: make gendisk hold a reference to its queue")
+Signed-off-by: Bart Van Assche <bart.vanassche@wdc.com>
+Cc: Tejun Heo <tj@kernel.org>
+Cc: Maciej S. Szmigiero <mail@maciej.szmigiero.name>
+Signed-off-by: Jens Axboe <axboe@kernel.dk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/block/pktcdvd.c | 4 +---
+ 1 file changed, 1 insertion(+), 3 deletions(-)
+
+--- a/drivers/block/pktcdvd.c
++++ b/drivers/block/pktcdvd.c
+@@ -2745,7 +2745,7 @@ static int pkt_setup_dev(dev_t dev, dev_
+ pd->pkt_dev = MKDEV(pktdev_major, idx);
+ ret = pkt_new_dev(pd, dev);
+ if (ret)
+- goto out_new_dev;
++ goto out_mem2;
+
+ /* inherit events of the host device */
+ disk->events = pd->bdev->bd_disk->events;
+@@ -2763,8 +2763,6 @@ static int pkt_setup_dev(dev_t dev, dev_
+ mutex_unlock(&ctl_mutex);
+ return 0;
+
+-out_new_dev:
+- blk_cleanup_queue(disk->queue);
+ out_mem2:
+ put_disk(disk);
+ out_mem:
--- /dev/null
+From 7d06d5895c159f64c46560dc258e553ad8670fe0 Mon Sep 17 00:00:00 2001
+From: Kai-Heng Feng <kai.heng.feng@canonical.com>
+Date: Wed, 20 Dec 2017 19:00:07 +0800
+Subject: Revert "Bluetooth: btusb: fix QCA Rome suspend/resume"
+
+From: Kai-Heng Feng <kai.heng.feng@canonical.com>
+
+commit 7d06d5895c159f64c46560dc258e553ad8670fe0 upstream.
+
+This reverts commit fd865802c66bc451dc515ed89360f84376ce1a56.
+
+This commit causes a regression on some QCA ROME chips. The USB device
+reset happens in btusb_open(), hence firmware loading gets interrupted.
+
+Furthermore, this commit stops working after commit
+("a0085f2510e8976614ad8f766b209448b385492f Bluetooth: btusb: driver to
+enable the usb-wakeup feature"). Reset-resume quirk only gets enabled in
+btusb_suspend() when it's not a wakeup source.
+
+If we really want to reset the USB device, we need to do it before
+btusb_open(). Let's handle it in drivers/usb/core/quirks.c.
+
+Cc: Leif Liddy <leif.linux@gmail.com>
+Cc: Matthias Kaehlcke <mka@chromium.org>
+Cc: Brian Norris <briannorris@chromium.org>
+Cc: Daniel Drake <drake@endlessm.com>
+Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
+Reviewed-by: Brian Norris <briannorris@chromium.org>
+Tested-by: Brian Norris <briannorris@chromium.org>
+Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/bluetooth/btusb.c | 6 ------
+ 1 file changed, 6 deletions(-)
+
+--- a/drivers/bluetooth/btusb.c
++++ b/drivers/bluetooth/btusb.c
+@@ -3099,12 +3099,6 @@ static int btusb_probe(struct usb_interf
+ if (id->driver_info & BTUSB_QCA_ROME) {
+ data->setup_on_usb = btusb_setup_qca;
+ hdev->set_bdaddr = btusb_set_bdaddr_ath3012;
+-
+- /* QCA Rome devices lose their updated firmware over suspend,
+- * but the USB hub doesn't notice any status change.
+- * Explicitly request a device reset on resume.
+- */
+- set_bit(BTUSB_RESET_RESUME, &data->flags);
+ }
+
+ #ifdef CONFIG_BT_HCIBTUSB_RTL
media-v4l2-compat-ioctl32.c-don-t-copy-back-the-result-for-certain-errors.patch
media-v4l2-compat-ioctl32.c-refactor-compat-ioctl32-logic.patch
media-v4l2-compat-ioctl32.c-make-ctrl_is_pointer-work-for-subdevs.patch
+crypto-caam-fix-endless-loop-when-deco-acquire-fails.patch
+crypto-sha512-mb-initialize-pending-lengths-correctly.patch
+crypto-talitos-fix-kernel-oops-on-hashing-an-empty-file.patch
+arm-kvm-fix-smccc-handling-of-unimplemented-smc-hvc-calls.patch
+kvm-nvmx-fix-races-when-sending-nested-pi-while-dest-enters-leaves-l2.patch
+kvm-nvmx-fix-bug-of-injecting-l2-exception-into-l1.patch
+kvm-ppc-book3s-hv-make-sure-we-don-t-re-enter-guest-without-xive-loaded.patch
+kvm-ppc-book3s-hv-drop-locks-before-reading-guest-memory.patch
+kvm-arm-arm64-handle-cpu_pm_enter_failed.patch
+kvm-ppc-book3s-pr-fix-broken-select-due-to-misspelling.patch
+asoc-rockchip-i2s-fix-playback-after-runtime-resume.patch
+asoc-skl-fix-kernel-warning-due-to-zero-nhtl-entry.patch
+watchdog-imx2_wdt-restore-previous-timeout-after-suspend-resume.patch
+btrfs-raid56-iterate-raid56-internal-bio-with-bio_for_each_segment_all.patch
+kasan-don-t-emit-builtin-calls-when-sanitization-is-off.patch
+kasan-rework-kconfig-settings.patch
+media-dvb-frontends-fix-i2c-access-helpers-for-kasan.patch
+media-ts2020-avoid-integer-overflows-on-32-bit-machines.patch
+media-cxusb-dib0700-ignore-xc2028_i2c_flush.patch
+fs-proc-kcore.c-use-probe_kernel_read-instead-of-memcpy.patch
+kernel-async.c-revert-async-simplify-lowest_in_progress.patch
+kernel-relay.c-revert-kernel-relay.c-fix-potential-memory-leak.patch
+pipe-actually-allow-root-to-exceed-the-pipe-buffer-limits.patch
+pipe-fix-off-by-one-error-when-checking-buffer-limits.patch
+hid-quirks-fix-keyboard-touchpad-on-toshiba-click-mini-not-working.patch
+bluetooth-btsdio-do-not-bind-to-non-removable-bcm43341.patch
+revert-bluetooth-btusb-fix-qca-rome-suspend-resume.patch
+bluetooth-btusb-restore-qca-rome-suspend-resume-fix-with-a-rewritten-version.patch
+ipmi-use-dynamic-memory-for-dmi-driver-override.patch
+signal-openrisc-fix-do_unaligned_access-to-send-the-proper-signal.patch
+signal-sh-ensure-si_signo-is-initialized-in-do_divide_error.patch
+alpha-fix-crash-if-pthread_create-races-with-signal-delivery.patch
+alpha-osf_sys.c-fix-put_tv32-regression.patch
+alpha-fix-mixed-up-args-in-exc-macro-in-futex-operations.patch
+alpha-fix-reboot-on-avanti-platform.patch
+alpha-fix-formating-of-stack-content.patch
+xtensa-fix-futex_atomic_cmpxchg_inatomic.patch
+edac-octeon-fix-an-uninitialized-variable-warning.patch
+pinctrl-intel-initialize-gpio-properly-when-used-through-irqchip.patch
+pinctrl-mcp23s08-fix-irq-setup-order.patch
+pinctrl-sx150x-unregister-the-pinctrl-on-release.patch
+pinctrl-sx150x-register-pinctrl-before-adding-the-gpiochip.patch
+pinctrl-sx150x-add-a-static-gpio-pinctrl-pin-range-mapping.patch
+pktcdvd-fix-pkt_setup_dev-error-path.patch
+pktcdvd-fix-a-recently-introduced-null-pointer-dereference.patch
+blk-mq-quiesce-queue-before-freeing-queue.patch
+clocksource-drivers-stm32-fix-kernel-panic-with-multiple-timers.patch
--- /dev/null
+From 500d58300571b6602341b041f97c082a461ef994 Mon Sep 17 00:00:00 2001
+From: "Eric W. Biederman" <ebiederm@xmission.com>
+Date: Tue, 1 Aug 2017 04:16:47 -0500
+Subject: signal/openrisc: Fix do_unaligned_access to send the proper signal
+
+From: Eric W. Biederman <ebiederm@xmission.com>
+
+commit 500d58300571b6602341b041f97c082a461ef994 upstream.
+
+While reviewing the signal sending on openrisc the do_unaligned_access
+function stood out because it is obviously wrong. A comment about an
+si_code set above when actually si_code is never set. Leading to a
+random si_code being sent to userspace in the event of an unaligned
+access.
+
+Looking further SIGBUS BUS_ADRALN is the proper pair of signal and
+si_code to send for an unaligned access. That is what other
+architectures do and what is required by posix.
+
+Given that do_unaligned_access is broken in a way that no one can be
+relying on it on openrisc fix the code to just do the right thing.
+
+Fixes: 769a8a96229e ("OpenRISC: Traps")
+Cc: Jonas Bonn <jonas@southpole.se>
+Cc: Stefan Kristiansson <stefan.kristiansson@saunalahti.fi>
+Cc: Stafford Horne <shorne@gmail.com>
+Cc: Arnd Bergmann <arnd@arndb.de>
+Cc: openrisc@lists.librecores.org
+Acked-by: Stafford Horne <shorne@gmail.com>
+Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/openrisc/kernel/traps.c | 10 +++++-----
+ 1 file changed, 5 insertions(+), 5 deletions(-)
+
+--- a/arch/openrisc/kernel/traps.c
++++ b/arch/openrisc/kernel/traps.c
+@@ -306,12 +306,12 @@ asmlinkage void do_unaligned_access(stru
+ siginfo_t info;
+
+ if (user_mode(regs)) {
+- /* Send a SIGSEGV */
+- info.si_signo = SIGSEGV;
++ /* Send a SIGBUS */
++ info.si_signo = SIGBUS;
+ info.si_errno = 0;
+- /* info.si_code has been set above */
+- info.si_addr = (void *)address;
+- force_sig_info(SIGSEGV, &info, current);
++ info.si_code = BUS_ADRALN;
++ info.si_addr = (void __user *)address;
++ force_sig_info(SIGBUS, &info, current);
+ } else {
+ printk("KERNEL: Unaligned Access 0x%.8lx\n", address);
+ show_registers(regs);
--- /dev/null
+From 0e88bb002a9b2ee8cc3cc9478ce2dc126f849696 Mon Sep 17 00:00:00 2001
+From: "Eric W. Biederman" <ebiederm@xmission.com>
+Date: Mon, 24 Jul 2017 17:30:30 -0500
+Subject: signal/sh: Ensure si_signo is initialized in do_divide_error
+
+From: Eric W. Biederman <ebiederm@xmission.com>
+
+commit 0e88bb002a9b2ee8cc3cc9478ce2dc126f849696 upstream.
+
+Set si_signo.
+
+Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
+Cc: Rich Felker <dalias@libc.org>
+Cc: Paul Mundt <lethal@linux-sh.org>
+Cc: linux-sh@vger.kernel.org
+Fixes: 0983b31849bb ("sh: Wire up division and address error exceptions on SH-2A.")
+Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/sh/kernel/traps_32.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/arch/sh/kernel/traps_32.c
++++ b/arch/sh/kernel/traps_32.c
+@@ -609,7 +609,8 @@ asmlinkage void do_divide_error(unsigned
+ break;
+ }
+
+- force_sig_info(SIGFPE, &info, current);
++ info.si_signo = SIGFPE;
++ force_sig_info(info.si_signo, &info, current);
+ }
+ #endif
+
--- /dev/null
+From 0be267255cef64e1c58475baa7b25568355a3816 Mon Sep 17 00:00:00 2001
+From: Martin Kaiser <martin@kaiser.cx>
+Date: Mon, 1 Jan 2018 18:26:47 +0100
+Subject: watchdog: imx2_wdt: restore previous timeout after suspend+resume
+
+From: Martin Kaiser <martin@kaiser.cx>
+
+commit 0be267255cef64e1c58475baa7b25568355a3816 upstream.
+
+When the watchdog device is suspended, its timeout is set to the maximum
+value. During resume, the previously set timeout should be restored.
+This does not work at the moment.
+
+The suspend function calls
+
+imx2_wdt_set_timeout(wdog, IMX2_WDT_MAX_TIME);
+
+and resume reverts this by calling
+
+imx2_wdt_set_timeout(wdog, wdog->timeout);
+
+However, imx2_wdt_set_timeout() updates wdog->timeout. Therefore,
+wdog->timeout is set to IMX2_WDT_MAX_TIME when we enter the resume
+function.
+
+Fix this by adding a new function __imx2_wdt_set_timeout() which
+only updates the hardware settings. imx2_wdt_set_timeout() now calls
+__imx2_wdt_set_timeout() and then saves the new timeout to
+wdog->timeout.
+
+During suspend, we call __imx2_wdt_set_timeout() directly so that
+wdog->timeout won't be updated and we can restore the previous value
+during resume. This approach makes wdog->timeout different from the
+actual setting in the hardware which is usually not a good thing.
+However, the two differ only while we're suspended and no kernel code is
+running, so it should be ok in this case.
+
+Signed-off-by: Martin Kaiser <martin@kaiser.cx>
+Reviewed-by: Guenter Roeck <linux@roeck-us.net>
+Signed-off-by: Guenter Roeck <linux@roeck-us.net>
+Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/watchdog/imx2_wdt.c | 20 +++++++++++++++-----
+ 1 file changed, 15 insertions(+), 5 deletions(-)
+
+--- a/drivers/watchdog/imx2_wdt.c
++++ b/drivers/watchdog/imx2_wdt.c
+@@ -169,15 +169,21 @@ static int imx2_wdt_ping(struct watchdog
+ return 0;
+ }
+
+-static int imx2_wdt_set_timeout(struct watchdog_device *wdog,
+- unsigned int new_timeout)
++static void __imx2_wdt_set_timeout(struct watchdog_device *wdog,
++ unsigned int new_timeout)
+ {
+ struct imx2_wdt_device *wdev = watchdog_get_drvdata(wdog);
+
+- wdog->timeout = new_timeout;
+-
+ regmap_update_bits(wdev->regmap, IMX2_WDT_WCR, IMX2_WDT_WCR_WT,
+ WDOG_SEC_TO_COUNT(new_timeout));
++}
++
++static int imx2_wdt_set_timeout(struct watchdog_device *wdog,
++ unsigned int new_timeout)
++{
++ __imx2_wdt_set_timeout(wdog, new_timeout);
++
++ wdog->timeout = new_timeout;
+ return 0;
+ }
+
+@@ -371,7 +377,11 @@ static int imx2_wdt_suspend(struct devic
+
+ /* The watchdog IP block is running */
+ if (imx2_wdt_is_running(wdev)) {
+- imx2_wdt_set_timeout(wdog, IMX2_WDT_MAX_TIME);
++ /*
++ * Don't update wdog->timeout, we'll restore the current value
++ * during resume.
++ */
++ __imx2_wdt_set_timeout(wdog, IMX2_WDT_MAX_TIME);
+ imx2_wdt_ping(wdog);
+ }
+
--- /dev/null
+From ca47480921587ae30417dd234a9f79af188e3666 Mon Sep 17 00:00:00 2001
+From: Max Filippov <jcmvbkbc@gmail.com>
+Date: Fri, 5 Jan 2018 14:27:58 -0800
+Subject: xtensa: fix futex_atomic_cmpxchg_inatomic
+
+From: Max Filippov <jcmvbkbc@gmail.com>
+
+commit ca47480921587ae30417dd234a9f79af188e3666 upstream.
+
+Return 0 if the operation was successful, not the userspace memory
+value. Check that userspace value equals passed oldval, not itself.
+Don't update *uval if the value wasn't read from userspace memory.
+
+This fixes process hang due to infinite loop in futex_lock_pi.
+It also fixes a bunch of glibc tests nptl/tst-mutexpi*.
+
+Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/xtensa/include/asm/futex.h | 23 ++++++++++-------------
+ 1 file changed, 10 insertions(+), 13 deletions(-)
+
+--- a/arch/xtensa/include/asm/futex.h
++++ b/arch/xtensa/include/asm/futex.h
+@@ -92,7 +92,6 @@ futex_atomic_cmpxchg_inatomic(u32 *uval,
+ u32 oldval, u32 newval)
+ {
+ int ret = 0;
+- u32 prev;
+
+ if (!access_ok(VERIFY_WRITE, uaddr, sizeof(u32)))
+ return -EFAULT;
+@@ -103,26 +102,24 @@ futex_atomic_cmpxchg_inatomic(u32 *uval,
+
+ __asm__ __volatile__ (
+ " # futex_atomic_cmpxchg_inatomic\n"
+- "1: l32i %1, %3, 0\n"
+- " mov %0, %5\n"
+- " wsr %1, scompare1\n"
+- "2: s32c1i %0, %3, 0\n"
+- "3:\n"
++ " wsr %5, scompare1\n"
++ "1: s32c1i %1, %4, 0\n"
++ " s32i %1, %6, 0\n"
++ "2:\n"
+ " .section .fixup,\"ax\"\n"
+ " .align 4\n"
+- "4: .long 3b\n"
+- "5: l32r %1, 4b\n"
+- " movi %0, %6\n"
++ "3: .long 2b\n"
++ "4: l32r %1, 3b\n"
++ " movi %0, %7\n"
+ " jx %1\n"
+ " .previous\n"
+ " .section __ex_table,\"a\"\n"
+- " .long 1b,5b,2b,5b\n"
++ " .long 1b,4b\n"
+ " .previous\n"
+- : "+r" (ret), "=&r" (prev), "+m" (*uaddr)
+- : "r" (uaddr), "r" (oldval), "r" (newval), "I" (-EFAULT)
++ : "+r" (ret), "+r" (newval), "+m" (*uaddr), "+m" (*uval)
++ : "r" (uaddr), "r" (oldval), "r" (uval), "I" (-EFAULT)
+ : "memory");
+
+- *uval = prev;
+ return ret;
+ }
+
projects / thirdparty / kernel / stable-queue.git / commitdiff
