--- /dev/null
+From fc96df16a1ce80cbb3c316ab7d4dc8cd5c2852ce Mon Sep 17 00:00:00 2001
+From: Dexuan Cui <decui@microsoft.com>
+Date: Thu, 13 Dec 2018 16:35:43 +0000
+Subject: Drivers: hv: vmbus: Return -EINVAL for the sys files for unopened channels
+
+From: Dexuan Cui <decui@microsoft.com>
+
+commit fc96df16a1ce80cbb3c316ab7d4dc8cd5c2852ce upstream.
+
+Before 98f4c651762c, we returned zeros for unopened channels.
+With 98f4c651762c, we started to return random on-stack values.
+
+We'd better return -EINVAL instead.
+
+Fixes: 98f4c651762c ("hv: move ringbuffer bus attributes to dev_groups")
+Cc: stable@vger.kernel.org
+Cc: K. Y. Srinivasan <kys@microsoft.com>
+Cc: Haiyang Zhang <haiyangz@microsoft.com>
+Cc: Stephen Hemminger <sthemmin@microsoft.com>
+Signed-off-by: Dexuan Cui <decui@microsoft.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/hv/vmbus_drv.c | 20 ++++++++++++++++++++
+ 1 file changed, 20 insertions(+)
+
+--- a/drivers/hv/vmbus_drv.c
++++ b/drivers/hv/vmbus_drv.c
+@@ -316,6 +316,8 @@ static ssize_t out_intr_mask_show(struct
+
+ if (!hv_dev->channel)
+ return -ENODEV;
++ if (hv_dev->channel->state != CHANNEL_OPENED_STATE)
++ return -EINVAL;
+ hv_ringbuffer_get_debuginfo(&hv_dev->channel->outbound, &outbound);
+ return sprintf(buf, "%d\n", outbound.current_interrupt_mask);
+ }
+@@ -329,6 +331,8 @@ static ssize_t out_read_index_show(struc
+
+ if (!hv_dev->channel)
+ return -ENODEV;
++ if (hv_dev->channel->state != CHANNEL_OPENED_STATE)
++ return -EINVAL;
+ hv_ringbuffer_get_debuginfo(&hv_dev->channel->outbound, &outbound);
+ return sprintf(buf, "%d\n", outbound.current_read_index);
+ }
+@@ -343,6 +347,8 @@ static ssize_t out_write_index_show(stru
+
+ if (!hv_dev->channel)
+ return -ENODEV;
++ if (hv_dev->channel->state != CHANNEL_OPENED_STATE)
++ return -EINVAL;
+ hv_ringbuffer_get_debuginfo(&hv_dev->channel->outbound, &outbound);
+ return sprintf(buf, "%d\n", outbound.current_write_index);
+ }
+@@ -357,6 +363,8 @@ static ssize_t out_read_bytes_avail_show
+
+ if (!hv_dev->channel)
+ return -ENODEV;
++ if (hv_dev->channel->state != CHANNEL_OPENED_STATE)
++ return -EINVAL;
+ hv_ringbuffer_get_debuginfo(&hv_dev->channel->outbound, &outbound);
+ return sprintf(buf, "%d\n", outbound.bytes_avail_toread);
+ }
+@@ -371,6 +379,8 @@ static ssize_t out_write_bytes_avail_sho
+
+ if (!hv_dev->channel)
+ return -ENODEV;
++ if (hv_dev->channel->state != CHANNEL_OPENED_STATE)
++ return -EINVAL;
+ hv_ringbuffer_get_debuginfo(&hv_dev->channel->outbound, &outbound);
+ return sprintf(buf, "%d\n", outbound.bytes_avail_towrite);
+ }
+@@ -384,6 +394,8 @@ static ssize_t in_intr_mask_show(struct
+
+ if (!hv_dev->channel)
+ return -ENODEV;
++ if (hv_dev->channel->state != CHANNEL_OPENED_STATE)
++ return -EINVAL;
+ hv_ringbuffer_get_debuginfo(&hv_dev->channel->inbound, &inbound);
+ return sprintf(buf, "%d\n", inbound.current_interrupt_mask);
+ }
+@@ -397,6 +409,8 @@ static ssize_t in_read_index_show(struct
+
+ if (!hv_dev->channel)
+ return -ENODEV;
++ if (hv_dev->channel->state != CHANNEL_OPENED_STATE)
++ return -EINVAL;
+ hv_ringbuffer_get_debuginfo(&hv_dev->channel->inbound, &inbound);
+ return sprintf(buf, "%d\n", inbound.current_read_index);
+ }
+@@ -410,6 +424,8 @@ static ssize_t in_write_index_show(struc
+
+ if (!hv_dev->channel)
+ return -ENODEV;
++ if (hv_dev->channel->state != CHANNEL_OPENED_STATE)
++ return -EINVAL;
+ hv_ringbuffer_get_debuginfo(&hv_dev->channel->inbound, &inbound);
+ return sprintf(buf, "%d\n", inbound.current_write_index);
+ }
+@@ -424,6 +440,8 @@ static ssize_t in_read_bytes_avail_show(
+
+ if (!hv_dev->channel)
+ return -ENODEV;
++ if (hv_dev->channel->state != CHANNEL_OPENED_STATE)
++ return -EINVAL;
+ hv_ringbuffer_get_debuginfo(&hv_dev->channel->inbound, &inbound);
+ return sprintf(buf, "%d\n", inbound.bytes_avail_toread);
+ }
+@@ -438,6 +456,8 @@ static ssize_t in_write_bytes_avail_show
+
+ if (!hv_dev->channel)
+ return -ENODEV;
++ if (hv_dev->channel->state != CHANNEL_OPENED_STATE)
++ return -EINVAL;
+ hv_ringbuffer_get_debuginfo(&hv_dev->channel->inbound, &inbound);
+ return sprintf(buf, "%d\n", inbound.bytes_avail_towrite);
+ }
--- /dev/null
+From da791a667536bf8322042e38ca85d55a78d3c273 Mon Sep 17 00:00:00 2001
+From: Thomas Gleixner <tglx@linutronix.de>
+Date: Mon, 10 Dec 2018 14:35:14 +0100
+Subject: futex: Cure exit race
+
+From: Thomas Gleixner <tglx@linutronix.de>
+
+commit da791a667536bf8322042e38ca85d55a78d3c273 upstream.
+
+Stefan reported, that the glibc tst-robustpi4 test case fails
+occasionally. That case creates the following race between
+sys_exit() and sys_futex_lock_pi():
+
+ CPU0 CPU1
+
+ sys_exit() sys_futex()
+ do_exit() futex_lock_pi()
+ exit_signals(tsk) No waiters:
+ tsk->flags |= PF_EXITING; *uaddr == 0x00000PID
+ mm_release(tsk) Set waiter bit
+ exit_robust_list(tsk) { *uaddr = 0x80000PID;
+ Set owner died attach_to_pi_owner() {
+ *uaddr = 0xC0000000; tsk = get_task(PID);
+ } if (!tsk->flags & PF_EXITING) {
+ ... attach();
+ tsk->flags |= PF_EXITPIDONE; } else {
+ if (!(tsk->flags & PF_EXITPIDONE))
+ return -EAGAIN;
+ return -ESRCH; <--- FAIL
+ }
+
+ESRCH is returned all the way to user space, which triggers the glibc test
+case assert. Returning ESRCH unconditionally is wrong here because the user
+space value has been changed by the exiting task to 0xC0000000, i.e. the
+FUTEX_OWNER_DIED bit is set and the futex PID value has been cleared. This
+is a valid state and the kernel has to handle it, i.e. taking the futex.
+
+Cure it by rereading the user space value when PF_EXITING and PF_EXITPIDONE
+is set in the task which 'owns' the futex. If the value has changed, let
+the kernel retry the operation, which includes all regular sanity checks
+and correctly handles the FUTEX_OWNER_DIED case.
+
+If it hasn't changed, then return ESRCH as there is no way to distinguish
+this case from malfunctioning user space. This happens when the exiting
+task did not have a robust list, the robust list was corrupted or the user
+space value in the futex was simply bogus.
+
+Reported-by: Stefan Liebler <stli@linux.ibm.com>
+Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
+Acked-by: Peter Zijlstra <peterz@infradead.org>
+Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
+Cc: Darren Hart <dvhart@infradead.org>
+Cc: Ingo Molnar <mingo@kernel.org>
+Cc: Sasha Levin <sashal@kernel.org>
+Cc: stable@vger.kernel.org
+Link: https://bugzilla.kernel.org/show_bug.cgi?id=200467
+Link: https://lkml.kernel.org/r/20181210152311.986181245@linutronix.de
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ kernel/futex.c | 69 ++++++++++++++++++++++++++++++++++++++++++++++++++++-----
+ 1 file changed, 63 insertions(+), 6 deletions(-)
+
+--- a/kernel/futex.c
++++ b/kernel/futex.c
+@@ -1148,11 +1148,65 @@ out_error:
+ return ret;
+ }
+
++static int handle_exit_race(u32 __user *uaddr, u32 uval,
++ struct task_struct *tsk)
++{
++ u32 uval2;
++
++ /*
++ * If PF_EXITPIDONE is not yet set, then try again.
++ */
++ if (tsk && !(tsk->flags & PF_EXITPIDONE))
++ return -EAGAIN;
++
++ /*
++ * Reread the user space value to handle the following situation:
++ *
++ * CPU0 CPU1
++ *
++ * sys_exit() sys_futex()
++ * do_exit() futex_lock_pi()
++ * futex_lock_pi_atomic()
++ * exit_signals(tsk) No waiters:
++ * tsk->flags |= PF_EXITING; *uaddr == 0x00000PID
++ * mm_release(tsk) Set waiter bit
++ * exit_robust_list(tsk) { *uaddr = 0x80000PID;
++ * Set owner died attach_to_pi_owner() {
++ * *uaddr = 0xC0000000; tsk = get_task(PID);
++ * } if (!tsk->flags & PF_EXITING) {
++ * ... attach();
++ * tsk->flags |= PF_EXITPIDONE; } else {
++ * if (!(tsk->flags & PF_EXITPIDONE))
++ * return -EAGAIN;
++ * return -ESRCH; <--- FAIL
++ * }
++ *
++ * Returning ESRCH unconditionally is wrong here because the
++ * user space value has been changed by the exiting task.
++ *
++ * The same logic applies to the case where the exiting task is
++ * already gone.
++ */
++ if (get_futex_value_locked(&uval2, uaddr))
++ return -EFAULT;
++
++ /* If the user space value has changed, try again. */
++ if (uval2 != uval)
++ return -EAGAIN;
++
++ /*
++ * The exiting task did not have a robust list, the robust list was
++ * corrupted or the user space value in *uaddr is simply bogus.
++ * Give up and tell user space.
++ */
++ return -ESRCH;
++}
++
+ /*
+ * Lookup the task for the TID provided from user space and attach to
+ * it after doing proper sanity checks.
+ */
+-static int attach_to_pi_owner(u32 uval, union futex_key *key,
++static int attach_to_pi_owner(u32 __user *uaddr, u32 uval, union futex_key *key,
+ struct futex_pi_state **ps)
+ {
+ pid_t pid = uval & FUTEX_TID_MASK;
+@@ -1162,12 +1216,15 @@ static int attach_to_pi_owner(u32 uval,
+ /*
+ * We are the first waiter - try to look up the real owner and attach
+ * the new pi_state to it, but bail out when TID = 0 [1]
++ *
++ * The !pid check is paranoid. None of the call sites should end up
++ * with pid == 0, but better safe than sorry. Let the caller retry
+ */
+ if (!pid)
+- return -ESRCH;
++ return -EAGAIN;
+ p = find_get_task_by_vpid(pid);
+ if (!p)
+- return -ESRCH;
++ return handle_exit_race(uaddr, uval, NULL);
+
+ if (unlikely(p->flags & PF_KTHREAD)) {
+ put_task_struct(p);
+@@ -1187,7 +1244,7 @@ static int attach_to_pi_owner(u32 uval,
+ * set, we know that the task has finished the
+ * cleanup:
+ */
+- int ret = (p->flags & PF_EXITPIDONE) ? -ESRCH : -EAGAIN;
++ int ret = handle_exit_race(uaddr, uval, p);
+
+ raw_spin_unlock_irq(&p->pi_lock);
+ put_task_struct(p);
+@@ -1244,7 +1301,7 @@ static int lookup_pi_state(u32 __user *u
+ * We are the first waiter - try to look up the owner based on
+ * @uval and attach to it.
+ */
+- return attach_to_pi_owner(uval, key, ps);
++ return attach_to_pi_owner(uaddr, uval, key, ps);
+ }
+
+ static int lock_pi_update_atomic(u32 __user *uaddr, u32 uval, u32 newval)
+@@ -1352,7 +1409,7 @@ static int futex_lock_pi_atomic(u32 __us
+ * attach to the owner. If that fails, no harm done, we only
+ * set the FUTEX_WAITERS bit in the user space variable.
+ */
+- return attach_to_pi_owner(uval, key, ps);
++ return attach_to_pi_owner(uaddr, newval, key, ps);
+ }
+
+ /**
--- /dev/null
+From abf221d2f51b8ce7b9959a8953f880a8b0a1400d Mon Sep 17 00:00:00 2001
+From: Christophe Leroy <christophe.leroy@c-s.fr>
+Date: Fri, 7 Dec 2018 13:07:55 +0000
+Subject: gpio: max7301: fix driver for use with CONFIG_VMAP_STACK
+
+From: Christophe Leroy <christophe.leroy@c-s.fr>
+
+commit abf221d2f51b8ce7b9959a8953f880a8b0a1400d upstream.
+
+spi_read() and spi_write() require DMA-safe memory. When
+CONFIG_VMAP_STACK is selected, those functions cannot be used
+with buffers on stack.
+
+This patch replaces calls to spi_read() and spi_write() by
+spi_write_then_read() which doesn't require DMA-safe buffers.
+
+Fixes: 0c36ec314735 ("gpio: gpio driver for max7301 SPI GPIO expander")
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
+Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpio/gpio-max7301.c | 12 +++---------
+ 1 file changed, 3 insertions(+), 9 deletions(-)
+
+--- a/drivers/gpio/gpio-max7301.c
++++ b/drivers/gpio/gpio-max7301.c
+@@ -25,7 +25,7 @@ static int max7301_spi_write(struct devi
+ struct spi_device *spi = to_spi_device(dev);
+ u16 word = ((reg & 0x7F) << 8) | (val & 0xFF);
+
+- return spi_write(spi, (const u8 *)&word, sizeof(word));
++ return spi_write_then_read(spi, &word, sizeof(word), NULL, 0);
+ }
+
+ /* A read from the MAX7301 means two transfers; here, one message each */
+@@ -37,14 +37,8 @@ static int max7301_spi_read(struct devic
+ struct spi_device *spi = to_spi_device(dev);
+
+ word = 0x8000 | (reg << 8);
+- ret = spi_write(spi, (const u8 *)&word, sizeof(word));
+- if (ret)
+- return ret;
+- /*
+- * This relies on the fact, that a transfer with NULL tx_buf shifts out
+- * zero bytes (=NOOP for MAX7301)
+- */
+- ret = spi_read(spi, (u8 *)&word, sizeof(word));
++ ret = spi_write_then_read(spi, &word, sizeof(word), &word,
++ sizeof(word));
+ if (ret)
+ return ret;
+ return word & 0xff;
--- /dev/null
+From e59f5e08ece1060073d92c66ded52e1f2c43b5bb Mon Sep 17 00:00:00 2001
+From: Hans de Goede <hdegoede@redhat.com>
+Date: Wed, 28 Nov 2018 17:57:55 +0100
+Subject: gpiolib-acpi: Only defer request_irq for GpioInt ACPI event handlers
+
+From: Hans de Goede <hdegoede@redhat.com>
+
+commit e59f5e08ece1060073d92c66ded52e1f2c43b5bb upstream.
+
+Commit 78d3a92edbfb ("gpiolib-acpi: Register GpioInt ACPI event handlers
+from a late_initcall") deferred the entire acpi_gpiochip_request_interrupt
+call for each event resource.
+
+This means it also delays the gpiochip_request_own_desc(..., "ACPI:Event")
+call. This is a problem if some AML code reads the GPIO pin before we
+run the deferred acpi_gpiochip_request_interrupt, because in that case
+acpi_gpio_adr_space_handler() will already have called
+gpiochip_request_own_desc(..., "ACPI:OpRegion") causing the call from
+acpi_gpiochip_request_interrupt to fail with -EBUSY and we will fail to
+register an event handler.
+
+acpi_gpio_adr_space_handler is prepared for acpi_gpiochip_request_interrupt
+already having claimed the pin, but the other way around does not work.
+
+One example of a problem this causes, is the event handler for the OTG
+ID pin on a Prowise PT301 tablet not registering, keeping the port stuck
+in whatever mode it was in during boot and e.g. only allowing charging
+after a reboot.
+
+This commit fixes this by only deferring the request_irq call and the
+initial run of edge-triggered IRQs instead of deferring all of
+acpi_gpiochip_request_interrupt.
+
+Cc: stable@vger.kernel.org
+Fixes: 78d3a92edbfb ("gpiolib-acpi: Register GpioInt ACPI event ...")
+Signed-off-by: Hans de Goede <hdegoede@redhat.com>
+Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
+Acked-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/gpio/gpiolib-acpi.c | 144 +++++++++++++++++++++++++-------------------
+ 1 file changed, 84 insertions(+), 60 deletions(-)
+
+--- a/drivers/gpio/gpiolib-acpi.c
++++ b/drivers/gpio/gpiolib-acpi.c
+@@ -23,11 +23,28 @@
+
+ #include "gpiolib.h"
+
++/**
++ * struct acpi_gpio_event - ACPI GPIO event handler data
++ *
++ * @node: list-entry of the events list of the struct acpi_gpio_chip
++ * @handle: handle of ACPI method to execute when the IRQ triggers
++ * @handler: irq_handler to pass to request_irq when requesting the IRQ
++ * @pin: GPIO pin number on the gpio_chip
++ * @irq: Linux IRQ number for the event, for request_ / free_irq
++ * @irqflags: flags to pass to request_irq when requesting the IRQ
++ * @irq_is_wake: If the ACPI flags indicate the IRQ is a wakeup source
++ * @is_requested: True if request_irq has been done
++ * @desc: gpio_desc for the GPIO pin for this event
++ */
+ struct acpi_gpio_event {
+ struct list_head node;
+ acpi_handle handle;
++ irq_handler_t handler;
+ unsigned int pin;
+ unsigned int irq;
++ unsigned long irqflags;
++ bool irq_is_wake;
++ bool irq_requested;
+ struct gpio_desc *desc;
+ };
+
+@@ -53,10 +70,10 @@ struct acpi_gpio_chip {
+
+ /*
+ * For gpiochips which call acpi_gpiochip_request_interrupts() before late_init
+- * (so builtin drivers) we register the ACPI GpioInt event handlers from a
++ * (so builtin drivers) we register the ACPI GpioInt IRQ handlers from a
+ * late_initcall_sync handler, so that other builtin drivers can register their
+ * OpRegions before the event handlers can run. This list contains gpiochips
+- * for which the acpi_gpiochip_request_interrupts() has been deferred.
++ * for which the acpi_gpiochip_request_irqs() call has been deferred.
+ */
+ static DEFINE_MUTEX(acpi_gpio_deferred_req_irqs_lock);
+ static LIST_HEAD(acpi_gpio_deferred_req_irqs_list);
+@@ -137,8 +154,42 @@ bool acpi_gpio_get_irq_resource(struct a
+ }
+ EXPORT_SYMBOL_GPL(acpi_gpio_get_irq_resource);
+
+-static acpi_status acpi_gpiochip_request_interrupt(struct acpi_resource *ares,
+- void *context)
++static void acpi_gpiochip_request_irq(struct acpi_gpio_chip *acpi_gpio,
++ struct acpi_gpio_event *event)
++{
++ int ret, value;
++
++ ret = request_threaded_irq(event->irq, NULL, event->handler,
++ event->irqflags, "ACPI:Event", event);
++ if (ret) {
++ dev_err(acpi_gpio->chip->parent,
++ "Failed to setup interrupt handler for %d\n",
++ event->irq);
++ return;
++ }
++
++ if (event->irq_is_wake)
++ enable_irq_wake(event->irq);
++
++ event->irq_requested = true;
++
++ /* Make sure we trigger the initial state of edge-triggered IRQs */
++ value = gpiod_get_raw_value_cansleep(event->desc);
++ if (((event->irqflags & IRQF_TRIGGER_RISING) && value == 1) ||
++ ((event->irqflags & IRQF_TRIGGER_FALLING) && value == 0))
++ event->handler(event->irq, event);
++}
++
++static void acpi_gpiochip_request_irqs(struct acpi_gpio_chip *acpi_gpio)
++{
++ struct acpi_gpio_event *event;
++
++ list_for_each_entry(event, &acpi_gpio->events, node)
++ acpi_gpiochip_request_irq(acpi_gpio, event);
++}
++
++static acpi_status acpi_gpiochip_alloc_event(struct acpi_resource *ares,
++ void *context)
+ {
+ struct acpi_gpio_chip *acpi_gpio = context;
+ struct gpio_chip *chip = acpi_gpio->chip;
+@@ -147,8 +198,7 @@ static acpi_status acpi_gpiochip_request
+ struct acpi_gpio_event *event;
+ irq_handler_t handler = NULL;
+ struct gpio_desc *desc;
+- unsigned long irqflags;
+- int ret, pin, irq, value;
++ int ret, pin, irq;
+
+ if (!acpi_gpio_get_irq_resource(ares, &agpio))
+ return AE_OK;
+@@ -179,8 +229,6 @@ static acpi_status acpi_gpiochip_request
+
+ gpiod_direction_input(desc);
+
+- value = gpiod_get_value_cansleep(desc);
+-
+ ret = gpiochip_lock_as_irq(chip, pin);
+ if (ret) {
+ dev_err(chip->parent, "Failed to lock GPIO as interrupt\n");
+@@ -193,64 +241,42 @@ static acpi_status acpi_gpiochip_request
+ goto fail_unlock_irq;
+ }
+
+- irqflags = IRQF_ONESHOT;
++ event = kzalloc(sizeof(*event), GFP_KERNEL);
++ if (!event)
++ goto fail_unlock_irq;
++
++ event->irqflags = IRQF_ONESHOT;
+ if (agpio->triggering == ACPI_LEVEL_SENSITIVE) {
+ if (agpio->polarity == ACPI_ACTIVE_HIGH)
+- irqflags |= IRQF_TRIGGER_HIGH;
++ event->irqflags |= IRQF_TRIGGER_HIGH;
+ else
+- irqflags |= IRQF_TRIGGER_LOW;
++ event->irqflags |= IRQF_TRIGGER_LOW;
+ } else {
+ switch (agpio->polarity) {
+ case ACPI_ACTIVE_HIGH:
+- irqflags |= IRQF_TRIGGER_RISING;
++ event->irqflags |= IRQF_TRIGGER_RISING;
+ break;
+ case ACPI_ACTIVE_LOW:
+- irqflags |= IRQF_TRIGGER_FALLING;
++ event->irqflags |= IRQF_TRIGGER_FALLING;
+ break;
+ default:
+- irqflags |= IRQF_TRIGGER_RISING |
+- IRQF_TRIGGER_FALLING;
++ event->irqflags |= IRQF_TRIGGER_RISING |
++ IRQF_TRIGGER_FALLING;
+ break;
+ }
+ }
+
+- event = kzalloc(sizeof(*event), GFP_KERNEL);
+- if (!event)
+- goto fail_unlock_irq;
+-
+ event->handle = evt_handle;
++ event->handler = handler;
+ event->irq = irq;
++ event->irq_is_wake = agpio->wake_capable == ACPI_WAKE_CAPABLE;
+ event->pin = pin;
+ event->desc = desc;
+
+- ret = request_threaded_irq(event->irq, NULL, handler, irqflags,
+- "ACPI:Event", event);
+- if (ret) {
+- dev_err(chip->parent,
+- "Failed to setup interrupt handler for %d\n",
+- event->irq);
+- goto fail_free_event;
+- }
+-
+- if (agpio->wake_capable == ACPI_WAKE_CAPABLE)
+- enable_irq_wake(irq);
+-
+ list_add_tail(&event->node, &acpi_gpio->events);
+
+- /*
+- * Make sure we trigger the initial state of the IRQ when using RISING
+- * or FALLING. Note we run the handlers on late_init, the AML code
+- * may refer to OperationRegions from other (builtin) drivers which
+- * may be probed after us.
+- */
+- if (((irqflags & IRQF_TRIGGER_RISING) && value == 1) ||
+- ((irqflags & IRQF_TRIGGER_FALLING) && value == 0))
+- handler(event->irq, event);
+-
+ return AE_OK;
+
+-fail_free_event:
+- kfree(event);
+ fail_unlock_irq:
+ gpiochip_unlock_as_irq(chip, pin);
+ fail_free_desc:
+@@ -287,6 +313,9 @@ void acpi_gpiochip_request_interrupts(st
+ if (ACPI_FAILURE(status))
+ return;
+
++ acpi_walk_resources(handle, "_AEI",
++ acpi_gpiochip_alloc_event, acpi_gpio);
++
+ mutex_lock(&acpi_gpio_deferred_req_irqs_lock);
+ defer = !acpi_gpio_deferred_req_irqs_done;
+ if (defer)
+@@ -297,8 +326,7 @@ void acpi_gpiochip_request_interrupts(st
+ if (defer)
+ return;
+
+- acpi_walk_resources(handle, "_AEI",
+- acpi_gpiochip_request_interrupt, acpi_gpio);
++ acpi_gpiochip_request_irqs(acpi_gpio);
+ }
+ EXPORT_SYMBOL_GPL(acpi_gpiochip_request_interrupts);
+
+@@ -335,10 +363,13 @@ void acpi_gpiochip_free_interrupts(struc
+ list_for_each_entry_safe_reverse(event, ep, &acpi_gpio->events, node) {
+ struct gpio_desc *desc;
+
+- if (irqd_is_wakeup_set(irq_get_irq_data(event->irq)))
+- disable_irq_wake(event->irq);
++ if (event->irq_requested) {
++ if (event->irq_is_wake)
++ disable_irq_wake(event->irq);
++
++ free_irq(event->irq, event);
++ }
+
+- free_irq(event->irq, event);
+ desc = event->desc;
+ if (WARN_ON(IS_ERR(desc)))
+ continue;
+@@ -1204,23 +1235,16 @@ bool acpi_can_fallback_to_crs(struct acp
+ return con_id == NULL;
+ }
+
+-/* Run deferred acpi_gpiochip_request_interrupts() */
+-static int acpi_gpio_handle_deferred_request_interrupts(void)
++/* Run deferred acpi_gpiochip_request_irqs() */
++static int acpi_gpio_handle_deferred_request_irqs(void)
+ {
+ struct acpi_gpio_chip *acpi_gpio, *tmp;
+
+ mutex_lock(&acpi_gpio_deferred_req_irqs_lock);
+ list_for_each_entry_safe(acpi_gpio, tmp,
+ &acpi_gpio_deferred_req_irqs_list,
+- deferred_req_irqs_list_entry) {
+- acpi_handle handle;
+-
+- handle = ACPI_HANDLE(acpi_gpio->chip->parent);
+- acpi_walk_resources(handle, "_AEI",
+- acpi_gpiochip_request_interrupt, acpi_gpio);
+-
+- list_del_init(&acpi_gpio->deferred_req_irqs_list_entry);
+- }
++ deferred_req_irqs_list_entry)
++ acpi_gpiochip_request_irqs(acpi_gpio);
+
+ acpi_gpio_deferred_req_irqs_done = true;
+ mutex_unlock(&acpi_gpio_deferred_req_irqs_lock);
+@@ -1228,4 +1252,4 @@ static int acpi_gpio_handle_deferred_req
+ return 0;
+ }
+ /* We must use _sync so that this runs after the first deferred_probe run */
+-late_initcall_sync(acpi_gpio_handle_deferred_request_interrupts);
++late_initcall_sync(acpi_gpio_handle_deferred_request_irqs);
--- /dev/null
+From c2dd5146e9fe1f22c77c1b011adf84eea0245806 Mon Sep 17 00:00:00 2001
+From: Cfir Cohen <cfir@google.com>
+Date: Tue, 18 Dec 2018 08:18:41 -0800
+Subject: KVM: Fix UAF in nested posted interrupt processing
+
+From: Cfir Cohen <cfir@google.com>
+
+commit c2dd5146e9fe1f22c77c1b011adf84eea0245806 upstream.
+
+nested_get_vmcs12_pages() processes the posted_intr address in vmcs12. It
+caches the kmap()ed page object and pointer, however, it doesn't handle
+errors correctly: it's possible to cache a valid pointer, then release
+the page and later dereference the dangling pointer.
+
+I was able to reproduce with the following steps:
+
+1. Call vmlaunch with valid posted_intr_desc_addr but an invalid
+MSR_EFER. This causes nested_get_vmcs12_pages() to cache the kmap()ed
+pi_desc_page and pi_desc. Later the invalid EFER value fails
+check_vmentry_postreqs() which fails the first vmlaunch.
+
+2. Call vmlanuch with a valid EFER but an invalid posted_intr_desc_addr
+(I set it to 2G - 0x80). The second time we call nested_get_vmcs12_pages
+pi_desc_page is unmapped and released and pi_desc_page is set to NULL
+(the "shouldn't happen" clause). Due to the invalid
+posted_intr_desc_addr, kvm_vcpu_gpa_to_page() fails and
+nested_get_vmcs12_pages() returns. It doesn't return an error value so
+vmlaunch proceeds. Note that at this time we have a dangling pointer in
+vmx->nested.pi_desc and POSTED_INTR_DESC_ADDR in L0's vmcs.
+
+3. Issue an IPI in L2 guest code. This triggers a call to
+vmx_complete_nested_posted_interrupt() and pi_test_and_clear_on() which
+dereferences the dangling pointer.
+
+Vulnerable code requires nested and enable_apicv variables to be set to
+true. The host CPU must also support posted interrupts.
+
+Fixes: 5e2f30b756a37 "KVM: nVMX: get rid of nested_get_page()"
+Cc: stable@vger.kernel.org
+Reviewed-by: Andy Honig <ahonig@google.com>
+Signed-off-by: Cfir Cohen <cfir@google.com>
+Reviewed-by: Liran Alon <liran.alon@oracle.com>
+Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/x86/kvm/vmx.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/arch/x86/kvm/vmx.c
++++ b/arch/x86/kvm/vmx.c
+@@ -11471,6 +11471,8 @@ static void nested_get_vmcs12_pages(stru
+ kunmap(vmx->nested.pi_desc_page);
+ kvm_release_page_dirty(vmx->nested.pi_desc_page);
+ vmx->nested.pi_desc_page = NULL;
++ vmx->nested.pi_desc = NULL;
++ vmcs_write64(POSTED_INTR_DESC_ADDR, -1ull);
+ }
+ page = kvm_vcpu_gpa_to_page(vcpu, vmcs12->posted_intr_desc_addr);
+ if (is_error_page(page))
--- /dev/null
+From 0e1b869fff60c81b510c2d00602d778f8f59dd9a Mon Sep 17 00:00:00 2001
+From: Eduardo Habkost <ehabkost@redhat.com>
+Date: Mon, 17 Dec 2018 22:34:18 -0200
+Subject: kvm: x86: Add AMD's EX_CFG to the list of ignored MSRs
+
+From: Eduardo Habkost <ehabkost@redhat.com>
+
+commit 0e1b869fff60c81b510c2d00602d778f8f59dd9a upstream.
+
+Some guests OSes (including Windows 10) write to MSR 0xc001102c
+on some cases (possibly while trying to apply a CPU errata).
+Make KVM ignore reads and writes to that MSR, so the guest won't
+crash.
+
+The MSR is documented as "Execution Unit Configuration (EX_CFG)",
+at AMD's "BIOS and Kernel Developer's Guide (BKDG) for AMD Family
+15h Models 00h-0Fh Processors".
+
+Cc: stable@vger.kernel.org
+Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
+Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/x86/include/asm/msr-index.h | 1 +
+ arch/x86/kvm/x86.c | 2 ++
+ 2 files changed, 3 insertions(+)
+
+--- a/arch/x86/include/asm/msr-index.h
++++ b/arch/x86/include/asm/msr-index.h
+@@ -389,6 +389,7 @@
+ #define MSR_F15H_NB_PERF_CTR 0xc0010241
+ #define MSR_F15H_PTSC 0xc0010280
+ #define MSR_F15H_IC_CFG 0xc0011021
++#define MSR_F15H_EX_CFG 0xc001102c
+
+ /* Fam 10h MSRs */
+ #define MSR_FAM10H_MMIO_CONF_BASE 0xc0010058
+--- a/arch/x86/kvm/x86.c
++++ b/arch/x86/kvm/x86.c
+@@ -2343,6 +2343,7 @@ int kvm_set_msr_common(struct kvm_vcpu *
+ case MSR_AMD64_PATCH_LOADER:
+ case MSR_AMD64_BU_CFG2:
+ case MSR_AMD64_DC_CFG:
++ case MSR_F15H_EX_CFG:
+ break;
+
+ case MSR_IA32_UCODE_REV:
+@@ -2638,6 +2639,7 @@ int kvm_get_msr_common(struct kvm_vcpu *
+ case MSR_AMD64_BU_CFG2:
+ case MSR_IA32_PERF_CTL:
+ case MSR_AMD64_DC_CFG:
++ case MSR_F15H_EX_CFG:
+ msr_info->data = 0;
+ break;
+ case MSR_F15H_PERF_CTL0 ... MSR_F15H_PERF_CTR5:
--- /dev/null
+From dcbd3e49c2f0b2c2d8a321507ff8f3de4af76d7c Mon Sep 17 00:00:00 2001
+From: Wanpeng Li <wanpengli@tencent.com>
+Date: Mon, 17 Dec 2018 10:43:23 +0800
+Subject: KVM: X86: Fix NULL deref in vcpu_scan_ioapic
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Wanpeng Li <wanpengli@tencent.com>
+
+commit dcbd3e49c2f0b2c2d8a321507ff8f3de4af76d7c upstream.
+
+Reported by syzkaller:
+
+ CPU: 1 PID: 5962 Comm: syz-executor118 Not tainted 4.20.0-rc6+ #374
+ Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
+ RIP: 0010:kvm_apic_hw_enabled arch/x86/kvm/lapic.h:169 [inline]
+ RIP: 0010:vcpu_scan_ioapic arch/x86/kvm/x86.c:7449 [inline]
+ RIP: 0010:vcpu_enter_guest arch/x86/kvm/x86.c:7602 [inline]
+ RIP: 0010:vcpu_run arch/x86/kvm/x86.c:7874 [inline]
+ RIP: 0010:kvm_arch_vcpu_ioctl_run+0x5296/0x7320 arch/x86/kvm/x86.c:8074
+ Call Trace:
+ kvm_vcpu_ioctl+0x5c8/0x1150 arch/x86/kvm/../../../virt/kvm/kvm_main.c:2596
+ vfs_ioctl fs/ioctl.c:46 [inline]
+ file_ioctl fs/ioctl.c:509 [inline]
+ do_vfs_ioctl+0x1de/0x1790 fs/ioctl.c:696
+ ksys_ioctl+0xa9/0xd0 fs/ioctl.c:713
+ __do_sys_ioctl fs/ioctl.c:720 [inline]
+ __se_sys_ioctl fs/ioctl.c:718 [inline]
+ __x64_sys_ioctl+0x73/0xb0 fs/ioctl.c:718
+ do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
+ entry_SYSCALL_64_after_hwframe+0x49/0xbe
+
+The reason is that the testcase writes hyperv synic HV_X64_MSR_SINT14 msr
+and triggers scan ioapic logic to load synic vectors into EOI exit bitmap.
+However, irqchip is not initialized by this simple testcase, ioapic/apic
+objects should not be accessed.
+
+This patch fixes it by also considering whether or not apic is present.
+
+Reported-by: syzbot+39810e6c400efadfef71@syzkaller.appspotmail.com
+Cc: stable@vger.kernel.org
+Cc: Paolo Bonzini <pbonzini@redhat.com>
+Cc: Radim Krčmář <rkrcmar@redhat.com>
+Signed-off-by: Wanpeng Li <wanpengli@tencent.com>
+Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/x86/kvm/x86.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/arch/x86/kvm/x86.c
++++ b/arch/x86/kvm/x86.c
+@@ -7304,7 +7304,7 @@ void kvm_make_scan_ioapic_request(struct
+
+ static void vcpu_scan_ioapic(struct kvm_vcpu *vcpu)
+ {
+- if (!kvm_apic_hw_enabled(vcpu->arch.apic))
++ if (!kvm_apic_present(vcpu))
+ return;
+
+ bitmap_zero(vcpu->arch.ioapic_handled_vectors, 256);
--- /dev/null
+From ba9f39a785a9977e72233000711ef1eb48203551 Mon Sep 17 00:00:00 2001
+From: Ulf Hansson <ulf.hansson@linaro.org>
+Date: Mon, 10 Dec 2018 17:52:37 +0100
+Subject: mmc: core: Allow BKOPS and CACHE ctrl even if no HPI support
+
+From: Ulf Hansson <ulf.hansson@linaro.org>
+
+commit ba9f39a785a9977e72233000711ef1eb48203551 upstream.
+
+In commit 5320226a0512 ("mmc: core: Disable HPI for certain Hynix eMMC
+cards"), then intent was to prevent HPI from being used for some eMMC
+cards, which didn't properly support it. However, that went too far, as
+even BKOPS and CACHE ctrl became prevented. Let's restore those parts and
+allow BKOPS and CACHE ctrl even if HPI isn't supported.
+
+Fixes: 5320226a0512 ("mmc: core: Disable HPI for certain Hynix eMMC cards")
+Cc: Pratibhasagar V <pratibha@codeaurora.org>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/mmc/core/mmc.c | 6 ++----
+ 1 file changed, 2 insertions(+), 4 deletions(-)
+
+--- a/drivers/mmc/core/mmc.c
++++ b/drivers/mmc/core/mmc.c
+@@ -526,8 +526,7 @@ static int mmc_decode_ext_csd(struct mmc
+ card->cid.year += 16;
+
+ /* check whether the eMMC card supports BKOPS */
+- if (!mmc_card_broken_hpi(card) &&
+- ext_csd[EXT_CSD_BKOPS_SUPPORT] & 0x1) {
++ if (ext_csd[EXT_CSD_BKOPS_SUPPORT] & 0x1) {
+ card->ext_csd.bkops = 1;
+ card->ext_csd.man_bkops_en =
+ (ext_csd[EXT_CSD_BKOPS_EN] &
+@@ -1793,8 +1792,7 @@ static int mmc_init_card(struct mmc_host
+ * If cache size is higher than 0, this indicates
+ * the existence of cache and it can be turned on.
+ */
+- if (!mmc_card_broken_hpi(card) &&
+- card->ext_csd.cache_size > 0) {
++ if (card->ext_csd.cache_size > 0) {
+ err = mmc_switch(card, EXT_CSD_CMD_SET_NORMAL,
+ EXT_CSD_CACHE_CTRL, 1,
+ card->ext_csd.generic_cmd6_time);
--- /dev/null
+From a0741ba40a009f97c019ae7541dc61c1fdf41efb Mon Sep 17 00:00:00 2001
+From: Ulf Hansson <ulf.hansson@linaro.org>
+Date: Mon, 10 Dec 2018 17:52:36 +0100
+Subject: mmc: core: Reset HPI enabled state during re-init and in case of errors
+
+From: Ulf Hansson <ulf.hansson@linaro.org>
+
+commit a0741ba40a009f97c019ae7541dc61c1fdf41efb upstream.
+
+During a re-initialization of the eMMC card, we may fail to re-enable HPI.
+In these cases, that isn't properly reflected in the card->ext_csd.hpi_en
+bit, as it keeps being set. This may cause following attempts to use HPI,
+even if's not enabled. Let's fix this!
+
+Fixes: eb0d8f135b67 ("mmc: core: support HPI send command")
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/mmc/core/mmc.c | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+--- a/drivers/mmc/core/mmc.c
++++ b/drivers/mmc/core/mmc.c
+@@ -1782,9 +1782,11 @@ static int mmc_init_card(struct mmc_host
+ if (err) {
+ pr_warn("%s: Enabling HPI failed\n",
+ mmc_hostname(card->host));
++ card->ext_csd.hpi_en = 0;
+ err = 0;
+- } else
++ } else {
+ card->ext_csd.hpi_en = 1;
++ }
+ }
+
+ /*
--- /dev/null
+From e3ae3401aa19432ee4943eb0bbc2ec704d07d793 Mon Sep 17 00:00:00 2001
+From: Ulf Hansson <ulf.hansson@linaro.org>
+Date: Mon, 10 Dec 2018 17:52:38 +0100
+Subject: mmc: core: Use a minimum 1600ms timeout when enabling CACHE ctrl
+
+From: Ulf Hansson <ulf.hansson@linaro.org>
+
+commit e3ae3401aa19432ee4943eb0bbc2ec704d07d793 upstream.
+
+Some eMMCs from Micron have been reported to need ~800 ms timeout, while
+enabling the CACHE ctrl after running sudden power failure tests. The
+needed timeout is greater than what the card specifies as its generic CMD6
+timeout, through the EXT_CSD register, hence the problem.
+
+Normally we would introduce a card quirk to extend the timeout for these
+specific Micron cards. However, due to the rather complicated debug process
+needed to find out the error, let's simply use a minimum timeout of 1600ms,
+the double of what has been reported, for all cards when enabling CACHE
+ctrl.
+
+Reported-by: Sjoerd Simons <sjoerd.simons@collabora.co.uk>
+Reported-by: Andreas Dannenberg <dannenberg@ti.com>
+Reported-by: Faiz Abbas <faiz_abbas@ti.com>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/mmc/core/mmc.c | 14 ++++++++++----
+ 1 file changed, 10 insertions(+), 4 deletions(-)
+
+--- a/drivers/mmc/core/mmc.c
++++ b/drivers/mmc/core/mmc.c
+@@ -30,6 +30,7 @@
+ #include "pwrseq.h"
+
+ #define DEFAULT_CMD6_TIMEOUT_MS 500
++#define MIN_CACHE_EN_TIMEOUT_MS 1600
+
+ static const unsigned int tran_exp[] = {
+ 10000, 100000, 1000000, 10000000,
+@@ -1789,13 +1790,18 @@ static int mmc_init_card(struct mmc_host
+ }
+
+ /*
+- * If cache size is higher than 0, this indicates
+- * the existence of cache and it can be turned on.
++ * If cache size is higher than 0, this indicates the existence of cache
++ * and it can be turned on. Note that some eMMCs from Micron has been
++ * reported to need ~800 ms timeout, while enabling the cache after
++ * sudden power failure tests. Let's extend the timeout to a minimum of
++ * DEFAULT_CACHE_EN_TIMEOUT_MS and do it for all cards.
+ */
+ if (card->ext_csd.cache_size > 0) {
++ unsigned int timeout_ms = MIN_CACHE_EN_TIMEOUT_MS;
++
++ timeout_ms = max(card->ext_csd.generic_cmd6_time, timeout_ms);
+ err = mmc_switch(card, EXT_CSD_CMD_SET_NORMAL,
+- EXT_CSD_CACHE_CTRL, 1,
+- card->ext_csd.generic_cmd6_time);
++ EXT_CSD_CACHE_CTRL, 1, timeout_ms);
+ if (err && err != -EBADMSG)
+ goto free_card;
+
--- /dev/null
+From 0b479790684192ab7024ce6a621f93f6d0a64d92 Mon Sep 17 00:00:00 2001
+From: Russell King <rmk+kernel@armlinux.org.uk>
+Date: Tue, 11 Dec 2018 14:41:31 +0000
+Subject: mmc: omap_hsmmc: fix DMA API warning
+
+From: Russell King <rmk+kernel@armlinux.org.uk>
+
+commit 0b479790684192ab7024ce6a621f93f6d0a64d92 upstream.
+
+While booting with rootfs on MMC, the following warning is encountered
+on OMAP4430:
+
+omap-dma-engine 4a056000.dma-controller: DMA-API: mapping sg segment longer than device claims to support [len=69632] [max=65536]
+
+This is because the DMA engine has a default maximum segment size of 64K
+but HSMMC sets:
+
+ mmc->max_blk_size = 512; /* Block Length at max can be 1024 */
+ mmc->max_blk_count = 0xFFFF; /* No. of Blocks is 16 bits */
+ mmc->max_req_size = mmc->max_blk_size * mmc->max_blk_count;
+ mmc->max_seg_size = mmc->max_req_size;
+
+which ends up telling the block layer that we support a maximum segment
+size of 65535*512, which exceeds the advertised DMA engine capabilities.
+
+Fix this by clamping the maximum segment size to the lower of the
+maximum request size and of the DMA engine device used for either DMA
+channel.
+
+Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/mmc/host/omap_hsmmc.c | 12 +++++++++++-
+ 1 file changed, 11 insertions(+), 1 deletion(-)
+
+--- a/drivers/mmc/host/omap_hsmmc.c
++++ b/drivers/mmc/host/omap_hsmmc.c
+@@ -2066,7 +2066,6 @@ static int omap_hsmmc_probe(struct platf
+ mmc->max_blk_size = 512; /* Block Length at max can be 1024 */
+ mmc->max_blk_count = 0xFFFF; /* No. of Blocks is 16 bits */
+ mmc->max_req_size = mmc->max_blk_size * mmc->max_blk_count;
+- mmc->max_seg_size = mmc->max_req_size;
+
+ mmc->caps |= MMC_CAP_MMC_HIGHSPEED | MMC_CAP_SD_HIGHSPEED |
+ MMC_CAP_WAIT_WHILE_BUSY | MMC_CAP_ERASE | MMC_CAP_CMD23;
+@@ -2096,6 +2095,17 @@ static int omap_hsmmc_probe(struct platf
+ goto err_irq;
+ }
+
++ /*
++ * Limit the maximum segment size to the lower of the request size
++ * and the DMA engine device segment size limits. In reality, with
++ * 32-bit transfers, the DMA engine can do longer segments than this
++ * but there is no way to represent that in the DMA model - if we
++ * increase this figure here, we get warnings from the DMA API debug.
++ */
++ mmc->max_seg_size = min3(mmc->max_req_size,
++ dma_get_max_seg_size(host->rx_chan->device->dev),
++ dma_get_max_seg_size(host->tx_chan->device->dev));
++
+ /* Request IRQ for MMC operations */
+ ret = devm_request_irq(&pdev->dev, host->irq, omap_hsmmc_irq, 0,
+ mmc_hostname(mmc), host);
--- /dev/null
+From 0e334db6bb4b1fd1e2d72c1f3d8f004313cd9f94 Mon Sep 17 00:00:00 2001
+From: Thomas Gleixner <tglx@linutronix.de>
+Date: Mon, 17 Dec 2018 13:31:05 +0100
+Subject: posix-timers: Fix division by zero bug
+
+From: Thomas Gleixner <tglx@linutronix.de>
+
+commit 0e334db6bb4b1fd1e2d72c1f3d8f004313cd9f94 upstream.
+
+The signal delivery path of posix-timers can try to rearm the timer even if
+the interval is zero. That's handled for the common case (hrtimer) but not
+for alarm timers. In that case the forwarding function raises a division by
+zero exception.
+
+The handling for hrtimer based posix timers is wrong because it marks the
+timer as active despite the fact that it is stopped.
+
+Move the check from common_hrtimer_rearm() to posixtimer_rearm() to cure
+both issues.
+
+Reported-by: syzbot+9d38bedac9cc77b8ad5e@syzkaller.appspotmail.com
+Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
+Cc: John Stultz <john.stultz@linaro.org>
+Cc: Linus Torvalds <torvalds@linux-foundation.org>
+Cc: Peter Zijlstra <peterz@infradead.org>
+Cc: sboyd@kernel.org
+Cc: stable@vger.kernel.org
+Cc: syzkaller-bugs@googlegroups.com
+Link: http://lkml.kernel.org/r/alpine.DEB.2.21.1812171328050.1880@nanos.tec.linutronix.de
+Signed-off-by: Ingo Molnar <mingo@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ kernel/time/posix-timers.c | 5 +----
+ 1 file changed, 1 insertion(+), 4 deletions(-)
+
+--- a/kernel/time/posix-timers.c
++++ b/kernel/time/posix-timers.c
+@@ -289,9 +289,6 @@ static void common_hrtimer_rearm(struct
+ {
+ struct hrtimer *timer = &timr->it.real.timer;
+
+- if (!timr->it_interval)
+- return;
+-
+ timr->it_overrun += hrtimer_forward(timer, timer->base->get_time(),
+ timr->it_interval);
+ hrtimer_restart(timer);
+@@ -317,7 +314,7 @@ void posixtimer_rearm(struct siginfo *in
+ if (!timr)
+ return;
+
+- if (timr->it_requeue_pending == info->si_sys_private) {
++ if (timr->it_interval && timr->it_requeue_pending == info->si_sys_private) {
+ timr->kclock->timer_rearm(timr);
+
+ timr->it_active = 1;
ubifs-handle-re-linking-of-inodes-correctly-while-recovery.patch
scsi-t10-pi-return-correct-ref-tag-when-queue-has-no-integrity-profile.patch
scsi-sd-use-mempool-for-discard-special-page.patch
+mmc-core-reset-hpi-enabled-state-during-re-init-and-in-case-of-errors.patch
+mmc-core-allow-bkops-and-cache-ctrl-even-if-no-hpi-support.patch
+mmc-core-use-a-minimum-1600ms-timeout-when-enabling-cache-ctrl.patch
+mmc-omap_hsmmc-fix-dma-api-warning.patch
+gpio-max7301-fix-driver-for-use-with-config_vmap_stack.patch
+gpiolib-acpi-only-defer-request_irq-for-gpioint-acpi-event-handlers.patch
+posix-timers-fix-division-by-zero-bug.patch
+kvm-x86-fix-null-deref-in-vcpu_scan_ioapic.patch
+kvm-x86-add-amd-s-ex_cfg-to-the-list-of-ignored-msrs.patch
+kvm-fix-uaf-in-nested-posted-interrupt-processing.patch
+drivers-hv-vmbus-return-einval-for-the-sys-files-for-unopened-channels.patch
+futex-cure-exit-race.patch
+x86-mtrr-don-t-copy-uninitialized-gentry-fields-back-to-userspace.patch
+x86-mm-fix-decoy-address-handling-vs-32-bit-builds.patch
+x86-vdso-pass-eh-frame-hdr-to-the-linker.patch
+x86-intel_rdt-ensure-a-cpu-remains-online-for-the-region-s-pseudo-locking-sequence.patch
--- /dev/null
+From 80b71c340f17705ec145911b9a193ea781811b16 Mon Sep 17 00:00:00 2001
+From: Reinette Chatre <reinette.chatre@intel.com>
+Date: Mon, 10 Dec 2018 13:21:54 -0800
+Subject: x86/intel_rdt: Ensure a CPU remains online for the region's pseudo-locking sequence
+
+From: Reinette Chatre <reinette.chatre@intel.com>
+
+commit 80b71c340f17705ec145911b9a193ea781811b16 upstream.
+
+The user triggers the creation of a pseudo-locked region when writing
+the requested schemata to the schemata resctrl file. The pseudo-locking
+of a region is required to be done on a CPU that is associated with the
+cache on which the pseudo-locked region will reside. In order to run the
+locking code on a specific CPU, the needed CPU has to be selected and
+ensured to remain online during the entire locking sequence.
+
+At this time, the cpu_hotplug_lock is not taken during the pseudo-lock
+region creation and it is thus possible for a CPU to be selected to run
+the pseudo-locking code and then that CPU to go offline before the
+thread is able to run on it.
+
+Fix this by ensuring that the cpu_hotplug_lock is taken while the CPU on
+which code has to run needs to be controlled. Since the cpu_hotplug_lock
+is always taken before rdtgroup_mutex the lock order is maintained.
+
+Fixes: e0bdfe8e36f3 ("x86/intel_rdt: Support creation/removal of pseudo-locked region")
+Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
+Signed-off-by: Borislav Petkov <bp@suse.de>
+Cc: "H. Peter Anvin" <hpa@zytor.com>
+Cc: Fenghua Yu <fenghua.yu@intel.com>
+Cc: Ingo Molnar <mingo@redhat.com>
+Cc: Thomas Gleixner <tglx@linutronix.de>
+Cc: Tony Luck <tony.luck@intel.com>
+Cc: gavin.hindman@intel.com
+Cc: jithu.joseph@intel.com
+Cc: stable <stable@vger.kernel.org>
+Cc: x86-ml <x86@kernel.org>
+Link: https://lkml.kernel.org/r/b7b17432a80f95a1fa21a1698ba643014f58ad31.1544476425.git.reinette.chatre@intel.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/x86/kernel/cpu/intel_rdt_ctrlmondata.c | 4 ++++
+ 1 file changed, 4 insertions(+)
+
+--- a/arch/x86/kernel/cpu/intel_rdt_ctrlmondata.c
++++ b/arch/x86/kernel/cpu/intel_rdt_ctrlmondata.c
+@@ -23,6 +23,7 @@
+
+ #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
++#include <linux/cpu.h>
+ #include <linux/kernfs.h>
+ #include <linux/seq_file.h>
+ #include <linux/slab.h>
+@@ -310,9 +311,11 @@ ssize_t rdtgroup_schemata_write(struct k
+ return -EINVAL;
+ buf[nbytes - 1] = '\0';
+
++ cpus_read_lock();
+ rdtgrp = rdtgroup_kn_lock_live(of->kn);
+ if (!rdtgrp) {
+ rdtgroup_kn_unlock(of->kn);
++ cpus_read_unlock();
+ return -ENOENT;
+ }
+ rdt_last_cmd_clear();
+@@ -367,6 +370,7 @@ ssize_t rdtgroup_schemata_write(struct k
+
+ out:
+ rdtgroup_kn_unlock(of->kn);
++ cpus_read_unlock();
+ return ret ?: nbytes;
+ }
+
--- /dev/null
+From 51c3fbd89d7554caa3290837604309f8d8669d99 Mon Sep 17 00:00:00 2001
+From: Dan Williams <dan.j.williams@intel.com>
+Date: Tue, 11 Dec 2018 07:49:39 -0800
+Subject: x86/mm: Fix decoy address handling vs 32-bit builds
+
+From: Dan Williams <dan.j.williams@intel.com>
+
+commit 51c3fbd89d7554caa3290837604309f8d8669d99 upstream.
+
+A decoy address is used by set_mce_nospec() to update the cache attributes
+for a page that may contain poison (multi-bit ECC error) while attempting
+to minimize the possibility of triggering a speculative access to that
+page.
+
+When reserve_memtype() is handling a decoy address it needs to convert it
+to its real physical alias. The conversion, AND'ing with __PHYSICAL_MASK,
+is broken for a 32-bit physical mask and reserve_memtype() is passed the
+last physical page. Gert reports triggering the:
+
+ BUG_ON(start >= end);
+
+...assertion when running a 32-bit non-PAE build on a platform that has
+a driver resource at the top of physical memory:
+
+ BIOS-e820: [mem 0x00000000fff00000-0x00000000ffffffff] reserved
+
+Given that the decoy address scheme is only targeted at 64-bit builds and
+assumes that the top of physical address space is free for use as a decoy
+address range, simply bypass address sanitization in the 32-bit case.
+
+Lastly, there was no need to crash the system when this failure occurred,
+and no need to crash future systems if the assumptions of decoy addresses
+are ever violated. Change the BUG_ON() to a WARN() with an error return.
+
+Fixes: 510ee090abc3 ("x86/mm/pat: Prepare {reserve, free}_memtype() for...")
+Reported-by: Gert Robben <t2@gert.gr>
+Signed-off-by: Dan Williams <dan.j.williams@intel.com>
+Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
+Tested-by: Gert Robben <t2@gert.gr>
+Cc: stable@vger.kernel.org
+Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
+Cc: Dave Hansen <dave.hansen@linux.intel.com>
+Cc: Andy Lutomirski <luto@kernel.org>
+Cc: Peter Zijlstra <peterz@infradead.org>
+Cc: Borislav Petkov <bp@alien8.de>
+Cc: "H. Peter Anvin" <hpa@zytor.com>
+Cc: platform-driver-x86@vger.kernel.org
+Cc: <stable@vger.kernel.org>
+Link: https://lkml.kernel.org/r/154454337985.789277.12133288391664677775.stgit@dwillia2-desk3.amr.corp.intel.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/x86/mm/pat.c | 13 +++++++++++--
+ 1 file changed, 11 insertions(+), 2 deletions(-)
+
+--- a/arch/x86/mm/pat.c
++++ b/arch/x86/mm/pat.c
+@@ -519,8 +519,13 @@ static u64 sanitize_phys(u64 address)
+ * for a "decoy" virtual address (bit 63 clear) passed to
+ * set_memory_X(). __pa() on a "decoy" address results in a
+ * physical address with bit 63 set.
++ *
++ * Decoy addresses are not present for 32-bit builds, see
++ * set_mce_nospec().
+ */
+- return address & __PHYSICAL_MASK;
++ if (IS_ENABLED(CONFIG_X86_64))
++ return address & __PHYSICAL_MASK;
++ return address;
+ }
+
+ /*
+@@ -546,7 +551,11 @@ int reserve_memtype(u64 start, u64 end,
+
+ start = sanitize_phys(start);
+ end = sanitize_phys(end);
+- BUG_ON(start >= end); /* end is exclusive */
++ if (start >= end) {
++ WARN(1, "%s failed: [mem %#010Lx-%#010Lx], req %s\n", __func__,
++ start, end - 1, cattr_name(req_type));
++ return -EINVAL;
++ }
+
+ if (!pat_enabled()) {
+ /* This is identical to page table setting without PAT */
--- /dev/null
+From 32043fa065b51e0b1433e48d118821c71b5cd65d Mon Sep 17 00:00:00 2001
+From: Colin Ian King <colin.king@canonical.com>
+Date: Tue, 18 Dec 2018 17:29:56 +0000
+Subject: x86/mtrr: Don't copy uninitialized gentry fields back to userspace
+
+From: Colin Ian King <colin.king@canonical.com>
+
+commit 32043fa065b51e0b1433e48d118821c71b5cd65d upstream.
+
+Currently the copy_to_user of data in the gentry struct is copying
+uninitiaized data in field _pad from the stack to userspace.
+
+Fix this by explicitly memset'ing gentry to zero, this also will zero any
+compiler added padding fields that may be in struct (currently there are
+none).
+
+Detected by CoverityScan, CID#200783 ("Uninitialized scalar variable")
+
+Fixes: b263b31e8ad6 ("x86, mtrr: Use explicit sizing and padding for the 64-bit ioctls")
+Signed-off-by: Colin Ian King <colin.king@canonical.com>
+Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
+Reviewed-by: Tyler Hicks <tyhicks@canonical.com>
+Cc: security@kernel.org
+Link: https://lkml.kernel.org/r/20181218172956.1440-1-colin.king@canonical.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/x86/kernel/cpu/mtrr/if.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/arch/x86/kernel/cpu/mtrr/if.c
++++ b/arch/x86/kernel/cpu/mtrr/if.c
+@@ -165,6 +165,8 @@ mtrr_ioctl(struct file *file, unsigned i
+ struct mtrr_gentry gentry;
+ void __user *arg = (void __user *) __arg;
+
++ memset(&gentry, 0, sizeof(gentry));
++
+ switch (cmd) {
+ case MTRRIOC_ADD_ENTRY:
+ case MTRRIOC_SET_ENTRY:
--- /dev/null
+From cd01544a268ad8ee5b1dfe42c4393f1095f86879 Mon Sep 17 00:00:00 2001
+From: Alistair Strachan <astrachan@google.com>
+Date: Fri, 14 Dec 2018 14:36:37 -0800
+Subject: x86/vdso: Pass --eh-frame-hdr to the linker
+
+From: Alistair Strachan <astrachan@google.com>
+
+commit cd01544a268ad8ee5b1dfe42c4393f1095f86879 upstream.
+
+Commit
+
+ 379d98ddf413 ("x86: vdso: Use $LD instead of $CC to link")
+
+accidentally broke unwinding from userspace, because ld would strip the
+.eh_frame sections when linking.
+
+Originally, the compiler would implicitly add --eh-frame-hdr when
+invoking the linker, but when this Makefile was converted from invoking
+ld via the compiler, to invoking it directly (like vmlinux does),
+the flag was missed. (The EH_FRAME section is important for the VDSO
+shared libraries, but not for vmlinux.)
+
+Fix the problem by explicitly specifying --eh-frame-hdr, which restores
+parity with the old method.
+
+See relevant bug reports for additional info:
+
+ https://bugzilla.kernel.org/show_bug.cgi?id=201741
+ https://bugzilla.redhat.com/show_bug.cgi?id=1659295
+
+Fixes: 379d98ddf413 ("x86: vdso: Use $LD instead of $CC to link")
+Reported-by: Florian Weimer <fweimer@redhat.com>
+Reported-by: Carlos O'Donell <carlos@redhat.com>
+Reported-by: "H. J. Lu" <hjl.tools@gmail.com>
+Signed-off-by: Alistair Strachan <astrachan@google.com>
+Signed-off-by: Borislav Petkov <bp@suse.de>
+Tested-by: Laura Abbott <labbott@redhat.com>
+Cc: Andy Lutomirski <luto@kernel.org>
+Cc: Carlos O'Donell <carlos@redhat.com>
+Cc: "H. Peter Anvin" <hpa@zytor.com>
+Cc: Ingo Molnar <mingo@redhat.com>
+Cc: Joel Fernandes <joel@joelfernandes.org>
+Cc: kernel-team@android.com
+Cc: Laura Abbott <labbott@redhat.com>
+Cc: stable <stable@vger.kernel.org>
+Cc: Thomas Gleixner <tglx@linutronix.de>
+Cc: X86 ML <x86@kernel.org>
+Link: https://lkml.kernel.org/r/20181214223637.35954-1-astrachan@google.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/x86/entry/vdso/Makefile | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/arch/x86/entry/vdso/Makefile
++++ b/arch/x86/entry/vdso/Makefile
+@@ -171,7 +171,8 @@ quiet_cmd_vdso = VDSO $@
+ sh $(srctree)/$(src)/checkundef.sh '$(NM)' '$@'
+
+ VDSO_LDFLAGS = -shared $(call ld-option, --hash-style=both) \
+- $(call ld-option, --build-id) -Bsymbolic
++ $(call ld-option, --build-id) $(call ld-option, --eh-frame-hdr) \
++ -Bsymbolic
+ GCOV_PROFILE := n
+
+ #
projects / thirdparty / kernel / stable-queue.git / commitdiff
