--- /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
+@@ -265,12 +265,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
+@@ -158,11 +158,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 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
+@@ -143,7 +143,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 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_psci_call(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
+@@ -476,6 +476,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:
+@@ -490,6 +491,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;
+@@ -499,6 +503,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_UUID, 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
+@@ -580,6 +580,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>
+
+@@ -291,6 +292,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 | 21 ++++++++++-----------
+ 1 file changed, 10 insertions(+), 11 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 <asm/unaligned.h>
+
+@@ -369,8 +370,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_DIAG_RUNNING 10
++#define BTUSB_OOB_WAKE_ENABLED 11
+
+ struct btusb_data {
+ struct hci_dev *hdev;
+@@ -2925,6 +2926,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
+@@ -2935,7 +2942,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
+
+@@ -3092,14 +3099,6 @@ static int btusb_suspend(struct usb_inte
+ btusb_stop_traffic(data);
+ usb_kill_anchored_urbs(&data->tx_anchor);
+
+- /* 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 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
+@@ -79,6 +79,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
+@@ -507,23 +507,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
+@@ -2365,7 +2365,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) },
+@@ -2635,6 +2634,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 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>
+
+---
+ arch/arm/kvm/arm.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/arch/arm/kvm/arm.c
++++ b/arch/arm/kvm/arm.c
+@@ -1165,6 +1165,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 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
+@@ -4967,14 +4967,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);
+ /*
+ * 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))
++ kvm_vcpu_kick(vcpu);
+ return 0;
+ }
+ return -1;
--- /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
+@@ -820,6 +820,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
+@@ -431,6 +431,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
+@@ -261,7 +261,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
+@@ -99,8 +99,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
+@@ -552,7 +552,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
+@@ -804,7 +804,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
+@@ -761,7 +761,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
+@@ -138,7 +138,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
+@@ -369,7 +369,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);
+@@ -387,7 +387,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
+@@ -368,6 +368,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)
+@@ -375,7 +387,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);
+
+@@ -385,13 +396,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);
+
+@@ -770,6 +775,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 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
+@@ -617,6 +617,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;
+@@ -633,12 +638,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
+@@ -609,12 +609,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 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
+@@ -2779,7 +2779,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;
+@@ -2797,8 +2797,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
+@@ -2925,12 +2925,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-drop-pr_info-for-unknown-buffer-type.patch
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
+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-arm-arm64-handle-cpu_pm_enter_failed.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
+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
+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-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
+pktcdvd-fix-pkt_setup_dev-error-path.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
+@@ -302,12 +302,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
+@@ -607,7 +607,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
+@@ -109,7 +109,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;
+@@ -120,26 +119,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
