4.8.7-stable review

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/i2c/busses/i2c-rk3x.c |    2 ++
 1 file changed, 2 insertions(+)

drivers/i2c/busses/i2c-rk3x.c +2 -0

@@ -694,6 +694,8 @@ static int rk3x_i2c_v0_calc_timings(unsi
 	t_calc->div_low--;
 	t_calc->div_high--;
 
+	/* Give the tuning value 0, that would not update con register */
+	t_calc->tuning = 0;
 	/* Maximum divider supported by hw is 0xffff */
 	if (t_calc->div_low > 0xffff) {
 		t_calc->div_low = 0xffff;

Greg Kroah-Hartman

author maintainer

2016-11-09 11:05 UTC #2 lore raw

PATCH 2/138 i2c: xgene: Avoid dma_buffer overrun

4.8-stable review patch. If anyone has any objections, please let me know.

------------------

From: Hoan Tran <[email protected]>

commit 603616017c35f4d0fbdbcace72adf9bf949c4a65 upstream.

SMBus block command uses the first byte of buffer for the data length. The dma_buffer should be increased by 1 to avoid the overrun issue.

Reported-by Phil Endecott <[email protected]>

Signed-off-by Hoan Tran <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/i2c/busses/i2c-xgene-slimpro.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/i2c/busses/i2c-xgene-slimpro.c +1 -1

@@ -105,7 +105,7 @@ struct slimpro_i2c_dev {
 	struct mbox_chan *mbox_chan;
 	struct mbox_client mbox_client;
 	struct completion rd_complete;
-	u8 dma_buffer[I2C_SMBUS_BLOCK_MAX];
+	u8 dma_buffer[I2C_SMBUS_BLOCK_MAX + 1]; /* dma_buffer[0] is used for length */
 	u32 *resp_msg;
 };

Greg Kroah-Hartman

author maintainer

2016-11-09 11:05 UTC #3 lore raw

PATCH 3/138 i2c: core: fix NULL pointer dereference under race condition

4.8-stable review patch. If anyone has any objections, please let me know.

------------------

From: Vladimir Zapolskiy <[email protected]>

commit 147b36d5b70c083cc76770c47d60b347e8eaf231 upstream.

Race condition between registering an I2C device driver and deregistering an I2C adapter device which is assumed to manage that I2C device may lead to a NULL pointer dereference due to the uninitialized list head of driver clients.

The root cause of the issue is that the I2C bus may know about the registered device driver and thus it is matched by bus_for_each_drv(), but the list of clients is not initialized and commonly it is NULL, because I2C device drivers define struct i2c_driver as static and clients field is expected to be initialized by I2C core:

  i2c_register_driver()             i2c_del_adapter()
    driver_register()                 ...
      bus_add_driver()                ...
        ...                           bus_for_each_drv(..., __process_removed_adapter)
      ...                               i2c_do_del_adapter()
    ...                                   list_for_each_entry_safe(..., &driver->clients, ...)
    INIT_LIST_HEAD(&driver->clients);

To solve the problem it is sufficient to do clients list head initialization before calling driver_register().

The problem was found while using an I2C device driver with a sluggish registration routine on a bus provided by a physically detachable I2C master controller, but practically the oops may be reproduced under the race between arbitraty I2C device driver registration and managing I2C bus device removal e.g. by unbinding the latter over sysfs:

% echo 21a4000.i2c > /sys/bus/platform/drivers/imx-i2c/unbind

  Unable to handle kernel NULL pointer dereference at virtual address 00000000
  Internal error: Oops: 17 [#1] SMP ARM
  CPU: 2 PID: 533 Comm: sh Not tainted 4.9.0-rc3+ #61
  Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
  task: e5ada400 task.stack: e4936000
  PC is at i2c_do_del_adapter+0x20/0xcc
  LR is at __process_removed_adapter+0x14/0x1c
  Flags: NzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none
  Control: 10c5387d  Table: 35bd004a  DAC: 00000051
  Process sh (pid: 533, stack limit = 0xe4936210)
  Stack: (0xe4937d28 to 0xe4938000)
  Backtrace:
  [<c0667be0>] (i2c_do_del_adapter) from [<c0667cc0>] (__process_removed_adapter+0x14/0x1c)
  [<c0667cac>] (__process_removed_adapter) from [<c0516998>] (bus_for_each_drv+0x6c/0xa0)
  [<c051692c>] (bus_for_each_drv) from [<c06685ec>] (i2c_del_adapter+0xbc/0x284)
  [<c0668530>] (i2c_del_adapter) from [<bf0110ec>] (i2c_imx_remove+0x44/0x164 [i2c_imx])
  [<bf0110a8>] (i2c_imx_remove [i2c_imx]) from [<c051a838>] (platform_drv_remove+0x2c/0x44)
  [<c051a80c>] (platform_drv_remove) from [<c05183d8>] (__device_release_driver+0x90/0x12c)
  [<c0518348>] (__device_release_driver) from [<c051849c>] (device_release_driver+0x28/0x34)
  [<c0518474>] (device_release_driver) from [<c0517150>] (unbind_store+0x80/0x104)
  [<c05170d0>] (unbind_store) from [<c0516520>] (drv_attr_store+0x28/0x34)
  [<c05164f8>] (drv_attr_store) from [<c0298acc>] (sysfs_kf_write+0x50/0x54)
  [<c0298a7c>] (sysfs_kf_write) from [<c029801c>] (kernfs_fop_write+0x100/0x214)
  [<c0297f1c>] (kernfs_fop_write) from [<c0220130>] (__vfs_write+0x34/0x120)
  [<c02200fc>] (__vfs_write) from [<c0221088>] (vfs_write+0xa8/0x170)
  [<c0220fe0>] (vfs_write) from [<c0221e74>] (SyS_write+0x4c/0xa8)
  [<c0221e28>] (SyS_write) from [<c0108a20>] (ret_fast_syscall+0x0/0x1c)

Signed-off-by Vladimir Zapolskiy <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/i2c/i2c-core.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/i2c/i2c-core.c +1 -1

@@ -2073,6 +2073,7 @@ int i2c_register_driver(struct module *o
 	/* add the driver to the list of i2c drivers in the driver core */
 	driver->driver.owner = owner;
 	driver->driver.bus = &i2c_bus_type;
+	INIT_LIST_HEAD(&driver->clients);
 
 	/* When registration returns, the driver core
 	 * will have called probe() for all matching-but-unbound devices.

@@ -2083,7 +2084,6 @@ int i2c_register_driver(struct module *o
 
 	pr_debug("driver [%s] registered\n", driver->driver.name);
 
-	INIT_LIST_HEAD(&driver->clients);
 	/* Walk the adapters that are already present */
 	i2c_for_each_dev(driver, __process_new_driver);

Greg Kroah-Hartman

author maintainer

2016-11-09 11:05 UTC #4 lore raw

PATCH 5/138 spi: fsl-espi: avoid processing uninitalized data on error

4.8-stable review patch. If anyone has any objections, please let me know.

------------------

From: Arnd Bergmann <[email protected]>

commit 5c0ba57744b1422d528f19430dd66d6803cea86f upstream.

When we get a spurious interrupt in fsl_espi_irq, we end up processing four uninitalized bytes of data, as shown in this warning message:

drivers/spi/spi-fsl-espi.c: In function 'fsl_espi_irq':
drivers/spi/spi-fsl-espi.c:462:4: warning: 'rx_data' may be used uninitialized in this function [-Wmaybe-uninitialized]

This adds another check so we skip the data in this case.

Fixes 6319a68011b8 ("spi/fsl-espi: avoid infinite loops on fsl_espi_cpu_irq()")

Signed-off-by Arnd Bergmann <[email protected]>

Signed-off-by Mark Brown <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/spi/spi-fsl-espi.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/spi/spi-fsl-espi.c +1 -1

@@ -581,7 +581,7 @@ void fsl_espi_cpu_irq(struct mpc8xxx_spi
 
 		mspi->len -= rx_nr_bytes;
 
-		if (mspi->rx)
+		if (rx_nr_bytes && mspi->rx)
 			mspi->get_rx(rx_data, mspi);
 	}

Greg Kroah-Hartman

author maintainer

2016-11-09 11:05 UTC #5 lore raw

PATCH 6/138 spi: mark device nodes only in case of successful instantiation

4.8-stable review patch. If anyone has any objections, please let me know.

------------------

From: Ralf Ramsauer <[email protected]>

commit e0af98a7e025a7263ae7e50264f6f79ed29642a7 upstream.

Instantiated SPI device nodes are marked with OF_POPULATE. This was introduced in bd6c164. On unloading, loaded device nodes will of course be unmarked. The problem are nodes that fail during initialisation: If a node fails, it won't be unloaded and hence not be unmarked.

If a SPI driver module is unloaded and reloaded, it will skip nodes that failed before.

Skip device nodes that are already populated and mark them only in case of success.

Note that the same issue exists for I2C.

Fixes bd6c164 ("spi: Mark instantiated device nodes with OF_POPULATE")

Signed-off-by Ralf Ramsauer <[email protected]>

Reviewed-by Geert Uytterhoeven <[email protected]>

Acked-by Pantelis Antoniou <[email protected]>

Signed-off-by Mark Brown <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/spi/spi.c |    5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

drivers/spi/spi.c +4 -1

@@ -1607,9 +1607,11 @@ static void of_register_spi_devices(stru
 		if (of_node_test_and_set_flag(nc, OF_POPULATED))
 			continue;
 		spi = of_register_spi_device(master, nc);
-		if (IS_ERR(spi))
+		if (IS_ERR(spi)) {
 			dev_warn(&master->dev, "Failed to create SPI device for %s\n",
 				nc->full_name);
+			of_node_clear_flag(nc, OF_POPULATED);
+		}
 	}
 }
 #else

@@ -3120,6 +3122,7 @@ static int of_spi_notify(struct notifier
 		if (IS_ERR(spi)) {
 			pr_err("%s: failed to create for '%s'\n",
 					__func__, rd->dn->full_name);
+			of_node_clear_flag(rd->dn, OF_POPULATED);
 			return notifier_from_errno(PTR_ERR(spi));
 		}
 		break;

Greg Kroah-Hartman

author maintainer

2016-11-09 11:05 UTC #6 lore raw

PATCH 7/138 h8300: fix syscall restarting

4.8-stable review patch. If anyone has any objections, please let me know.

------------------

From: Mark Rutland <[email protected]>

commit 21753583056d48a5fad964d6f272e28168426845 upstream.

Back in commit f56141e3e2d9 ("all arches, signal: move restart_block to struct task_struct"), all architectures and core code were changed to use task_struct::restart_block. However, when h8300 support was subsequently restored in v4.2, it was not updated to account for this, and maintains thread_info::restart_block, which is not kept in sync.

This patch drops the redundant restart_block from thread_info, and moves h8300 to the common one in task_struct, ensuring that syscall restarting always works as expected.

Fixes f56141e3e2d9 ("all arches, signal: move restart_block to struct task_struct")

Link http://lkml.kernel.org/r/[email protected] open here

Signed-off-by Mark Rutland <[email protected]>

Cc Andy Lutomirski <[email protected]>

Cc Yoshinori Sato <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 arch/h8300/include/asm/thread_info.h |    4 ----
 arch/h8300/kernel/signal.c           |    2 +-
 2 files changed, 1 insertion(+), 5 deletions(-)

arch/h8300/include/asm/thread_info.h +0 -4

@@ -31,7 +31,6 @@ struct thread_info {
 	int		   cpu;			/* cpu we're on */
 	int		   preempt_count;	/* 0 => preemptable, <0 => BUG */
 	mm_segment_t		addr_limit;
-	struct restart_block restart_block;
 };
 
 /*

@@ -44,9 +43,6 @@ struct thread_info {
 	.cpu =		0,			\
 	.preempt_count = INIT_PREEMPT_COUNT,	\
 	.addr_limit	= KERNEL_DS,		\
-	.restart_block	= {			\
-		.fn = do_no_restart_syscall,	\
-	},					\
 }
 
 #define init_thread_info	(init_thread_union.thread_info)

arch/h8300/kernel/signal.c +1 -1

@@ -79,7 +79,7 @@ restore_sigcontext(struct sigcontext *us
 	unsigned int er0;
 
 	/* Always make any pending restarted system calls return -EINTR */
-	current_thread_info()->restart_block.fn = do_no_restart_syscall;
+	current->restart_block.fn = do_no_restart_syscall;
 
 	/* restore passed registers */
 #define COPY(r)  do { err |= get_user(regs->r, &usc->sc_##r); } while (0)

Greg Kroah-Hartman

author maintainer

2016-11-09 10:44 UTC #7 lore raw

PATCH 8/138 gpio / ACPI: fix returned error from acpi_dev_gpio_irq_get()

4.8-stable review patch. If anyone has any objections, please let me know.

------------------

From: David Arcari <[email protected]>

commit 67bf5156edc4f58241fd7c119ae145c552adddd6 upstream.

acpi_dev_gpio_irq_get() currently ignores the error returned by acpi_get_gpiod_by_index() and overwrites it with -ENOENT.

Problem is this error can be -EPROBE_DEFER, which just blows up some drivers when the module ordering is not correct.

Signed-off-by David Arcari <[email protected]>

Signed-off-by Benjamin Tissoires <[email protected]>

Acked-by Mika Westerberg <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/gpio/gpiolib-acpi.c |    7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

drivers/gpio/gpiolib-acpi.c +5 -2

@@ -602,14 +602,17 @@ int acpi_dev_gpio_irq_get(struct acpi_de
 {
 	int idx, i;
 	unsigned int irq_flags;
+	int ret = -ENOENT;
 
 	for (i = 0, idx = 0; idx <= index; i++) {
 		struct acpi_gpio_info info;
 		struct gpio_desc *desc;
 
 		desc = acpi_get_gpiod_by_index(adev, NULL, i, &info);
-		if (IS_ERR(desc))
+		if (IS_ERR(desc)) {
+			ret = PTR_ERR(desc);
 			break;
+		}
 		if (info.gpioint && idx++ == index) {
 			int irq = gpiod_to_irq(desc);

@@ -628,7 +631,7 @@ int acpi_dev_gpio_irq_get(struct acpi_de
 		}
 
 	}
-	return -ENOENT;
+	return ret;
 }
 EXPORT_SYMBOL_GPL(acpi_dev_gpio_irq_get);

Greg Kroah-Hartman

author maintainer

2016-11-09 11:05 UTC #8 lore raw

PATCH 9/138 gpio: GPIO_GET_CHIPINFO_IOCTL: Fix line offset validation

4.8-stable review patch. If anyone has any objections, please let me know.

------------------

From: Lars-Peter Clausen <[email protected]>

commit 1f1cc4566bd9dd8d3cf19965a4b6392143618536 upstream.

The current line offset validation is off by one. Depending on the data stored behind the descs array this can either cause undefined behavior or disclose arbitrary, potentially sensitive, memory to the issuing userspace application.

Make sure that offset is within the bounds of the desc array.

Fixes 521a2ad6f862 ("gpio: add userspace ABI for GPIO line information")

Signed-off-by Lars-Peter Clausen <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/gpio/gpiolib.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/gpio/gpiolib.c +1 -1

@@ -837,7 +837,7 @@ static long gpio_ioctl(struct file *filp
 
 		if (copy_from_user(&lineinfo, ip, sizeof(lineinfo)))
 			return -EFAULT;
-		if (lineinfo.line_offset > gdev->ngpio)
+		if (lineinfo.line_offset >= gdev->ngpio)
 			return -EINVAL;
 
 		desc = &gdev->descs[lineinfo.line_offset];

Greg Kroah-Hartman

author maintainer

2016-11-09 11:04 UTC #9 lore raw

PATCH 10/138 gpio: GPIO_GET_CHIPINFO_IOCTL: Fix information leak

4.8-stable review patch. If anyone has any objections, please let me know.

------------------

From: Lars-Peter Clausen <[email protected]>

commit 0f4bbb233743bdfd51d47688b0bc2561f310488b upstream.

The GPIO_GET_CHIPINFO_IOCTL handler allocates a gpiochip_info struct on the stack and then passes it to copy_to_user(). But depending on the length of the GPIO chip name and label the struct is only partially initialized.

This exposes the previous, potentially sensitive, stack content to the issuing userspace application. To avoid this make sure that the struct is fully initialized.

Fixes 521a2ad6f862 ("gpio: add userspace ABI for GPIO line information")

Signed-off-by Lars-Peter Clausen <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/gpio/gpiolib.c |    2 ++
 1 file changed, 2 insertions(+)

drivers/gpio/gpiolib.c +2 -0

@@ -821,6 +821,8 @@ static long gpio_ioctl(struct file *filp
 	if (cmd == GPIO_GET_CHIPINFO_IOCTL) {
 		struct gpiochip_info chipinfo;
 
+		memset(&chipinfo, 0, sizeof(chipinfo));
+
 		strncpy(chipinfo.name, dev_name(&gdev->dev),
 			sizeof(chipinfo.name));
 		chipinfo.name[sizeof(chipinfo.name)-1] = '\0';

Greg Kroah-Hartman

author maintainer

2016-11-09 10:44 UTC #10 lore raw

PATCH 11/138 gpio: GPIO_GET_LINEHANDLE_IOCTL: Validate line offset

4.8-stable review patch. If anyone has any objections, please let me know.

------------------

From: Lars-Peter Clausen <[email protected]>

commit e405f9fcb63602d35f7a419ededa3f952a395a72 upstream.

The line offset that is used as an index into the descs array is provided by userspace and might go beyond the bounds of the array. If that happens undefined behavior will occur.

Make sure that the offset is within the bounds of the desc array and reject any requests that specify a value outside of it.

Fixes d7c51b47ac11 ("gpio: userspace ABI for reading/writing GPIO lines")

Signed-off-by Lars-Peter Clausen <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/gpio/gpiolib.c |    5 +++++
 1 file changed, 5 insertions(+)

drivers/gpio/gpiolib.c +5 -0

@@ -442,6 +442,11 @@ static int linehandle_create(struct gpio
 		u32 lflags = handlereq.flags;
 		struct gpio_desc *desc;
 
+		if (offset >= gdev->ngpio) {
+			ret = -EINVAL;
+			goto out_free_descs;
+		}
+
 		desc = &gdev->descs[offset];
 		ret = gpiod_request(desc, lh->label);
 		if (ret)

Greg Kroah-Hartman

author maintainer

2016-11-09 10:44 UTC #11 lore raw

PATCH 12/138 gpio: GPIOHANDLE_GET_LINE_VALUES_IOCTL: Fix information leak

4.8-stable review patch. If anyone has any objections, please let me know.

------------------

From: Lars-Peter Clausen <[email protected]>

commit 3eded5d83bf4e36ad78775c7ceb44a45480b0abd upstream.

The GPIOHANDLE_GET_LINE_VALUES_IOCTL handler allocates a gpiohandle_data struct on the stack and then passes it to copy_to_user(). But depending on the number of requested line handles the struct is only partially initialized.

This exposes the previous, potentially sensitive, stack content to the issuing userspace application. To avoid this make sure that the struct is fully initialized.

Fixes d7c51b47ac11 ("gpio: userspace ABI for reading/writing GPIO lines")

Signed-off-by Lars-Peter Clausen <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/gpio/gpiolib.c |    2 ++
 1 file changed, 2 insertions(+)

drivers/gpio/gpiolib.c +2 -0

@@ -342,6 +342,8 @@ static long linehandle_ioctl(struct file
 	if (cmd == GPIOHANDLE_GET_LINE_VALUES_IOCTL) {
 		int val;
 
+		memset(&ghd, 0, sizeof(ghd));
+
 		/* TODO: check if descriptors are really input */
 		for (i = 0; i < lh->numdescs; i++) {
 			val = gpiod_get_value_cansleep(lh->descs[i]);

Greg Kroah-Hartman

author maintainer

2016-11-09 10:44 UTC #12 lore raw

PATCH 13/138 gpio: GPIO_GET_LINEEVENT_IOCTL: Validate line offset

4.8-stable review patch. If anyone has any objections, please let me know.

------------------

From: Lars-Peter Clausen <[email protected]>

commit b8b0e3d303654b3bb7b31b0266c513fd6f4132ce upstream.

The line offset that is used as an index into the descs array is provided by userspace and might go beyond the bounds of the array. If that happens undefined behavior will occur.

Make sure that the offset is within the bounds of the desc array and reject any requests that specify a value outside of it.

Fixes 61f922db7221 ("gpio: userspace ABI for reading GPIO line events")

Signed-off-by Lars-Peter Clausen <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/gpio/gpiolib.c |    5 +++++
 1 file changed, 5 insertions(+)

drivers/gpio/gpiolib.c +5 -0

@@ -731,6 +731,11 @@ static int lineevent_create(struct gpio_
 	lflags = eventreq.handleflags;
 	eflags = eventreq.eventflags;
 
+	if (offset >= gdev->ngpio) {
+		ret = -EINVAL;
+		goto out_free_label;
+	}
+
 	/* This is just wrong: we don't look for events on output lines */
 	if (lflags & GPIOHANDLE_REQUEST_OUTPUT) {
 		ret = -EINVAL;

Greg Kroah-Hartman

author maintainer

2016-11-09 11:05 UTC #13 lore raw

PATCH 14/138 gpio: GPIO_GET_LINEHANDLE_IOCTL: Reject invalid line flags

4.8-stable review patch. If anyone has any objections, please let me know.

------------------

From: Lars-Peter Clausen <[email protected]>

commit e3e847c7f15a27c80f526b2a7a8d4dd7ce0960a0 upstream.

The GPIO_GET_LINEHANDLE_IOCTL currently ignores unknown or undefined linehandle flags. From a backwards and forwards compatibility viewpoint it is highly desirable to reject unknown flags though.

On one hand an application that is using newer flags and is running on an older kernel has no way to detect if the new flags were handled correctly if they are silently discarded.

On the other hand an application that (accidentally) passes undefined flags will run fine on an older kernel, but may break on a newer kernel when these flags get defined.

Ensure that requests that have undefined flags set are rejected with an error, rather than silently discarding the undefined flags.

Fixes d7c51b47ac11 ("gpio: userspace ABI for reading/writing GPIO lines")

Signed-off-by Lars-Peter Clausen <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/gpio/gpiolib.c |   13 +++++++++++++
 1 file changed, 13 insertions(+)

drivers/gpio/gpiolib.c +13 -0

@@ -331,6 +331,13 @@ struct linehandle_state {
 	u32 numdescs;
 };
 
+#define GPIOHANDLE_REQUEST_VALID_FLAGS \
+	(GPIOHANDLE_REQUEST_INPUT | \
+	GPIOHANDLE_REQUEST_OUTPUT | \
+	GPIOHANDLE_REQUEST_ACTIVE_LOW | \
+	GPIOHANDLE_REQUEST_OPEN_DRAIN | \
+	GPIOHANDLE_REQUEST_OPEN_SOURCE)
+
 static long linehandle_ioctl(struct file *filep, unsigned int cmd,
 			     unsigned long arg)
 {

@@ -448,6 +455,12 @@ static int linehandle_create(struct gpio
 			ret = -EINVAL;
 			goto out_free_descs;
 		}
+
+		/* Return an error if a unknown flag is set */
+		if (lflags & ~GPIOHANDLE_REQUEST_VALID_FLAGS) {
+			ret = -EINVAL;
+			goto out_free_descs;
+		}
 
 		desc = &gdev->descs[offset];
 		ret = gpiod_request(desc, lh->label);

Greg Kroah-Hartman

author maintainer

2016-11-09 11:05 UTC #14 lore raw

PATCH 15/138 gpio: GPIO_GET_LINEEVENT_IOCTL: Reject invalid line and event flags

4.8-stable review patch. If anyone has any objections, please let me know.

------------------

From: Lars-Peter Clausen <[email protected]>

commit ac7dbb991ee5afc0beacce3a252dcaaa249a7786 upstream.

The GPIO_GET_LINEEVENT_IOCTL currently ignores unknown or undefined linehandle and lineevent flags. From a backwards and forwards compatibility viewpoint it is highly desirable to reject unknown flags though.

On one hand an application that is using newer flags and is running on an older kernel has no way to detect if the new flags were handled correctly if they are silently discarded.

On the other hand an application that (accidentally) passes undefined flags will run fine on an older kernel, but may break on a newer kernel when these flags get defined.

Ensure that requests that have undefined flags set are rejected with an error, rather than silently discarding the undefined flags.

Fixes 61f922db7221 ("gpio: userspace ABI for reading GPIO line events")

Signed-off-by Lars-Peter Clausen <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/gpio/gpiolib.c |   11 +++++++++++
 1 file changed, 11 insertions(+)

drivers/gpio/gpiolib.c +11 -0

@@ -554,6 +554,10 @@ struct lineevent_state {
 	struct mutex read_lock;
 };
 
+#define GPIOEVENT_REQUEST_VALID_FLAGS \
+	(GPIOEVENT_REQUEST_RISING_EDGE | \
+	GPIOEVENT_REQUEST_FALLING_EDGE)
+
 static unsigned int lineevent_poll(struct file *filep,
 				   struct poll_table_struct *wait)
 {

@@ -748,6 +752,13 @@ static int lineevent_create(struct gpio_
 		ret = -EINVAL;
 		goto out_free_label;
 	}
+
+	/* Return an error if a unknown flag is set */
+	if ((lflags & ~GPIOHANDLE_REQUEST_VALID_FLAGS) ||
+	    (eflags & ~GPIOEVENT_REQUEST_VALID_FLAGS)) {
+		ret = -EINVAL;
+		goto out_free_label;
+	}
 
 	/* This is just wrong: we don't look for events on output lines */
 	if (lflags & GPIOHANDLE_REQUEST_OUTPUT) {

Greg Kroah-Hartman

author maintainer

2016-11-09 10:44 UTC #15 lore raw

PATCH 16/138 gpio: GPIOHANDLE_GET_LINE_VALUES_IOCTL: Fix another information leak

4.8-stable review patch. If anyone has any objections, please let me know.

------------------

From: Lars-Peter Clausen <[email protected]>

commit d82aa4a8f2e8df9673ddb099262355da4c9b99b1 upstream.

The GPIOHANDLE_GET_LINE_VALUES_IOCTL handler allocates a gpiohandle_data struct on the stack and then passes it to copy_to_user(). But only the first element of the values array in the struct is set, which leaves the struct partially initialized.

This exposes the previous, potentially sensitive, stack content to the issuing userspace application. To avoid this make sure that the struct is fully initialized.

Fixes 61f922db7221 ("gpio: userspace ABI for reading GPIO line events")

Signed-off-by Lars-Peter Clausen <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/gpio/gpiolib.c |    2 ++
 1 file changed, 2 insertions(+)

drivers/gpio/gpiolib.c +2 -0

@@ -645,6 +645,8 @@ static long lineevent_ioctl(struct file
 	if (cmd == GPIOHANDLE_GET_LINE_VALUES_IOCTL) {
 		int val;
 
+		memset(&ghd, 0, sizeof(ghd));
+
 		val = gpiod_get_value_cansleep(le->desc);
 		if (val < 0)
 			return val;

Greg Kroah-Hartman

author maintainer

2016-11-09 11:05 UTC #16 lore raw

PATCH 17/138 gpio: GPIO_GET_LINE{HANDLE,EVENT}_IOCTL: Fix file descriptor leak

4.8-stable review patch. If anyone has any objections, please let me know.

------------------

From: Lars-Peter Clausen <[email protected]>

commit 953b956a2e6d35298e684f251bad98ea6c96f982 upstream.

When allocating a new line handle or event a file is allocated that it is associated to. The file is attached to a file descriptor of the current process and the file descriptor is returned to userspace using copy_to_user(). If this copy operation fails the line handle or event allocation is aborted, all acquired resources are freed and an error is returned.

But the file struct is not freed and left attached to the userspace application and even though the file descriptor number was not copied it is trivial to guess. If a userspace application performs a IOCTL on such a left over file descriptor it will trigger a use-after-free and if the file descriptor is closed (latest when the application exits) a double-free is triggered.

anon_inode_getfd() performs 3 tasks, allocate a file struct, allocate a file descriptor for the current process and install the file struct in the file descriptor. As soon as the file struct is installed in the file descriptor it is accessible by userspace (even if the IOCTL itself hasn't completed yet), this means uninstalling the fd on the error path is not an option, since userspace might already got a reference to the file.

Instead anon_inode_getfd() needs to be broken into its individual steps. The allocation of the file struct and file descriptor is done first, then the copy_to_user() is executed and only if it succeeds the file is installed.

Since the file struct is reference counted it can not be just freed, but its reference needs to be dropped, which will also call the release() callback, which will free the state attached to the file. So in this case the normal error cleanup path should not be taken.

Fixes d932cd49182f ("gpio: free handles in fringe cases")

Signed-off-by Lars-Peter Clausen <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/gpio/gpiolib.c |   57 ++++++++++++++++++++++++++++++++++++++-----------
 1 file changed, 45 insertions(+), 12 deletions(-)

drivers/gpio/gpiolib.c +45 ~~-12~~

@@ -21,6 +21,7 @@
 #include <linux/uaccess.h>
 #include <linux/compat.h>
 #include <linux/anon_inodes.h>
+#include <linux/file.h>
 #include <linux/kfifo.h>
 #include <linux/poll.h>
 #include <linux/timekeeping.h>

@@ -421,6 +422,7 @@ static int linehandle_create(struct gpio
 {
 	struct gpiohandle_request handlereq;
 	struct linehandle_state *lh;
+	struct file *file;
 	int fd, i, ret;
 
 	if (copy_from_user(&handlereq, ip, sizeof(handlereq)))

@@ -497,26 +499,41 @@ static int linehandle_create(struct gpio
 	i--;
 	lh->numdescs = handlereq.lines;
 
-	fd = anon_inode_getfd("gpio-linehandle",
-			      &linehandle_fileops,
-			      lh,
-			      O_RDONLY | O_CLOEXEC);
+	fd = get_unused_fd_flags(O_RDONLY | O_CLOEXEC);
 	if (fd < 0) {
 		ret = fd;
 		goto out_free_descs;
 	}
 
+	file = anon_inode_getfile("gpio-linehandle",
+				  &linehandle_fileops,
+				  lh,
+				  O_RDONLY | O_CLOEXEC);
+	if (IS_ERR(file)) {
+		ret = PTR_ERR(file);
+		goto out_put_unused_fd;
+	}
+
 	handlereq.fd = fd;
 	if (copy_to_user(ip, &handlereq, sizeof(handlereq))) {
-		ret = -EFAULT;
-		goto out_free_descs;
+		/*
+		 * fput() will trigger the release() callback, so do not go onto
+		 * the regular error cleanup path here.
+		 */
+		fput(file);
+		put_unused_fd(fd);
+		return -EFAULT;
 	}
 
+	fd_install(fd, file);
+
 	dev_dbg(&gdev->dev, "registered chardev handle for %d lines\n",
 		lh->numdescs);
 
 	return 0;
 
+out_put_unused_fd:
+	put_unused_fd(fd);
 out_free_descs:
 	for (; i >= 0; i--)
 		gpiod_free(lh->descs[i]);

@@ -719,6 +736,7 @@ static int lineevent_create(struct gpio_
 	struct gpioevent_request eventreq;
 	struct lineevent_state *le;
 	struct gpio_desc *desc;
+	struct file *file;
 	u32 offset;
 	u32 lflags;
 	u32 eflags;

@@ -813,23 +831,38 @@ static int lineevent_create(struct gpio_
 	if (ret)
 		goto out_free_desc;
 
-	fd = anon_inode_getfd("gpio-event",
-			      &lineevent_fileops,
-			      le,
-			      O_RDONLY | O_CLOEXEC);
+	fd = get_unused_fd_flags(O_RDONLY | O_CLOEXEC);
 	if (fd < 0) {
 		ret = fd;
 		goto out_free_irq;
 	}
 
+	file = anon_inode_getfile("gpio-event",
+				  &lineevent_fileops,
+				  le,
+				  O_RDONLY | O_CLOEXEC);
+	if (IS_ERR(file)) {
+		ret = PTR_ERR(file);
+		goto out_put_unused_fd;
+	}
+
 	eventreq.fd = fd;
 	if (copy_to_user(ip, &eventreq, sizeof(eventreq))) {
-		ret = -EFAULT;
-		goto out_free_irq;
+		/*
+		 * fput() will trigger the release() callback, so do not go onto
+		 * the regular error cleanup path here.
+		 */
+		fput(file);
+		put_unused_fd(fd);
+		return -EFAULT;
 	}
 
+	fd_install(fd, file);
+
 	return 0;
 
+out_put_unused_fd:
+	put_unused_fd(fd);
 out_free_irq:
 	free_irq(le->irq, le);
 out_free_desc:

Greg Kroah-Hartman

author maintainer

2016-11-09 10:45 UTC #17 lore raw

PATCH 18/138 libxfs: clean up _calc_dquots_per_chunk

4.8-stable review patch. If anyone has any objections, please let me know.

------------------

From: Darrick J. Wong <[email protected]>

commit 58d789678546d46d7bbd809dd7dab417c0f23655 upstream.

The function xfs_calc_dquots_per_chunk takes a parameter in units of basic blocks. The kernel seems to get the units wrong, but userspace got 'fixed' by commenting out the unnecessary conversion. Fix both.

Signed-off-by Darrick J. Wong <[email protected]>

Reviewed-by Eric Sandeen <[email protected]>

Signed-off-by Dave Chinner <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 fs/xfs/libxfs/xfs_dquot_buf.c |    3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

fs/xfs/libxfs/xfs_dquot_buf.c +1 -2

@@ -191,8 +191,7 @@ xfs_dquot_buf_verify_crc(
 	if (mp->m_quotainfo)
 		ndquots = mp->m_quotainfo->qi_dqperchunk;
 	else
-		ndquots = xfs_calc_dquots_per_chunk(
-					XFS_BB_TO_FSB(mp, bp->b_length));
+		ndquots = xfs_calc_dquots_per_chunk(bp->b_length);
 
 	for (i = 0; i < ndquots; i++, d++) {
 		if (!xfs_verify_cksum((char *)d, sizeof(struct xfs_dqblk),

Greg Kroah-Hartman

author maintainer

2016-11-09 11:05 UTC #18 lore raw

PATCH 19/138 mm/list_lru.c: avoid error-path NULL pointer deref

4.8-stable review patch. If anyone has any objections, please let me know.

------------------

From: Alexander Polakov <[email protected]>

commit 1bc11d70b5db7c6bb1414b283d7f09b1fe1ac0d0 upstream.

As described in https://bugzilla.kernel.org/show_bug.cgi?id=177821:

After some analysis it seems to be that the problem is in alloc_super(). In case list_lru_init_memcg() fails it goes into destroy_super(), which calls list_lru_destroy().

And in list_lru_init() we see that in case memcg_init_list_lru() fails, lru->node is freed, but not set NULL, which then leads list_lru_destroy() to believe it is initialized and call memcg_destroy_list_lru(). memcg_destroy_list_lru() in turn can access lru->node[i].memcg_lrus, which is NULL.

[[email protected]: add comment]

Signed-off-by Alexander Polakov <[email protected]>

Acked-by Vladimir Davydov <[email protected]>

Cc Al Viro <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 mm/list_lru.c |    2 ++
 1 file changed, 2 insertions(+)

mm/list_lru.c +2 -0

@@ -554,6 +554,8 @@ int __list_lru_init(struct list_lru *lru
 	err = memcg_init_list_lru(lru, memcg_aware);
 	if (err) {
 		kfree(lru->node);
+		/* Do this so a list_lru_destroy() doesn't crash: */
+		lru->node = NULL;
 		goto out;
 	}

Greg Kroah-Hartman

author maintainer

2016-11-09 10:45 UTC #19 lore raw

PATCH 20/138 mm/slab: fix kmemcg cache creation delayed issue

https://bugzilla.kernel.org/show_bug.cgi?id=172981

4.8-stable review patch. If anyone has any objections, please let me know.

------------------

From: Joonsoo Kim <[email protected]>

commit 86d9f48534e800e4d62cdc1b5aaf539f4c1d47d6 upstream.

There is a bug report that SLAB makes extreme load average due to over 2000 kworker thread.

This issue is caused by kmemcg feature that try to create new set of kmem_caches for each memcg. Recently, kmem_cache creation is slowed by synchronize_sched() and futher kmem_cache creation is also delayed since kmem_cache creation is synchronized by a global slab_mutex lock. So, the number of kworker that try to create kmem_cache increases quietly.

synchronize_sched() is for lockless access to node's shared array but it's not needed when a new kmem_cache is created. So, this patch rules out that case.

Fixes 801faf0db894 ("mm/slab: lockless decision to grow cache")

Link http://lkml.kernel.org/r/[email protected] open here

Reported-by Doug Smythies <[email protected]>

Tested-by Doug Smythies <[email protected]>

Signed-off-by Joonsoo Kim <[email protected]>

Cc Christoph Lameter <[email protected]>

Cc Pekka Enberg <[email protected]>

Cc David Rientjes <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 mm/slab.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

mm/slab.c +1 -1

@@ -964,7 +964,7 @@ static int setup_kmem_cache_node(struct
 	 * guaranteed to be valid until irq is re-enabled, because it will be
 	 * freed after synchronize_sched().
 	 */
-	if (force_change)
+	if (old_shared && force_change)
 		synchronize_sched();
 
 fail:

Greg Kroah-Hartman

author maintainer

2016-11-09 10:45 UTC #20 lore raw

PATCH 21/138 mm: memcontrol: do not recurse in direct reclaim

4.8-stable review patch. If anyone has any objections, please let me know.

------------------

From: Johannes Weiner <[email protected]>

commit 89a2848381b5fcd9c4d9c0cd97680e3b28730e31 upstream.

On 4.0, we saw a stack corruption from a page fault entering direct memory cgroup reclaim, calling into btrfs_releasepage(), which then tried to allocate an extent and recursed back into a kmem charge ad nauseam:

[...]

  btrfs_releasepage+0x2c/0x30
  try_to_release_page+0x32/0x50
  shrink_page_list+0x6da/0x7a0
  shrink_inactive_list+0x1e5/0x510
  shrink_lruvec+0x605/0x7f0
  shrink_zone+0xee/0x320
  do_try_to_free_pages+0x174/0x440
  try_to_free_mem_cgroup_pages+0xa7/0x130
  try_charge+0x17b/0x830
  memcg_charge_kmem+0x40/0x80
  new_slab+0x2d9/0x5a0
  __slab_alloc+0x2fd/0x44f
  kmem_cache_alloc+0x193/0x1e0
  alloc_extent_state+0x21/0xc0
  __clear_extent_bit+0x2b5/0x400
  try_release_extent_mapping+0x1a3/0x220
  __btrfs_releasepage+0x31/0x70
  btrfs_releasepage+0x2c/0x30
  try_to_release_page+0x32/0x50
  shrink_page_list+0x6da/0x7a0
  shrink_inactive_list+0x1e5/0x510
  shrink_lruvec+0x605/0x7f0
  shrink_zone+0xee/0x320
  do_try_to_free_pages+0x174/0x440
  try_to_free_mem_cgroup_pages+0xa7/0x130
  try_charge+0x17b/0x830
  mem_cgroup_try_charge+0x65/0x1c0
  handle_mm_fault+0x117f/0x1510
  __do_page_fault+0x177/0x420
  do_page_fault+0xc/0x10
  page_fault+0x22/0x30

On later kernels, kmem charging is opt-in rather than opt-out, and that particular kmem allocation in btrfs_releasepage() is no longer being charged and won't recurse and overrun the stack anymore.

But it's not impossible for an accounted allocation to happen from the memcg direct reclaim context, and we needed to reproduce this crash many times before we even got a useful stack trace out of it.

Like other direct reclaimers, mark tasks in memcg reclaim PF_MEMALLOC to avoid recursing into any other form of direct reclaim. Then let recursive charges from PF_MEMALLOC contexts bypass the cgroup limit.

Link http://lkml.kernel.org/r/[email protected] open here

Signed-off-by Johannes Weiner <[email protected]>

Acked-by Michal Hocko <[email protected]>

Cc Vladimir Davydov <[email protected]>

Cc Tejun Heo <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 mm/memcontrol.c |    9 +++++++++
 mm/vmscan.c     |    2 ++
 2 files changed, 11 insertions(+)

mm/memcontrol.c +9 -0

@@ -1947,6 +1947,15 @@ retry:
 		     current->flags & PF_EXITING))
 		goto force;
 
+	/*
+	 * Prevent unbounded recursion when reclaim operations need to
+	 * allocate memory. This might exceed the limits temporarily,
+	 * but we prefer facilitating memory reclaim and getting back
+	 * under the limit over triggering OOM kills in these cases.
+	 */
+	if (unlikely(current->flags & PF_MEMALLOC))
+		goto force;
+
 	if (unlikely(task_in_memcg_oom(current)))
 		goto nomem;

mm/vmscan.c +2 -0

@@ -3048,7 +3048,9 @@ unsigned long try_to_free_mem_cgroup_pag
 					    sc.gfp_mask,
 					    sc.reclaim_idx);
 
+	current->flags |= PF_MEMALLOC;
 	nr_reclaimed = do_try_to_free_pages(zonelist, &sc);
+	current->flags &= ~PF_MEMALLOC;
 
 	trace_mm_vmscan_memcg_reclaim_end(nr_reclaimed);

Greg Kroah-Hartman

author maintainer

2016-11-09 11:07 UTC #21 lore raw

PATCH 22/138 thermal/powerclamp: correct cpu support check

4.8-stable review patch. If anyone has any objections, please let me know.

------------------

From: Eric Ernst <[email protected]>

commit 3105f234e0aba43e44e277c20f9b32ee8add43d4 upstream.

Initial logic for checking CPU match resulted in OR of CPU features rather than the intended AND.

Updated to use boot_cpu_has macro rather than x86_match_cpu.

In addition, MWAIT is the only required CPU feature for idle injection to work. Drop other feature requirements since they are only needed for optimal efficiency.

Signed-off-by Eric Ernst <[email protected]>

Acked-by Jacob Pan <[email protected]>

Signed-off-by Zhang Rui <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/thermal/intel_powerclamp.c |   14 ++------------
 1 file changed, 2 insertions(+), 12 deletions(-)

drivers/thermal/intel_powerclamp.c +2 ~~-12~~

@@ -669,20 +669,10 @@ static struct thermal_cooling_device_ops
 	.set_cur_state = powerclamp_set_cur_state,
 };
 
-static const struct x86_cpu_id intel_powerclamp_ids[] __initconst = {
-	{ X86_VENDOR_INTEL, X86_FAMILY_ANY, X86_MODEL_ANY, X86_FEATURE_MWAIT },
-	{ X86_VENDOR_INTEL, X86_FAMILY_ANY, X86_MODEL_ANY, X86_FEATURE_ARAT },
-	{ X86_VENDOR_INTEL, X86_FAMILY_ANY, X86_MODEL_ANY, X86_FEATURE_NONSTOP_TSC },
-	{ X86_VENDOR_INTEL, X86_FAMILY_ANY, X86_MODEL_ANY, X86_FEATURE_CONSTANT_TSC},
-	{}
-};
-MODULE_DEVICE_TABLE(x86cpu, intel_powerclamp_ids);
-
 static int __init powerclamp_probe(void)
 {
-	if (!x86_match_cpu(intel_powerclamp_ids)) {
-		pr_err("Intel powerclamp does not run on family %d model %d\n",
-				boot_cpu_data.x86, boot_cpu_data.x86_model);
+	if (!boot_cpu_has(X86_FEATURE_MWAIT)) {
+		pr_err("CPU does not support MWAIT");
 		return -ENODEV;
 	}

Jacob Pan

2016-11-09 15:03 UTC #22 lore raw

Re: [PATCH 4.8 022/138] thermal/powerclamp: correct cpu support check

Quoted 3 lines · On Wed, 9 Nov 2016 11:45:05 +0100 Greg Kroah-Hartman…

4.8-stable review patch. If anyone has any objections, please let me know.

I just realized that this patch would prevent module auto loading since we don't have device id table.

I will send out this patch in a minute. So we need to apply both this patch and the one below.

drivers/thermal/intel_powerclamp.c | 9 ++++++++-

 1 file changed, 8 insertions(+), 1 deletion(-)

(quoted diff) +0 -0

b/drivers/thermal/intel_powerclamp.c
index f0bad48..c82b41f 100644

drivers/thermal/intel_powerclamp.c +0 -0

@@ -694,9 +694,16 @@ static int powerclamp_set_cur_state(struct

thermal_cooling_device *cdev,
.set_cur_state = powerclamp_set_cur_state,
};

+static const struct x86_cpu_id __initconst intel_powerclamp_ids[] = {
+ { X86_VENDOR_INTEL, X86_FAMILY_ANY, X86_MODEL_ANY,
X86_FEATURE_MWAIT },
+ {}
+};
+MODULE_DEVICE_TABLE(x86cpu, intel_powerclamp_ids);
+
static int __init powerclamp_probe(void)
{
- if (!boot_cpu_has(X86_FEATURE_MWAIT)) {
+

+       if (!x86_match_cpu(intel_powerclamp_ids)) {
                pr_err("CPU does not support MWAIT");
                return -ENODEV;
        }

Quoted 53 lines

------------------
From: Eric Ernst <[email protected]>
commit 3105f234e0aba43e44e277c20f9b32ee8add43d4 upstream.
Initial logic for checking CPU match resulted in OR of CPU features rather than the intended AND.
Updated to use boot_cpu_has macro rather than x86_match_cpu.
In addition, MWAIT is the only required CPU feature for idle injection to work. Drop other feature requirements since they are only needed for optimal efficiency.
Signed-off-by Eric Ernst <[email protected]>
Acked-by Jacob Pan <[email protected]>
Signed-off-by Zhang Rui <[email protected]>
Signed-off-by Greg Kroah-Hartman <[email protected]>
---
 drivers/thermal/intel_powerclamp.c |   14 ++------------
 1 file changed, 2 insertions(+), 12 deletions(-)
drivers/thermal/intel_powerclamp.c +0 ~~-11~~
@@ -669,20 +669,10 @@ static struct thermal_cooling_device_ops
 	.set_cur_state = powerclamp_set_cur_state,
 };
 
-static const struct x86_cpu_id intel_powerclamp_ids[] __initconst = {
-	{ X86_VENDOR_INTEL, X86_FAMILY_ANY, X86_MODEL_ANY,
 X86_FEATURE_MWAIT },
-	{ X86_VENDOR_INTEL, X86_FAMILY_ANY, X86_MODEL_ANY,
 X86_FEATURE_ARAT },
-	{ X86_VENDOR_INTEL, X86_FAMILY_ANY, X86_MODEL_ANY,
 X86_FEATURE_NONSTOP_TSC },
-	{ X86_VENDOR_INTEL, X86_FAMILY_ANY, X86_MODEL_ANY,
 X86_FEATURE_CONSTANT_TSC},
-	{}
-};
-MODULE_DEVICE_TABLE(x86cpu, intel_powerclamp_ids);
-
 static int __init powerclamp_probe(void)
 {
-	if (!x86_match_cpu(intel_powerclamp_ids)) {
-		pr_err("Intel powerclamp does not run on family %d
model %d\n",
drivers/thermal/intel_powerclamp.c +0 -1
-				boot_cpu_data.x86,
boot_cpu_data.x86_model);

drivers/thermal/intel_powerclamp.c

Quoted 4 lines

drivers/thermal/intel_powerclamp.c +2 -0

+	if (!boot_cpu_has(X86_FEATURE_MWAIT)) {
+		pr_err("CPU does not support MWAIT");
 		return -ENODEV;
 	}

[Jacob Pan]

Greg Kroah-Hartman

author maintainer

2016-11-09 11:06 UTC #23 lore raw

PATCH 23/138 KEYS: Fix short sprintf buffer in /proc/keys show function

4.8-stable review patch. If anyone has any objections, please let me know.

------------------

From: David Howells <[email protected]>

commit 03dab869b7b239c4e013ec82aea22e181e441cfc upstream.

This fixes CVE-2016-7042.

Fix a short sprintf buffer in proc_keys_show(). If the gcc stack protector is turned on, this can cause a panic due to stack corruption.

The problem is that xbuf[] is not big enough to hold a 64-bit timeout rendered as weeks:

	(gdb) p 0xffffffffffffffffULL/(60*60*24*7)
	$2 = 30500568904943

That's 14 chars plus NUL, not 11 chars plus NUL.

Expand the buffer to 16 chars.

I think the unpatched code apparently works if the stack-protector is not enabled because on a 32-bit machine the buffer won't be overflowed and on a 64-bit machine there's a 64-bit aligned pointer at one side and an int that isn't checked again on the other side.

The panic incurred looks something like:

Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: ffffffff81352ebe
CPU: 0 PID: 1692 Comm: reproducer Not tainted 4.7.2-201.fc24.x86_64 #1
Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011
 0000000000000086 00000000fbbd2679 ffff8800a044bc00 ffffffff813d941f
 ffffffff81a28d58 ffff8800a044bc98 ffff8800a044bc88 ffffffff811b2cb6
 ffff880000000010 ffff8800a044bc98 ffff8800a044bc30 00000000fbbd2679
Call Trace:
 [<ffffffff813d941f>] dump_stack+0x63/0x84
 [<ffffffff811b2cb6>] panic+0xde/0x22a
 [<ffffffff81352ebe>] ? proc_keys_show+0x3ce/0x3d0
 [<ffffffff8109f7f9>] __stack_chk_fail+0x19/0x30
 [<ffffffff81352ebe>] proc_keys_show+0x3ce/0x3d0
 [<ffffffff81350410>] ? key_validate+0x50/0x50
 [<ffffffff8134db30>] ? key_default_cmp+0x20/0x20
 [<ffffffff8126b31c>] seq_read+0x2cc/0x390
 [<ffffffff812b6b12>] proc_reg_read+0x42/0x70
 [<ffffffff81244fc7>] __vfs_read+0x37/0x150
 [<ffffffff81357020>] ? security_file_permission+0xa0/0xc0
 [<ffffffff81246156>] vfs_read+0x96/0x130
 [<ffffffff81247635>] SyS_read+0x55/0xc0
 [<ffffffff817eb872>] entry_SYSCALL_64_fastpath+0x1a/0xa4

Reported-by Ondrej Kozina <[email protected]>

Signed-off-by David Howells <[email protected]>

Tested-by Ondrej Kozina <[email protected]>

Signed-off-by James Morris <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 security/keys/proc.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

security/keys/proc.c +1 -1

@@ -181,7 +181,7 @@ static int proc_keys_show(struct seq_fil
 	struct timespec now;
 	unsigned long timo;
 	key_ref_t key_ref, skey_ref;
-	char xbuf[12];
+	char xbuf[16];
 	int rc;
 
 	struct keyring_search_context ctx = {

Greg Kroah-Hartman

author maintainer

2016-11-09 11:06 UTC #24 lore raw

PATCH 24/138 KEYS: Sort out big_key initialisation

4.8-stable review patch. If anyone has any objections, please let me know.

------------------

From: David Howells <[email protected]>

commit 7df3e59c3d1df4f87fe874c7956ef7a3d2f4d5fb upstream.

big_key has two separate initialisation functions, one that registers the key type and one that registers the crypto. If the key type fails to register, there's no problem if the crypto registers successfully because there's no way to reach the crypto except through the key type.

However, if the key type registers successfully but the crypto does not, big_key_rng and big_key_blkcipher may end up set to NULL - but the code neither checks for this nor unregisters the big key key type.

Furthermore, since the key type is registered before the crypto, it is theoretically possible for the kernel to try adding a big_key before the crypto is set up, leading to the same effect.

Fix this by merging big_key_crypto_init() and big_key_init() and calling the resulting function late. If they're going to be encrypted, we shouldn't be creating big_keys before we have the facilities to do the encryption available. The key type registration is also moved after the crypto initialisation.

The fix also includes message printing on failure.

If the big_key type isn't correctly set up, simply doing:

dd if=/dev/zero bs=4096 count=1 | keyctl padd big_key a @s

ought to cause an oops.

Fixes 13100a72f40f5748a04017e0ab3df4cf27c809ef ('Security: Keys: Big keys stored encrypted')

Signed-off-by David Howells <[email protected]>

cc Peter Hlavaty <[email protected]>

cc Kirill Marinushkin <[email protected]>

cc Artem Savkov <[email protected]>

Signed-off-by James Morris <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 security/keys/big_key.c |   59 ++++++++++++++++++++++++++----------------------
 1 file changed, 32 insertions(+), 27 deletions(-)

security/keys/big_key.c +32 ~~-27~~

@@ -9,6 +9,7 @@
  * 2 of the Licence, or (at your option) any later version.
  */
 
+#define pr_fmt(fmt) "big_key: "fmt
 #include <linux/init.h>
 #include <linux/seq_file.h>
 #include <linux/file.h>

@@ -341,44 +342,48 @@ error:
  */
 static int __init big_key_init(void)
 {
-	return register_key_type(&key_type_big_key);
-}
-
-/*
- * Initialize big_key crypto and RNG algorithms
- */
-static int __init big_key_crypto_init(void)
-{
-	int ret = -EINVAL;
+	struct crypto_skcipher *cipher;
+	struct crypto_rng *rng;
+	int ret;
 
-	/* init RNG */
-	big_key_rng = crypto_alloc_rng(big_key_rng_name, 0, 0);
-	if (IS_ERR(big_key_rng)) {
-		big_key_rng = NULL;
-		return -EFAULT;
+	rng = crypto_alloc_rng(big_key_rng_name, 0, 0);
+	if (IS_ERR(rng)) {
+		pr_err("Can't alloc rng: %ld\n", PTR_ERR(rng));
+		return PTR_ERR(rng);
 	}
 
+	big_key_rng = rng;
+
 	/* seed RNG */
-	ret = crypto_rng_reset(big_key_rng, NULL, crypto_rng_seedsize(big_key_rng));
-	if (ret)
-		goto error;
+	ret = crypto_rng_reset(rng, NULL, crypto_rng_seedsize(rng));
+	if (ret) {
+		pr_err("Can't reset rng: %d\n", ret);
+		goto error_rng;
+	}
 
 	/* init block cipher */
-	big_key_skcipher = crypto_alloc_skcipher(big_key_alg_name,
-						 0, CRYPTO_ALG_ASYNC);
-	if (IS_ERR(big_key_skcipher)) {
-		big_key_skcipher = NULL;
-		ret = -EFAULT;
-		goto error;
+	cipher = crypto_alloc_skcipher(big_key_alg_name, 0, CRYPTO_ALG_ASYNC);
+	if (IS_ERR(cipher)) {
+		ret = PTR_ERR(cipher);
+		pr_err("Can't alloc crypto: %d\n", ret);
+		goto error_rng;
+	}
+
+	big_key_skcipher = cipher;
+
+	ret = register_key_type(&key_type_big_key);
+	if (ret < 0) {
+		pr_err("Can't register type: %d\n", ret);
+		goto error_cipher;
 	}
 
 	return 0;
 
-error:
+error_cipher:
+	crypto_free_skcipher(big_key_skcipher);
+error_rng:
 	crypto_free_rng(big_key_rng);
-	big_key_rng = NULL;
 	return ret;
 }
 
-device_initcall(big_key_init);
-late_initcall(big_key_crypto_init);
+late_initcall(big_key_init);

Greg Kroah-Hartman

author maintainer

2016-11-09 11:07 UTC #25 lore raw

PATCH 25/138 security/keys: make BIG_KEYS dependent on stdrng.

4.8-stable review patch. If anyone has any objections, please let me know.

------------------

From: Artem Savkov <[email protected]>

commit 31e6ec4519c0fe0ee4a2f6ba3ab278e9506b9500 upstream.

Since BIG_KEYS can't be compiled as module it requires one of the "stdrng" providers to be compiled into kernel. Otherwise big_key_crypto_init() fails on crypto_alloc_rng step and next dereference of big_key_skcipher (e.g. in big_key_preparse()) results in a NULL pointer dereference.

Fixes 13100a72f40f5748a04017e0ab3df4cf27c809ef ('Security: Keys: Big keys stored encrypted')

Signed-off-by Artem Savkov <[email protected]>

Signed-off-by David Howells <[email protected]>

cc Stephan Mueller <[email protected]>

cc Kirill Marinushkin <[email protected]>

Signed-off-by James Morris <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 security/keys/Kconfig |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

security/keys/Kconfig +1 -1

@@ -41,7 +41,7 @@ config BIG_KEYS
 	bool "Large payload keys"
 	depends on KEYS
 	depends on TMPFS
-	select CRYPTO
+	depends on (CRYPTO_ANSI_CPRNG = y || CRYPTO_DRBG = y)
 	select CRYPTO_AES
 	select CRYPTO_ECB
 	select CRYPTO_RNG

Greg Kroah-Hartman

author maintainer

2016-11-09 11:07 UTC #26 lore raw

PATCH 26/138 device-dax: fix percpu_ref_exit ordering

4.8-stable review patch. If anyone has any objections, please let me know.

------------------

From: Dan Williams <[email protected]>

commit 52e73eb2872c9af6f382b2b22954ca8214397a4e upstream.

We need to wait until the percpu_ref is released before exit. Otherwise, we sometimes lose the race and trigger this new warning that was added in v4.9 (commit a67823c1ed10 "percpu-refcount: init ->confirm_switch member properly"):

 WARNING: CPU: 0 PID: 3629 at lib/percpu-refcount.c:107 percpu_ref_exit+0x51/0x60
 [..]
 Call Trace:
  [<ffffffff814bf093>] dump_stack+0x85/0xc2
  [<ffffffff810b15db>] __warn+0xcb/0xf0
  [<ffffffff810b170d>] warn_slowpath_null+0x1d/0x20
  [<ffffffff814d70c1>] percpu_ref_exit+0x51/0x60
  [<ffffffffa005706a>] dax_pmem_percpu_exit+0x1a/0x50 [dax_pmem]
  [<ffffffff81615f1f>] devm_action_release+0xf/0x20

Fixes ab68f2622136 ("/dev/dax, pmem: direct access to persistent memory")

Signed-off-by Dan Williams <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/dax/pmem.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/dax/pmem.c +1 -1

@@ -44,7 +44,6 @@ static void dax_pmem_percpu_exit(void *d
 
 	dev_dbg(dax_pmem->dev, "%s\n", __func__);
 	percpu_ref_exit(ref);
-	wait_for_completion(&dax_pmem->cmp);
 }
 
 static void dax_pmem_percpu_kill(void *data)

@@ -54,6 +53,7 @@ static void dax_pmem_percpu_kill(void *d
 
 	dev_dbg(dax_pmem->dev, "%s\n", __func__);
 	percpu_ref_kill(ref);
+	wait_for_completion(&dax_pmem->cmp);
 }
 
 static int dax_pmem_probe(struct device *dev)

Greg Kroah-Hartman

author maintainer

2016-11-09 11:07 UTC #27 lore raw

PATCH 27/138 ALSA: usb-audio: Add quirk for Syntek STK1160

4.8-stable review patch. If anyone has any objections, please let me know.

------------------

From: Marcel Hasler <[email protected]>

commit bdc3478f90cd4d2928197f36629d5cf93b64dbe9 upstream.

The stk1160 chip needs QUIRK_AUDIO_ALIGN_TRANSFER. This patch resolves the issue reported on the mailing list
(http://marc.info/?l=linux-sound&m=139223599126215&w=2) and also fixes bug 180071 (https://bugzilla.kernel.org/show_bug.cgi?id=180071).

Signed-off-by Marcel Hasler <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 sound/usb/quirks-table.h |   17 +++++++++++++++++
 1 file changed, 17 insertions(+)

sound/usb/quirks-table.h +17 -0

@@ -2907,6 +2907,23 @@ AU0828_DEVICE(0x2040, 0x7260, "Hauppauge
 AU0828_DEVICE(0x2040, 0x7213, "Hauppauge", "HVR-950Q"),
 AU0828_DEVICE(0x2040, 0x7270, "Hauppauge", "HVR-950Q"),
 
+/* Syntek STK1160 */
+{
+	.match_flags = USB_DEVICE_ID_MATCH_DEVICE |
+		       USB_DEVICE_ID_MATCH_INT_CLASS |
+		       USB_DEVICE_ID_MATCH_INT_SUBCLASS,
+	.idVendor = 0x05e1,
+	.idProduct = 0x0408,
+	.bInterfaceClass = USB_CLASS_AUDIO,
+	.bInterfaceSubClass = USB_SUBCLASS_AUDIOCONTROL,
+	.driver_info = (unsigned long) &(const struct snd_usb_audio_quirk) {
+		.vendor_name = "Syntek",
+		.product_name = "STK1160",
+		.ifnum = QUIRK_ANY_INTERFACE,
+		.type = QUIRK_AUDIO_ALIGN_TRANSFER
+	}
+},
+
 /* Digidesign Mbox */
 {
 	/* Thanks to Clemens Ladisch <[email protected]> */

Greg Kroah-Hartman

author maintainer

2016-11-09 11:07 UTC #28 lore raw

PATCH 28/138 ALSA: seq: Fix time account regression

4.8-stable review patch. If anyone has any objections, please let me know.

------------------

From: Takashi Iwai <[email protected]>

commit 9b50898ad96c793a8f7cde9d8f281596d752a7dd upstream.

The recent rewrite of the sequencer time accounting using timespec64 in the commit [3915bf294652: ALSA: seq_timer: use monotonic times internally] introduced a bad regression. Namely, the time reported back doesn't increase but goes back and forth.

The culprit was obvious: the delta is stored to the result (cur_time = delta), instead of adding the delta (cur_time += delta)!

Let's fix it.

Fixes 3915bf294652 ('ALSA: seq_timer: use monotonic times internally')

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=177571

Reported-by Yves Guillemot <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 sound/core/seq/seq_timer.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

sound/core/seq/seq_timer.c +2 -2

@@ -448,8 +448,8 @@ snd_seq_real_time_t snd_seq_timer_get_cu
 
 		ktime_get_ts64(&tm);
 		tm = timespec64_sub(tm, tmr->last_update);
-		cur_time.tv_nsec = tm.tv_nsec;
-		cur_time.tv_sec = tm.tv_sec;
+		cur_time.tv_nsec += tm.tv_nsec;
+		cur_time.tv_sec += tm.tv_sec;
 		snd_seq_sanity_real_time(&cur_time);
 	}
 	spin_unlock_irqrestore(&tmr->lock, flags);

Greg Kroah-Hartman

author maintainer

2016-11-09 11:07 UTC #29 lore raw

PATCH 29/138 ALSA: hda - allow 40 bit DMA mask for NVidia devices

4.8-stable review patch. If anyone has any objections, please let me know.

------------------

From: Ard Biesheuvel <[email protected]>

commit 3ab7511eafdd5c4f40d2832f09554478dfbea170 upstream.

Commit 49d9e77e72cf ("ALSA: hda - Fix system panic when DMA > 40 bits for Nvidia audio controllers") simply disabled any DMA exceeding 32 bits for NVidia devices, even though they are capable of performing DMA up to 40 bits. On some architectures (such as arm64), system memory is not guaranteed to be 32-bit addressable by PCI devices, and so this change prevents NVidia devices from working on platforms such as AMD Seattle.

Since the original commit already mentioned that up to 40 bits of DMA is supported, and given that the code has been updated in the meantime to support a 40 bit DMA mask on other devices, revert commit 49d9e77e72cf and explicitly set the DMA mask to 40 bits for NVidia devices.

Fixes 49d9e77e72cf ('ALSA: hda - Fix system panic when DMA > 40 bits...')

Signed-off-by Ard Biesheuvel <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 sound/pci/hda/hda_intel.c |    7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

sound/pci/hda/hda_intel.c +5 -2

@@ -340,8 +340,7 @@ enum {
 
 /* quirks for Nvidia */
 #define AZX_DCAPS_PRESET_NVIDIA \
-	(AZX_DCAPS_NO_MSI | /*AZX_DCAPS_ALIGN_BUFSIZE |*/ \
-	 AZX_DCAPS_NO_64BIT | AZX_DCAPS_CORBRP_SELF_CLEAR |\
+	(AZX_DCAPS_NO_MSI | AZX_DCAPS_CORBRP_SELF_CLEAR |\
 	 AZX_DCAPS_SNOOP_TYPE(NVIDIA))
 
 #define AZX_DCAPS_PRESET_CTHDA \

@@ -1699,6 +1698,10 @@ static int azx_first_init(struct azx *ch
 		}
 	}
 
+	/* NVidia hardware normally only supports up to 40 bits of DMA */
+	if (chip->pci->vendor == PCI_VENDOR_ID_NVIDIA)
+		dma_bits = 40;
+
 	/* disable 64bit DMA address on some devices */
 	if (chip->driver_caps & AZX_DCAPS_NO_64BIT) {
 		dev_dbg(card->dev, "Disabling 64bit DMA\n");

Greg Kroah-Hartman

author maintainer

2016-11-09 10:45 UTC #30 lore raw

PATCH 30/138 ALSA: hda - Adding a new group of pin cfg into ALC295 pin quirk table

4.8-stable review patch. If anyone has any objections, please let me know.

------------------

From: Hui Wang <[email protected]>

commit f771d5bb71d4df9573d12386400540516672208b upstream.

We have a new Dell laptop model which uses ALC295, the pin definition is different from the existing ones in the pin quirk table, to fix the headset mic detection and mic mute led's problem, we need to add the new pin defintion into the pin quirk table.

Signed-off-by Hui Wang <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 sound/pci/hda/patch_realtek.c |   10 +++++++---
 1 file changed, 7 insertions(+), 3 deletions(-)

sound/pci/hda/patch_realtek.c +7 -3

@@ -5809,8 +5809,6 @@ static const struct hda_model_fixup alc2
 #define ALC295_STANDARD_PINS \
 	{0x12, 0xb7a60130}, \
 	{0x14, 0x90170110}, \
-	{0x17, 0x21014020}, \
-	{0x18, 0x21a19030}, \
 	{0x21, 0x04211020}
 
 #define ALC298_STANDARD_PINS \

@@ -6037,7 +6035,13 @@ static const struct snd_hda_pin_quirk al
 		ALC292_STANDARD_PINS,
 		{0x13, 0x90a60140}),
 	SND_HDA_PIN_QUIRK(0x10ec0295, 0x1028, "Dell", ALC269_FIXUP_DELL1_MIC_NO_PRESENCE,
-		ALC295_STANDARD_PINS),
+		ALC295_STANDARD_PINS,
+		{0x17, 0x21014020},
+		{0x18, 0x21a19030}),
+	SND_HDA_PIN_QUIRK(0x10ec0295, 0x1028, "Dell", ALC269_FIXUP_DELL1_MIC_NO_PRESENCE,
+		ALC295_STANDARD_PINS,
+		{0x17, 0x21014040},
+		{0x18, 0x21a19050}),
 	SND_HDA_PIN_QUIRK(0x10ec0298, 0x1028, "Dell", ALC298_FIXUP_DELL1_MIC_NO_PRESENCE,
 		ALC298_STANDARD_PINS,
 		{0x17, 0x90170110}),

Greg Kroah-Hartman

author maintainer

2016-11-09 11:07 UTC #31 lore raw

PATCH 31/138 ALSA: hda - Fix surround output pins for ASRock B150M mobo

4.8-stable review patch. If anyone has any objections, please let me know.

------------------

From: Takashi Iwai <[email protected]>

commit 1a3f099101b85cc93d864eb030d97e7725c72ea7 upstream.

ASRock B150M Pro4/D3 mobo with ALC892 codec doesn't seem to provide proper pins for the surround outputs, hence we need to specify the pincfgs manually with a couple of other corrections.

Reported-and-tested-by Benjamin Valentin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 sound/pci/hda/patch_realtek.c |   12 ++++++++++++
 1 file changed, 12 insertions(+)

sound/pci/hda/patch_realtek.c +12 -0

@@ -6615,6 +6615,7 @@ enum {
 	ALC891_FIXUP_HEADSET_MODE,
 	ALC891_FIXUP_DELL_MIC_NO_PRESENCE,
 	ALC662_FIXUP_ACER_VERITON,
+	ALC892_FIXUP_ASROCK_MOBO,
 };
 
 static const struct hda_fixup alc662_fixups[] = {

@@ -6891,6 +6892,16 @@ static const struct hda_fixup alc662_fix
 			{ }
 		}
 	},
+	[ALC892_FIXUP_ASROCK_MOBO] = {
+		.type = HDA_FIXUP_PINS,
+		.v.pins = (const struct hda_pintbl[]) {
+			{ 0x15, 0x40f000f0 }, /* disabled */
+			{ 0x16, 0x40f000f0 }, /* disabled */
+			{ 0x18, 0x01014011 }, /* LO */
+			{ 0x1a, 0x01014012 }, /* LO */
+			{ }
+		}
+	},
 };
 
 static const struct snd_pci_quirk alc662_fixup_tbl[] = {

@@ -6928,6 +6939,7 @@ static const struct snd_pci_quirk alc662
 	SND_PCI_QUIRK(0x144d, 0xc051, "Samsung R720", ALC662_FIXUP_IDEAPAD),
 	SND_PCI_QUIRK(0x17aa, 0x38af, "Lenovo Ideapad Y550P", ALC662_FIXUP_IDEAPAD),
 	SND_PCI_QUIRK(0x17aa, 0x3a0d, "Lenovo Ideapad Y550", ALC662_FIXUP_IDEAPAD),
+	SND_PCI_QUIRK(0x1849, 0x5892, "ASRock B150M", ALC892_FIXUP_ASROCK_MOBO),
 	SND_PCI_QUIRK(0x19da, 0xa130, "Zotac Z68", ALC662_FIXUP_ZOTAC_Z68),
 	SND_PCI_QUIRK(0x1b0a, 0x01b8, "ACER Veriton", ALC662_FIXUP_ACER_VERITON),
 	SND_PCI_QUIRK(0x1b35, 0x2206, "CZC P10T", ALC662_FIXUP_CZC_P10T),

Greg Kroah-Hartman

author maintainer

2016-11-09 11:06 UTC #32 lore raw

PATCH 32/138 ALSA: hda - Fix headset mic detection problem for two Dell laptops

4.8-stable review patch. If anyone has any objections, please let me know.

------------------

From: Hui Wang <[email protected]>

commit 6aecd8715802d23dc6a0859b50c62d2b0a99de3a upstream.

They uses the codec ALC255, and have the different pin cfg definition from the ones in the existing pin quirk table. Now adding them into the table to fix the problem.

Signed-off-by Hui Wang <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 sound/pci/hda/patch_realtek.c |    8 ++++++++
 1 file changed, 8 insertions(+)

sound/pci/hda/patch_realtek.c +8 -0

@@ -5855,11 +5855,19 @@ static const struct snd_hda_pin_quirk al
 		{0x1b, 0x02011020},
 		{0x21, 0x0221101f}),
 	SND_HDA_PIN_QUIRK(0x10ec0255, 0x1028, "Dell", ALC255_FIXUP_DELL1_MIC_NO_PRESENCE,
+		{0x14, 0x90170110},
+		{0x1b, 0x01011020},
+		{0x21, 0x0221101f}),
+	SND_HDA_PIN_QUIRK(0x10ec0255, 0x1028, "Dell", ALC255_FIXUP_DELL1_MIC_NO_PRESENCE,
 		{0x14, 0x90170130},
 		{0x1b, 0x01014020},
 		{0x21, 0x0221103f}),
 	SND_HDA_PIN_QUIRK(0x10ec0255, 0x1028, "Dell", ALC255_FIXUP_DELL1_MIC_NO_PRESENCE,
 		{0x14, 0x90170130},
+		{0x1b, 0x01011020},
+		{0x21, 0x0221103f}),
+	SND_HDA_PIN_QUIRK(0x10ec0255, 0x1028, "Dell", ALC255_FIXUP_DELL1_MIC_NO_PRESENCE,
+		{0x14, 0x90170130},
 		{0x1b, 0x02011020},
 		{0x21, 0x0221103f}),
 	SND_HDA_PIN_QUIRK(0x10ec0255, 0x1028, "Dell", ALC255_FIXUP_DELL1_MIC_NO_PRESENCE,

Greg Kroah-Hartman

author maintainer

2016-11-09 11:06 UTC #33 lore raw

PATCH 35/138 cxl: Fix leaking pid refs in some error paths

4.8-stable review patch. If anyone has any objections, please let me know.

------------------

From: Vaibhav Jain <[email protected]>

commit a05b82d5149dfeef05254a11c3636a89a854520a upstream.

In some error paths in functions cxl_start_context and afu_ioctl_start_work pid references to the current & group-leader tasks can leak after they are taken. This patch fixes these error paths to release these pid references before exiting the error path.

Fixes 7b8ad495d592 ("cxl: Fix DSI misses when the context owning task exits")

Reviewed-by Andrew Donnellan <[email protected]>

Reported-by Frederic Barrat <[email protected]>

Signed-off-by Vaibhav Jain <[email protected]>

Acked-by Frederic Barrat <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/misc/cxl/api.c  |    2 ++
 drivers/misc/cxl/file.c |   22 +++++++++++++---------
 2 files changed, 15 insertions(+), 9 deletions(-)

drivers/misc/cxl/api.c +2 -0

@@ -247,7 +247,9 @@ int cxl_start_context(struct cxl_context
 	cxl_ctx_get();
 
 	if ((rc = cxl_ops->attach_process(ctx, kernel, wed, 0))) {
+		put_pid(ctx->glpid);
 		put_pid(ctx->pid);
+		ctx->glpid = ctx->pid = NULL;
 		cxl_adapter_context_put(ctx->afu->adapter);
 		cxl_ctx_put();
 		goto out;

drivers/misc/cxl/file.c +13 -9

@@ -194,6 +194,16 @@ static long afu_ioctl_start_work(struct
 	ctx->mmio_err_ff = !!(work.flags & CXL_START_WORK_ERR_FF);
 
 	/*
+	 * Increment the mapped context count for adapter. This also checks
+	 * if adapter_context_lock is taken.
+	 */
+	rc = cxl_adapter_context_get(ctx->afu->adapter);
+	if (rc) {
+		afu_release_irqs(ctx, ctx);
+		goto out;
+	}
+
+	/*
 	 * We grab the PID here and not in the file open to allow for the case
 	 * where a process (master, some daemon, etc) has opened the chardev on
 	 * behalf of another process, so the AFU's mm gets bound to the process

@@ -205,15 +215,6 @@ static long afu_ioctl_start_work(struct
 	ctx->pid = get_task_pid(current, PIDTYPE_PID);
 	ctx->glpid = get_task_pid(current->group_leader, PIDTYPE_PID);
 
-	/*
-	 * Increment the mapped context count for adapter. This also checks
-	 * if adapter_context_lock is taken.
-	 */
-	rc = cxl_adapter_context_get(ctx->afu->adapter);
-	if (rc) {
-		afu_release_irqs(ctx, ctx);
-		goto out;
-	}
 
 	trace_cxl_attach(ctx, work.work_element_descriptor, work.num_interrupts, amr);

@@ -221,6 +222,9 @@ static long afu_ioctl_start_work(struct
 							amr))) {
 		afu_release_irqs(ctx, ctx);
 		cxl_adapter_context_put(ctx->afu->adapter);
+		put_pid(ctx->glpid);
+		put_pid(ctx->pid);
+		ctx->glpid = ctx->pid = NULL;
 		goto out;
 	}

Greg Kroah-Hartman

author maintainer

2016-11-09 10:45 UTC #34 lore raw

PATCH 36/138 btrfs: fix races on root_log_ctx lists

4.8-stable review patch. If anyone has any objections, please let me know.

------------------

From: Chris Mason <[email protected]>

commit 570dd45042a7c8a7aba1ee029c5dd0f5ccf41b9b upstream.

btrfs_remove_all_log_ctxs takes a shortcut where it avoids walking the list because it knows all of the waiters are patiently waiting for the commit to finish.

But, there's a small race where btrfs_sync_log can remove itself from the list if it finds a log commit is already done. Also, it uses list_del_init() to remove itself from the list, but there's no way to know if btrfs_remove_all_log_ctxs has already run, so we don't know for sure if it is safe to call list_del_init().

This gets rid of all the shortcuts for btrfs_remove_all_log_ctxs(), and just calls it with the proper locking.

This is part two of the corruption fixed by cbd60aa7cd1. I should have done this in the first place, but convinced myself the optimizations were safe. A 12 hour run of dbench 2048 will eventually trigger a list debug WARN_ON for the list_del_init() in btrfs_sync_log().

Fixes d1433debe7f4346cf9fc0dafc71c3137d2a97bc4

Reported-by Dave Jones <[email protected]>

Signed-off-by Chris Mason <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 fs/btrfs/tree-log.c |   20 ++++++--------------
 1 file changed, 6 insertions(+), 14 deletions(-)

fs/btrfs/tree-log.c +6 ~~-14~~

@@ -2713,14 +2713,12 @@ static inline void btrfs_remove_all_log_
 					     int index, int error)
 {
 	struct btrfs_log_ctx *ctx;
+	struct btrfs_log_ctx *safe;
 
-	if (!error) {
-		INIT_LIST_HEAD(&root->log_ctxs[index]);
-		return;
-	}
-
-	list_for_each_entry(ctx, &root->log_ctxs[index], list)
+	list_for_each_entry_safe(ctx, safe, &root->log_ctxs[index], list) {
+		list_del_init(&ctx->list);
 		ctx->log_ret = error;
+	}
 
 	INIT_LIST_HEAD(&root->log_ctxs[index]);
 }

@@ -2961,13 +2959,9 @@ int btrfs_sync_log(struct btrfs_trans_ha
 	mutex_unlock(&root->log_mutex);
 
 out_wake_log_root:
-	/*
-	 * We needn't get log_mutex here because we are sure all
-	 * the other tasks are blocked.
-	 */
+	mutex_lock(&log_root_tree->log_mutex);
 	btrfs_remove_all_log_ctxs(log_root_tree, index2, ret);
 
-	mutex_lock(&log_root_tree->log_mutex);
 	log_root_tree->log_transid_committed++;
 	atomic_set(&log_root_tree->log_commit[index2], 0);
 	mutex_unlock(&log_root_tree->log_mutex);

@@ -2978,10 +2972,8 @@ out_wake_log_root:
 	if (waitqueue_active(&log_root_tree->log_commit_wait[index2]))
 		wake_up(&log_root_tree->log_commit_wait[index2]);
 out:
-	/* See above. */
-	btrfs_remove_all_log_ctxs(root, index1, ret);
-
 	mutex_lock(&root->log_mutex);
+	btrfs_remove_all_log_ctxs(root, index1, ret);
 	root->log_transid_committed++;
 	atomic_set(&root->log_commit[index1], 0);
 	mutex_unlock(&root->log_mutex);

Greg Kroah-Hartman

author maintainer

2016-11-09 11:06 UTC #35 lore raw

PATCH 37/138 powerpc: Convert cmp to cmpd in idle enter sequence

4.8-stable review patch. If anyone has any objections, please let me know.

------------------

From: Segher Boessenkool <[email protected]>

commit 80f23935cadb1c654e81951f5a8b7ceae0acc1b4 upstream.

PowerPC's "cmp" instruction has four operands. Normally people write "cmpw" or "cmpd" for the second cmp operand 0 or 1. But, frequently people forget, and write "cmp" with just three operands.

With older binutils this is silently accepted as if this was "cmpw", while often "cmpd" is wanted. With newer binutils GAS will complain about this for 64-bit code. For 32-bit code it still silently assumes "cmpw" is what is meant.

In this instance the code comes directly from ISA v2.07, including the cmp, but cmpd is correct. Backport to stable so that new toolchains can build old kernels.

Fixes 948cf67c4726 ("powerpc: Add NAP mode support on Power7 in HV mode")

Reviewed-by Vaidyanathan Srinivasan <[email protected]>

Signed-off-by Segher Boessenkool <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 arch/powerpc/include/asm/cpuidle.h |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

arch/powerpc/include/asm/cpuidle.h +1 -1

@@ -26,7 +26,7 @@ extern u64 pnv_first_deep_stop_state;
 	std	r0,0(r1);					\
 	ptesync;						\
 	ld	r0,0(r1);					\
-1:	cmp	cr0,r0,r0;					\
+1:	cmpd	cr0,r0,r0;					\
 	bne	1b;						\
 	IDLE_INST;						\
 	b	.

Greg Kroah-Hartman

author maintainer

2016-11-09 10:45 UTC #36 lore raw

PATCH 38/138 powerpc/mm/radix: Use tlbiel only if we ever ran on the current cpu

4.8-stable review patch. If anyone has any objections, please let me know.

------------------

From: Aneesh Kumar K.V <[email protected]>

commit bd77c4498616e27d5725b5959d880ce2272fefa9 upstream.

Before this patch, we used tlbiel, if we ever ran only on this core. That was mostly derived from the nohash usage of the same. But is incorrect, the ISA 3.0 clarifies tlbiel such that:

"All TLB entries that have all of the following properties are made invalid on the thread executing the tlbiel instruction"

ie. tlbiel only invalidates TLB entries on the current thread. So if the mm has been used on any other thread (aka. cpu) then we must broadcast the invalidate.

This bug could lead to invalid TLB entries if a program runs on multiple threads of a core.

Hence use tlbiel, if we only ever ran on only the current cpu.

Fixes 1a472c9dba6b ("powerpc/mm/radix: Add tlbflush routines")

Signed-off-by Aneesh Kumar K.V <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 arch/powerpc/include/asm/tlb.h |   12 ++++++++++++
 arch/powerpc/mm/tlb-radix.c    |    8 ++++----
 2 files changed, 16 insertions(+), 4 deletions(-)

arch/powerpc/include/asm/tlb.h +12 -0

@@ -52,11 +52,23 @@ static inline int mm_is_core_local(struc
 	return cpumask_subset(mm_cpumask(mm),
 			      topology_sibling_cpumask(smp_processor_id()));
 }
+
+static inline int mm_is_thread_local(struct mm_struct *mm)
+{
+	return cpumask_equal(mm_cpumask(mm),
+			      cpumask_of(smp_processor_id()));
+}
+
 #else
 static inline int mm_is_core_local(struct mm_struct *mm)
 {
 	return 1;
 }
+
+static inline int mm_is_thread_local(struct mm_struct *mm)
+{
+	return 1;
+}
 #endif
 
 #endif /* __KERNEL__ */

arch/powerpc/mm/tlb-radix.c +4 -4

@@ -175,7 +175,7 @@ void radix__flush_tlb_mm(struct mm_struc
 	if (unlikely(pid == MMU_NO_CONTEXT))
 		goto no_context;
 
-	if (!mm_is_core_local(mm)) {
+	if (!mm_is_thread_local(mm)) {
 		int lock_tlbie = !mmu_has_feature(MMU_FTR_LOCKLESS_TLBIE);
 
 		if (lock_tlbie)

@@ -201,7 +201,7 @@ void radix__flush_tlb_pwc(struct mmu_gat
 	if (unlikely(pid == MMU_NO_CONTEXT))
 		goto no_context;
 
-	if (!mm_is_core_local(mm)) {
+	if (!mm_is_thread_local(mm)) {
 		int lock_tlbie = !mmu_has_feature(MMU_FTR_LOCKLESS_TLBIE);
 
 		if (lock_tlbie)

@@ -226,7 +226,7 @@ void radix__flush_tlb_page_psize(struct
 	pid = mm ? mm->context.id : 0;
 	if (unlikely(pid == MMU_NO_CONTEXT))
 		goto bail;
-	if (!mm_is_core_local(mm)) {
+	if (!mm_is_thread_local(mm)) {
 		int lock_tlbie = !mmu_has_feature(MMU_FTR_LOCKLESS_TLBIE);
 
 		if (lock_tlbie)

@@ -321,7 +321,7 @@ void radix__flush_tlb_range_psize(struct
 {
 	unsigned long pid;
 	unsigned long addr;
-	int local = mm_is_core_local(mm);
+	int local = mm_is_thread_local(mm);
 	unsigned long ap = mmu_get_ap(psize);
 	int lock_tlbie = !mmu_has_feature(MMU_FTR_LOCKLESS_TLBIE);
 	unsigned long page_size = 1UL << mmu_psize_defs[psize].shift;

Greg Kroah-Hartman

author maintainer

2016-11-09 10:45 UTC #37 lore raw

PATCH 39/138 powerpc/64: Re-fix race condition between going idle and entering guest

4.8-stable review patch. If anyone has any objections, please let me know.

------------------

From: Paul Mackerras <[email protected]>

commit 56c46222af0d09149fadec2a3ce9d4889de01cc6 upstream.

Commit 8117ac6a6c2f ("powerpc/powernv: Switch off MMU before entering nap/sleep/rvwinkle mode", 2014-12-10) fixed a race condition where one thread entering a KVM guest could switch the MMU context to the guest while another thread was still in host kernel context with the MMU on. That commit moved the point where a thread entering a power-saving mode set its kvm_hstate.hwthread_state field in its PACA to KVM_HWTHREAD_IN_IDLE from a point where the MMU was on to after the MMU had been switched off. That commit also added a comment explaining that we have to switch to real mode before setting hwthread_state to avoid this race.

Nevertheless, commit 4eae2c9ae54a ("powerpc/powernv: Make pnv_powersave_common more generic", 2016-07-08) subsequently moved the setting of hwthread_state back to a point where the MMU is on, thus reintroducing the race, despite the comment saying that this should not be done being included in full in the context lines of the patch that did it.

This fixes the race again and adds a bigger and shoutier comment explaining the potential race condition.

Fixes 4eae2c9ae54a ("powerpc/powernv: Make pnv_powersave_common more generic")

Signed-off-by Paul Mackerras <[email protected]>

Reviewed-by Shreyas B. Prabhu <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 arch/powerpc/kernel/idle_book3s.S |   32 ++++++++++++++++++++++++++------
 1 file changed, 26 insertions(+), 6 deletions(-)

arch/powerpc/kernel/idle_book3s.S +26 -6

@@ -163,12 +163,6 @@ _GLOBAL(pnv_powersave_common)
 	std	r9,_MSR(r1)
 	std	r1,PACAR1(r13)
 
-#ifdef CONFIG_KVM_BOOK3S_HV_POSSIBLE
-	/* Tell KVM we're entering idle */
-	li	r4,KVM_HWTHREAD_IN_IDLE
-	stb	r4,HSTATE_HWTHREAD_STATE(r13)
-#endif
-
 	/*
 	 * Go to real mode to do the nap, as required by the architecture.
 	 * Also, we need to be in real mode before setting hwthread_state,

@@ -185,6 +179,26 @@ _GLOBAL(pnv_powersave_common)
 
 	.globl pnv_enter_arch207_idle_mode
 pnv_enter_arch207_idle_mode:
+#ifdef CONFIG_KVM_BOOK3S_HV_POSSIBLE
+	/* Tell KVM we're entering idle */
+	li	r4,KVM_HWTHREAD_IN_IDLE
+	/******************************************************/
+	/*  N O T E   W E L L    ! ! !    N O T E   W E L L   */
+	/* The following store to HSTATE_HWTHREAD_STATE(r13)  */
+	/* MUST occur in real mode, i.e. with the MMU off,    */
+	/* and the MMU must stay off until we clear this flag */
+	/* and test HSTATE_HWTHREAD_REQ(r13) in the system    */
+	/* reset interrupt vector in exceptions-64s.S.        */
+	/* The reason is that another thread can switch the   */
+	/* MMU to a guest context whenever this flag is set   */
+	/* to KVM_HWTHREAD_IN_IDLE, and if the MMU was on,    */
+	/* that would potentially cause this thread to start  */
+	/* executing instructions from guest memory in        */
+	/* hypervisor mode, leading to a host crash or data   */
+	/* corruption, or worse.                              */
+	/******************************************************/
+	stb	r4,HSTATE_HWTHREAD_STATE(r13)
+#endif
 	stb	r3,PACA_THREAD_IDLE_STATE(r13)
 	cmpwi	cr3,r3,PNV_THREAD_SLEEP
 	bge	cr3,2f

@@ -250,6 +264,12 @@ enter_winkle:
  * r3 - requested stop state
  */
 power_enter_stop:
+#ifdef CONFIG_KVM_BOOK3S_HV_POSSIBLE
+	/* Tell KVM we're entering idle */
+	li	r4,KVM_HWTHREAD_IN_IDLE
+	/* DO THIS IN REAL MODE!  See comment above. */
+	stb	r4,HSTATE_HWTHREAD_STATE(r13)
+#endif
 /*
  * Check if the requested state is a deep idle state.
  */

Greg Kroah-Hartman

author maintainer

2016-11-09 10:45 UTC #38 lore raw

PATCH 40/138 powerpc/64: Fix race condition in setting lock bit in idle/wakeup code

4.8-stable review patch. If anyone has any objections, please let me know.

------------------

From: Paul Mackerras <[email protected]>

commit 09b7e37b18eecc1e347f4b1a3bc863f32801f634 upstream.

This fixes a race condition where one thread that is entering or leaving a power-saving state can inadvertently ignore the lock bit that was set by another thread, and potentially also clear it. The core_idle_lock_held function is called when the lock bit is seen to be set. It polls the lock bit until it is clear, then does a lwarx to load the word containing the lock bit and thread idle bits so it can be updated. However, it is possible that the value loaded with the lwarx has the lock bit set, even though an immediately preceding lwz loaded a value with the lock bit clear. If this happens then we go ahead and update the word despite the lock bit being set, and when called from pnv_enter_arch207_idle_mode, we will subsequently clear the lock bit.

No identifiable misbehaviour has been attributed to this race.

This fixes it by checking the lock bit in the value loaded by the lwarx. If it is set then we just go back and keep on polling.

Fixes b32aadc1a8ed ("powerpc/powernv: Fix race in updating core_idle_state")

Signed-off-by Paul Mackerras <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 arch/powerpc/kernel/idle_book3s.S |    3 +++
 1 file changed, 3 insertions(+)

arch/powerpc/kernel/idle_book3s.S +3 -0

@@ -90,6 +90,7 @@ ALT_FTR_SECTION_END_IFSET(CPU_FTR_ARCH_3
  * Threads will spin in HMT_LOW until the lock bit is cleared.
  * r14 - pointer to core_idle_state
  * r15 - used to load contents of core_idle_state
+ * r9  - used as a temporary variable
  */
 
 core_idle_lock_held:

@@ -99,6 +100,8 @@ core_idle_lock_held:
 	bne	3b
 	HMT_MEDIUM
 	lwarx	r15,0,r14
+	andi.	r9,r15,PNV_CORE_IDLE_LOCK_BIT
+	bne	core_idle_lock_held
 	blr
 
 /*

Greg Kroah-Hartman

author maintainer

2016-11-09 10:45 UTC #39 lore raw

PATCH 41/138 x86/microcode/AMD: Fix more fallout from CONFIG_RANDOMIZE_MEMORY=y

4.8-stable review patch. If anyone has any objections, please let me know.

------------------

From: Borislav Petkov <[email protected]>

commit 1c27f646b18fb56308dff82784ca61951bad0b48 upstream.

We needed the physical address of the container in order to compute the offset within the relocated ramdisk. And we did this by doing __pa() on the virtual address.

However, __pa() does checks whether the physical address is within PAGE_OFFSET and __START_KERNEL_map - see __phys_addr() - which fail if we have CONFIG_RANDOMIZE_MEMORY enabled: we feed a virtual address which *doesn't* have the randomization offset into a function which uses PAGE_OFFSET which *does* have that offset.

This makes this check fire:

	VIRTUAL_BUG_ON((x > y) || !phys_addr_valid(x));
			^^^^^^

due to the randomization offset.

The fix is as simple as using __pa_nodebug() because we do that randomization offset accounting later in that function ourselves.

Reported-by Bob Peterson <[email protected]>

Tested-by Bob Peterson <[email protected]>

Signed-off-by Borislav Petkov <[email protected]>

Cc Andreas Gruenbacher <[email protected]>

Cc Andy Lutomirski <[email protected]>

Cc Borislav Petkov <[email protected]>

Cc Brian Gerst <[email protected]>

Cc Denys Vlasenko <[email protected]>

Cc H. Peter Anvin <[email protected]>

Cc Josh Poimboeuf <[email protected]>

Cc Linus Torvalds <[email protected]>

Cc Mel Gorman <[email protected]>

Cc Peter Zijlstra <[email protected]>

Cc Steven Whitehouse <[email protected]>

Cc Thomas Gleixner <[email protected]>

Cc linux-mm <[email protected]>

Link http://lkml.kernel.org/r/[email protected] open here

Signed-off-by Ingo Molnar <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 arch/x86/kernel/cpu/microcode/amd.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

arch/x86/kernel/cpu/microcode/amd.c +1 -1

@@ -429,7 +429,7 @@ int __init save_microcode_in_initrd_amd(
 	 * We need the physical address of the container for both bitness since
 	 * boot_params.hdr.ramdisk_image is a physical address.
 	 */
-	cont    = __pa(container);
+	cont    = __pa_nodebug(container);
 	cont_va = container;
 #endif

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

Greg Kroah-Hartman

author maintainer

2016-11-09 10:45 UTC #40 lore raw

PATCH 42/138 timers: Prevent base clock rewind when forwarding clock

4.8-stable review patch. If anyone has any objections, please let me know.

------------------

From: Thomas Gleixner <[email protected]>

commit 041ad7bc758db259bb960ef795197dd14aab19a6 upstream.

Ashton and Michael reported, that kernel versions 4.8 and later suffer from USB timeouts which are caused by the timer wheel rework.

This is caused by a bug in the base clock forwarding mechanism, which leads to timers expiring early. The scenario which leads to this is:

run_timers()

  while (jiffies >= base->clk) {
    collect_expired_timers();
    base->clk++;
    expire_timers();

}

So base->clk = jiffies + 1. Now the cpu goes idle:

idle()
get_next_timer_interrupt()

    nextevt = __next_time_interrupt();
    if (time_after(nextevt, base->clk))
       	base->clk = jiffies;

jiffies has not advanced since run_timers(), so this assignment effectively decrements base->clk by one.

base->clk is the index into the timer wheel arrays. So let's assume the following state after the base->clk increment in run_timers():

jiffies = 0
base->clk = 1

A timer gets enqueued with an expiry delta of 63 ticks (which is the case with the USB timeout and HZ=250) so the resulting bucket index is:

base->clk + delta = 1 + 63 = 64

The timer goes into the first wheel level. The array size is 64 so it ends up in bucket 0, which is correct as it takes 63 ticks to advance base->clk to index into bucket 0 again.

If the cpu goes idle before jiffies advance, then the bug in the forwarding mechanism sets base->clk back to 0, so the next invocation of run_timers() at the next tick will index into bucket 0 and therefore expire the timer 62 ticks too early.

Instead of blindly setting base->clk to jiffies we must make the forwarding conditional on jiffies > base->clk, but we cannot use jiffies for this as we might run into the following issue:

  if (time_after(jiffies, base->clk) {
    if (time_after(nextevt, base->clk))
       base->clk = jiffies;

jiffies can increment between the check and the assigment far enough to advance beyond nextevt. So we need to use a stable value for checking.

get_next_timer_interrupt() has the basej argument which is the jiffies value snapshot taken in the calling code. So we can just that.

Thanks to Ashton for bisecting and providing trace data!

Fixes a683f390b93f ("timers: Forward the wheel clock whenever possible")

Reported-by Ashton Holmes <[email protected]>

Reported-by Michael Thayer <[email protected]>

Cc Michal Necasek <[email protected]>

Cc Peter Zijlstra <[email protected]>

Link http://lkml.kernel.org/r/[email protected] open here

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 kernel/time/timer.c |   14 +++++++++-----
 1 file changed, 9 insertions(+), 5 deletions(-)

kernel/time/timer.c +9 -5

@@ -1510,12 +1510,16 @@ u64 get_next_timer_interrupt(unsigned lo
 	is_max_delta = (nextevt == base->clk + NEXT_TIMER_MAX_DELTA);
 	base->next_expiry = nextevt;
 	/*
-	 * We have a fresh next event. Check whether we can forward the base:
+	 * We have a fresh next event. Check whether we can forward the
+	 * base. We can only do that when @basej is past base->clk
+	 * otherwise we might rewind base->clk.
 	 */
-	if (time_after(nextevt, jiffies))
-		base->clk = jiffies;
-	else if (time_after(nextevt, base->clk))
-		base->clk = nextevt;
+	if (time_after(basej, base->clk)) {
+		if (time_after(nextevt, basej))
+			base->clk = basej;
+		else if (time_after(nextevt, base->clk))
+			base->clk = nextevt;
+	}
 
 	if (time_before_eq(nextevt, basej)) {
 		expires = basem;

Greg Kroah-Hartman

author maintainer

2016-11-09 10:45 UTC #41 lore raw

PATCH 43/138 timers: Prevent base clock corruption when forwarding

4.8-stable review patch. If anyone has any objections, please let me know.

------------------

From: Thomas Gleixner <[email protected]>

commit 6bad6bccf2d717f652d37e63cf261eaa23466009 upstream.

When a timer is enqueued we try to forward the timer base clock. This mechanism has two issues:

1) Forwarding a remote base unlocked

The forwarding function is called from get_target_base() with the current timer base lock held. But if the new target base is a different base than the current base (can happen with NOHZ, sigh!) then the forwarding is done on an unlocked base. This can lead to corruption of base->clk.

Solution is simple: Invoke the forwarding after the target base is locked.

2) Possible corruption due to jiffies advancing

This is similar to the issue in get_net_timer_interrupt() which was fixed in the previous patch. jiffies can advance between check and assignement and therefore advancing base->clk beyond the next expiry value.

So we need to read jiffies into a local variable once and do the checks and assignment with the local copy.

Fixes a683f390b93f("timers: Forward the wheel clock whenever possible")

Reported-by Ashton Holmes <[email protected]>

Reported-by Michael Thayer <[email protected]>

Cc Michal Necasek <[email protected]>

Cc Peter Zijlstra <[email protected]>

Link http://lkml.kernel.org/r/[email protected] open here

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 kernel/time/timer.c |   23 ++++++++++-------------
 1 file changed, 10 insertions(+), 13 deletions(-)

kernel/time/timer.c +10 ~~-13~~

@@ -878,7 +878,7 @@ static inline struct timer_base *get_tim
 
 #ifdef CONFIG_NO_HZ_COMMON
 static inline struct timer_base *
-__get_target_base(struct timer_base *base, unsigned tflags)
+get_target_base(struct timer_base *base, unsigned tflags)
 {
 #ifdef CONFIG_SMP
 	if ((tflags & TIMER_PINNED) || !base->migration_enabled)

@@ -891,25 +891,27 @@ __get_target_base(struct timer_base *bas
 
 static inline void forward_timer_base(struct timer_base *base)
 {
+	unsigned long jnow = READ_ONCE(jiffies);
+
 	/*
 	 * We only forward the base when it's idle and we have a delta between
 	 * base clock and jiffies.
 	 */
-	if (!base->is_idle || (long) (jiffies - base->clk) < 2)
+	if (!base->is_idle || (long) (jnow - base->clk) < 2)
 		return;
 
 	/*
 	 * If the next expiry value is > jiffies, then we fast forward to
 	 * jiffies otherwise we forward to the next expiry value.
 	 */
-	if (time_after(base->next_expiry, jiffies))
-		base->clk = jiffies;
+	if (time_after(base->next_expiry, jnow))
+		base->clk = jnow;
 	else
 		base->clk = base->next_expiry;
 }
 #else
 static inline struct timer_base *
-__get_target_base(struct timer_base *base, unsigned tflags)
+get_target_base(struct timer_base *base, unsigned tflags)
 {
 	return get_timer_this_cpu_base(tflags);
 }

@@ -917,14 +919,6 @@ __get_target_base(struct timer_base *bas
 static inline void forward_timer_base(struct timer_base *base) { }
 #endif
 
-static inline struct timer_base *
-get_target_base(struct timer_base *base, unsigned tflags)
-{
-	struct timer_base *target = __get_target_base(base, tflags);
-
-	forward_timer_base(target);
-	return target;
-}
 
 /*
  * We are using hashed locking: Holding per_cpu(timer_bases[x]).lock means

@@ -1025,6 +1019,9 @@ __mod_timer(struct timer_list *timer, un
 		}
 	}
 
+	/* Try to forward a stale timer base clock */
+	forward_timer_base(base);
+
 	timer->expires = expires;
 	/*
 	 * If 'idx' was calculated above and the base time did not advance

Greg Kroah-Hartman

author maintainer

2016-11-09 11:06 UTC #42 lore raw

PATCH 44/138 timers: Plug locking race vs. timer migration

4.8-stable review patch. If anyone has any objections, please let me know.

------------------

From: Thomas Gleixner <[email protected]>

commit b831275a3553c32091222ac619cfddd73a5553fb upstream.

Linus noticed that lock_timer_base() lacks a READ_ONCE() for accessing the timer flags. As a consequence the compiler is allowed to reload the flags between the initial check for TIMER_MIGRATION and the following timer base computation and the spin lock of the base.

While this has not been observed (yet), we need to make sure that it never happens.

Fixes 0eeda71bc30d ("timer: Replace timer base by a cpu index")

Reported-by Linus Torvalds <[email protected]>

Link http://lkml.kernel.org/r/alpine.DEB.2.20.1610241711220.4983@nanos open here

Cc Andrew Morton <[email protected]>

Cc Peter Zijlstra <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 kernel/time/timer.c |    9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

kernel/time/timer.c +8 -1

@@ -937,7 +937,14 @@ static struct timer_base *lock_timer_bas
 {
 	for (;;) {
 		struct timer_base *base;
-		u32 tf = timer->flags;
+		u32 tf;
+
+		/*
+		 * We need to use READ_ONCE() here, otherwise the compiler
+		 * might re-read @tf between the check for TIMER_MIGRATING
+		 * and spin_lock().
+		 */
+		tf = READ_ONCE(timer->flags);
 
 		if (!(tf & TIMER_MIGRATING)) {
 			base = get_timer_base(tf);

Greg Kroah-Hartman

author maintainer

2016-11-09 11:06 UTC #43 lore raw

PATCH 45/138 timers: Lock base for same bucket optimization

4.8-stable review patch. If anyone has any objections, please let me know.

------------------

From: Thomas Gleixner <[email protected]>

commit 4da9152a4308dcbf611cde399c695c359fc9145f upstream.

Linus stumbled over the unlocked modification of the timer expiry value in mod_timer() which is an optimization for timers which stay in the same bucket - due to the bucket granularity - despite their expiry time getting updated.

The optimization itself still makes sense even if we take the lock, because in case that the bucket stays the same, we avoid the pointless queue/enqueue dance.

Make the check and the modification of timer->expires protected by the base lock and shuffle the remaining code around so we can keep the lock held when we actually have to requeue the timer to a different bucket.

Fixes f00c0afdfa62 ("timers: Implement optimization for same expiry time in mod_timer()")

Reported-by Linus Torvalds <[email protected]>

Link http://lkml.kernel.org/r/alpine.DEB.2.20.1610241711220.4983@nanos open here

Cc Andrew Morton <[email protected]>

Cc Peter Zijlstra <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 kernel/time/timer.c |   28 +++++++++++++++++-----------
 1 file changed, 17 insertions(+), 11 deletions(-)

kernel/time/timer.c +17 ~~-11~~

@@ -965,6 +965,8 @@ __mod_timer(struct timer_list *timer, un
 	unsigned long clk = 0, flags;
 	int ret = 0;
 
+	BUG_ON(!timer->function);
+
 	/*
 	 * This is a common optimization triggered by the networking code - if
 	 * the timer is re-modified to have the same timeout or ends up in the

@@ -973,13 +975,16 @@ __mod_timer(struct timer_list *timer, un
 	if (timer_pending(timer)) {
 		if (timer->expires == expires)
 			return 1;
+
 		/*
-		 * Take the current timer_jiffies of base, but without holding
-		 * the lock!
+		 * We lock timer base and calculate the bucket index right
+		 * here. If the timer ends up in the same bucket, then we
+		 * just update the expiry time and avoid the whole
+		 * dequeue/enqueue dance.
 		 */
-		base = get_timer_base(timer->flags);
-		clk = base->clk;
+		base = lock_timer_base(timer, &flags);
 
+		clk = base->clk;
 		idx = calc_wheel_index(expires, clk);
 
 		/*

@@ -989,14 +994,14 @@ __mod_timer(struct timer_list *timer, un
 		 */
 		if (idx == timer_get_idx(timer)) {
 			timer->expires = expires;
-			return 1;
+			ret = 1;
+			goto out_unlock;
 		}
+	} else {
+		base = lock_timer_base(timer, &flags);
 	}
 
 	timer_stats_timer_set_start_info(timer);
-	BUG_ON(!timer->function);
-
-	base = lock_timer_base(timer, &flags);
 
 	ret = detach_if_pending(timer, base, false);
 	if (!ret && pending_only)

@@ -1032,9 +1037,10 @@ __mod_timer(struct timer_list *timer, un
 	timer->expires = expires;
 	/*
 	 * If 'idx' was calculated above and the base time did not advance
-	 * between calculating 'idx' and taking the lock, only enqueue_timer()
-	 * and trigger_dyntick_cpu() is required. Otherwise we need to
-	 * (re)calculate the wheel index via internal_add_timer().
+	 * between calculating 'idx' and possibly switching the base, only
+	 * enqueue_timer() and trigger_dyntick_cpu() is required. Otherwise
+	 * we need to (re)calculate the wheel index via
+	 * internal_add_timer().
 	 */
 	if (idx != UINT_MAX && clk == base->clk) {
 		enqueue_timer(base, timer, idx);

Greg Kroah-Hartman

author maintainer

2016-11-09 10:45 UTC #44 lore raw

PATCH 46/138 ubifs: Abort readdir upon error

4.8-stable review patch. If anyone has any objections, please let me know.

------------------

From: Richard Weinberger <[email protected]>

commit c83ed4c9dbb358b9e7707486e167e940d48bfeed upstream.

If UBIFS is facing an error while walking a directory, it reports this error and ubifs_readdir() returns the error code. But the VFS readdir logic does not make the getdents system call fail in all cases. When the readdir cursor indicates that more entries are present, the system call will just return and the libc wrapper will try again since it also knows that more entries are present.
This causes the libc wrapper to busy loop for ever when a directory is corrupted on UBIFS.
A common approach do deal with corrupted directory entries is skipping them by setting the cursor to the next entry. On UBIFS this approach is not possible since we cannot compute the next directory entry cursor position without reading the current entry. So all we can do is setting the cursor to the "no more entries" position and make getdents exit.

Signed-off-by Richard Weinberger <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 fs/ubifs/dir.c |    8 +++-----
 1 file changed, 3 insertions(+), 5 deletions(-)

fs/ubifs/dir.c +3 -5

@@ -350,7 +350,7 @@ static unsigned int vfs_dent_type(uint8_
  */
 static int ubifs_readdir(struct file *file, struct dir_context *ctx)
 {
-	int err;
+	int err = 0;
 	struct qstr nm;
 	union ubifs_key key;
 	struct ubifs_dent_node *dent;

@@ -452,14 +452,12 @@ out:
 	kfree(file->private_data);
 	file->private_data = NULL;
 
-	if (err != -ENOENT) {
+	if (err != -ENOENT)
 		ubifs_err(c, "cannot find next direntry, error %d", err);
-		return err;
-	}
 
 	/* 2 is a special value indicating that there are no more direntries */
 	ctx->pos = 2;
-	return 0;
+	return err;
 }
 
 /* Free saved readdir() state when the directory is closed */

Greg Kroah-Hartman

author maintainer

2016-11-09 11:06 UTC #45 lore raw

PATCH 47/138 ubifs: Fix regression in ubifs_readdir()

4.8-stable review patch. If anyone has any objections, please let me know.

------------------

From: Richard Weinberger <[email protected]>

commit a00052a296e54205cf238c75bd98d17d5d02a6db upstream.

Commit c83ed4c9dbb35 ("ubifs: Abort readdir upon error") broke overlayfs support because the fix exposed an internal error code to VFS.

Reported-by Peter Rosin <[email protected]>

Tested-by Peter Rosin <[email protected]>

Reported-by Ralph Sennhauser <[email protected]>

Tested-by Ralph Sennhauser <[email protected]>

Fixes c83ed4c9dbb35 ("ubifs: Abort readdir upon error")

Signed-off-by Richard Weinberger <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 fs/ubifs/dir.c |    8 ++++++++
 1 file changed, 8 insertions(+)

fs/ubifs/dir.c +8 -0

@@ -454,6 +454,14 @@ out:
 
 	if (err != -ENOENT)
 		ubifs_err(c, "cannot find next direntry, error %d", err);
+	else
+		/*
+		 * -ENOENT is a non-fatal error in this context, the TNC uses
+		 * it to indicate that the cursor moved past the current directory
+		 * and readdir() has to stop.
+		 */
+		err = 0;
+
 
 	/* 2 is a special value indicating that there are no more direntries */
 	ctx->pos = 2;

Greg Kroah-Hartman

author maintainer

2016-11-09 11:06 UTC #46 lore raw

PATCH 48/138 mei: txe: dont clean an unprocessed interrupt cause.

4.8-stable review patch. If anyone has any objections, please let me know.

------------------

From: Alexander Usyskin <[email protected]>

commit 43605e293eb13c07acb546c14f407a271837af17 upstream.

SEC registers are not accessible when the TXE device is in low power state, hence the SEC interrupt cannot be processed if device is not awake.

In some rare cases entrance to low power state (aliveness off) and input ready bits can be signaled at the same time, resulting in communication stall as input ready won't be signaled again after waking up. To resolve this IPC_HHIER_SEC bit in HHISR_REG should not be cleaned if the interrupt is not processed.

Signed-off-by Alexander Usyskin <[email protected]>

Signed-off-by Tomas Winkler <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/misc/mei/hw-txe.c |    6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

drivers/misc/mei/hw-txe.c +4 -2

@@ -978,11 +978,13 @@ static bool mei_txe_check_and_ack_intrs(
 	hisr = mei_txe_br_reg_read(hw, HISR_REG);
 
 	aliveness = mei_txe_aliveness_get(dev);
-	if (hhisr & IPC_HHIER_SEC && aliveness)
+	if (hhisr & IPC_HHIER_SEC && aliveness) {
 		ipc_isr = mei_txe_sec_reg_read_silent(hw,
 				SEC_IPC_HOST_INT_STATUS_REG);
-	else
+	} else {
 		ipc_isr = 0;
+		hhisr &= ~IPC_HHIER_SEC;
+	}
 
 	generated = generated ||
 		(hisr & HISR_INT_STS_MSK) ||

Greg Kroah-Hartman

author maintainer

2016-11-09 11:06 UTC #47 lore raw

PATCH 49/138 usb: gadget: udc: atmel: fix endpoint name

4.8-stable review patch. If anyone has any objections, please let me know.

------------------

From: Alexandre Belloni <[email protected]>

commit bbe097f092b0d13e9736bd2794d0ab24547d0e5d upstream.

Since commit c32b5bcfa3c4 ("ARM: dts: at91: Fix USB endpoint nodes"), atmel_usba_udc fails with:

------------[ cut here ]------------
WARNING: CPU: 0 PID: 0 at include/linux/usb/gadget.h:405
ecm_do_notify+0x188/0x1a0
Modules linked in:
CPU: 0 PID: 0 Comm: swapper Not tainted 4.7.0+ #15
Hardware name: Atmel SAMA5
[<c010ccfc>] (unwind_backtrace) from [<c010a7ec>] (show_stack+0x10/0x14)
[<c010a7ec>] (show_stack) from [<c0115c10>] (__warn+0xe4/0xfc)
[<c0115c10>] (__warn) from [<c0115cd8>] (warn_slowpath_null+0x20/0x28)
[<c0115cd8>] (warn_slowpath_null) from [<c04377ac>] (ecm_do_notify+0x188/0x1a0)
[<c04377ac>] (ecm_do_notify) from [<c04379a4>] (ecm_set_alt+0x74/0x1ac)
[<c04379a4>] (ecm_set_alt) from [<c042f74c>] (composite_setup+0xfc0/0x19f8)
[<c042f74c>] (composite_setup) from [<c04356e8>] (usba_udc_irq+0x8f4/0xd9c)
[<c04356e8>] (usba_udc_irq) from [<c013ec9c>] (handle_irq_event_percpu+0x9c/0x158)
[<c013ec9c>] (handle_irq_event_percpu) from [<c013ed80>] (handle_irq_event+0x28/0x3c)
[<c013ed80>] (handle_irq_event) from [<c01416d4>] (handle_fasteoi_irq+0xa0/0x168)
[<c01416d4>] (handle_fasteoi_irq) from [<c013e3f8>] (generic_handle_irq+0x24/0x34)
[<c013e3f8>] (generic_handle_irq) from [<c013e640>] (__handle_domain_irq+0x54/0xa8)
[<c013e640>] (__handle_domain_irq) from [<c010b214>] (__irq_svc+0x54/0x70)
[<c010b214>] (__irq_svc) from [<c0107eb0>] (arch_cpu_idle+0x38/0x3c)
[<c0107eb0>] (arch_cpu_idle) from [<c0137300>] (cpu_startup_entry+0x9c/0xdc)
[<c0137300>] (cpu_startup_entry) from [<c0900c40>] (start_kernel+0x354/0x360)
[<c0900c40>] (start_kernel) from [<20008078>] (0x20008078)
---[ end trace e7cf9dcebf4815a6 ]---

Fixes c32b5bcfa3c4 ("ARM: dts: at91: Fix USB endpoint nodes")

Reported-by Richard Genoud <[email protected]>

Acked-by Nicolas Ferre <[email protected]>

Signed-off-by Alexandre Belloni <[email protected]>

Signed-off-by Felipe Balbi <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/usb/gadget/udc/atmel_usba_udc.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/usb/gadget/udc/atmel_usba_udc.c +1 -1

@@ -1978,7 +1978,7 @@ static struct usba_ep * atmel_udc_of_ini
 			dev_err(&pdev->dev, "of_probe: name error(%d)\n", ret);
 			goto err;
 		}
-		ep->ep.name = name;
+		ep->ep.name = kasprintf(GFP_KERNEL, "ep%d", ep->index);
 
 		ep->ep_regs = udc->regs + USBA_EPT_BASE(i);
 		ep->dma_regs = udc->regs + USBA_DMA_BASE(i);

Greg Kroah-Hartman

author maintainer

2016-11-09 11:07 UTC #48 lore raw

PATCH 51/138 USB: serial: fix potential NULL-dereference at probe

4.8-stable review patch. If anyone has any objections, please let me know.

------------------

From: Johan Hovold <[email protected]>

commit 126d26f66d9890a69158812a6caa248c05359daa upstream.

Make sure we have at least one port before attempting to register a console.

Currently, at least one driver binds to a "dummy" interface and requests zero ports for it. Should such an interface also lack endpoints, we get a NULL-deref during probe.

Fixes e5b1e2062e05 ("USB: serial: make minor allocation dynamic")

Signed-off-by Johan Hovold <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/usb/serial/usb-serial.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

drivers/usb/serial/usb-serial.c +2 -1

@@ -1078,7 +1078,8 @@ static int usb_serial_probe(struct usb_i
 
 	serial->disconnected = 0;
 
-	usb_serial_console_init(serial->port[0]->minor);
+	if (num_ports > 0)
+		usb_serial_console_init(serial->port[0]->minor);
 exit:
 	module_put(type->driver.owner);
 	return 0;

Greg Kroah-Hartman

author maintainer

2016-11-09 11:07 UTC #49 lore raw

PATCH 52/138 USB: serial: cp210x: fix tiocmget error handling

4.8-stable review patch. If anyone has any objections, please let me know.

------------------

From: Johan Hovold <[email protected]>

commit de24e0a108bc48062e1c7acaa97014bce32a919f upstream.

The current tiocmget implementation would fail to report errors up the stack and instead leaked a few bits from the stack as a mask of modem-status flags.

Fixes 39a66b8d22a3 ("[PATCH] USB: CP2101 Add support for flow control")

Signed-off-by Johan Hovold <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/usb/serial/cp210x.c |    4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

drivers/usb/serial/cp210x.c +3 -1

@@ -1077,7 +1077,9 @@ static int cp210x_tiocmget(struct tty_st
 	u8 control;
 	int result;
 
-	cp210x_read_u8_reg(port, CP210X_GET_MDMSTS, &control);
+	result = cp210x_read_u8_reg(port, CP210X_GET_MDMSTS, &control);
+	if (result)
+		return result;
 
 	result = ((control & CONTROL_DTR) ? TIOCM_DTR : 0)
 		|((control & CONTROL_RTS) ? TIOCM_RTS : 0)

Greg Kroah-Hartman

author maintainer

2016-11-09 11:07 UTC #50 lore raw

PATCH 53/138 USB: serial: ftdi_sio: add support for Infineon TriBoard TC2X7

4.8-stable review patch. If anyone has any objections, please let me know.

------------------

From: Stefan Tauner <[email protected]>

commit ca006f785fbfd7a5c901900bd3fe2b26e946a1ee upstream.

This adds support to ftdi_sio for the Infineon TriBoard TC2X7 engineering board for first-generation Aurix SoCs with Tricore CPUs. Mere addition of the device IDs does the job.

Signed-off-by Stefan Tauner <[email protected]>

Signed-off-by Johan Hovold <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/usb/serial/ftdi_sio.c     |    3 ++-
 drivers/usb/serial/ftdi_sio_ids.h |    5 +++--
 2 files changed, 5 insertions(+), 3 deletions(-)

drivers/usb/serial/ftdi_sio.c +2 -1

@@ -986,7 +986,8 @@ static const struct usb_device_id id_tab
 	/* ekey Devices */
 	{ USB_DEVICE(FTDI_VID, FTDI_EKEY_CONV_USB_PID) },
 	/* Infineon Devices */
-	{ USB_DEVICE_INTERFACE_NUMBER(INFINEON_VID, INFINEON_TRIBOARD_PID, 1) },
+	{ USB_DEVICE_INTERFACE_NUMBER(INFINEON_VID, INFINEON_TRIBOARD_TC1798_PID, 1) },
+	{ USB_DEVICE_INTERFACE_NUMBER(INFINEON_VID, INFINEON_TRIBOARD_TC2X7_PID, 1) },
 	/* GE Healthcare devices */
 	{ USB_DEVICE(GE_HEALTHCARE_VID, GE_HEALTHCARE_NEMO_TRACKER_PID) },
 	/* Active Research (Actisense) devices */

drivers/usb/serial/ftdi_sio_ids.h +3 -2

@@ -626,8 +626,9 @@
 /*
  * Infineon Technologies
  */
-#define INFINEON_VID		0x058b
-#define INFINEON_TRIBOARD_PID	0x0028 /* DAS JTAG TriBoard TC1798 V1.0 */
+#define INFINEON_VID		        0x058b
+#define INFINEON_TRIBOARD_TC1798_PID	0x0028 /* DAS JTAG TriBoard TC1798 V1.0 */
+#define INFINEON_TRIBOARD_TC2X7_PID	0x0043 /* DAS JTAG TriBoard TC2X7 V1.0 */
 
 /*
  * Acton Research Corp.

Greg Kroah-Hartman

author maintainer

2016-11-09 10:45 UTC #51 lore raw

PATCH 54/138 xhci: use default USB_RESUME_TIMEOUT when resuming ports.

4.8-stable review patch. If anyone has any objections, please let me know.

------------------

From: Mathias Nyman <[email protected]>

commit 7d3b016a6f5a0fa610dfd02b05654c08fa4ae514 upstream.

USB2 host inititated resume, and system suspend bus resume need to use the same USB_RESUME_TIMEOUT as elsewhere.

This resolves a device disconnect issue at system resume seen on Intel Braswell and Apollolake, but is in no way limited to those platforms.

Signed-off-by Mathias Nyman <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/usb/host/xhci-hub.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

drivers/usb/host/xhci-hub.c +2 -2

@@ -1166,7 +1166,7 @@ int xhci_hub_control(struct usb_hcd *hcd
 				xhci_set_link_state(xhci, port_array, wIndex,
 							XDEV_RESUME);
 				spin_unlock_irqrestore(&xhci->lock, flags);
-				msleep(20);
+				msleep(USB_RESUME_TIMEOUT);
 				spin_lock_irqsave(&xhci->lock, flags);
 				xhci_set_link_state(xhci, port_array, wIndex,
 							XDEV_U0);

@@ -1410,7 +1410,7 @@ int xhci_bus_resume(struct usb_hcd *hcd)
 
 	if (need_usb2_u3_exit) {
 		spin_unlock_irqrestore(&xhci->lock, flags);
-		msleep(20);
+		msleep(USB_RESUME_TIMEOUT);
 		spin_lock_irqsave(&xhci->lock, flags);
 	}

Greg Kroah-Hartman

author maintainer

2016-11-09 10:45 UTC #52 lore raw

PATCH 55/138 usb: renesas_usbhs: add wait after initialization for R-Car Gen3

4.8-stable review patch. If anyone has any objections, please let me know.

------------------

From: Yoshihiro Shimoda <[email protected]>

commit b76032396d7958f006bccf5fb2535beb5526837c upstream.

Since the controller on R-Car Gen3 doesn't have any status registers to detect initialization (LPSTS.SUSPM = 1) and the initialization needs up to 45 usec, this patch adds wait after the initialization. Otherwise, writing other registers (e.g. INTENB0) will fail.

Fixes de18757e272d ("usb: renesas_usbhs: add R-Car Gen3 power control")

Cc <[email protected]>

Signed-off-by Yoshihiro Shimoda <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/usb/renesas_usbhs/rcar3.c |    8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

drivers/usb/renesas_usbhs/rcar3.c +6 -2

@@ -9,6 +9,7 @@
  *
  */
 
+#include <linux/delay.h>
 #include <linux/io.h>
 #include "common.h"
 #include "rcar3.h"

@@ -35,10 +36,13 @@ static int usbhs_rcar3_power_ctrl(struct
 
 	usbhs_write32(priv, UGCTRL2, UGCTRL2_RESERVED_3 | UGCTRL2_USB0SEL_OTG);
 
-	if (enable)
+	if (enable) {
 		usbhs_bset(priv, LPSTS, LPSTS_SUSPM, LPSTS_SUSPM);
-	else
+		/* The controller on R-Car Gen3 needs to wait up to 45 usec */
+		udelay(45);
+	} else {
 		usbhs_bset(priv, LPSTS, LPSTS_SUSPM, 0);
+	}
 
 	return 0;
 }

Greg Kroah-Hartman

author maintainer

2016-11-09 11:08 UTC #53 lore raw

PATCH 56/138 usb: increase ohci watchdog delay to 275 msec

4.8-stable review patch. If anyone has any objections, please let me know.

------------------

From: Bryan Paluch <[email protected]>

commit ed6d6f8f42d7302f6f9b6245f34927ec20d26c12 upstream.

Increase ohci watchout delay to 275 ms. Previous delay was 250 ms with 20 ms of slack, after removing slack time some ohci controllers don't respond in time. Logs from systems with controllers that have the issue would show "HcDoneHead not written back; disabled"

Signed-off-by Bryan Paluch <[email protected]>

Acked-by Alan Stern <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/usb/host/ohci-hcd.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/usb/host/ohci-hcd.c +1 -1

@@ -72,7 +72,7 @@
 static const char	hcd_name [] = "ohci_hcd";
 
 #define	STATECHANGE_DELAY	msecs_to_jiffies(300)
-#define	IO_WATCHDOG_DELAY	msecs_to_jiffies(250)
+#define	IO_WATCHDOG_DELAY	msecs_to_jiffies(275)
 
 #include "ohci.h"
 #include "pci-quirks.h"

Greg Kroah-Hartman

author maintainer

2016-11-09 11:09 UTC #54 lore raw

PATCH 57/138 GenWQE: Fix bad page access during abort of resource allocation

4.8-stable review patch. If anyone has any objections, please let me know.

------------------

From: Gerald Schaefer <[email protected]>

commit a7a7aeefbca2982586ba2c9fd7739b96416a6d1d upstream.

When interrupting an application which was allocating DMAable memory, it was possible, that the DMA memory was deallocated twice, leading to the error symptoms below.

Thanks to Gerald, who analyzed the problem and provided this patch.

I agree with his analysis of the problem: ddcb_cmd_fixups() -> genwqe_alloc_sync_sgl() (fails in f/lpage, but sgl->sgl != NULL and f/lpage maybe also != NULL) -> ddcb_cmd_cleanup() -> genwqe_free_sync_sgl() (double free, because sgl->sgl != NULL and f/lpage maybe also != NULL)

In this scenario we would have exactly the kind of double free that would explain the WARNING / Bad page state, and as expected it is caused by broken error handling (cleanup).

Using the Ubuntu git source, tag Ubuntu-4.4.0-33.52, he was able to reproduce the "Bad page state" issue, and with the patch on top he could not reproduce it any more.

------------[ cut here ]------------
WARNING: at /build/linux-o03cxz/linux-4.4.0/arch/s390/include/asm/pci_dma.h:141
Modules linked in: qeth_l2 ghash_s390 prng aes_s390 des_s390 des_generic sha512_s390 sha256_s390 sha1_s390 sha_common genwqe_card qeth crc_itu_t qdio ccwgroup vmur dm_multipath dasd_eckd_mod dasd_mod
CPU: 2 PID: 3293 Comm: genwqe_gunzip Not tainted 4.4.0-33-generic #52-Ubuntu
task: 0000000032c7e270 ti: 00000000324e4000 task.ti: 00000000324e4000
Krnl PSW : 0404c00180000000 0000000000156346 (dma_update_cpu_trans+0x9e/0xa8)
           R:0 T:1 IO:0 EX:0 Key:0 M:1 W:0 P:0 AS:3 CC:0 PM:0 EA:3
Krnl GPRS: 00000000324e7bcd 0000000000c3c34a 0000000027628298 000000003215b400
           0000000000000400 0000000000001fff 0000000000000400 0000000116853000
           07000000324e7b1e 0000000000000001 0000000000000001 0000000000000001
           0000000000001000 0000000116854000 0000000000156402 00000000324e7a38
Krnl Code: 000000000015633a: 95001000           cli     0(%r1),0
           000000000015633e: a774ffc3           brc     7,1562c4
          #0000000000156342: a7f40001           brc     15,156344
          >0000000000156346: 92011000           mvi     0(%r1),1
           000000000015634a: a7f4ffbd           brc     15,1562c4
           000000000015634e: 0707               bcr     0,%r7
           0000000000156350: c00400000000       brcl    0,156350
           0000000000156356: eb7ff0500024       stmg    %r7,%r15,80(%r15)
Call Trace:
([<00000000001563e0>] dma_update_trans+0x90/0x228)
 [<00000000001565dc>] s390_dma_unmap_pages+0x64/0x160
 [<00000000001567c2>] s390_dma_free+0x62/0x98
 [<000003ff801310ce>] __genwqe_free_consistent+0x56/0x70 [genwqe_card]
 [<000003ff801316d0>] genwqe_free_sync_sgl+0xf8/0x160 [genwqe_card]
 [<000003ff8012bd6e>] ddcb_cmd_cleanup+0x86/0xa8 [genwqe_card]
 [<000003ff8012c1c0>] do_execute_ddcb+0x110/0x348 [genwqe_card]
 [<000003ff8012c914>] genwqe_ioctl+0x51c/0xc20 [genwqe_card]
 [<000000000032513a>] do_vfs_ioctl+0x3b2/0x518
 [<0000000000325344>] SyS_ioctl+0xa4/0xb8
 [<00000000007b86c6>] system_call+0xd6/0x264
 [<000003ff9e8e520a>] 0x3ff9e8e520a
Last Breaking-Event-Address:
 [<0000000000156342>] dma_update_cpu_trans+0x9a/0xa8
---[ end trace 35996336235145c8 ]---
BUG: Bad page state in process jbd2/dasdb1-8  pfn:3215b
page:000003d100c856c0 count:-1 mapcount:0 mapping:          (null) index:0x0
flags: 0x3fffc0000000000()
page dumped because: nonzero _count

Signed-off-by Gerald Schaefer <[email protected]>

Signed-off-by Frank Haverkamp <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/misc/genwqe/card_utils.c |   12 +++++++++++-
 1 file changed, 11 insertions(+), 1 deletion(-)

drivers/misc/genwqe/card_utils.c +11 -1

@@ -352,17 +352,27 @@ int genwqe_alloc_sync_sgl(struct genwqe_
 		if (copy_from_user(sgl->lpage, user_addr + user_size -
 				   sgl->lpage_size, sgl->lpage_size)) {
 			rc = -EFAULT;
-			goto err_out1;
+			goto err_out2;
 		}
 	}
 	return 0;
 
+ err_out2:
+	__genwqe_free_consistent(cd, PAGE_SIZE, sgl->lpage,
+				 sgl->lpage_dma_addr);
+	sgl->lpage = NULL;
+	sgl->lpage_dma_addr = 0;
  err_out1:
 	__genwqe_free_consistent(cd, PAGE_SIZE, sgl->fpage,
 				 sgl->fpage_dma_addr);
+	sgl->fpage = NULL;
+	sgl->fpage_dma_addr = 0;
  err_out:
 	__genwqe_free_consistent(cd, sgl->sgl_size, sgl->sgl,
 				 sgl->sgl_dma_addr);
+	sgl->sgl = NULL;
+	sgl->sgl_dma_addr = 0;
+	sgl->sgl_size = 0;
 	return -ENOMEM;
 }

Greg Kroah-Hartman

author maintainer

2016-11-09 11:09 UTC #55 lore raw

PATCH 58/138 x86/smpboot: Init apic mapping before usage

4.8-stable review patch. If anyone has any objections, please let me know.

------------------

From: Thomas Gleixner <[email protected]>

commit 1e90a13d0c3dc94512af1ccb2b6563e8297838fa upstream.

The recent changes, which forced the registration of the boot cpu on UP systems, which do not have ACPI tables, have been fixed for systems w/o local APIC, but left a wreckage for systems which have neither ACPI nor mptables, but the CPU has an APIC, e.g. virtualbox.

The boot process crashes in prefill_possible_map() as it wants to register the boot cpu, which needs to access the local apic, but the local APIC is not yet mapped.

There is no reason why init_apic_mapping() can't be invoked before prefill_possible_map(). So instead of playing another silly early mapping game, as the ACPI/mptables code does, we just move init_apic_mapping() before the call to prefill_possible_map().

In hindsight, I should have noticed that combination earlier.

Sorry for the churn (also in stable)!

Fixes ff8560512b8d ("x86/boot/smp: Don't try to poke disabled/non-existent APIC")

Reported-and-debugged-by Michal Necasek <[email protected]>

Reported-and-tested-by Wolfgang Bauer <[email protected]>

Link http://lkml.kernel.org/r/alpine.DEB.2.20.1610282114380.5053@nanos open here

Cc Borislav Petkov <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 arch/x86/kernel/setup.c |    7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

arch/x86/kernel/setup.c +6 -1

@@ -1222,11 +1222,16 @@ void __init setup_arch(char **cmdline_p)
 	if (smp_found_config)
 		get_smp_config();
 
+	/*
+	 * Systems w/o ACPI and mptables might not have it mapped the local
+	 * APIC yet, but prefill_possible_map() might need to access it.
+	 */
+	init_apic_mappings();
+
 	prefill_possible_map();
 
 	init_cpu_to_node();
 
-	init_apic_mappings();
 	io_apic_init_mappings();
 
 	kvm_guest_init();

Greg Kroah-Hartman

author maintainer

2016-11-09 11:09 UTC #56 lore raw

PATCH 59/138 vt: clear selection before resizing

[1] http://lkml.kernel.org/r/CACT4Y+acDTwy4umEvf5ROBGiRJNrxHN4Cn5szCXE5Jw-d1B=Xw@mail.gmail.com

4.8-stable review patch. If anyone has any objections, please let me know.

------------------

From: Scot Doyle <[email protected]>

commit 009e39ae44f4191188aeb6dfbf661b771dbbe515 upstream.

When resizing a vt its selection may exceed the new size, resulting in an invalid memory access [1]. Clear the selection before resizing.

Reported-and-tested-by Dmitry Vyukov <[email protected]>

Signed-off-by Scot Doyle <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/tty/vt/vt.c |    3 +++
 1 file changed, 3 insertions(+)

drivers/tty/vt/vt.c +3 -0

@@ -874,6 +874,9 @@ static int vc_do_resize(struct tty_struc
 	if (!newscreen)
 		return -ENOMEM;
 
+	if (vc == sel_cons)
+		clear_selection();
+
 	old_rows = vc->vc_rows;
 	old_row_size = vc->vc_size_row;

Greg Kroah-Hartman

author maintainer

2016-11-09 10:45 UTC #57 lore raw

PATCH 60/138 hv: do not lose pending heartbeat vmbus packets

4.8-stable review patch. If anyone has any objections, please let me know.

------------------

From: Long Li <[email protected]>

commit 407a3aee6ee2d2cb46d9ba3fc380bc29f35d020c upstream.

The host keeps sending heartbeat packets independent of the
guest responding to them. Even though we respond to the heartbeat messages at interrupt level, we can have situations where there maybe multiple heartbeat messages pending that have not been responded to. For instance this occurs when the VM is paused and the host continues to send the heartbeat messages. Address this issue by draining and responding to all
the heartbeat messages that maybe pending.

Signed-off-by Long Li <[email protected]>

Signed-off-by K. Y. Srinivasan <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/hv/hv_util.c |   10 +++++++---
 1 file changed, 7 insertions(+), 3 deletions(-)

drivers/hv/hv_util.c +7 -3

@@ -283,10 +283,14 @@ static void heartbeat_onchannelcallback(
 	u8 *hbeat_txf_buf = util_heartbeat.recv_buffer;
 	struct icmsg_negotiate *negop = NULL;
 
-	vmbus_recvpacket(channel, hbeat_txf_buf,
-			 PAGE_SIZE, &recvlen, &requestid);
+	while (1) {
+
+		vmbus_recvpacket(channel, hbeat_txf_buf,
+				 PAGE_SIZE, &recvlen, &requestid);
+
+		if (!recvlen)
+			break;
 
-	if (recvlen > 0) {
 		icmsghdrp = (struct icmsg_hdr *)&hbeat_txf_buf[
 				sizeof(struct vmbuspipe_hdr)];

Greg Kroah-Hartman

author maintainer

2016-11-09 10:45 UTC #58 lore raw

PATCH 61/138 xhci: add restart quirk for Intel Wildcatpoint PCH

4.8-stable review patch. If anyone has any objections, please let me know.

------------------

From: Mathias Nyman <[email protected]>

commit 4c39135aa412d2f1381e43802523da110ca7855c upstream.

xHC in Wildcatpoint-LP PCH is similar to LynxPoint-LP and need the same quirks to prevent machines from spurious restart while shutting them down.

Reported-by Hasan Mahmood <[email protected]>

Signed-off-by Mathias Nyman <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/usb/host/xhci-pci.c |    4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

drivers/usb/host/xhci-pci.c +3 -1

@@ -45,6 +45,7 @@
 
 #define PCI_DEVICE_ID_INTEL_LYNXPOINT_XHCI	0x8c31
 #define PCI_DEVICE_ID_INTEL_LYNXPOINT_LP_XHCI	0x9c31
+#define PCI_DEVICE_ID_INTEL_WILDCATPOINT_LP_XHCI	0x9cb1
 #define PCI_DEVICE_ID_INTEL_CHERRYVIEW_XHCI		0x22b5
 #define PCI_DEVICE_ID_INTEL_SUNRISEPOINT_H_XHCI		0xa12f
 #define PCI_DEVICE_ID_INTEL_SUNRISEPOINT_LP_XHCI	0x9d2f

@@ -153,7 +154,8 @@ static void xhci_pci_quirks(struct devic
 		xhci->quirks |= XHCI_SPURIOUS_REBOOT;
 	}
 	if (pdev->vendor == PCI_VENDOR_ID_INTEL &&
-		pdev->device == PCI_DEVICE_ID_INTEL_LYNXPOINT_LP_XHCI) {
+		(pdev->device == PCI_DEVICE_ID_INTEL_LYNXPOINT_LP_XHCI ||
+		 pdev->device == PCI_DEVICE_ID_INTEL_WILDCATPOINT_LP_XHCI)) {
 		xhci->quirks |= XHCI_SPURIOUS_REBOOT;
 		xhci->quirks |= XHCI_SPURIOUS_WAKEUP;
 	}

Greg Kroah-Hartman

author maintainer

2016-11-09 11:09 UTC #59 lore raw

PATCH 62/138 xhci: workaround for hosts missing CAS bit

4.8-stable review patch. If anyone has any objections, please let me know.

------------------

From: Mathias Nyman <[email protected]>

commit 346e99736c3ce328fd42d678343b70243aca5f36 upstream.

If a device is unplugged and replugged during Sx system suspend some Intel xHC hosts will overwrite the CAS (Cold attach status) flag and no device connection is noticed in resume.

A device in this state can be identified in resume if its link state is in polling or compliance mode, and the current connect status is 0. A device in this state needs to be warm reset.

Intel 100/c230 series PCH specification update Doc #332692-006 Errata #8

Observed on Cherryview and Apollolake as they go into compliance mode if LFPS times out during polling, and re-plugged devices are not discovered at resume.

Signed-off-by Mathias Nyman <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/usb/host/xhci-hub.c |   37 +++++++++++++++++++++++++++++++++++++
 drivers/usb/host/xhci-pci.c |    6 ++++++
 drivers/usb/host/xhci.h     |    3 +++
 3 files changed, 46 insertions(+)

drivers/usb/host/xhci-hub.c +37 -0

@@ -1355,6 +1355,35 @@ int xhci_bus_suspend(struct usb_hcd *hcd
 	return 0;
 }
 
+/*
+ * Workaround for missing Cold Attach Status (CAS) if device re-plugged in S3.
+ * warm reset a USB3 device stuck in polling or compliance mode after resume.
+ * See Intel 100/c230 series PCH specification update Doc #332692-006 Errata #8
+ */
+static bool xhci_port_missing_cas_quirk(int port_index,
+					     __le32 __iomem **port_array)
+{
+	u32 portsc;
+
+	portsc = readl(port_array[port_index]);
+
+	/* if any of these are set we are not stuck */
+	if (portsc & (PORT_CONNECT | PORT_CAS))
+		return false;
+
+	if (((portsc & PORT_PLS_MASK) != XDEV_POLLING) &&
+	    ((portsc & PORT_PLS_MASK) != XDEV_COMP_MODE))
+		return false;
+
+	/* clear wakeup/change bits, and do a warm port reset */
+	portsc &= ~(PORT_RWC_BITS | PORT_CEC | PORT_WAKE_BITS);
+	portsc |= PORT_WR;
+	writel(portsc, port_array[port_index]);
+	/* flush write */
+	readl(port_array[port_index]);
+	return true;
+}
+
 int xhci_bus_resume(struct usb_hcd *hcd)
 {
 	struct xhci_hcd	*xhci = hcd_to_xhci(hcd);

@@ -1392,6 +1421,14 @@ int xhci_bus_resume(struct usb_hcd *hcd)
 		u32 temp;
 
 		temp = readl(port_array[port_index]);
+
+		/* warm reset CAS limited ports stuck in polling/compliance */
+		if ((xhci->quirks & XHCI_MISSING_CAS) &&
+		    (hcd->speed >= HCD_USB3) &&
+		    xhci_port_missing_cas_quirk(port_index, port_array)) {
+			xhci_dbg(xhci, "reset stuck port %d\n", port_index);
+			continue;
+		}
 		if (DEV_SUPERSPEED_ANY(temp))
 			temp &= ~(PORT_RWC_BITS | PORT_CEC | PORT_WAKE_BITS);
 		else

drivers/usb/host/xhci-pci.c +6 -0

@@ -51,6 +51,7 @@
 #define PCI_DEVICE_ID_INTEL_SUNRISEPOINT_LP_XHCI	0x9d2f
 #define PCI_DEVICE_ID_INTEL_BROXTON_M_XHCI		0x0aa8
 #define PCI_DEVICE_ID_INTEL_BROXTON_B_XHCI		0x1aa8
+#define PCI_DEVICE_ID_INTEL_APL_XHCI			0x5aa8
 
 static const char hcd_name[] = "xhci_hcd";

@@ -171,6 +172,11 @@ static void xhci_pci_quirks(struct devic
 		 pdev->device == PCI_DEVICE_ID_INTEL_CHERRYVIEW_XHCI) {
 		xhci->quirks |= XHCI_SSIC_PORT_UNUSED;
 	}
+	if (pdev->vendor == PCI_VENDOR_ID_INTEL &&
+	    (pdev->device == PCI_DEVICE_ID_INTEL_CHERRYVIEW_XHCI ||
+	     pdev->device == PCI_DEVICE_ID_INTEL_APL_XHCI))
+		xhci->quirks |= XHCI_MISSING_CAS;
+
 	if (pdev->vendor == PCI_VENDOR_ID_ETRON &&
 			pdev->device == PCI_DEVICE_ID_EJ168) {
 		xhci->quirks |= XHCI_RESET_ON_RESUME;

drivers/usb/host/xhci.h +3 -0

@@ -314,6 +314,8 @@ struct xhci_op_regs {
 #define XDEV_U2		(0x2 << 5)
 #define XDEV_U3		(0x3 << 5)
 #define XDEV_INACTIVE	(0x6 << 5)
+#define XDEV_POLLING	(0x7 << 5)
+#define XDEV_COMP_MODE  (0xa << 5)
 #define XDEV_RESUME	(0xf << 5)
 /* true: port has power (see HCC_PPC) */
 #define PORT_POWER	(1 << 9)

@@ -1653,6 +1655,7 @@ struct xhci_hcd {
 #define XHCI_MTK_HOST		(1 << 21)
 #define XHCI_SSIC_PORT_UNUSED	(1 << 22)
 #define XHCI_NO_64BIT_SUPPORT	(1 << 23)
+#define XHCI_MISSING_CAS	(1 << 24)
 	unsigned int		num_active_eps;
 	unsigned int		limit_active_eps;
 	/* There are two roothubs to keep track of bus suspend info for */

Greg Kroah-Hartman

author maintainer

2016-11-09 11:09 UTC #60 lore raw

PATCH 63/138 tty: limit terminal size to 4M chars

4.8-stable review patch. If anyone has any objections, please let me know.

------------------

From: Dmitry Vyukov <[email protected]>

commit 32b2921e6a7461fe63b71217067a6cf4bddb132f upstream.

Size of kmalloc() in vc_do_resize() is controlled by user. Too large kmalloc() size triggers WARNING message on console. Put a reasonable upper bound on terminal size to prevent WARNINGs.

Signed-off-by Dmitry Vyukov <[email protected]>

CC David Rientjes <[email protected]>

Cc One Thousand Gnomes <[email protected]>

Cc Greg Kroah-Hartman <[email protected]>

Cc Jiri Slaby <[email protected]>

Cc Peter Hurley <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/tty/vt/vt.c |    2 ++
 1 file changed, 2 insertions(+)

drivers/tty/vt/vt.c +2 -0

@@ -870,6 +870,8 @@ static int vc_do_resize(struct tty_struc
 	if (new_cols == vc->vc_cols && new_rows == vc->vc_rows)
 		return 0;
 
+	if (new_screen_size > (4 << 20))
+		return -EINVAL;
 	newscreen = kmalloc(new_screen_size, GFP_USER);
 	if (!newscreen)
 		return -ENOMEM;

Greg Kroah-Hartman

author maintainer

2016-11-09 11:07 UTC #61 lore raw

PATCH 64/138 arm64: dts: marvell: fix clocksource for CP110 master SPI0

4.8-stable review patch. If anyone has any objections, please let me know.

------------------

From: Marcin Wojtas <[email protected]>

commit 51227bf52008bd4c4c50da4b749bbc6e7bbbca52 upstream.

I2C and SPI interfaces share common clock trees within the CP110 HW block. It occurred that SPI0 interface has wrong clock assignment in the device tree, which is fixed in this commit to a proper value.

Fixes 728dacc7f4dd ("arm64: dts: marvell: initial DT description of ...")

Signed-off-by Marcin Wojtas <[email protected]>

Signed-off-by Gregory CLEMENT <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi +1 -1

@@ -131,7 +131,7 @@
 				#address-cells = <0x1>;
 				#size-cells = <0x0>;
 				cell-index = <1>;
-				clocks = <&cpm_syscon0 0 3>;
+				clocks = <&cpm_syscon0 1 21>;
 				status = "disabled";
 			};

Greg Kroah-Hartman

author maintainer

2016-11-09 10:45 UTC #62 lore raw

PATCH 65/138 iio:chemical:atlas-ph-sensor: Fix use of 32 bit int to hold 16 bit big endian value

4.8-stable review patch. If anyone has any objections, please let me know.

------------------

From: Sandhya Bankar <[email protected]>

commit d1fe85ec7702917f2f1515b4c421d5d4792201a0 upstream.

This will result in a random value being reported on big endian architectures. (thanks to Lars-Peter Clausen for pointing out the effects of this bug)

Only effects a value printed to the log, but as this reports the settings of the probe in question it may be of direct interest to users.

Also, fixes the following sparse endianness warnings:

drivers/iio/chemical/atlas-ph-sensor.c:215:9: warning: cast to restricted __be16 drivers/iio/chemical/atlas-ph-sensor.c:215:9: warning: cast to restricted __be16 drivers/iio/chemical/atlas-ph-sensor.c:215:9: warning: cast to restricted __be16 drivers/iio/chemical/atlas-ph-sensor.c:215:9: warning: cast to restricted __be16 drivers/iio/chemical/atlas-ph-sensor.c:215:9: warning: cast to restricted __be16 drivers/iio/chemical/atlas-ph-sensor.c:215:9: warning: cast to restricted __be16 drivers/iio/chemical/atlas-ph-sensor.c:215:9: warning: cast to restricted __be16 drivers/iio/chemical/atlas-ph-sensor.c:215:9: warning: cast to restricted __be16

Signed-off-by Sandhya Bankar <[email protected]>

Fixes e8dd92bfbff25 ("iio: chemical: atlas-ph-sensor: add EC feature")

Signed-off-by Jonathan Cameron <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/iio/chemical/atlas-ph-sensor.c |    7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

drivers/iio/chemical/atlas-ph-sensor.c +4 -3

@@ -207,13 +207,14 @@ static int atlas_check_ec_calibration(st
 	struct device *dev = &data->client->dev;
 	int ret;
 	unsigned int val;
+	__be16	rval;
 
-	ret = regmap_bulk_read(data->regmap, ATLAS_REG_EC_PROBE, &val, 2);
+	ret = regmap_bulk_read(data->regmap, ATLAS_REG_EC_PROBE, &rval, 2);
 	if (ret)
 		return ret;
 
-	dev_info(dev, "probe set to K = %d.%.2d", be16_to_cpu(val) / 100,
-						 be16_to_cpu(val) % 100);
+	val = be16_to_cpu(rval);
+	dev_info(dev, "probe set to K = %d.%.2d", val / 100, val % 100);
 
 	ret = regmap_read(data->regmap, ATLAS_REG_EC_CALIB_STATUS, &val);
 	if (ret)

Greg Kroah-Hartman

author maintainer

2016-11-09 11:07 UTC #63 lore raw

PATCH 66/138 Staging: wilc1000: Fix kernel Oops on opening the device

4.8-stable review patch. If anyone has any objections, please let me know.

------------------

From: Aditya Shankar <[email protected]>

commit 1d4f1d53e1e2d5e38f4d3ca3bf60f8be5025540f upstream.

Commit 2518ac59eb27 ("staging: wilc1000: Replace kthread with workqueue for host interface") adds an unconditional destroy_workqueue() on the wilc's "hif_workqueue" soon after its creation thereby rendering it unusable. It then further attempts to queue work onto this non-existing hif_worqueue and results in:

Unable to handle kernel NULL pointer dereference at virtual address 00000010
pgd = de478000
[00000010] *pgd=3eec0831, *pte=00000000, *ppte=00000000
Internal error: Oops: 17 [#1] ARM
Modules linked in: wilc1000_sdio(C) wilc1000(C)
CPU: 0 PID: 825 Comm: ifconfig Tainted: G         C      4.8.0-rc8+ #37
Hardware name: Atmel SAMA5
task: df56f800 task.stack: deeb0000
PC is at __queue_work+0x90/0x284
LR is at __queue_work+0x58/0x284
pc : [<c0126bb0>]    lr : [<c0126b78>]    psr: 600f0093

sp : deeb1aa0 ip : def22d78 fp : deea6000
r10: 00000000 r9 : c0a08150 r8 : c0a2f058
r7 : 00000001 r6 : dee9b600 r5 : def22d74 r4 : 00000000
r3 : 00000000 r2 : def22d74 r1 : 07ffffff r0 : 00000000
Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment none
...
[<c0127060>] (__queue_work) from [<c0127298>] (queue_work_on+0x34/0x40)
[<c0127298>] (queue_work_on) from [<bf0076b4>] (wilc_enqueue_cmd+0x54/0x64 [wilc1000]) [<bf0076b4>] (wilc_enqueue_cmd [wilc1000]) from [<bf0082b4>] (wilc_set_wfi_drv_handler+0x48/0x70 [wilc1000]) [<bf0082b4>] (wilc_set_wfi_drv_handler [wilc1000]) from [<bf00509c>] (wilc_mac_open+0x214/0x250 [wilc1000]) [<bf00509c>] (wilc_mac_open [wilc1000]) from [<c04fde98>] (__dev_open+0xb8/0x11c) [<c04fde98>] (__dev_open) from [<c04fe128>] (__dev_change_flags+0x94/0x158)
[<c04fe128>] (__dev_change_flags) from [<c04fe204>] (dev_change_flags+0x18/0x48) [<c04fe204>] (dev_change_flags) from [<c0557d5c>] (devinet_ioctl+0x6b4/0x788)
[<c0557d5c>] (devinet_ioctl) from [<c04e40a0>] (sock_ioctl+0x154/0x2cc)
[<c04e40a0>] (sock_ioctl) from [<c01b16e0>] (do_vfs_ioctl+0x9c/0x878)
[<c01b16e0>] (do_vfs_ioctl) from [<c01b1ef0>] (SyS_ioctl+0x34/0x5c)
[<c01b1ef0>] (SyS_ioctl) from [<c0107520>] (ret_fast_syscall+0x0/0x3c)

Code: e5932004 e1520006 01a04003 0affffff (e5943010)
---[ end trace b612328adaa6bf20 ]---

This fix removes the unnecessary call to destroy_workqueue() while opening the device to avoid the above kernel panic. The deinit routine already does a good job of terminating the workqueue when no longer needed.

Reported-by Nicolas Ferre <[email protected]>

Fixes 2518ac59eb27 ("staging: wilc1000: Replace kthread with workqueue for host interface")

Signed-off-by Aditya Shankar <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/staging/wilc1000/host_interface.c |    1 -
 1 file changed, 1 deletion(-)

drivers/staging/wilc1000/host_interface.c +0 -1

@@ -3391,7 +3391,6 @@ int wilc_init(struct net_device *dev, st
 
 	clients_count++;
 
-	destroy_workqueue(hif_workqueue);
 _fail_:
 	return result;
 }

Greg Kroah-Hartman

author maintainer

2016-11-09 11:07 UTC #64 lore raw

PATCH 67/138 dm: free io_barrier after blk_cleanup_queue call

4.8-stable review patch. If anyone has any objections, please let me know.

------------------

From: Tahsin Erdogan <[email protected]>

commit d09960b0032174eb493c4c13be5b9c9ef36dc9a7 upstream.

dm_old_request_fn() has paths that access md->io_barrier. The party destroying io_barrier should ensure that no future execution of dm_old_request_fn() is possible. Move io_barrier destruction to below blk_cleanup_queue() to ensure this and avoid a NULL pointer crash during request-based DM device shutdown.

Signed-off-by Tahsin Erdogan <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/md/dm.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

drivers/md/dm.c +2 -2

@@ -1423,8 +1423,6 @@ static void cleanup_mapped_device(struct
 	if (md->bs)
 		bioset_free(md->bs);
 
-	cleanup_srcu_struct(&md->io_barrier);
-
 	if (md->disk) {
 		spin_lock(&_minor_lock);
 		md->disk->private_data = NULL;

@@ -1436,6 +1434,8 @@ static void cleanup_mapped_device(struct
 	if (md->queue)
 		blk_cleanup_queue(md->queue);
 
+	cleanup_srcu_struct(&md->io_barrier);
+
 	if (md->bdev) {
 		bdput(md->bdev);
 		md->bdev = NULL;

Greg Kroah-Hartman

author maintainer

2016-11-09 10:45 UTC #65 lore raw

PATCH 69/138 KVM: s390: Fix STHYI buffer alignment for diag224

4.8-stable review patch. If anyone has any objections, please let me know.

------------------

From: Janosch Frank <[email protected]>

commit 45c7ee43a5184ddbff652ee0d2e826f86f1b616b upstream.

Diag224 requires a page-aligned 4k buffer to store the name table into. kmalloc does not guarantee page alignment, hence we replace it with __get_free_page for the buffer allocation.

Reported-by Michael Holzheu <[email protected]>

Signed-off-by Janosch Frank <[email protected]>

Reviewed-by Cornelia Huck <[email protected]>

Signed-off-by Christian Borntraeger <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 arch/s390/kvm/sthyi.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

arch/s390/kvm/sthyi.c +2 -2

@@ -315,7 +315,7 @@ static void fill_diag(struct sthyi_sctns
 	if (r < 0)
 		goto out;
 
-	diag224_buf = kmalloc(PAGE_SIZE, GFP_KERNEL | GFP_DMA);
+	diag224_buf = (void *)__get_free_page(GFP_KERNEL | GFP_DMA);
 	if (!diag224_buf || diag224(diag224_buf))
 		goto out;

@@ -378,7 +378,7 @@ static void fill_diag(struct sthyi_sctns
 	sctns->par.infpval1 |= PAR_WGHT_VLD;
 
 out:
-	kfree(diag224_buf);
+	free_page((unsigned long)diag224_buf);
 	vfree(diag204_buf);
 }

Greg Kroah-Hartman

author maintainer

2016-11-09 10:45 UTC #66 lore raw

PATCH 70/138 KVM: MIPS: Make ERET handle ERL before EXL

4.8-stable review patch. If anyone has any objections, please let me know.

------------------

From: James Hogan <[email protected]>

commit ede5f3e7b54a4347be4d8525269eae50902bd7cd upstream.

The ERET instruction to return from exception is used for returning from exception level (Status.EXL) and error level (Status.ERL). If both bits are set however we should be returning from ERL first, as ERL can interrupt EXL, for example when an NMI is taken. KVM however checks EXL first.

Fix the order of the checks to match the pseudocode in the instruction set manual.

Fixes e685c689f3a8 ("KVM/MIPS32: Privileged instruction/target branch emulation.")

Signed-off-by James Hogan <[email protected]>

Cc Paolo Bonzini <[email protected]>

Cc "Radim Krčmář" <[email protected]>

Cc Ralf Baechle <[email protected]>

Signed-off-by Paolo Bonzini <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 arch/mips/kvm/emulate.c |    8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

arch/mips/kvm/emulate.c +4 -4

@@ -791,15 +791,15 @@ enum emulation_result kvm_mips_emul_eret
 	struct mips_coproc *cop0 = vcpu->arch.cop0;
 	enum emulation_result er = EMULATE_DONE;
 
-	if (kvm_read_c0_guest_status(cop0) & ST0_EXL) {
+	if (kvm_read_c0_guest_status(cop0) & ST0_ERL) {
+		kvm_clear_c0_guest_status(cop0, ST0_ERL);
+		vcpu->arch.pc = kvm_read_c0_guest_errorepc(cop0);
+	} else if (kvm_read_c0_guest_status(cop0) & ST0_EXL) {
 		kvm_debug("[%#lx] ERET to %#lx\n", vcpu->arch.pc,
 			  kvm_read_c0_guest_epc(cop0));
 		kvm_clear_c0_guest_status(cop0, ST0_EXL);
 		vcpu->arch.pc = kvm_read_c0_guest_epc(cop0);
 
-	} else if (kvm_read_c0_guest_status(cop0) & ST0_ERL) {
-		kvm_clear_c0_guest_status(cop0, ST0_ERL);
-		vcpu->arch.pc = kvm_read_c0_guest_errorepc(cop0);
 	} else {
 		kvm_err("[%#lx] ERET when MIPS_SR_EXL|MIPS_SR_ERL == 0\n",
 			vcpu->arch.pc);

Greg Kroah-Hartman

author maintainer

2016-11-09 10:45 UTC #67 lore raw

PATCH 71/138 KVM: MIPS: Precalculate MMIO load resume PC

4.8-stable review patch. If anyone has any objections, please let me know.

------------------

From: James Hogan <[email protected]>

commit e1e575f6b026734be3b1f075e780e91ab08ca541 upstream.

The advancing of the PC when completing an MMIO load is done before re-entering the guest, i.e. before restoring the guest ASID. However if the load is in a branch delay slot it may need to access guest code to read the prior branch instruction. This isn't safe in TLB mapped code at the moment, nor in the future when we'll access unmapped guest segments using direct user accessors too, as it could read the branch from host user memory instead.

Therefore calculate the resume PC in advance while we're still in the right context and save it in the new vcpu->arch.io_pc (replacing the no longer needed vcpu->arch.pending_load_cause), and restore it on MMIO completion.

Fixes e685c689f3a8 ("KVM/MIPS32: Privileged instruction/target branch emulation.")

Signed-off-by James Hogan <[email protected]>

Cc Paolo Bonzini <[email protected]>

Cc "Radim Krčmář" <[email protected]>

Cc Ralf Baechle <[email protected]>

Signed-off-by Paolo Bonzini <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 arch/mips/include/asm/kvm_host.h |    7 ++++---
 arch/mips/kvm/emulate.c          |   24 +++++++++++++++---------
 2 files changed, 19 insertions(+), 12 deletions(-)

arch/mips/include/asm/kvm_host.h +4 -3

@@ -279,7 +279,10 @@ struct kvm_vcpu_arch {
 	/* Host KSEG0 address of the EI/DI offset */
 	void *kseg0_commpage;
 
-	u32 io_gpr;		/* GPR used as IO source/target */
+	/* Resume PC after MMIO completion */
+	unsigned long io_pc;
+	/* GPR used as IO source/target */
+	u32 io_gpr;
 
 	struct hrtimer comparecount_timer;
 	/* Count timer control KVM register */

@@ -301,8 +304,6 @@ struct kvm_vcpu_arch {
 	/* Bitmask of pending exceptions to be cleared */
 	unsigned long pending_exceptions_clr;
 
-	u32 pending_load_cause;
-
 	/* Save/Restore the entryhi register when are are preempted/scheduled back in */
 	unsigned long preempt_entryhi;

arch/mips/kvm/emulate.c +15 -9

@@ -1522,13 +1522,25 @@ enum emulation_result kvm_mips_emulate_l
 					    struct kvm_vcpu *vcpu)
 {
 	enum emulation_result er = EMULATE_DO_MMIO;
+	unsigned long curr_pc;
 	u32 op, rt;
 	u32 bytes;
 
 	rt = inst.i_format.rt;
 	op = inst.i_format.opcode;
 
-	vcpu->arch.pending_load_cause = cause;
+	/*
+	 * Find the resume PC now while we have safe and easy access to the
+	 * prior branch instruction, and save it for
+	 * kvm_mips_complete_mmio_load() to restore later.
+	 */
+	curr_pc = vcpu->arch.pc;
+	er = update_pc(vcpu, cause);
+	if (er == EMULATE_FAIL)
+		return er;
+	vcpu->arch.io_pc = vcpu->arch.pc;
+	vcpu->arch.pc = curr_pc;
+
 	vcpu->arch.io_gpr = rt;
 
 	switch (op) {

@@ -2488,9 +2500,8 @@ enum emulation_result kvm_mips_complete_
 		goto done;
 	}
 
-	er = update_pc(vcpu, vcpu->arch.pending_load_cause);
-	if (er == EMULATE_FAIL)
-		return er;
+	/* Restore saved resume PC */
+	vcpu->arch.pc = vcpu->arch.io_pc;
 
 	switch (run->mmio.len) {
 	case 4:

@@ -2512,11 +2523,6 @@ enum emulation_result kvm_mips_complete_
 		break;
 	}
 
-	if (vcpu->arch.pending_load_cause & CAUSEF_BD)
-		kvm_debug("[%#lx] Completing %d byte BD Load to gpr %d (0x%08lx) type %d\n",
-			  vcpu->arch.pc, run->mmio.len, vcpu->arch.io_gpr, *gpr,
-			  vcpu->mmio_needed);
-
 done:
 	return er;
 }

Greg Kroah-Hartman

author maintainer

2016-11-09 11:08 UTC #68 lore raw

PATCH 73/138 ARM: dts: fix the SD card on the Snowball

4.8-stable review patch. If anyone has any objections, please let me know.

------------------

From: Linus Walleij <[email protected]>

commit 1b283eea6228880b765bc40fe4e555416437ce58 upstream.

This fixes a very annoying regression on the Snowball SD card that has been around for a while. It turns out that the device tree does not configure the direction pins properly, nor sets up the pins for the voltage converter properly at boot. Unless all things are correctly set up, the feedback clock will not work, and makes the driver spew messages in the console (but it works, very slowly):

root@Ux500:/ mount /dev/mmcblk0p2 /mnt/

[    9.953460] mmci-pl18x 80126000.sdi0_per1: error during DMA transfer!
[    9.960296] mmcblk0: error -110 sending status command, retrying
[    9.966461] mmcblk0: error -110 sending status command, retrying
[    9.972534] mmcblk0: error -110 sending status command, aborting

Fix this by rectifying the device tree to correspond to that of the Ux500 HREF boards plus the DAT31DIR setting that is unique for the Snowball, and things start working smoothly. Add in the SDR12 and SDR25 modes which this host can do without any problems.

I don't know if this has ever been correct, sadly. It works after this patch.

Reported-by Daniel Lezcano <[email protected]>

Cc Ulf Hansson <[email protected]>

Signed-off-by Olof Johansson <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 arch/arm/boot/dts/ste-snowball.dts |   15 +++++++++++++--
 1 file changed, 13 insertions(+), 2 deletions(-)

arch/arm/boot/dts/ste-snowball.dts +13 -2

@@ -239,14 +239,25 @@
 			arm,primecell-periphid = <0x10480180>;
 			max-frequency = <100000000>;
 			bus-width = <4>;
+			cap-sd-highspeed;
 			cap-mmc-highspeed;
+			sd-uhs-sdr12;
+			sd-uhs-sdr25;
+			/* All direction control is used */
+			st,sig-dir-cmd;
+			st,sig-dir-dat0;
+			st,sig-dir-dat2;
+			st,sig-dir-dat31;
+			st,sig-pin-fbclk;
+			full-pwr-cycle;
 			vmmc-supply = <&ab8500_ldo_aux3_reg>;
 			vqmmc-supply = <&vmmci>;
 			pinctrl-names = "default", "sleep";
 			pinctrl-0 = <&sdi0_default_mode>;
 			pinctrl-1 = <&sdi0_sleep_mode>;
 
-			cd-gpios  = <&gpio6 26 GPIO_ACTIVE_LOW>; // 218
+			/* GPIO218 MMC_CD */
+			cd-gpios  = <&gpio6 26 GPIO_ACTIVE_LOW>;
 
 			status = "okay";
 		};

@@ -549,7 +560,7 @@
 					/* VMMCI level-shifter enable */
 					snowball_cfg3 {
 						pins = "GPIO217_AH12";
-						ste,config = <&gpio_out_lo>;
+						ste,config = <&gpio_out_hi>;
 					};
 					/* VMMCI level-shifter voltage select */
 					snowball_cfg4 {

Greg Kroah-Hartman

author maintainer

2016-11-09 11:15 UTC #69 lore raw

PATCH 74/138 nfsd: Fix general protection fault in release_lock_stateid()

4.8-stable review patch. If anyone has any objections, please let me know.

------------------

From: Chuck Lever <[email protected]>

commit f46c445b79906a9da55c13e0a6f6b6a006b892fe upstream.

When I push NFSv4.1 / RDMA hard, (xfstests generic/089, for example), I get this crash on the server:

Oct 28 22:04:30 klimt kernel: general protection fault: 0000 [#1] SMP DEBUG_PAGEALLOC
Oct 28 22:04:30 klimt kernel: Modules linked in: cts rpcsec_gss_krb5 iTCO_wdt iTCO_vendor_support sb_edac edac_core x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm btrfs irqbypass crct10dif_pclmul crc32_pclmul ghash_clmulni_intel aesni_intel lrw gf128mul glue_helper ablk_helper cryptd xor pcspkr raid6_pq i2c_i801 i2c_smbus lpc_ich mfd_core sg mei_me mei ioatdma shpchp wmi ipmi_si ipmi_msghandler rpcrdma ib_ipoib rdma_ucm acpi_power_meter acpi_pad ib_ucm ib_uverbs ib_umad rdma_cm ib_cm iw_cm nfsd auth_rpcgss nfs_acl lockd grace sunrpc ip_tables xfs libcrc32c mlx4_ib mlx4_en ib_core sr_mod cdrom sd_mod ast drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops ttm drm crc32c_intel igb ahci libahci ptp mlx4_core pps_core dca libata i2c_algo_bit i2c_core dm_mirror dm_region_hash dm_log dm_mod
Oct 28 22:04:30 klimt kernel: CPU: 7 PID: 1558 Comm: nfsd Not tainted 4.9.0-rc2-00005-g82cd754 #8
Oct 28 22:04:30 klimt kernel: Hardware name: Supermicro Super Server/X10SRL-F, BIOS 1.0c 09/09/2015
Oct 28 22:04:30 klimt kernel: task: ffff880835c3a100 task.stack: ffff8808420d8000
Oct 28 22:04:30 klimt kernel: RIP: 0010:[<ffffffffa05a759f>]  [<ffffffffa05a759f>] release_lock_stateid+0x1f/0x60 [nfsd]
Oct 28 22:04:30 klimt kernel: RSP: 0018:ffff8808420dbce0  EFLAGS: 00010246
Oct 28 22:04:30 klimt kernel: RAX: ffff88084e6660f0 RBX: ffff88084e667020 RCX: 0000000000000000
Oct 28 22:04:30 klimt kernel: RDX: 0000000000000007 RSI: 0000000000000000 RDI: ffff88084e667020
Oct 28 22:04:30 klimt kernel: RBP: ffff8808420dbcf8 R08: 0000000000000001 R09: 0000000000000000
Oct 28 22:04:30 klimt kernel: R10: ffff880835c3a100 R11: ffff880835c3aca8 R12: 6b6b6b6b6b6b6b6b
Oct 28 22:04:30 klimt kernel: R13: ffff88084e6670d8 R14: ffff880835f546f0 R15: ffff880835f1c548
Oct 28 22:04:30 klimt kernel: FS:  0000000000000000(0000) GS:ffff88087bdc0000(0000) knlGS:0000000000000000
Oct 28 22:04:30 klimt kernel: CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Oct 28 22:04:30 klimt kernel: CR2: 00007ff020389000 CR3: 0000000001c06000 CR4: 00000000001406e0
Oct 28 22:04:30 klimt kernel: Stack:
Oct 28 22:04:30 klimt kernel: ffff88084e667020 0000000000000000 ffff88084e6670d8 ffff8808420dbd20
Oct 28 22:04:30 klimt kernel: ffffffffa05ac80d ffff880835f54548 ffff88084e640008 ffff880835f545b0
Oct 28 22:04:30 klimt kernel: ffff8808420dbd70 ffffffffa059803d ffff880835f1c768 0000000000000870
Oct 28 22:04:30 klimt kernel: Call Trace:
Oct 28 22:04:30 klimt kernel: [<ffffffffa05ac80d>] nfsd4_free_stateid+0xfd/0x1b0 [nfsd]
Oct 28 22:04:30 klimt kernel: [<ffffffffa059803d>] nfsd4_proc_compound+0x40d/0x690 [nfsd]
Oct 28 22:04:30 klimt kernel: [<ffffffffa0583114>] nfsd_dispatch+0xd4/0x1d0 [nfsd]
Oct 28 22:04:30 klimt kernel: [<ffffffffa047bbf9>] svc_process_common+0x3d9/0x700 [sunrpc]
Oct 28 22:04:30 klimt kernel: [<ffffffffa047ca64>] svc_process+0xf4/0x330 [sunrpc]
Oct 28 22:04:30 klimt kernel: [<ffffffffa05827ca>] nfsd+0xfa/0x160 [nfsd]
Oct 28 22:04:30 klimt kernel: [<ffffffffa05826d0>] ? nfsd_destroy+0x170/0x170 [nfsd]
Oct 28 22:04:30 klimt kernel: [<ffffffff810b367b>] kthread+0x10b/0x120
Oct 28 22:04:30 klimt kernel: [<ffffffff810b3570>] ? kthread_stop+0x280/0x280
Oct 28 22:04:30 klimt kernel: [<ffffffff8174e8ba>] ret_from_fork+0x2a/0x40
Oct 28 22:04:30 klimt kernel: Code: c3 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 55 48 89 e5 41 55 41 54 53 48 8b 87 b0 00 00 00 48 89 fb 4c 8b a0 98 00 00 00 <49> 8b 44 24 20 48 8d b8 80 03 00 00 e8 10 66 1a e1 48 89 df e8
Oct 28 22:04:30 klimt kernel: RIP  [<ffffffffa05a759f>] release_lock_stateid+0x1f/0x60 [nfsd]
Oct 28 22:04:30 klimt kernel: RSP <ffff8808420dbce0>
Oct 28 22:04:30 klimt kernel: ---[ end trace cf5d0b371973e167 ]---

Jeff Layton says:

Quoted 7 lines

Hm...now that I look though, this is a little suspicious:
   struct nfs4_openowner *oo = openowner(stp->st_openstp->st_stateowner);
I wonder if it's possible for the openstateid to have already been destroyed at this point.

Quoted 6 lines

We might be better off doing something like this to get the client pointer:
   stp->st_stid.sc_client;
...which should be more direct and less dependent on other stateids staying valid.

With the suggested change, I am no longer able to reproduce the above oops.

v2: Fix unhash_lock_stateid() as well

Fix-suggested-by Jeff Layton <[email protected]>

Fixes 42691398be08 ('nfsd: Fix race between FREE_STATEID and LOCK')

Signed-off-by Chuck Lever <[email protected]>

Reviewed-by Jeff Layton <[email protected]>

Signed-off-by J. Bruce Fields <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 fs/nfsd/nfs4state.c |   10 ++++------
 1 file changed, 4 insertions(+), 6 deletions(-)

fs/nfsd/nfs4state.c +4 -6

@@ -1147,9 +1147,7 @@ static void put_ol_stateid_locked(struct
 
 static bool unhash_lock_stateid(struct nfs4_ol_stateid *stp)
 {
-	struct nfs4_openowner *oo = openowner(stp->st_openstp->st_stateowner);
-
-	lockdep_assert_held(&oo->oo_owner.so_client->cl_lock);
+	lockdep_assert_held(&stp->st_stid.sc_client->cl_lock);
 
 	list_del_init(&stp->st_locks);
 	nfs4_unhash_stid(&stp->st_stid);

@@ -1158,12 +1156,12 @@ static bool unhash_lock_stateid(struct n
 
 static void release_lock_stateid(struct nfs4_ol_stateid *stp)
 {
-	struct nfs4_openowner *oo = openowner(stp->st_openstp->st_stateowner);
+	struct nfs4_client *clp = stp->st_stid.sc_client;
 	bool unhashed;
 
-	spin_lock(&oo->oo_owner.so_client->cl_lock);
+	spin_lock(&clp->cl_lock);
 	unhashed = unhash_lock_stateid(stp);
-	spin_unlock(&oo->oo_owner.so_client->cl_lock);
+	spin_unlock(&clp->cl_lock);
 	if (unhashed)
 		nfs4_put_stid(&stp->st_stid);
 }

Greg Kroah-Hartman

author maintainer

2016-11-09 11:09 UTC #70 lore raw

PATCH 75/138 MIPS: KASLR: Fix handling of NULL FDT

4.8-stable review patch. If anyone has any objections, please let me know.

------------------

From: Matt Redfearn <[email protected]>

commit 4736697963385e6257ee8e260e97347e858cd962 upstream.

If platform code returns a NULL pointer to the FDT, initial_boot_params will not get set to a valid pointer and attempting to find the /chosen node in it will cause a NULL pointer dereference and the kernel to crash immediately on startup - with no output to the console.

Fix this by checking that initial_boot_params is valid before using it.

Fixes 405bc8fd12f5 ("MIPS: Kernel: Implement KASLR using CONFIG_RELOCATABLE")

Signed-off-by Matt Redfearn <[email protected]>

Patchwork: https://patchwork.linux-mips.org/patch/14414/

Signed-off-by Ralf Baechle <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 arch/mips/kernel/relocate.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

arch/mips/kernel/relocate.c +1 -1

@@ -200,7 +200,7 @@ static inline __init unsigned long get_r
 
 #if defined(CONFIG_USE_OF)
 	/* Get any additional entropy passed in device tree */
-	{
+	if (initial_boot_params) {
 		int node, len;
 		u64 *prop;

Greg Kroah-Hartman

author maintainer

2016-11-09 11:15 UTC #71 lore raw

PATCH 76/138 ovl: fix get_acl() on tmpfs

4.8-stable review patch. If anyone has any objections, please let me know.

------------------

From: Miklos Szeredi <[email protected]>

commit b93d4a0eb308d4400b84c8b24c1b80e09a9497d0 upstream.

tmpfs doesn't have ->get_acl() because it only uses cached acls.

This fixes the acl tests in pjdfstest when tmpfs is used as the upper layer of the overlay.

Reported-by Amir Goldstein <[email protected]>

Signed-off-by Miklos Szeredi <[email protected]>

Fixes 39a25b2b3762 ("ovl: define ->get_acl() for overlay inodes")

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 fs/overlayfs/inode.c |    3 ---
 1 file changed, 3 deletions(-)

fs/overlayfs/inode.c +0 -3

@@ -294,9 +294,6 @@ struct posix_acl *ovl_get_acl(struct ino
 	if (!IS_ENABLED(CONFIG_FS_POSIX_ACL) || !IS_POSIXACL(realinode))
 		return NULL;
 
-	if (!realinode->i_op->get_acl)
-		return NULL;
-
 	old_cred = ovl_override_creds(inode->i_sb);
 	acl = get_acl(realinode, type);
 	revert_creds(old_cred);

Greg Kroah-Hartman

author maintainer

2016-11-09 11:15 UTC #72 lore raw

PATCH 77/138 ovl: update S_ISGID when setting posix ACLs

4.8-stable review patch. If anyone has any objections, please let me know.

------------------

From: Miklos Szeredi <[email protected]>

commit fd3220d37b1f6f0cab6142d98b0e6c4082e63299 upstream.

This change fixes xfstest generic/375, which failed to clear the setgid bit in the following test case on overlayfs:

touch $testfile
chown 100:100 $testfile
chmod 2755 $testfile
_runas -u 100 -g 101 -- setfacl -m u::rwx,g::rwx,o::rwx $testfile

Reported-by Amir Goldstein <[email protected]>

Signed-off-by Miklos Szeredi <[email protected]>

Tested-by Amir Goldstein <[email protected]>

Fixes d837a49bd57f ("ovl: fix POSIX ACL setting")

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 fs/overlayfs/super.c |   15 +++++++++++++++
 1 file changed, 15 insertions(+)

fs/overlayfs/super.c +15 -0

@@ -1026,6 +1026,21 @@ ovl_posix_acl_xattr_set(const struct xat
 
 	posix_acl_release(acl);
 
+	/*
+	 * Check if sgid bit needs to be cleared (actual setacl operation will
+	 * be done with mounter's capabilities and so that won't do it for us).
+	 */
+	if (unlikely(inode->i_mode & S_ISGID) &&
+	    handler->flags == ACL_TYPE_ACCESS &&
+	    !in_group_p(inode->i_gid) &&
+	    !capable_wrt_inode_uidgid(inode, CAP_FSETID)) {
+		struct iattr iattr = { .ia_valid = ATTR_KILL_SGID };
+
+		err = ovl_setattr(dentry, &iattr);
+		if (err)
+			return err;
+	}
+
 	err = ovl_xattr_set(dentry, handler->name, value, size, flags);
 	if (!err)
 		ovl_copyattr(ovl_inode_real(inode, NULL), inode);

Greg Kroah-Hartman

author maintainer

2016-11-09 10:46 UTC #73 lore raw

PATCH 78/138 ovl: fsync after copy-up

4.8-stable review patch. If anyone has any objections, please let me know.

------------------

From: Miklos Szeredi <[email protected]>

commit 641089c1549d8d3df0b047b5de7e9a111362cdce upstream.

Make sure the copied up file hits the disk before renaming to the final destination. If this is not done then the copy-up may corrupt the data in the file in case of a crash.

Signed-off-by Miklos Szeredi <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 fs/overlayfs/copy_up.c |    2 ++
 1 file changed, 2 insertions(+)

fs/overlayfs/copy_up.c +2 -0

@@ -171,6 +171,8 @@ static int ovl_copy_up_data(struct path
 		len -= bytes;
 	}
 
+	if (!error)
+		error = vfs_fsync(new_file, 0);
 	fput(new_file);
 out_fput:
 	fput(old_file);

Greg Kroah-Hartman

author maintainer

2016-11-09 11:09 UTC #74 lore raw

PATCH 79/138 parisc: Ensure consistent state when switching to kernel stack at syscall entry

4.8-stable review patch. If anyone has any objections, please let me know.

------------------

From: John David Anglin <[email protected]>

commit 6ed518328d0189e0fdf1bb7c73290d546143ea66 upstream.

We have one critical section in the syscall entry path in which we switch from the userspace stack to kernel stack. In the event of an external interrupt, the interrupt code distinguishes between those two states by analyzing the value of sr7. If sr7 is zero, it uses the kernel stack. Therefore it's important, that the value of sr7 is in sync with the currently enabled stack.

This patch now disables interrupts while executing the critical section. This prevents the interrupt handler to possibly see an inconsistent state which in the worst case can lead to crashes.

Interestingly, in the syscall exit path interrupts were already disabled in the critical section which switches back to the userspace stack.

Signed-off-by John David Anglin <[email protected]>

Signed-off-by Helge Deller <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 arch/parisc/kernel/syscall.S |   11 +++++++++--
 1 file changed, 9 insertions(+), 2 deletions(-)

arch/parisc/kernel/syscall.S +9 -2

@@ -106,8 +106,6 @@ linux_gateway_entry:
 	mtsp	%r0,%sr4			/* get kernel space into sr4 */
 	mtsp	%r0,%sr5			/* get kernel space into sr5 */
 	mtsp	%r0,%sr6			/* get kernel space into sr6 */
-	mfsp    %sr7,%r1                        /* save user sr7 */
-	mtsp    %r1,%sr3                        /* and store it in sr3 */
 
 #ifdef CONFIG_64BIT
 	/* for now we can *always* set the W bit on entry to the syscall

@@ -133,6 +131,14 @@ linux_gateway_entry:
 	depdi	0, 31, 32, %r21
 1:	
 #endif
+
+	/* We use a rsm/ssm pair to prevent sr3 from being clobbered
+	 * by external interrupts.
+	 */
+	mfsp    %sr7,%r1                        /* save user sr7 */
+	rsm	PSW_SM_I, %r0			/* disable interrupts */
+	mtsp    %r1,%sr3                        /* and store it in sr3 */
+
 	mfctl   %cr30,%r1
 	xor     %r1,%r30,%r30                   /* ye olde xor trick */
 	xor     %r1,%r30,%r1

@@ -147,6 +153,7 @@ linux_gateway_entry:
 	 */
 
 	mtsp	%r0,%sr7			/* get kernel space into sr7 */
+	ssm	PSW_SM_I, %r0			/* enable interrupts */
 	STREGM	%r1,FRAME_SIZE(%r30)		/* save r1 (usp) here for now */
 	mfctl	%cr30,%r1			/* get task ptr in %r1 */
 	LDREG	TI_TASK(%r1),%r1

Greg Kroah-Hartman

author maintainer

2016-11-09 10:46 UTC #75 lore raw

PATCH 80/138 virtio_ring: Make interrupt suppression spec compliant

4.8-stable review patch. If anyone has any objections, please let me know.

------------------

From: Ladi Prosek <[email protected]>

commit 0ea1e4a6d9b62cf29e210d2b4ba9fd43917522e3 upstream.

According to the spec, if the VIRTIO_RING_F_EVENT_IDX feature bit is negotiated the driver MUST set flags to 0. Not dirtying the available ring in virtqueue_disable_cb also has a minor positive performance impact, improving L1 dcache load missed by ~0.5% in vring_bench.

Writes to the used event field (vring_used_event) are still unconditional.

Cc Michael S. Tsirkin <[email protected]>

Signed-off-by Ladi Prosek <[email protected]>

Signed-off-by Michael S. Tsirkin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/virtio/virtio_ring.c |   14 +++++++++-----
 1 file changed, 9 insertions(+), 5 deletions(-)

drivers/virtio/virtio_ring.c +9 -5

@@ -732,7 +732,8 @@ void virtqueue_disable_cb(struct virtque
 
 	if (!(vq->avail_flags_shadow & VRING_AVAIL_F_NO_INTERRUPT)) {
 		vq->avail_flags_shadow |= VRING_AVAIL_F_NO_INTERRUPT;
-		vq->vring.avail->flags = cpu_to_virtio16(_vq->vdev, vq->avail_flags_shadow);
+		if (!vq->event)
+			vq->vring.avail->flags = cpu_to_virtio16(_vq->vdev, vq->avail_flags_shadow);
 	}
 
 }

@@ -764,7 +765,8 @@ unsigned virtqueue_enable_cb_prepare(str
 	 * entry. Always do both to keep code simple. */
 	if (vq->avail_flags_shadow & VRING_AVAIL_F_NO_INTERRUPT) {
 		vq->avail_flags_shadow &= ~VRING_AVAIL_F_NO_INTERRUPT;
-		vq->vring.avail->flags = cpu_to_virtio16(_vq->vdev, vq->avail_flags_shadow);
+		if (!vq->event)
+			vq->vring.avail->flags = cpu_to_virtio16(_vq->vdev, vq->avail_flags_shadow);
 	}
 	vring_used_event(&vq->vring) = cpu_to_virtio16(_vq->vdev, last_used_idx = vq->last_used_idx);
 	END_USE(vq);

@@ -832,10 +834,11 @@ bool virtqueue_enable_cb_delayed(struct
 	 * more to do. */
 	/* Depending on the VIRTIO_RING_F_USED_EVENT_IDX feature, we need to
 	 * either clear the flags bit or point the event index at the next
-	 * entry. Always do both to keep code simple. */
+	 * entry. Always update the event index to keep code simple. */
 	if (vq->avail_flags_shadow & VRING_AVAIL_F_NO_INTERRUPT) {
 		vq->avail_flags_shadow &= ~VRING_AVAIL_F_NO_INTERRUPT;
-		vq->vring.avail->flags = cpu_to_virtio16(_vq->vdev, vq->avail_flags_shadow);
+		if (!vq->event)
+			vq->vring.avail->flags = cpu_to_virtio16(_vq->vdev, vq->avail_flags_shadow);
 	}
 	/* TODO: tune this threshold */
 	bufs = (u16)(vq->avail_idx_shadow - vq->last_used_idx) * 3 / 4;

@@ -953,7 +956,8 @@ struct virtqueue *__vring_new_virtqueue(
 	/* No callback?  Tell other side not to bother us. */
 	if (!callback) {
 		vq->avail_flags_shadow |= VRING_AVAIL_F_NO_INTERRUPT;
-		vq->vring.avail->flags = cpu_to_virtio16(vdev, vq->avail_flags_shadow);
+		if (!vq->event)
+			vq->vring.avail->flags = cpu_to_virtio16(vdev, vq->avail_flags_shadow);
 	}
 
 	/* Put everything in free lists. */

Greg Kroah-Hartman

author maintainer

2016-11-09 10:46 UTC #76 lore raw

PATCH 81/138 virtio_pci: Limit DMA mask to 44 bits for legacy virtio devices

4.8-stable review patch. If anyone has any objections, please let me know.

------------------

From: Will Deacon <[email protected]>

commit a0be1db4304f51c99af6b6e515549794182a94df upstream.

Legacy virtio defines the virtqueue base using a 32-bit PFN field, with a read-only register indicating a fixed page size of 4k.

This can cause problems for DMA allocators that allocate top down from the DMA mask, which is set to 64 bits. In this case, the addresses are silently truncated to 44-bit, leading to IOMMU faults, failure to read from the queue or data corruption.

This patch restricts the coherent DMA mask for legacy PCI virtio devices to 44 bits, which matches the specification.

Cc Andy Lutomirski <[email protected]>

Cc Michael S. Tsirkin <[email protected]>

Cc Benjamin Serebrin <[email protected]>

Signed-off-by Will Deacon <[email protected]>

Signed-off-by Michael S. Tsirkin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/virtio/virtio_pci_legacy.c |   16 ++++++++++++----
 1 file changed, 12 insertions(+), 4 deletions(-)

drivers/virtio/virtio_pci_legacy.c +12 -4

@@ -212,10 +212,18 @@ int virtio_pci_legacy_probe(struct virti
 		return -ENODEV;
 	}
 
-	rc = dma_set_mask_and_coherent(&pci_dev->dev, DMA_BIT_MASK(64));
-	if (rc)
-		rc = dma_set_mask_and_coherent(&pci_dev->dev,
-						DMA_BIT_MASK(32));
+	rc = dma_set_mask(&pci_dev->dev, DMA_BIT_MASK(64));
+	if (rc) {
+		rc = dma_set_mask_and_coherent(&pci_dev->dev, DMA_BIT_MASK(32));
+	} else {
+		/*
+		 * The virtio ring base address is expressed as a 32-bit PFN,
+		 * with a page size of 1 << VIRTIO_PCI_QUEUE_ADDR_SHIFT.
+		 */
+		dma_set_coherent_mask(&pci_dev->dev,
+				DMA_BIT_MASK(32 + VIRTIO_PCI_QUEUE_ADDR_SHIFT));
+	}
+
 	if (rc)
 		dev_warn(&pci_dev->dev, "Failed to enable 64-bit or 32-bit DMA.  Trying to continue, but this might not work.\n");

Greg Kroah-Hartman

author maintainer

2016-11-09 11:09 UTC #77 lore raw

PATCH 82/138 virtio: console: Unlock vqs while freeing buffers

4.8-stable review patch. If anyone has any objections, please let me know.

------------------

From: Matt Redfearn <[email protected]>

commit 34563769e438d2881f62cf4d9badc4e589ac0ec0 upstream.

Commit c6017e793b93 ("virtio: console: add locks around buffer removal in port unplug path") added locking around the freeing of buffers in the vq. However, when free_buf() is called with can_sleep = true and rproc is enabled, it calls dma_free_coherent() directly, requiring interrupts to be enabled. Currently a WARNING is triggered due to the spin locking around free_buf, with a call stack like this:

WARNING: CPU: 3 PID: 121 at ./include/linux/dma-mapping.h:433
free_buf+0x1a8/0x288
Call Trace:
[<8040c538>] show_stack+0x74/0xc0
[<80757240>] dump_stack+0xd0/0x110
[<80430d98>] __warn+0xfc/0x130
[<80430ee0>] warn_slowpath_null+0x2c/0x3c
[<807e7c6c>] free_buf+0x1a8/0x288
[<807ea590>] remove_port_data+0x50/0xac
[<807ea6a0>] unplug_port+0xb4/0x1bc
[<807ea858>] virtcons_remove+0xb0/0xfc
[<807b6734>] virtio_dev_remove+0x58/0xc0
[<807f918c>] __device_release_driver+0xac/0x134
[<807f924c>] device_release_driver+0x38/0x50
[<807f7edc>] bus_remove_device+0xfc/0x130
[<807f4b74>] device_del+0x17c/0x21c
[<807f4c38>] device_unregister+0x24/0x38
[<807b6b50>] unregister_virtio_device+0x28/0x44

Fix this by restructuring the loops to allow the locks to only be taken where it is necessary to protect the vqs, and release it while the buffer is being freed.

Fixes c6017e793b93 ("virtio: console: add locks around buffer removal in port unplug path")

Signed-off-by Matt Redfearn <[email protected]>

Signed-off-by Michael S. Tsirkin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/char/virtio_console.c |   22 ++++++++++++++++------
 1 file changed, 16 insertions(+), 6 deletions(-)

drivers/char/virtio_console.c +16 -6

@@ -1540,19 +1540,29 @@ static void remove_port_data(struct port
 	spin_lock_irq(&port->inbuf_lock);
 	/* Remove unused data this port might have received. */
 	discard_port_data(port);
+	spin_unlock_irq(&port->inbuf_lock);
 
 	/* Remove buffers we queued up for the Host to send us data in. */
-	while ((buf = virtqueue_detach_unused_buf(port->in_vq)))
-		free_buf(buf, true);
-	spin_unlock_irq(&port->inbuf_lock);
+	do {
+		spin_lock_irq(&port->inbuf_lock);
+		buf = virtqueue_detach_unused_buf(port->in_vq);
+		spin_unlock_irq(&port->inbuf_lock);
+		if (buf)
+			free_buf(buf, true);
+	} while (buf);
 
 	spin_lock_irq(&port->outvq_lock);
 	reclaim_consumed_buffers(port);
+	spin_unlock_irq(&port->outvq_lock);
 
 	/* Free pending buffers from the out-queue. */
-	while ((buf = virtqueue_detach_unused_buf(port->out_vq)))
-		free_buf(buf, true);
-	spin_unlock_irq(&port->outvq_lock);
+	do {
+		spin_lock_irq(&port->outvq_lock);
+		buf = virtqueue_detach_unused_buf(port->out_vq);
+		spin_unlock_irq(&port->outvq_lock);
+		if (buf)
+			free_buf(buf, true);
+	} while (buf);
 }
 
 /*

Greg Kroah-Hartman

author maintainer

2016-11-09 11:09 UTC #78 lore raw

PATCH 83/138 dm mirror: fix read error on recovery after default leg failure

4.8-stable review patch. If anyone has any objections, please let me know.

------------------

From: Heinz Mauelshagen <[email protected]>

commit dcb2ff56417362c31f6b430c3c531a84581e8721 upstream.

If a default leg has failed, any read will cause a new operational default leg to be selected and the read is resubmitted. But until now the read will return failure even though it was successful due to resubmission. The reason for this is bio->bi_error was not being cleared before resubmitting the bio.

Fix by clearing bio->bi_error before resubmission.

Fixes 4246a0b63bd8 ("block: add a bi_error field to struct bio")

Signed-off-by Heinz Mauelshagen <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/md/dm-raid1.c |    1 +
 1 file changed, 1 insertion(+)

drivers/md/dm-raid1.c +1 -0

@@ -1292,6 +1292,7 @@ static int mirror_end_io(struct dm_targe
 
 			dm_bio_restore(bd, bio);
 			bio_record->details.bi_bdev = NULL;
+			bio->bi_error = 0;
 
 			queue_bio(ms, bio, rw);
 			return DM_ENDIO_INCOMPLETE;

Greg Kroah-Hartman

author maintainer

2016-11-09 11:09 UTC #79 lore raw

PATCH 84/138 dm table: fix missing dm_put_target_type() in dm_table_add_target()

4.8-stable review patch. If anyone has any objections, please let me know.

------------------

From: tang.junhui <[email protected]>

commit dafa724bf582181d9a7d54f5cb4ca0bf8ef29269 upstream.

dm_get_target_type() was previously called so any error returned from dm_table_add_target() must first call dm_put_target_type(). Otherwise the DM target module's reference count will leak and the associated kernel module will be unable to be removed.

Also, leverage the fact that r is already -EINVAL and remove an extra newline.

Fixes 36a0456 ("dm table: add immutable feature")

Fixes cc6cbe1 ("dm table: add always writeable feature")

Fixes 3791e2f ("dm table: add singleton feature")

Signed-off-by tang.junhui <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/md/dm-table.c |   24 +++++++++---------------
 1 file changed, 9 insertions(+), 15 deletions(-)

drivers/md/dm-table.c +9 ~~-15~~

@@ -695,37 +695,32 @@ int dm_table_add_target(struct dm_table
 
 	tgt->type = dm_get_target_type(type);
 	if (!tgt->type) {
-		DMERR("%s: %s: unknown target type", dm_device_name(t->md),
-		      type);
+		DMERR("%s: %s: unknown target type", dm_device_name(t->md), type);
 		return -EINVAL;
 	}
 
 	if (dm_target_needs_singleton(tgt->type)) {
 		if (t->num_targets) {
-			DMERR("%s: target type %s must appear alone in table",
-			      dm_device_name(t->md), type);
-			return -EINVAL;
+			tgt->error = "singleton target type must appear alone in table";
+			goto bad;
 		}
 		t->singleton = true;
 	}
 
 	if (dm_target_always_writeable(tgt->type) && !(t->mode & FMODE_WRITE)) {
-		DMERR("%s: target type %s may not be included in read-only tables",
-		      dm_device_name(t->md), type);
-		return -EINVAL;
+		tgt->error = "target type may not be included in a read-only table";
+		goto bad;
 	}
 
 	if (t->immutable_target_type) {
 		if (t->immutable_target_type != tgt->type) {
-			DMERR("%s: immutable target type %s cannot be mixed with other target types",
-			      dm_device_name(t->md), t->immutable_target_type->name);
-			return -EINVAL;
+			tgt->error = "immutable target type cannot be mixed with other target types";
+			goto bad;
 		}
 	} else if (dm_target_is_immutable(tgt->type)) {
 		if (t->num_targets) {
-			DMERR("%s: immutable target type %s cannot be mixed with other target types",
-			      dm_device_name(t->md), tgt->type->name);
-			return -EINVAL;
+			tgt->error = "immutable target type cannot be mixed with other target types";
+			goto bad;
 		}
 		t->immutable_target_type = tgt->type;
 	}

@@ -740,7 +735,6 @@ int dm_table_add_target(struct dm_table
 	 */
 	if (!adjoin(t, tgt)) {
 		tgt->error = "Gap in table";
-		r = -EINVAL;
 		goto bad;
 	}

Greg Kroah-Hartman

author maintainer

2016-11-09 11:09 UTC #80 lore raw

PATCH 85/138 dm rq: clear kworker_task if kthread_run() returned an error

4.8-stable review patch. If anyone has any objections, please let me know.

------------------

From: Mike Snitzer <[email protected]>

commit 937fa62e8a00d0b4bc2c0a40567d7c88ab2b2e8d upstream.

cleanup_mapped_device() calls kthread_stop() if kworker_task is non-NULL. Currently the assigned value could be a valid task struct or an error code (e.g -ENOMEM). Reset md->kworker_task to NULL if kthread_run() returned an erorr.

Fixes 7193a9defc ("dm rq: check kthread_run return for .request_fn request-based DM")

Reported-by Tahsin Erdogan <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/md/dm-rq.c |    7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

drivers/md/dm-rq.c +5 -2

@@ -835,8 +835,11 @@ int dm_old_init_request_queue(struct map
 	init_kthread_worker(&md->kworker);
 	md->kworker_task = kthread_run(kthread_worker_fn, &md->kworker,
 				       "kdmwork-%s", dm_device_name(md));
-	if (IS_ERR(md->kworker_task))
-		return PTR_ERR(md->kworker_task);
+	if (IS_ERR(md->kworker_task)) {
+		int error = PTR_ERR(md->kworker_task);
+		md->kworker_task = NULL;
+		return error;
+	}
 
 	elv_register_queue(md->queue);

Greg Kroah-Hartman

author maintainer

2016-11-09 11:09 UTC #81 lore raw

PATCH 86/138 dm raid: fix compat_features validation

4.8-stable review patch. If anyone has any objections, please let me know.

------------------

From: Andy Whitcroft <[email protected]>

commit 5c33677c87cbe44ae04df69c4a29c1750a9ec4e5 upstream.

In ecbfb9f118bce4 ("dm raid: add raid level takeover support") a new compatible feature flag was added. Validation for these compat_features was added but this only passes for new raid mappings with this feature flag. This causes previously created raid mappings to be failed at import.

Check compat_features for the only valid combination.

Fixes ecbfb9f118bce4 ("dm raid: add raid level takeover support")

Signed-off-by Andy Whitcroft <[email protected]>

Signed-off-by Heinz Mauelshagen <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/md/dm-raid.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

drivers/md/dm-raid.c +2 -1

@@ -2258,7 +2258,8 @@ static int super_validate(struct raid_se
 	if (!mddev->events && super_init_validation(rs, rdev))
 		return -EINVAL;
 
-	if (le32_to_cpu(sb->compat_features) != FEATURE_FLAG_SUPPORTS_V190) {
+	if (le32_to_cpu(sb->compat_features) &&
+	    le32_to_cpu(sb->compat_features) != FEATURE_FLAG_SUPPORTS_V190) {
 		rs->ti->error = "Unable to assemble array: Unknown flag(s) in compatible feature flags";
 		return -EINVAL;
 	}

Greg Kroah-Hartman

author maintainer

2016-11-09 10:46 UTC #82 lore raw

PATCH 87/138 dm raid: fix activation of existing raid4/10 devices

4.8-stable review patch. If anyone has any objections, please let me know.

------------------

From: Heinz Mauelshagen <[email protected]>

commit b052b07c39d593c9954a84d5bbe1563999483f38 upstream.

dm-raid 1.9.0 fails to activate existing RAID4/10 devices that have the old superblock format (which does not have takeover/reshaping support that was added via commit 33e53f06850f).

Fix validation path for old superblocks by reverting to the old raid4 layout and basing checks on mddev->new_{level,layout,...} members in super_init_validation().

Signed-off-by Heinz Mauelshagen <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 Documentation/device-mapper/dm-raid.txt |    1 +
 drivers/md/dm-raid.c                    |   12 +++++++-----
 2 files changed, 8 insertions(+), 5 deletions(-)

Documentation/device-mapper/dm-raid.txt +1 -0

@@ -309,3 +309,4 @@ Version History
 	with a reshape in progress.
 1.9.0   Add support for RAID level takeover/reshape/region size
 	and set size reduction.
+1.9.1   Fix activation of existing RAID 4/10 mapped devices

drivers/md/dm-raid.c +7 -5

@@ -266,7 +266,7 @@ static struct raid_type {
 	{"raid10_offset", "raid10 offset (striped mirrors)",	    0, 2, 10, ALGORITHM_RAID10_OFFSET},
 	{"raid10_near",	  "raid10 near (striped mirrors)",	    0, 2, 10, ALGORITHM_RAID10_NEAR},
 	{"raid10",	  "raid10 (striped mirrors)",		    0, 2, 10, ALGORITHM_RAID10_DEFAULT},
-	{"raid4",	  "raid4 (dedicated last parity disk)",	    1, 2, 4,  ALGORITHM_PARITY_N}, /* raid4 layout = raid5_n */
+	{"raid4",	  "raid4 (dedicated first parity disk)",    1, 2, 5,  ALGORITHM_PARITY_0}, /* raid4 layout = raid5_0 */
 	{"raid5_n",	  "raid5 (dedicated last parity disk)",	    1, 2, 5,  ALGORITHM_PARITY_N},
 	{"raid5_ls",	  "raid5 (left symmetric)",		    1, 2, 5,  ALGORITHM_LEFT_SYMMETRIC},
 	{"raid5_rs",	  "raid5 (right symmetric)",		    1, 2, 5,  ALGORITHM_RIGHT_SYMMETRIC},

@@ -2087,11 +2087,11 @@ static int super_init_validation(struct
 		/*
 		 * No takeover/reshaping, because we don't have the extended v1.9.0 metadata
 		 */
-		if (le32_to_cpu(sb->level) != mddev->level) {
+		if (le32_to_cpu(sb->level) != mddev->new_level) {
 			DMERR("Reshaping/takeover raid sets not yet supported. (raid level/stripes/size change)");
 			return -EINVAL;
 		}
-		if (le32_to_cpu(sb->layout) != mddev->layout) {
+		if (le32_to_cpu(sb->layout) != mddev->new_layout) {
 			DMERR("Reshaping raid sets not yet supported. (raid layout change)");
 			DMERR("	 0x%X vs 0x%X", le32_to_cpu(sb->layout), mddev->layout);
 			DMERR("	 Old layout: %s w/ %d copies",

@@ -2102,7 +2102,7 @@ static int super_init_validation(struct
 			      raid10_md_layout_to_copies(mddev->layout));
 			return -EINVAL;
 		}
-		if (le32_to_cpu(sb->stripe_sectors) != mddev->chunk_sectors) {
+		if (le32_to_cpu(sb->stripe_sectors) != mddev->new_chunk_sectors) {
 			DMERR("Reshaping raid sets not yet supported. (stripe sectors change)");
 			return -EINVAL;
 		}

@@ -2115,6 +2115,8 @@ static int super_init_validation(struct
 			return -EINVAL;
 		}
 
+		DMINFO("Discovered old metadata format; upgrading to extended metadata format");
+
 		/* Table line is checked vs. authoritative superblock */
 		rs_set_new(rs);
 	}

@@ -3647,7 +3649,7 @@ static void raid_resume(struct dm_target
 
 static struct target_type raid_target = {
 	.name = "raid",
-	.version = {1, 9, 0},
+	.version = {1, 9, 1},
 	.module = THIS_MODULE,
 	.ctr = raid_ctr,
 	.dtr = raid_dtr,

Greg Kroah-Hartman

author maintainer

2016-11-09 11:09 UTC #83 lore raw

PATCH 88/138 rtl8xxxu: Fix memory leak in handling rxdesc16 packets

4.8-stable review patch. If anyone has any objections, please let me know.

------------------

From: Jes Sorensen <[email protected]>

commit 1e54134ccad00f76ddf00f3e77db3dc8fdefbb47 upstream.

A device running without RX package aggregation could return more data in the USB packet than the actual network packet. In this case we could would clone the skb but then determine that that there was no packet to handle and exit without freeing the cloned skb first.

This has so far only been observed with 8188eu devices, but could affect others.

Signed-off-by Jes Sorensen <[email protected]>

Signed-off-by Kalle Valo <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c |    7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c +6 -1

@@ -5201,7 +5201,12 @@ int rtl8xxxu_parse_rxdesc16(struct rtl8x
 		pkt_offset = roundup(pkt_len + drvinfo_sz + desc_shift +
 				     sizeof(struct rtl8xxxu_rxdesc16), 128);
 
-		if (pkt_cnt > 1)
+		/*
+		 * Only clone the skb if there's enough data at the end to
+		 * at least cover the rx descriptor
+		 */
+		if (pkt_cnt > 1 &&
+		    urb_len > (pkt_offset + sizeof(struct rtl8xxxu_rxdesc16)))
 			next_skb = skb_clone(skb, GFP_ATOMIC);
 
 		rx_status = IEEE80211_SKB_RXCB(skb);

Greg Kroah-Hartman

author maintainer

2016-11-09 11:09 UTC #84 lore raw

PATCH 89/138 rtl8xxxu: Fix big-endian problem reporting mactime

4.8-stable review patch. If anyone has any objections, please let me know.

------------------

From: Jes Sorensen <[email protected]>

commit 8a55698f2f29d227825173420d7b99b9277ca88c upstream.

The full RX descriptor is converted so converting tsfl again would return it to it's original endian value.

Signed-off-by Jes Sorensen <[email protected]>

Signed-off-by Kalle Valo <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h      |    4 ++--
 drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c |    4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h +2 -2

@@ -231,7 +231,7 @@ struct rtl8xxxu_rxdesc16 {
 	u32 pattern1match:1;
 	u32 pattern0match:1;
 #endif
-	__le32 tsfl;
+	u32 tsfl;
 #if 0
 	u32 bassn:12;
 	u32 bavld:1;

@@ -361,7 +361,7 @@ struct rtl8xxxu_rxdesc24 {
 	u32 ldcp:1;
 	u32 splcp:1;
 #endif
-	__le32 tsfl;
+	u32 tsfl;
 };
 
 struct rtl8xxxu_txdesc32 {

drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c +2 -2

@@ -5224,7 +5224,7 @@ int rtl8xxxu_parse_rxdesc16(struct rtl8x
 			rtl8xxxu_rx_parse_phystats(priv, rx_status, phy_stats,
 						   rx_desc->rxmcs);
 
-		rx_status->mactime = le32_to_cpu(rx_desc->tsfl);
+		rx_status->mactime = rx_desc->tsfl;
 		rx_status->flag |= RX_FLAG_MACTIME_START;
 
 		if (!rx_desc->swdec)

@@ -5294,7 +5294,7 @@ int rtl8xxxu_parse_rxdesc24(struct rtl8x
 		rtl8xxxu_rx_parse_phystats(priv, rx_status, phy_stats,
 					   rx_desc->rxmcs);
 
-	rx_status->mactime = le32_to_cpu(rx_desc->tsfl);
+	rx_status->mactime = rx_desc->tsfl;
 	rx_status->flag |= RX_FLAG_MACTIME_START;
 
 	if (!rx_desc->swdec)

Greg Kroah-Hartman

author maintainer

2016-11-09 11:09 UTC #85 lore raw

PATCH 90/138 rtl8xxxu: Fix rtl8723bu driver reload issue

4.8-stable review patch. If anyone has any objections, please let me know.

------------------

From: Jes Sorensen <[email protected]>

commit ab05e5ec81c76f3a852919c22984c885edd2414a upstream.

The generic disable_rf() function clears bits 22 and 23 in REG_RX_WAIT_CCA, however we did not re-enable them again in rtl8723b_enable_rf()

This resolves the problem for me with 8723bu devices not working again after reloading the driver.

Signed-off-by Jes Sorensen <[email protected]>

Signed-off-by Kalle Valo <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723b.c |    4 ++++
 1 file changed, 4 insertions(+)

drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723b.c +4 -0

@@ -1498,6 +1498,10 @@ static void rtl8723b_enable_rf(struct rt
 	u32 val32;
 	u8 val8;
 
+	val32 = rtl8xxxu_read32(priv, REG_RX_WAIT_CCA);
+	val32 |= (BIT(22) | BIT(23));
+	rtl8xxxu_write32(priv, REG_RX_WAIT_CCA, val32);
+
 	/*
 	 * No indication anywhere as to what 0x0790 does. The 2 antenna
 	 * vendor code preserves bits 6-7 here.

Greg Kroah-Hartman

author maintainer

2016-11-09 11:09 UTC #86 lore raw

PATCH 91/138 Input: i8042 - add XMG C504 to keyboard reset table

4.8-stable review patch. If anyone has any objections, please let me know.

------------------

From: Patrick Scheuring <[email protected]>

commit da25311c7ca8b0254a686fc0d597075b9aa3b683 upstream.

The Schenker XMG C504 is a rebranded Gigabyte P35 v2 laptop. Therefore it also needs a keyboard reset to detect the Elantech touchpad. Otherwise the touchpad appears to be dead.

With this patch the touchpad is detected:

$ dmesg | grep -E "(i8042|Elantech|elantech)"

[    2.675399] i8042: PNP: PS/2 Controller [PNP0303:PS2K,PNP0f13:PS2M] at 0x60,0x64 irq 1,12
[    2.680372] i8042: Attempting to reset device connected to KBD port
[    2.789037] serio: i8042 KBD port at 0x60,0x64 irq 1
[    2.791586] serio: i8042 AUX port at 0x60,0x64 irq 12
[    2.813840] input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input4
[    3.811431] psmouse serio1: elantech: assuming hardware version 4 (with firmware version 0x361f0e)
[    3.825424] psmouse serio1: elantech: Synaptics capabilities query result 0x00, 0x15, 0x0f.
[    3.839424] psmouse serio1: elantech: Elan sample query result 03, 58, 74
[    3.911349] input: ETPS/2 Elantech Touchpad as /devices/platform/i8042/serio1/input/input6

Signed-off-by Patrick Scheuring <[email protected]>

Signed-off-by Dmitry Torokhov <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/input/serio/i8042-x86ia64io.h |    7 +++++++
 1 file changed, 7 insertions(+)

drivers/input/serio/i8042-x86ia64io.h +7 -0

@@ -877,6 +877,13 @@ static const struct dmi_system_id __init
 			DMI_MATCH(DMI_PRODUCT_NAME, "P34"),
 		},
 	},
+	{
+		/* Schenker XMG C504 - Elantech touchpad */
+		.matches = {
+			DMI_MATCH(DMI_SYS_VENDOR, "XMG"),
+			DMI_MATCH(DMI_PRODUCT_NAME, "C504"),
+		},
+	},
 	{ }
 };

Greg Kroah-Hartman

author maintainer

2016-11-09 10:46 UTC #87 lore raw

PATCH 92/138 firewire: net: guard against rx buffer overflows

4.8-stable review patch. If anyone has any objections, please let me know.

------------------

From: Stefan Richter <[email protected]>

commit 667121ace9dbafb368618dbabcf07901c962ddac upstream.

The IP-over-1394 driver firewire-net lacked input validation when handling incoming fragmented datagrams. A maliciously formed fragment with a respectively large datagram_offset would cause a memcpy past the datagram buffer.

So, drop any packets carrying a fragment with offset + length larger than datagram_size.

In addition, ensure that
- GASP header, unfragmented encapsulation header, or fragment encapsulation header actually exists before we access it,
- the encapsulated datagram or fragment is of nonzero size.

Reported-by Eyal Itkin <[email protected]>

Reviewed-by Eyal Itkin <[email protected]>

Fixes CVE 2016-8633

Signed-off-by Stefan Richter <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/firewire/net.c |   51 +++++++++++++++++++++++++++++++++----------------
 1 file changed, 35 insertions(+), 16 deletions(-)

drivers/firewire/net.c +35 ~~-16~~

@@ -578,6 +578,9 @@ static int fwnet_incoming_packet(struct
 	int retval;
 	u16 ether_type;
 
+	if (len <= RFC2374_UNFRAG_HDR_SIZE)
+		return 0;
+
 	hdr.w0 = be32_to_cpu(buf[0]);
 	lf = fwnet_get_hdr_lf(&hdr);
 	if (lf == RFC2374_HDR_UNFRAG) {

@@ -602,7 +605,12 @@ static int fwnet_incoming_packet(struct
 		return fwnet_finish_incoming_packet(net, skb, source_node_id,
 						    is_broadcast, ether_type);
 	}
+
 	/* A datagram fragment has been received, now the fun begins. */
+
+	if (len <= RFC2374_FRAG_HDR_SIZE)
+		return 0;
+
 	hdr.w1 = ntohl(buf[1]);
 	buf += 2;
 	len -= RFC2374_FRAG_HDR_SIZE;

@@ -616,6 +624,9 @@ static int fwnet_incoming_packet(struct
 	datagram_label = fwnet_get_hdr_dgl(&hdr);
 	dg_size = fwnet_get_hdr_dg_size(&hdr); /* ??? + 1 */
 
+	if (fg_off + len > dg_size)
+		return 0;
+
 	spin_lock_irqsave(&dev->lock, flags);
 
 	peer = fwnet_peer_find_by_node_id(dev, source_node_id, generation);

@@ -722,6 +733,22 @@ static void fwnet_receive_packet(struct
 	fw_send_response(card, r, rcode);
 }
 
+static int gasp_source_id(__be32 *p)
+{
+	return be32_to_cpu(p[0]) >> 16;
+}
+
+static u32 gasp_specifier_id(__be32 *p)
+{
+	return (be32_to_cpu(p[0]) & 0xffff) << 8 |
+	       (be32_to_cpu(p[1]) & 0xff000000) >> 24;
+}
+
+static u32 gasp_version(__be32 *p)
+{
+	return be32_to_cpu(p[1]) & 0xffffff;
+}
+
 static void fwnet_receive_broadcast(struct fw_iso_context *context,
 		u32 cycle, size_t header_length, void *header, void *data)
 {

@@ -731,9 +758,6 @@ static void fwnet_receive_broadcast(stru
 	__be32 *buf_ptr;
 	int retval;
 	u32 length;
-	u16 source_node_id;
-	u32 specifier_id;
-	u32 ver;
 	unsigned long offset;
 	unsigned long flags;

@@ -750,22 +774,17 @@ static void fwnet_receive_broadcast(stru
 
 	spin_unlock_irqrestore(&dev->lock, flags);
 
-	specifier_id =    (be32_to_cpu(buf_ptr[0]) & 0xffff) << 8
-			| (be32_to_cpu(buf_ptr[1]) & 0xff000000) >> 24;
-	ver = be32_to_cpu(buf_ptr[1]) & 0xffffff;
-	source_node_id = be32_to_cpu(buf_ptr[0]) >> 16;
-
-	if (specifier_id == IANA_SPECIFIER_ID &&
-	    (ver == RFC2734_SW_VERSION
+	if (length > IEEE1394_GASP_HDR_SIZE &&
+	    gasp_specifier_id(buf_ptr) == IANA_SPECIFIER_ID &&
+	    (gasp_version(buf_ptr) == RFC2734_SW_VERSION
 #if IS_ENABLED(CONFIG_IPV6)
-	     || ver == RFC3146_SW_VERSION
+	     || gasp_version(buf_ptr) == RFC3146_SW_VERSION
 #endif
-	    )) {
-		buf_ptr += 2;
-		length -= IEEE1394_GASP_HDR_SIZE;
-		fwnet_incoming_packet(dev, buf_ptr, length, source_node_id,
+	    ))
+		fwnet_incoming_packet(dev, buf_ptr + 2,
+				      length - IEEE1394_GASP_HDR_SIZE,
+				      gasp_source_id(buf_ptr),
 				      context->card->generation, true);
-	}
 
 	packet.payload_length = dev->rcv_buffer_size;
 	packet.interrupt = 1;

Greg Kroah-Hartman

author maintainer

2016-11-09 10:46 UTC #88 lore raw

PATCH 93/138 firewire: net: fix fragmented datagram_size off-by-one

4.8-stable review patch. If anyone has any objections, please let me know.

------------------

From: Stefan Richter <[email protected]>

commit e9300a4b7bbae83af1f7703938c94cf6dc6d308f upstream.

RFC 2734 defines the datagram_size field in fragment encapsulation headers thus:

datagram_size: The encoded size of the entire IP datagram. The value of datagram_size [...] SHALL be one less than the value of Total Length in the datagram's IP header (see STD 5, RFC 791).

Accordingly, the eth1394 driver of Linux 2.6.36 and older set and got this field with a -/+1 offset:

    ether1394_tx() /* transmit */
        ether1394_encapsulate_prep()
            hdr->ff.dg_size = dg_size - 1;

    ether1394_data_handler() /* receive */
        if (hdr->common.lf == ETH1394_HDR_LF_FF)
            dg_size = hdr->ff.dg_size + 1;
        else
            dg_size = hdr->sf.dg_size + 1;

Likewise, I observe OS X 10.4 and Windows XP Pro SP3 to transmit 1500 byte sized datagrams in fragments with datagram_size=1499 if link fragmentation is required.

Only firewire-net sets and gets datagram_size without this offset. The result is lacking interoperability of firewire-net with OS X, Windows XP, and presumably Linux' eth1394. (I did not test with the latter.) For example, FTP data transfers to a Linux firewire-net box with max_rec smaller than the 1500 bytes MTU
- from OS X fail entirely,
- from Win XP start out with a bunch of fragmented datagrams which time out, then continue with unfragmented datagrams because Win XP temporarily reduces the MTU to 576 bytes.

So let's fix firewire-net's datagram_size accessors.

Note that firewire-net thereby loses interoperability with unpatched firewire-net, but only if link fragmentation is employed. (This happens with large broadcast datagrams, and with large datagrams on several FireWire CardBus cards with smaller max_rec than equivalent PCI cards, and it can be worked around by setting a small enough MTU.)

Signed-off-by Stefan Richter <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/firewire/net.c |    8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

drivers/firewire/net.c +4 -4

@@ -73,13 +73,13 @@ struct rfc2734_header {
 
 #define fwnet_get_hdr_lf(h)		(((h)->w0 & 0xc0000000) >> 30)
 #define fwnet_get_hdr_ether_type(h)	(((h)->w0 & 0x0000ffff))
-#define fwnet_get_hdr_dg_size(h)	(((h)->w0 & 0x0fff0000) >> 16)
+#define fwnet_get_hdr_dg_size(h)	((((h)->w0 & 0x0fff0000) >> 16) + 1)
 #define fwnet_get_hdr_fg_off(h)		(((h)->w0 & 0x00000fff))
 #define fwnet_get_hdr_dgl(h)		(((h)->w1 & 0xffff0000) >> 16)
 
-#define fwnet_set_hdr_lf(lf)		((lf)  << 30)
+#define fwnet_set_hdr_lf(lf)		((lf) << 30)
 #define fwnet_set_hdr_ether_type(et)	(et)
-#define fwnet_set_hdr_dg_size(dgs)	((dgs) << 16)
+#define fwnet_set_hdr_dg_size(dgs)	(((dgs) - 1) << 16)
 #define fwnet_set_hdr_fg_off(fgo)	(fgo)
 
 #define fwnet_set_hdr_dgl(dgl)		((dgl) << 16)

@@ -622,7 +622,7 @@ static int fwnet_incoming_packet(struct
 		fg_off = fwnet_get_hdr_fg_off(&hdr);
 	}
 	datagram_label = fwnet_get_hdr_dgl(&hdr);
-	dg_size = fwnet_get_hdr_dg_size(&hdr); /* ??? + 1 */
+	dg_size = fwnet_get_hdr_dg_size(&hdr);
 
 	if (fg_off + len > dg_size)
 		return 0;

Greg Kroah-Hartman

author maintainer

2016-11-09 11:11 UTC #89 lore raw

PATCH 94/138 mac80211: discard multicast and 4-addr A-MSDUs

4.8-stable review patch. If anyone has any objections, please let me know.

------------------

From: Johannes Berg <[email protected]>

commit ea720935cf6686f72def9d322298bf7e9bd53377 upstream.

In mac80211, multicast A-MSDUs are accepted in many cases that they shouldn't be accepted in:
* drop A-MSDUs with a multicast A1 (RA), as required by the spec in 9.11 (802.11-2012 version)
* drop A-MSDUs with a 4-addr header, since the fourth address can't actually be useful for them; unless 4-address frame format is actually requested, even though the fourth address is still not useful in this case, but ignored

Accepting the first case, in particular, is very problematic since it allows anyone else with possession of a GTK to send unicast frames encapsulated in a multicast A-MSDU, even when the AP has client isolation enabled.

Signed-off-by Johannes Berg <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 net/mac80211/rx.c |   24 +++++++++++++++---------
 1 file changed, 15 insertions(+), 9 deletions(-)

net/mac80211/rx.c +15 -9

@@ -2253,16 +2253,22 @@ ieee80211_rx_h_amsdu(struct ieee80211_rx
 	if (!(status->rx_flags & IEEE80211_RX_AMSDU))
 		return RX_CONTINUE;
 
-	if (ieee80211_has_a4(hdr->frame_control) &&
-	    rx->sdata->vif.type == NL80211_IFTYPE_AP_VLAN &&
-	    !rx->sdata->u.vlan.sta)
-		return RX_DROP_UNUSABLE;
+	if (unlikely(ieee80211_has_a4(hdr->frame_control))) {
+		switch (rx->sdata->vif.type) {
+		case NL80211_IFTYPE_AP_VLAN:
+			if (!rx->sdata->u.vlan.sta)
+				return RX_DROP_UNUSABLE;
+			break;
+		case NL80211_IFTYPE_STATION:
+			if (!rx->sdata->u.mgd.use_4addr)
+				return RX_DROP_UNUSABLE;
+			break;
+		default:
+			return RX_DROP_UNUSABLE;
+		}
+	}
 
-	if (is_multicast_ether_addr(hdr->addr1) &&
-	    ((rx->sdata->vif.type == NL80211_IFTYPE_AP_VLAN &&
-	      rx->sdata->u.vlan.sta) ||
-	     (rx->sdata->vif.type == NL80211_IFTYPE_STATION &&
-	      rx->sdata->u.mgd.use_4addr)))
+	if (is_multicast_ether_addr(hdr->addr1))
 		return RX_DROP_UNUSABLE;
 
 	skb->dev = dev;

Greg Kroah-Hartman

author maintainer

2016-11-09 11:09 UTC #90 lore raw

PATCH 95/138 Revert "ath9k_hw: implement temperature compensation support for AR9003+"

4.8-stable review patch. If anyone has any objections, please let me know.

------------------

From: Felix Fietkau <[email protected]>

commit 304e5ac118cc351eb047b6c433a89e13ea7259cf upstream.

This reverts commit 171f6402e4aa ("ath9k_hw: implement temperature compensation support for AR9003+"). Some users report that this commit causes a regression in performance under some conditions.

Fixes 171f6402e4aa ("ath9k_hw: implement temperature compensation support for AR9003+")

Signed-off-by Felix Fietkau <[email protected]>

[[email protected]: improve commit log]

Signed-off-by Kalle Valo <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/net/wireless/ath/ath9k/ar9003_calib.c |   25 +++----------------------
 drivers/net/wireless/ath/ath9k/hw.h           |    1 -
 2 files changed, 3 insertions(+), 23 deletions(-)

drivers/net/wireless/ath/ath9k/ar9003_calib.c +3 ~~-22~~

@@ -33,7 +33,6 @@ struct coeff {
 
 enum ar9003_cal_types {
 	IQ_MISMATCH_CAL = BIT(0),
-	TEMP_COMP_CAL = BIT(1),
 };
 
 static void ar9003_hw_setup_calibration(struct ath_hw *ah,

@@ -59,12 +58,6 @@ static void ar9003_hw_setup_calibration(
 		/* Kick-off cal */
 		REG_SET_BIT(ah, AR_PHY_TIMING4, AR_PHY_TIMING4_DO_CAL);
 		break;
-	case TEMP_COMP_CAL:
-		ath_dbg(common, CALIBRATE,
-			"starting Temperature Compensation Calibration\n");
-		REG_SET_BIT(ah, AR_CH0_THERM, AR_CH0_THERM_LOCAL);
-		REG_SET_BIT(ah, AR_CH0_THERM, AR_CH0_THERM_START);
-		break;
 	default:
 		ath_err(common, "Invalid calibration type\n");
 		break;

@@ -93,8 +86,7 @@ static bool ar9003_hw_per_calibration(st
 		/*
 		* Accumulate cal measures for active chains
 		*/
-		if (cur_caldata->calCollect)
-			cur_caldata->calCollect(ah);
+		cur_caldata->calCollect(ah);
 		ah->cal_samples++;
 
 		if (ah->cal_samples >= cur_caldata->calNumSamples) {

@@ -107,8 +99,7 @@ static bool ar9003_hw_per_calibration(st
 			/*
 			* Process accumulated data
 			*/
-			if (cur_caldata->calPostProc)
-				cur_caldata->calPostProc(ah, numChains);
+			cur_caldata->calPostProc(ah, numChains);
 
 			/* Calibration has finished. */
 			caldata->CalValid |= cur_caldata->calType;

@@ -323,16 +314,9 @@ static const struct ath9k_percal_data iq
 	ar9003_hw_iqcalibrate
 };
 
-static const struct ath9k_percal_data temp_cal_single_sample = {
-	TEMP_COMP_CAL,
-	MIN_CAL_SAMPLES,
-	PER_MAX_LOG_COUNT,
-};
-
 static void ar9003_hw_init_cal_settings(struct ath_hw *ah)
 {
 	ah->iq_caldata.calData = &iq_cal_single_sample;
-	ah->temp_caldata.calData = &temp_cal_single_sample;
 
 	if (AR_SREV_9300_20_OR_LATER(ah)) {
 		ah->enabled_cals |= TX_IQ_CAL;

@@ -340,7 +324,7 @@ static void ar9003_hw_init_cal_settings(
 			ah->enabled_cals |= TX_IQ_ON_AGC_CAL;
 	}
 
-	ah->supp_cals = IQ_MISMATCH_CAL | TEMP_COMP_CAL;
+	ah->supp_cals = IQ_MISMATCH_CAL;
 }
 
 #define OFF_UPPER_LT 24

@@ -1399,9 +1383,6 @@ static void ar9003_hw_init_cal_common(st
 	INIT_CAL(&ah->iq_caldata);
 	INSERT_CAL(ah, &ah->iq_caldata);
 
-	INIT_CAL(&ah->temp_caldata);
-	INSERT_CAL(ah, &ah->temp_caldata);
-
 	/* Initialize current pointer to first element in list */
 	ah->cal_list_curr = ah->cal_list;

drivers/net/wireless/ath/ath9k/hw.h +0 -1

@@ -830,7 +830,6 @@ struct ath_hw {
 	/* Calibration */
 	u32 supp_cals;
 	struct ath9k_cal_list iq_caldata;
-	struct ath9k_cal_list temp_caldata;
 	struct ath9k_cal_list adcgain_caldata;
 	struct ath9k_cal_list adcdc_caldata;
 	struct ath9k_cal_list *cal_list;

Greg Kroah-Hartman

author maintainer

2016-11-09 10:46 UTC #91 lore raw

PATCH 96/138 ath10k: cache calibration data when the core is stopped

4.8-stable review patch. If anyone has any objections, please let me know.

------------------

From: Marty Faltesek <[email protected]>

commit f67b107d4ceddcf7aa65b706aaaf50d68edb52a6 upstream.

Commit 0b8e3c4ca29f ("ath10k: move cal data len to hw_params") broke retrieving the calibration data from cal_data debugfs file. The length of file was always zero. The reason is:

static ssize_t ath10k_debug_cal_data_read(struct file *file,
char __user *user_buf, size_t count, loff_t *ppos)
{
struct ath10k *ar = file->private_data;
void *buf = file->private_data;

This is obviously bogus, private_data cannot contain both struct ath10k and the buffer. Fix it by caching calibration data to ar->debug.cal_data. This also allows it to be accessed when the device is not active (interface is down).

The cal_data buffer is fixed size because during the first firmware probe we don't yet know what will be the lenght of the calibration data. It was simplest just to use a fixed length. There's a WARN_ON() in ath10k_debug_cal_data_fetch() if the buffer is too small.

Tested with qca988x and firmware 10.2.4.70.56.

Reported-by Nikolay Martynov <[email protected]>

Fixes 0b8e3c4ca29f ("ath10k: move cal data len to hw_params")

Signed-off-by Marty Faltesek <[email protected]>

[[email protected]: improve commit log and minor other changes]

Signed-off-by Kalle Valo <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/net/wireless/ath/ath10k/core.h  |    1 
 drivers/net/wireless/ath/ath10k/debug.c |   75 ++++++++++++++++----------------
 2 files changed, 40 insertions(+), 36 deletions(-)

drivers/net/wireless/ath/ath10k/core.h +1 -0

@@ -445,6 +445,7 @@ struct ath10k_debug {
 	u32 pktlog_filter;
 	u32 reg_addr;
 	u32 nf_cal_period;
+	void *cal_data;
 
 	struct ath10k_fw_crash_data *fw_crash_data;
 };

drivers/net/wireless/ath/ath10k/debug.c +39 ~~-36~~

144 lines not on this page · raw message

Greg Kroah-Hartman

author maintainer

2016-11-09 11:10 UTC #92 lore raw

PATCH 97/138 scsi: scsi_debug: Fix memory leak if LBP enabled and module is unloaded

4.8-stable review patch. If anyone has any objections, please let me know.

------------------

From: Ewan D. Milne <[email protected]>

commit 4d2b496f19f3c2cfaca1e8fa0710688b5ff3811d upstream.

map_storep was not being vfree()'d in the module_exit call.

Signed-off-by Ewan D. Milne <[email protected]>

Reviewed-by Laurence Oberman <[email protected]>

Signed-off-by Martin K. Petersen <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/scsi/scsi_debug.c |    1 +
 1 file changed, 1 insertion(+)

drivers/scsi/scsi_debug.c +1 -0

@@ -5134,6 +5134,7 @@ static void __exit scsi_debug_exit(void)
 	bus_unregister(&pseudo_lld_bus);
 	root_device_unregister(pseudo_primary);
 
+	vfree(map_storep);
 	vfree(dif_storep);
 	vfree(fake_storep);
 	kfree(sdebug_q_arr);

Greg Kroah-Hartman

author maintainer

2016-11-09 11:11 UTC #93 lore raw

PATCH 98/138 scsi: arcmsr: Send SYNCHRONIZE_CACHE command to firmware

4.8-stable review patch. If anyone has any objections, please let me know.

------------------

From: Ching Huang <[email protected]>

commit 2bf7dc8443e113844d078fd6541b7f4aa544f92f upstream.

The arcmsr driver failed to pass SYNCHRONIZE CACHE to controller firmware. Depending on how drive caches are handled internally by controller firmware this could potentially lead to data integrity problems.

Ensure that cache flushes are passed to the controller.

[mkp: applied by hand and removed unused vars]

Signed-off-by Ching Huang <[email protected]>

Reported-by Tomas Henzl <[email protected]>

Signed-off-by Martin K. Petersen <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/scsi/arcmsr/arcmsr_hba.c |    9 ---------
 1 file changed, 9 deletions(-)

drivers/scsi/arcmsr/arcmsr_hba.c +0 -9

@@ -2636,18 +2636,9 @@ static int arcmsr_queue_command_lck(stru
 	struct AdapterControlBlock *acb = (struct AdapterControlBlock *) host->hostdata;
 	struct CommandControlBlock *ccb;
 	int target = cmd->device->id;
-	int lun = cmd->device->lun;
-	uint8_t scsicmd = cmd->cmnd[0];
 	cmd->scsi_done = done;
 	cmd->host_scribble = NULL;
 	cmd->result = 0;
-	if ((scsicmd == SYNCHRONIZE_CACHE) ||(scsicmd == SEND_DIAGNOSTIC)){
-		if(acb->devstate[target][lun] == ARECA_RAID_GONE) {
-    			cmd->result = (DID_NO_CONNECT << 16);
-		}
-		cmd->scsi_done(cmd);
-		return 0;
-	}
 	if (target == 16) {
 		/* virtual device for iop message transfer */
 		arcmsr_handle_virtual_command(acb, cmd);

Greg Kroah-Hartman

author maintainer

2016-11-09 11:11 UTC #94 lore raw

PATCH 99/138 mmc: dw_mmc-pltfm: fix the potential NULL pointer dereference

4.8-stable review patch. If anyone has any objections, please let me know.

------------------

From: Jaehoon Chung <[email protected]>

commit 45c7a4908a307a023e237a64a3eadcafc4836493 upstream.

platform_get_resource can be returned the NULL pointer. Then regs->start should be referred to NULL Pointer. devm_ioremap_resource() checks whether res is NULL or not.

Signed-off-by Jaehoon Chung <[email protected]>

Reviewed-by Shawn Lin <[email protected]>

Signed-off-by Ulf Hansson <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/mmc/host/dw_mmc-pltfm.c |    5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

drivers/mmc/host/dw_mmc-pltfm.c +3 -2

@@ -46,12 +46,13 @@ int dw_mci_pltfm_register(struct platfor
 	host->pdata = pdev->dev.platform_data;
 
 	regs = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-	/* Get registers' physical base address */
-	host->phy_regs = regs->start;
 	host->regs = devm_ioremap_resource(&pdev->dev, regs);
 	if (IS_ERR(host->regs))
 		return PTR_ERR(host->regs);
 
+	/* Get registers' physical base address */
+	host->phy_regs = regs->start;
+
 	platform_set_drvdata(pdev, host);
 	return dw_mci_probe(host);
 }

Greg Kroah-Hartman

author maintainer

2016-11-09 11:11 UTC #95 lore raw

PATCH 100/138 RAID1: ignore discard error

4.8-stable review patch. If anyone has any objections, please let me know.

------------------

From: Shaohua Li <[email protected]>

commit e3f948cd3283e4fbe5907f1f3967c839912f480e upstream.

If a write error occurs, raid1 will try to rewrite the bio in small chunk size. If the rewrite fails, raid1 will record the error in bad block. narrow_write_error will always use WRITE for the bio, but actually it could be a discard. Since discard bio hasn't payload, write the bio will cause different issues. But discard error isn't fatal, we can safely ignore it. This is what this patch does.

This issue should exist since discard is added, but only exposed with recent arbitrary bio size feature.

Reported-and-tested-by Sitsofe Wheeler <[email protected]>

Signed-off-by Shaohua Li <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/md/raid1.c |    7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

drivers/md/raid1.c +5 -2

@@ -407,11 +407,14 @@ static void raid1_end_write_request(stru
 	struct bio *to_put = NULL;
 	int mirror = find_bio_disk(r1_bio, bio);
 	struct md_rdev *rdev = conf->mirrors[mirror].rdev;
+	bool discard_error;
+
+	discard_error = bio->bi_error && bio_op(bio) == REQ_OP_DISCARD;
 
 	/*
 	 * 'one mirror IO has finished' event handler:
 	 */
-	if (bio->bi_error) {
+	if (bio->bi_error && !discard_error) {
 		set_bit(WriteErrorSeen,	&rdev->flags);
 		if (!test_and_set_bit(WantReplacement, &rdev->flags))
 			set_bit(MD_RECOVERY_NEEDED, &

@@ -448,7 +451,7 @@ static void raid1_end_write_request(stru
 
 		/* Maybe we can clear some bad blocks. */
 		if (is_badblock(rdev, r1_bio->sector, r1_bio->sectors,
-				&first_bad, &bad_sectors)) {
+				&first_bad, &bad_sectors) && !discard_error) {
 			r1_bio->bios[mirror] = IO_MADE_GOOD;
 			set_bit(R1BIO_MadeGood, &r1_bio->state);
 		}

Greg Kroah-Hartman

author maintainer

2016-11-09 10:46 UTC #96 lore raw

PATCH 101/138 RAID10: ignore discard error

4.8-stable review patch. If anyone has any objections, please let me know.

------------------

From: Shaohua Li <[email protected]>

commit 579ed34f7b751b8add233cba4cf755258dbdd60a upstream.

This is the counterpart of raid10 fix. If a write error occurs, raid10 will try to rewrite the bio in small chunk size. If the rewrite fails, raid10 will record the error in bad block. narrow_write_error will always use WRITE for the bio, but actually it could be a discard. Since discard bio hasn't payload, write the bio will cause different issues. But discard error isn't fatal, we can safely ignore it. This is what this patch does.

This issue should exist since discard is added, but only exposed with recent arbitrary bio size feature.

Cc Sitsofe Wheeler <[email protected]>

Signed-off-by Shaohua Li <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/md/raid10.c |    7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

drivers/md/raid10.c +5 -2

@@ -447,6 +447,9 @@ static void raid10_end_write_request(str
 	struct r10conf *conf = r10_bio->mddev->private;
 	int slot, repl;
 	struct md_rdev *rdev = NULL;
+	bool discard_error;
+
+	discard_error = bio->bi_error && bio_op(bio) == REQ_OP_DISCARD;
 
 	dev = find_bio_disk(conf, r10_bio, bio, &slot, &repl);

@@ -460,7 +463,7 @@ static void raid10_end_write_request(str
 	/*
 	 * this branch is our 'one mirror IO has finished' event handler:
 	 */
-	if (bio->bi_error) {
+	if (bio->bi_error && !discard_error) {
 		if (repl)
 			/* Never record new bad blocks to replacement,
 			 * just fail it.

@@ -503,7 +506,7 @@ static void raid10_end_write_request(str
 		if (is_badblock(rdev,
 				r10_bio->devs[slot].addr,
 				r10_bio->sectors,
-				&first_bad, &bad_sectors)) {
+				&first_bad, &bad_sectors) && !discard_error) {
 			bio_put(bio);
 			if (repl)
 				r10_bio->devs[slot].repl_bio = IO_MADE_GOOD;

Greg Kroah-Hartman

author maintainer

2016-11-09 11:11 UTC #97 lore raw

PATCH 102/138 md: be careful not lot leak internal curr_resync value into metadata. -- (all)

4.8-stable review patch. If anyone has any objections, please let me know.

------------------

From: NeilBrown <[email protected]>

commit 1217e1d1999ed6c9c1e1b1acae0a74ab70464ae2 upstream.

mddev->curr_resync usually records where the current resync is up to, but during the starting phase it has some "magic" values.

1 - means that the array is trying to start a resync, but has yielded
to another array which shares physical devices, and also needs to start a resync
2 - means the array is trying to start resync, but has found another
array which shares physical devices and has already started resync.

3 - means that resync has commensed, but it is possible that nothing
has actually been resynced yet.

It is important that this value not be visible to user-space and particularly that it doesn't get written to the metadata, as the resync or recovery checkpoint. In part, this is because it may be slightly higher than the correct value, though this is very rare. In part, because it is not a multiple of 4K, and some devices only support 4K aligned accesses.

There are two places where this value is propagates into either ->curr_resync_completed or ->recovery_cp or ->recovery_offset. These currently avoid the propagation of values 1 and 3, but will allow 3 to leak through.

Change them to only propagate the value if it is > 3.

As this can cause an array to fail, the patch is suitable for -stable.

Reported-by Viswesh <[email protected]>

Signed-off-by NeilBrown <[email protected]>

Signed-off-by Shaohua Li <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/md/md.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

drivers/md/md.c +2 -2

@@ -8120,14 +8120,14 @@ void md_do_sync(struct md_thread *thread
 
 	if (!test_bit(MD_RECOVERY_RESHAPE, &mddev->recovery) &&
 	    !test_bit(MD_RECOVERY_INTR, &mddev->recovery) &&
-	    mddev->curr_resync > 2) {
+	    mddev->curr_resync > 3) {
 		mddev->curr_resync_completed = mddev->curr_resync;
 		sysfs_notify(&mddev->kobj, NULL, "sync_completed");
 	}
 	mddev->pers->sync_request(mddev, max_sectors, &skipped);
 
 	if (!test_bit(MD_RECOVERY_CHECK, &mddev->recovery) &&
-	    mddev->curr_resync > 2) {
+	    mddev->curr_resync > 3) {
 		if (test_bit(MD_RECOVERY_SYNC, &mddev->recovery)) {
 			if (test_bit(MD_RECOVERY_INTR, &mddev->recovery)) {
 				if (mddev->curr_resync >= mddev->recovery_cp) {

Greg Kroah-Hartman

author maintainer

2016-11-09 11:09 UTC #98 lore raw

PATCH 104/138 drm/imx: ipuv3-plane: Switch EBA buffer only when we dont need modeset

4.8-stable review patch. If anyone has any objections, please let me know.

------------------

From: Liu Ying <[email protected]>

commit 43daa01323da37a3692cabe1579ef5c2c4372e06 upstream.

We added active plane reconfiguration support by forcing a full modeset operation. So, looking at old_plane_state->fb to determine whether we need to switch EBA buffer(for hardware double buffering) in ipu_plane_atomic_set_base() or not is no more correct. Instead, we should do that only when we don't need modeset, otherwise, we initialize the two EBA buffers with the buffer address.

Fixes c6c1f9bc798b ("drm/imx: Add active plane reconfiguration support")

Signed-off-by Liu Ying <[email protected]>

Signed-off-by Philipp Zabel <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/gpu/drm/imx/ipuv3-plane.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

drivers/gpu/drm/imx/ipuv3-plane.c +2 -1

@@ -108,6 +108,7 @@ static void ipu_plane_atomic_set_base(st
 {
 	struct drm_plane *plane = &ipu_plane->base;
 	struct drm_plane_state *state = plane->state;
+	struct drm_crtc_state *crtc_state = state->crtc->state;
 	struct drm_framebuffer *fb = state->fb;
 	unsigned long eba, ubo, vbo;
 	int active;

@@ -149,7 +150,7 @@ static void ipu_plane_atomic_set_base(st
 		break;
 	}
 
-	if (old_state->fb) {
+	if (!drm_atomic_crtc_needs_modeset(crtc_state)) {
 		active = ipu_idmac_get_current_buffer(ipu_plane->ipu_ch);
 		ipu_cpmem_set_buffer(ipu_plane->ipu_ch, !active, eba);
 		ipu_idmac_select_buffer(ipu_plane->ipu_ch, !active);

Greg Kroah-Hartman

author maintainer

2016-11-09 10:46 UTC #99 lore raw

PATCH 105/138 drm/imx: ipuv3-plane: Access old u/vbo properly in ->atomic_check for YU12/YV12

Link https://bugs.freedesktop.org/show_bug.cgi?id=98150

4.8-stable review patch. If anyone has any objections, please let me know.

------------------

From: Liu Ying <[email protected]>

commit e73aca5184ad9fc948ba22b4d35dce11db35bb25 upstream.

Before accessing the u/v offset(aka, u/vbo for IPUv3) of the old plane state's relevant fb, we should make sure the fb is in YU12 or YV12 pixel format(which are the two YUV pixel formats we support only), otherwise, we are likely to trigger BUG_ON() in drm_plane_state_to_u/vbo() since the fb's pixel format is probably not YU12 or YV12.

Fixes c6c1f9bc798b ("drm/imx: Add active plane reconfiguration support")

Signed-off-by Liu Ying <[email protected]>

Signed-off-by Philipp Zabel <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/gpu/drm/imx/ipuv3-plane.c |    4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

drivers/gpu/drm/imx/ipuv3-plane.c +3 -1

@@ -360,7 +360,9 @@ static int ipu_plane_atomic_check(struct
 		if ((ubo > 0xfffff8) || (vbo > 0xfffff8))
 			return -EINVAL;
 
-		if (old_fb) {
+		if (old_fb &&
+		    (old_fb->pixel_format == DRM_FORMAT_YUV420 ||
+		     old_fb->pixel_format == DRM_FORMAT_YVU420)) {
 			old_ubo = drm_plane_state_to_ubo(old_state);
 			old_vbo = drm_plane_state_to_vbo(old_state);
 			if (ubo != old_ubo || vbo != old_vbo)

Greg Kroah-Hartman

author maintainer

2016-11-09 10:46 UTC #100 lore raw

PATCH 106/138 drm/radeon/si_dpm: Limit clocks on HD86xx part

4.8-stable review patch. If anyone has any objections, please let me know.

------------------

From: Tom St Denis <[email protected]>

commit fb9a5b0c1c9893db2e0d18544fd49e19d784a87d upstream.

Limit clocks on a specific HD86xx part to avoid crashes (while awaiting an appropriate PP fix).

Signed-off-by Tom St Denis <[email protected]>

Reviewed-by Alex Deucher <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/gpu/drm/radeon/si_dpm.c |    6 ++++++
 1 file changed, 6 insertions(+)

drivers/gpu/drm/radeon/si_dpm.c +6 -0

@@ -3021,6 +3021,12 @@ static void si_apply_state_adjust_rules(
 		max_sclk = 75000;
 		max_mclk = 80000;
 	}
+	/* limit clocks on HD8600 series */
+	if (rdev->pdev->device == 0x6660 &&
+	    rdev->pdev->revision == 0x83) {
+		max_sclk = 75000;
+		max_mclk = 80000;
+	}
 
 	if (rps->vce_active) {
 		rps->evclk = rdev->pm.dpm.vce_states[rdev->pm.dpm.vce_level].evclk;

Greg Kroah-Hartman

author maintainer

2016-11-09 11:09 UTC #101 lore raw

PATCH 107/138 drm/radeon/si_dpm: workaround for SI kickers

4.8-stable review patch. If anyone has any objections, please let me know.

------------------

From: Alex Deucher <[email protected]>

commit 7dc86ef5ac91642dfc3eb93ee0f0458e702a343e upstream.

Consolidate existing quirks. Fixes stability issues on some kickers.

Signed-off-by Alex Deucher <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/gpu/drm/radeon/si_dpm.c |   59 +++++++++++++++++++++++++++++-----------
 1 file changed, 43 insertions(+), 16 deletions(-)

drivers/gpu/drm/radeon/si_dpm.c +43 ~~-16~~

@@ -2999,6 +2999,49 @@ static void si_apply_state_adjust_rules(
 	int i;
 	struct si_dpm_quirk *p = si_dpm_quirk_list;
 
+	/* limit all SI kickers */
+	if (rdev->family == CHIP_PITCAIRN) {
+		if ((rdev->pdev->revision == 0x81) ||
+		    (rdev->pdev->device == 0x6810) ||
+		    (rdev->pdev->device == 0x6811) ||
+		    (rdev->pdev->device == 0x6816) ||
+		    (rdev->pdev->device == 0x6817) ||
+		    (rdev->pdev->device == 0x6806))
+			max_mclk = 120000;
+	} else if (rdev->family == CHIP_VERDE) {
+		if ((rdev->pdev->revision == 0x81) ||
+		    (rdev->pdev->revision == 0x83) ||
+		    (rdev->pdev->revision == 0x87) ||
+		    (rdev->pdev->device == 0x6820) ||
+		    (rdev->pdev->device == 0x6821) ||
+		    (rdev->pdev->device == 0x6822) ||
+		    (rdev->pdev->device == 0x6823) ||
+		    (rdev->pdev->device == 0x682A) ||
+		    (rdev->pdev->device == 0x682B)) {
+			max_sclk = 75000;
+			max_mclk = 80000;
+		}
+	} else if (rdev->family == CHIP_OLAND) {
+		if ((rdev->pdev->revision == 0xC7) ||
+		    (rdev->pdev->revision == 0x80) ||
+		    (rdev->pdev->revision == 0x81) ||
+		    (rdev->pdev->revision == 0x83) ||
+		    (rdev->pdev->device == 0x6604) ||
+		    (rdev->pdev->device == 0x6605)) {
+			max_sclk = 75000;
+			max_mclk = 80000;
+		}
+	} else if (rdev->family == CHIP_HAINAN) {
+		if ((rdev->pdev->revision == 0x81) ||
+		    (rdev->pdev->revision == 0x83) ||
+		    (rdev->pdev->revision == 0xC3) ||
+		    (rdev->pdev->device == 0x6664) ||
+		    (rdev->pdev->device == 0x6665) ||
+		    (rdev->pdev->device == 0x6667)) {
+			max_sclk = 75000;
+			max_mclk = 80000;
+		}
+	}
 	/* Apply dpm quirks */
 	while (p && p->chip_device != 0) {
 		if (rdev->pdev->vendor == p->chip_vendor &&

@@ -3011,22 +3054,6 @@ static void si_apply_state_adjust_rules(
 		}
 		++p;
 	}
-	/* limit mclk on all R7 370 parts for stability */
-	if (rdev->pdev->device == 0x6811 &&
-	    rdev->pdev->revision == 0x81)
-		max_mclk = 120000;
-	/* limit sclk/mclk on Jet parts for stability */
-	if (rdev->pdev->device == 0x6665 &&
-	    rdev->pdev->revision == 0xc3) {
-		max_sclk = 75000;
-		max_mclk = 80000;
-	}
-	/* limit clocks on HD8600 series */
-	if (rdev->pdev->device == 0x6660 &&
-	    rdev->pdev->revision == 0x83) {
-		max_sclk = 75000;
-		max_mclk = 80000;
-	}
 
 	if (rps->vce_active) {
 		rps->evclk = rdev->pm.dpm.vce_states[rdev->pm.dpm.vce_level].evclk;

Greg Kroah-Hartman

author maintainer

2016-11-09 11:09 UTC #102 lore raw

PATCH 109/138 drm/nouveau/acpi: fix check for power resources support

Link https://bugs.freedesktop.org/show_bug.cgi?id=98398

4.8-stable review patch. If anyone has any objections, please let me know.

------------------

From: Peter Wu <[email protected]>

commit b0a6af8b34c9ad20894aa46f85f4bf59d444f286 upstream.

Check whether the kernel really supports power resources for a device, otherwise the power might not be removed when the device is runtime suspended (DSM should still work in these cases where PR does not).

This is a workaround for a problem where ACPICA and Windows 10 differ in behavior. ACPICA does not correctly enumerate power resources within a conditional block (due to delayed execution of such blocks) and as a result power_resources is set to false even if _PR3 exists.

Fixes 692a17dcc292 ("drm/nouveau/acpi: fix lockup with PCIe runtime PM")

Reported-and-tested-by Rick Kerkhof <[email protected]>

Reviewed-by Mika Westerberg <[email protected]>

Signed-off-by Peter Wu <[email protected]>

Signed-off-by Dave Airlie <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/gpu/drm/nouveau/nouveau_acpi.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

drivers/gpu/drm/nouveau/nouveau_acpi.c +2 -1

@@ -240,7 +240,8 @@ static bool nouveau_pr3_present(struct p
 	if (!parent_adev)
 		return false;
 
-	return acpi_has_method(parent_adev->handle, "_PR3");
+	return parent_adev->power.flags.power_resources &&
+		acpi_has_method(parent_adev->handle, "_PR3");
 }
 
 static void nouveau_dsm_pci_probe(struct pci_dev *pdev, acpi_handle *dhandle_out,

Greg Kroah-Hartman

author maintainer

2016-11-09 11:10 UTC #103 lore raw

PATCH 113/138 drm/i915/gen9: fix DDB partitioning for multi-screen cases

Link http://patchwork.freedesktop.org/patch/msgid/[email protected]

4.8-stable review patch. If anyone has any objections, please let me know.

------------------

From: Paulo Zanoni <[email protected]>

commit 01c72d6c17dc524f04d4dbe361d214e423b35457 upstream.

With the previous code we were only recomputing the DDB partitioning for the CRTCs included in the atomic commit, so any other active CRTCs would end up having their DDB registers zeroed. In this patch we make sure that the computed state starts as a copy of the current partitioning, and then we only zero the DDBs that we're actually going to recompute.

How to reproduce the bug:
1 - Enable the primary plane on pipe A
2 - Enable the primary plane on pipe B
3 - Enable the cursor or sprite plane on pipe A

Step 3 will zero the DDB partitioning for pipe B since it's not included in the commit that enabled the cursor or sprite for pipe A.

I expect this to fix many FIFO underrun problems on gen9+.

v2:
- Mention the cursor on the steps to reproduce the problem (Paulo).
- Add Testcase tag provided by Maarten (Maarten).

Testcase: kms_cursor_legacy.cursorA-vs-flipB-atomic-transitions
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96226
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96828
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97450
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97596
Bugzilla: https://www.phoronix.com/scan.php?page=news_item&px=Intel-Skylake-Multi-Screen-Woes

Signed-off-by Paulo Zanoni <[email protected]>

Reviewed-by Lyude <[email protected]>

(cherry picked from commit 5a920b85f2c6e3fd7d9dd9bb3f3345e9085e2360)

Signed-off-by Jani Nikula <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/gpu/drm/i915/intel_pm.c |   12 ++++++++++--
 1 file changed, 10 insertions(+), 2 deletions(-)

drivers/gpu/drm/i915/intel_pm.c +10 -2

@@ -3363,13 +3363,15 @@ skl_allocate_pipe_ddb(struct intel_crtc_
 	int num_active;
 	int id, i;
 
+	/* Clear the partitioning for disabled planes. */
+	memset(ddb->plane[pipe], 0, sizeof(ddb->plane[pipe]));
+	memset(ddb->y_plane[pipe], 0, sizeof(ddb->y_plane[pipe]));
+
 	if (WARN_ON(!state))
 		return 0;
 
 	if (!cstate->base.active) {
 		ddb->pipe[pipe].start = ddb->pipe[pipe].end = 0;
-		memset(ddb->plane[pipe], 0, sizeof(ddb->plane[pipe]));
-		memset(ddb->y_plane[pipe], 0, sizeof(ddb->y_plane[pipe]));
 		return 0;
 	}

@@ -4051,6 +4053,12 @@ skl_compute_ddb(struct drm_atomic_state
 		intel_state->wm_results.dirty_pipes = ~0;
 	}
 
+	/*
+	 * We're not recomputing for the pipes not included in the commit, so
+	 * make sure we start with the current state.
+	 */
+	memcpy(ddb, &dev_priv->wm.skl_hw.ddb, sizeof(*ddb));
+
 	for_each_intel_crtc_mask(dev, intel_crtc, realloc_pipes) {
 		struct intel_crtc_state *cstate;

Greg Kroah-Hartman

author maintainer

2016-11-09 11:10 UTC #104 lore raw

PATCH 114/138 drm/i915/gen9: fix watermarks when using the pipe scaler

Link http://patchwork.freedesktop.org/patch/msgid/[email protected]

4.8-stable review patch. If anyone has any objections, please let me know.

------------------

From: Paulo Zanoni <[email protected]>

commit 5e33791e1f27c3207e7b44071e7c94a487d1eb39 upstream.

Luckily, the necessary adjustments for when we're using the scaler are exactly the same as the ones needed on ILK+, so just reuse the function we already have.

v2: Invert the patch order so stable backports get easier.

Signed-off-by Paulo Zanoni <[email protected]>

Reviewed-by Matt Roper <[email protected]>

(cherry picked from commit cfd7e3a20251b9ac95651d64556f87f86128a966)

Signed-off-by Jani Nikula <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/gpu/drm/i915/intel_pm.c |   12 +++---------
 1 file changed, 3 insertions(+), 9 deletions(-)

drivers/gpu/drm/i915/intel_pm.c +3 -9

@@ -3471,12 +3471,6 @@ skl_allocate_pipe_ddb(struct intel_crtc_
 	return 0;
 }
 
-static uint32_t skl_pipe_pixel_rate(const struct intel_crtc_state *config)
-{
-	/* TODO: Take into account the scalers once we support them */
-	return config->base.adjusted_mode.crtc_clock;
-}
-
 /*
  * The max latency should be 257 (max the punit can code is 255 and we add 2us
  * for the read latency) and cpp should always be <= 8, so that

@@ -3527,7 +3521,7 @@ static uint32_t skl_adjusted_plane_pixel
 	 * Adjusted plane pixel rate is just the pipe's adjusted pixel rate
 	 * with additional adjustments for plane-specific scaling.
 	 */
-	adjusted_pixel_rate = skl_pipe_pixel_rate(cstate);
+	adjusted_pixel_rate = ilk_pipe_pixel_rate(cstate);
 	downscale_amount = skl_plane_downscale_amount(pstate);
 
 	pixel_rate = adjusted_pixel_rate * downscale_amount >> 16;

@@ -3739,11 +3733,11 @@ skl_compute_linetime_wm(struct intel_crt
 	if (!cstate->base.active)
 		return 0;
 
-	if (WARN_ON(skl_pipe_pixel_rate(cstate) == 0))
+	if (WARN_ON(ilk_pipe_pixel_rate(cstate) == 0))
 		return 0;
 
 	return DIV_ROUND_UP(8 * cstate->base.adjusted_mode.crtc_htotal * 1000,
-			    skl_pipe_pixel_rate(cstate));
+			    ilk_pipe_pixel_rate(cstate));
 }
 
 static void skl_compute_transition_wm(struct intel_crtc_state *cstate,

Greg Kroah-Hartman

author maintainer

2016-11-09 11:10 UTC #105 lore raw

PATCH 120/138 drm: i915: Wait for fences on new fb, not old

Link http://patchwork.freedesktop.org/patch/msgid/[email protected]

4.8-stable review patch. If anyone has any objections, please let me know.

------------------

From: Daniel Stone <[email protected]>

commit 1fb3672eaf6ec95fb34c22734feffd6041531c5b upstream.

The previous code would wait for fences on the framebuffer from the old plane state to complete, rather than the new, so you would see tearing everywhere. Fix this to wait on the new state before we make it active.

Signed-off-by Daniel Stone <[email protected]>

Fixes 94f050246b42 ("drm/i915: nonblocking commit")

Cc Daniel Vetter <[email protected]>

Cc Maarten Lankhorst <[email protected]>

Signed-off-by Daniel Vetter <[email protected]>

(cherry picked from commit 2d2c5ad83f772d7d7b0bb8348ecea42e88f89ab0)

Signed-off-by Jani Nikula <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/gpu/drm/i915/intel_display.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/gpu/drm/i915/intel_display.c +1 -1

@@ -13834,7 +13834,7 @@ static void intel_atomic_commit_tail(str
 
 	for_each_plane_in_state(state, plane, plane_state, i) {
 		struct intel_plane_state *intel_plane_state =
-			to_intel_plane_state(plane_state);
+			to_intel_plane_state(plane->state);
 
 		if (!intel_plane_state->wait_req)
 			continue;

Greg Kroah-Hartman

author maintainer

2016-11-09 11:10 UTC #106 lore raw

PATCH 121/138 i2c: mark device nodes only in case of successful instantiation

4.8-stable review patch. If anyone has any objections, please let me know.

------------------

From: Ralf Ramsauer <[email protected]>

commit 6a676fb69dcbf3310b9e462c1db66c8e7f6ead38 upstream.

Instantiated I2C device nodes are marked with OF_POPULATE. This was introduced in 4f001fd30145a6. On unloading, loaded device nodes will of course be unmarked. The problem are nodes that fail during
initialisation: If a node fails, it won't be unloaded and hence not be unmarked.

If a I2C driver module is unloaded and reloaded, it will skip nodes that failed before.

Skip device nodes that are already populated and mark them only in case of success.

Fixes 4f001fd30145a6 ("i2c: Mark instantiated device nodes with OF_POPULATE")

Signed-off-by Ralf Ramsauer <[email protected]>

Reviewed-by Geert Uytterhoeven <[email protected]>

Acked-by Pantelis Antoniou <[email protected]>

[wsa: use 14-digit commit sha]

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/i2c/i2c-core.c |   11 ++++++++++-
 1 file changed, 10 insertions(+), 1 deletion(-)

drivers/i2c/i2c-core.c +10 -1

@@ -1592,6 +1592,7 @@ static struct i2c_client *of_i2c_registe
 static void of_i2c_register_devices(struct i2c_adapter *adap)
 {
 	struct device_node *node;
+	struct i2c_client *client;
 
 	/* Only register child devices if the adapter has a node pointer set */
 	if (!adap->dev.of_node)

@@ -1602,7 +1603,14 @@ static void of_i2c_register_devices(stru
 	for_each_available_child_of_node(adap->dev.of_node, node) {
 		if (of_node_test_and_set_flag(node, OF_POPULATED))
 			continue;
-		of_i2c_register_device(adap, node);
+
+		client = of_i2c_register_device(adap, node);
+		if (IS_ERR(client)) {
+			dev_warn(&adap->dev,
+				 "Failed to create I2C device for %s\n",
+				 node->full_name);
+			of_node_clear_flag(node, OF_POPULATED);
+		}
 	}
 }

@@ -2201,6 +2209,7 @@ static int of_i2c_notify(struct notifier
 		if (IS_ERR(client)) {
 			dev_err(&adap->dev, "failed to create client for '%s'\n",
 				 rd->dn->full_name);
+			of_node_clear_flag(rd->dn, OF_POPULATED);
 			return notifier_from_errno(PTR_ERR(client));
 		}
 		break;

Greg Kroah-Hartman

author maintainer

2016-11-09 11:10 UTC #107 lore raw

PATCH 122/138 netfilter: xt_NFLOG: fix unexpected truncated packet

4.8-stable review patch. If anyone has any objections, please let me know.

------------------

From: Liping Zhang <[email protected]>

commit 6d19375b58763fefc2f215fb45117d3353ced888 upstream.

Justin and Chris spotted that iptables NFLOG target was broken when they upgraded the kernel to 4.8: "ulogd-2.0.5- IPs are no longer logged" or "results in segfaults in ulogd-2.0.5".

Because "struct nf_loginfo li;" is a local variable, and flags will be filled with garbage value, not inited to zero. So if it contains 0x1, packets will not be logged to the userspace anymore.

Fixes 7643507fe8b5 ("netfilter: xt_NFLOG: nflog-range does not truncate packets")

Reported-by Justin Piszcz <[email protected]>

Reported-by Chris Caputo <[email protected]>

Tested-by Chris Caputo <[email protected]>

Signed-off-by Liping Zhang <[email protected]>

Signed-off-by Pablo Neira Ayuso <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 net/netfilter/xt_NFLOG.c |    1 +
 1 file changed, 1 insertion(+)

net/netfilter/xt_NFLOG.c +1 -0

@@ -32,6 +32,7 @@ nflog_tg(struct sk_buff *skb, const stru
 	li.u.ulog.copy_len   = info->len;
 	li.u.ulog.group	     = info->group;
 	li.u.ulog.qthreshold = info->threshold;
+	li.u.ulog.flags	     = 0;
 
 	if (info->flags & XT_NFLOG_F_COPY_LEN)
 		li.u.ulog.flags |= NF_LOG_F_COPY_LEN;

Greg Kroah-Hartman

author maintainer

2016-11-09 11:10 UTC #108 lore raw

PATCH 123/138 UBI: fastmap: scrub PEB when bitflips are detected in a free PEB EC header

4.8-stable review patch. If anyone has any objections, please let me know.

------------------

From: Boris Brezillon <[email protected]>

commit ecbfa8eabae9cd73522d1d3d15869703c263d859 upstream.

scan_pool() does not mark the PEB for scrubing when bitflips are detected in the EC header of a free PEB (VID header region left to 0xff).
Make sure we scrub the PEB in this case.

Signed-off-by Boris Brezillon <[email protected]>

Fixes dbb7d2a88d2a ("UBI: Add fastmap core")

Signed-off-by Richard Weinberger <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/mtd/ubi/fastmap.c |    7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

drivers/mtd/ubi/fastmap.c +4 -3

@@ -515,10 +515,11 @@ static int scan_pool(struct ubi_device *
 			unsigned long long ec = be64_to_cpu(ech->ec);
 			unmap_peb(ai, pnum);
 			dbg_bld("Adding PEB to free: %i", pnum);
+
 			if (err == UBI_IO_FF_BITFLIPS)
-				add_aeb(ai, free, pnum, ec, 1);
-			else
-				add_aeb(ai, free, pnum, ec, 0);
+				scrub = 1;
+
+			add_aeb(ai, free, pnum, ec, scrub);
 			continue;
 		} else if (err == 0 || err == UBI_IO_BITFLIPS) {
 			dbg_bld("Found non empty PEB:%i in pool", pnum);

Greg Kroah-Hartman

author maintainer

2016-11-09 11:10 UTC #109 lore raw

PATCH 125/138 video: fbdev: pxafb: potential NULL dereference on error

4.8-stable review patch. If anyone has any objections, please let me know.

------------------

From: Dan Carpenter <[email protected]>

commit e0299908d606a99e7ffb467bc3c11dfe54133af3 upstream.

If we "goto out;" then it calls display_timings_release(timings); Since "timings" is NULL, that's going to oops. Just return directly.

Fixes 420a488278e8 ('video: fbdev: pxafb: initial devicetree conversion')

Signed-off-by Dan Carpenter <[email protected]>

Acked-by Robert Jarzmik <[email protected]>

Signed-off-by Tomi Valkeinen <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/video/fbdev/pxafb.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/video/fbdev/pxafb.c +1 -1

@@ -2125,7 +2125,7 @@ static int of_get_pxafb_display(struct d
 
 	timings = of_get_display_timings(disp);
 	if (!timings)
-		goto out;
+		return -EINVAL;
 
 	ret = -ENOMEM;
 	info->modes = kmalloc_array(timings->num_timings,

Greg Kroah-Hartman

author maintainer

2016-11-09 11:10 UTC #110 lore raw

PATCH 126/138 omapfb: fix return value check in dsi_bind()

4.8-stable review patch. If anyone has any objections, please let me know.

------------------

From: Wei Yongjun <[email protected]>

commit 43da7575cdecaf5af2d6b3f3a9e4e6c9144be428 upstream.

Fix the retrn value check which testing the wrong variable in dsi_bind().

Fixes f76ee892a99e ("omapfb: copy omapdss & displays for omapfb")

Signed-off-by Wei Yongjun <[email protected]>

Reviewed-by Peter Ujfalusi <[email protected]>

Signed-off-by Tomi Valkeinen <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/video/fbdev/omap2/omapfb/dss/dsi.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

drivers/video/fbdev/omap2/omapfb/dss/dsi.c +2 -2

@@ -5348,7 +5348,7 @@ static int dsi_bind(struct device *dev,
 
 	dsi->phy_base = devm_ioremap(&dsidev->dev, res->start,
 		resource_size(res));
-	if (!dsi->proto_base) {
+	if (!dsi->phy_base) {
 		DSSERR("can't ioremap DSI PHY\n");
 		return -ENOMEM;
 	}

@@ -5368,7 +5368,7 @@ static int dsi_bind(struct device *dev,
 
 	dsi->pll_base = devm_ioremap(&dsidev->dev, res->start,
 		resource_size(res));
-	if (!dsi->proto_base) {
+	if (!dsi->pll_base) {
 		DSSERR("can't ioremap DSI PLL\n");
 		return -ENOMEM;
 	}

Greg Kroah-Hartman

author maintainer

2016-11-09 10:46 UTC #111 lore raw

PATCH 127/138 pwm: Unexport children before chip removal

4.8-stable review patch. If anyone has any objections, please let me know.

------------------

From: David Hsu <[email protected]>

commit 0733424c9ba9f42242409d1ece780777272f7ea1 upstream.

Exported pwm channels aren't removed before the pwmchip and are leaked. This results in invalid sysfs files. This fix removes all exported pwm channels before chip removal.

Signed-off-by David Hsu <[email protected]>

Fixes 76abbdde2d95 ("pwm: Add sysfs interface")

Signed-off-by Thierry Reding <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/pwm/core.c  |    2 ++
 drivers/pwm/sysfs.c |   18 ++++++++++++++++++
 include/linux/pwm.h |    5 +++++
 3 files changed, 25 insertions(+)

drivers/pwm/core.c +2 -0

@@ -339,6 +339,8 @@ int pwmchip_remove(struct pwm_chip *chip
 	unsigned int i;
 	int ret = 0;
 
+	pwmchip_sysfs_unexport_children(chip);
+
 	mutex_lock(&pwm_lock);
 
 	for (i = 0; i < chip->npwm; i++) {

drivers/pwm/sysfs.c +18 -0

@@ -409,6 +409,24 @@ void pwmchip_sysfs_unexport(struct pwm_c
 	}
 }
 
+void pwmchip_sysfs_unexport_children(struct pwm_chip *chip)
+{
+	struct device *parent;
+	unsigned int i;
+
+	parent = class_find_device(&pwm_class, NULL, chip,
+				   pwmchip_sysfs_match);
+	if (!parent)
+		return;
+
+	for (i = 0; i < chip->npwm; i++) {
+		struct pwm_device *pwm = &chip->pwms[i];
+
+		if (test_bit(PWMF_EXPORTED, &pwm->flags))
+			pwm_unexport_child(parent, pwm);
+	}
+}
+
 static int __init pwm_sysfs_init(void)
 {
 	return class_register(&pwm_class);

include/linux/pwm.h +5 -0

@@ -641,6 +641,7 @@ static inline void pwm_remove_table(stru
 #ifdef CONFIG_PWM_SYSFS
 void pwmchip_sysfs_export(struct pwm_chip *chip);
 void pwmchip_sysfs_unexport(struct pwm_chip *chip);
+void pwmchip_sysfs_unexport_children(struct pwm_chip *chip);
 #else
 static inline void pwmchip_sysfs_export(struct pwm_chip *chip)
 {

@@ -649,6 +650,10 @@ static inline void pwmchip_sysfs_export(
 static inline void pwmchip_sysfs_unexport(struct pwm_chip *chip)
 {
 }
+
+static inline void pwmchip_sysfs_unexport_children(struct pwm_chip *chip)
+{
+}
 #endif /* CONFIG_PWM_SYSFS */
 
 #endif /* __LINUX_PWM_H */

Greg Kroah-Hartman

author maintainer

2016-11-09 10:46 UTC #112 lore raw

PATCH 128/138 usb: dwc3: Fix size used in dma_free_coherent()

4.8-stable review patch. If anyone has any objections, please let me know.

------------------

From: Christophe JAILLET <[email protected]>

commit 51fbc7c06c8900370c6da5fc4a4685add8fa4fb0 upstream.

In commit 2abd9d5fa60f9 ("usb: dwc3: ep0: Add chained TRB support"), the size of the memory allocated with 'dma_alloc_coherent()' has been modified but the corresponding calls to 'dma_free_coherent()' have not been updated accordingly.

This has been spotted with coccinelle, using the following script:
////////////////////
@r@
expression x0, x1, y0, y1, z0, z1, t0, t1, ret;
@@

*   ret = dma_alloc_coherent(x0, y0, z0, t0);
    ...

* dma_free_coherent(x1, y1, ret, t1);

@script:python@
y0 << r.y0;
y1 << r.y1;

@@
if y1.find(y0) == -1:
print "WARNING: sizes look different: '%s' vs '%s'" % (y0, y1)
////////////////////

Fixes 2abd9d5fa60f9 ("usb: dwc3: ep0: Add chained TRB support")

Signed-off-by Christophe JAILLET <[email protected]>

Signed-off-by Felipe Balbi <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/usb/dwc3/gadget.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

drivers/usb/dwc3/gadget.c +2 -2

@@ -3055,7 +3055,7 @@ err3:
 	kfree(dwc->setup_buf);
 
 err2:
-	dma_free_coherent(dwc->dev, sizeof(*dwc->ep0_trb),
+	dma_free_coherent(dwc->dev, sizeof(*dwc->ep0_trb) * 2,
 			dwc->ep0_trb, dwc->ep0_trb_addr);
 
 err1:

@@ -3080,7 +3080,7 @@ void dwc3_gadget_exit(struct dwc3 *dwc)
 	kfree(dwc->setup_buf);
 	kfree(dwc->zlp_buf);
 
-	dma_free_coherent(dwc->dev, sizeof(*dwc->ep0_trb),
+	dma_free_coherent(dwc->dev, sizeof(*dwc->ep0_trb) * 2,
 			dwc->ep0_trb, dwc->ep0_trb_addr);
 
 	dma_free_coherent(dwc->dev, sizeof(*dwc->ctrl_req),

Greg Kroah-Hartman

author maintainer

2016-11-09 11:11 UTC #113 lore raw

PATCH 129/138 usb: chipidea: host: fix NULL ptr dereference during shutdown

4.8-stable review patch. If anyone has any objections, please let me know.

------------------

From: Stefan Wahren <[email protected]>

commit 991d5add50a5bb6ab8f12f2129f5c7487f6baaf6 upstream.

After commit b09b5224fe86 ("usb: chipidea: implement platform shutdown callback") and commit 43a404577a93 ("usb: chipidea: host: set host to be null after hcd is freed") a NULL pointer dereference is caused on i.MX23 during shutdown. So ensure that role is set to CI_ROLE_END and we finish interrupt handling before the hcd is deallocated. This avoids the NULL pointer dereference.

Signed-off-by Stefan Wahren <[email protected]>

Fixes b09b5224fe86 ("usb: chipidea: implement platform shutdown callback")

Signed-off-by Peter Chen <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/usb/chipidea/host.c |    2 ++
 1 file changed, 2 insertions(+)

drivers/usb/chipidea/host.c +2 -0

@@ -185,6 +185,8 @@ static void host_stop(struct ci_hdrc *ci
 
 	if (hcd) {
 		usb_remove_hcd(hcd);
+		ci->role = CI_ROLE_END;
+		synchronize_irq(ci->irq);
 		usb_put_hcd(hcd);
 		if (ci->platdata->reg_vbus && !ci_otg_is_fsm_mode(ci) &&
 			(ci->platdata->flags & CI_HDRC_TURN_VBUS_EARLY_ON))

Greg Kroah-Hartman

author maintainer

2016-11-09 11:11 UTC #114 lore raw

PATCH 130/138 usb: musb: Fix hardirq-safe hardirq-unsafe lock order error

4.8-stable review patch. If anyone has any objections, please let me know.

------------------

From: Tony Lindgren <[email protected]>

commit d8e5f0eca1e88215e45aca27115ea747e6164da1 upstream.

If we configure musb with 2430 glue as a peripheral, and then rmmod omap2430 module, we'll get the following error:

[ INFO: HARDIRQ-safe -> HARDIRQ-unsafe lock order detected ]
...
rmmod/413 [HC0[0]:SC0[0]:HE0:SE1] is trying to acquire:
(&phy->mutex){+.+.+.}, at: [<c04b9fd0>] phy_power_off+0x1c/0xb8

[  204.678710]
               and this task is already holding:
 (&(&musb->lock)->rlock){-.-...}, at: [<bf3a482c>]
 musb_gadget_stop+0x24/0xec [musb_hdrc]

which would create a new lock dependency:
(&(&musb->lock)->rlock){-.-...} -> (&phy->mutex){+.+.+.}
...

This is because some glue layers expect musb_platform_enable/disable to be called with spinlock held, and 2430 glue layer has USB PHY on the I2C bus using a mutex.

We could fix the glue layers to take the spinlock, but we still have a problem of musb_plaform_enable/disable being called in an unbalanced manner. So that would still lead into USB PHY enable/disable related problems for omap2430 glue layer.

While it makes sense to only enable USB PHY when needed from PM point of view, in this case we just can't do it yet without breaking things. So let's just revert phy_enable/disable related changes instead and reconsider this after we have fixed musb_platform_enable/disable to be balanced.

Fixes a83e17d0f73b ("usb: musb: Improve PM runtime and phy handling for 2430 glue layer")

Reviewed-by Laurent Pinchart <[email protected]>

Signed-off-by Tony Lindgren <[email protected]>

Signed-off-by Bin Liu <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/usb/musb/omap2430.c |    7 ++-----
 1 file changed, 2 insertions(+), 5 deletions(-)

drivers/usb/musb/omap2430.c +2 -5

@@ -337,6 +337,7 @@ static int omap2430_musb_init(struct mus
 	}
 	musb->isr = omap2430_musb_interrupt;
 	phy_init(musb->phy);
+	phy_power_on(musb->phy);
 
 	l = musb_readl(musb->mregs, OTG_INTERFSEL);

@@ -373,8 +374,6 @@ static void omap2430_musb_enable(struct
 	struct musb_hdrc_platform_data *pdata = dev_get_platdata(dev);
 	struct omap_musb_board_data *data = pdata->board_data;
 
-	if (!WARN_ON(!musb->phy))
-		phy_power_on(musb->phy);
 
 	omap2430_set_power(musb, true, glue->cable_connected);

@@ -413,9 +412,6 @@ static void omap2430_musb_disable(struct
 	struct device *dev = musb->controller;
 	struct omap2430_glue *glue = dev_get_drvdata(dev->parent);
 
-	if (!WARN_ON(!musb->phy))
-		phy_power_off(musb->phy);
-
 	if (glue->status != MUSB_UNKNOWN)
 		omap_control_usb_set_mode(glue->control_otghs,
 			USB_MODE_DISCONNECT);

@@ -429,6 +425,7 @@ static int omap2430_musb_exit(struct mus
 	struct omap2430_glue *glue = dev_get_drvdata(dev->parent);
 
 	omap2430_low_level_exit(musb);
+	phy_power_off(musb->phy);
 	phy_exit(musb->phy);
 	musb->phy = NULL;
 	cancel_work_sync(&glue->omap_musb_mailbox_work);

Greg Kroah-Hartman

author maintainer

2016-11-09 11:11 UTC #115 lore raw

PATCH 131/138 v4l: vsp1: Prevent pipelines from running when not streaming

4.8-stable review patch. If anyone has any objections, please let me know.

------------------

From: Laurent Pinchart <[email protected]>

commit e4e70a147a48618a36ae1b81c641516cb9d45993 upstream.

Pipelines can only be run if all their video nodes are streaming. Commit b4dfb9b35a19 ("[media] v4l: vsp1: Stop the pipeline upon the first STREAMOFF") fixed the pipeline stop sequence, but introduced a race condition that makes it possible to run a pipeline after stopping the stream on a video node by queuing a buffer on the other side of the pipeline.

Fix this by clearing the buffers ready flag when stopping the stream, which will prevent the QBUF handler from running the pipeline.

Fixes b4dfb9b35a19 ("[media] v4l: vsp1: Stop the pipeline upon the first STREAMOFF")

Reported-by Kieran Bingham <[email protected]>

Tested-by Kieran Bingham <[email protected]>

Signed-off-by Laurent Pinchart <[email protected]>

Signed-off-by Mauro Carvalho Chehab <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/media/platform/vsp1/vsp1_video.c |    7 +++++++
 1 file changed, 7 insertions(+)

drivers/media/platform/vsp1/vsp1_video.c +7 -0

@@ -675,6 +675,13 @@ static void vsp1_video_stop_streaming(st
 	unsigned long flags;
 	int ret;
 
+	/* Clear the buffers ready flag to make sure the device won't be started
+	 * by a QBUF on the video node on the other side of the pipeline.
+	 */
+	spin_lock_irqsave(&video->irqlock, flags);
+	pipe->buffers_ready &= ~(1 << video->pipe_index);
+	spin_unlock_irqrestore(&video->irqlock, flags);
+
 	mutex_lock(&pipe->lock);
 	if (--pipe->stream_count == pipe->num_inputs) {
 		/* Stop the pipeline. */

Greg Kroah-Hartman

author maintainer

2016-11-09 11:11 UTC #116 lore raw

PATCH 133/138 ARM: fix oops when using older ARMv4T CPUs

4.8-stable review patch. If anyone has any objections, please let me know.

------------------

From: Russell King <[email protected]>

commit 04946fb60fb157faafa01658dff3131d49f49ccb upstream.

Alexander Shiyan reports that CLPS711x fails at boot time in the data exception handler due to a NULL pointer dereference. This is caused by the late-v4t abort handler overwriting R9 (which becomes zero). Fix this by making the abort handler save and restore R9.

Unable to handle kernel NULL pointer dereference at virtual address 00000008
pgd = c3b58000
[00000008] *pgd=800000000, *pte=00000000, *ppte=feff4140
Internal error: Oops: 63c11817 [#1] PREEMPT ARM
CPU: 0 PID: 448 Comm: ash Not tainted 4.8.1+ #1
Hardware name: Cirrus Logic CLPS711X (Device Tree Support)
task: c39e03a0 ti: c3b4e000 task.ti: c3b4e000
PC is at __dabt_svc+0x4c/0x60
LR is at do_page_fault+0x144/0x2ac
pc : [<c000d3ac>]    lr : [<c000fcec>]    psr: 60000093

sp : c3b4fe6c ip : 00000001 fp : b6f1bf88
r10: c387a5a0 r9 : 00000000 r8 : e4e0e001
r7 : bee3ef83 r6 : 00100000 r5 : 80000013 r4 : c022fcf8 r3 : 00000000 r2 : 00000008 r1 : bf000000 r0 : 00000000
Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment user
Control: 0000217f Table: c3b58055 DAC: 00000055 Process ash (pid: 448, stack limit = 0xc3b4e190)

Stack: (0xc3b4fe6c to 0xc3b50000)

fe60: bee3ef83 c05168d1 ffffffff 00000000 c3adfe80
fe80: c3a03300 00000000 c3b4fed0 c3a03400 bee3ef83 c387a5a0 b6f1bf88 00000001
fea0: c3b4febc 00000076 c022fcf8 80000013 ffffffff 0000003f bf000000 bee3ef83
fec0: 00000004 00000000 c3adfe80 c00e432c 00000812 00000005 00000001 00000006
fee0: b6f1b000 00000000 00010000 0003c944 0004d000 0004d439 00010000 b6f1b000
ff00: 00000005 00000000 00015ecc c3b4fed0 0000000a 00000000 00000000 c00a1dc0
ff20: befff000 c3a03300 c3b4e000 c0507cd8 c0508024 fffffff8 c3a03300 00000000
ff40: c0516a58 c00a35bc c39e03a0 000001c0 bea84ce8 0004e008 c3b3a000 c00a3ac0
ff60: c3b40374 c3b3a000 bea84d11 00000000 c0500188 bea84d11 bea84ce8 00000001
ff80: 0000000b c000a304 c3b4e000 00000000 bea84ce4 c00a3cd0 00000000 bea84d11
ffa0: bea84ce8 c000a160 bea84d11 bea84ce8 bea84d11 bea84ce8 0004e008 0004d450
ffc0: bea84d11 bea84ce8 00000001 0000000b b6f45ee4 00000000 b6f5ff70 bea84ce4
ffe0: b6f2f130 bea84cb0 b6f2f194 b6ef29f4 a0000010 bea84d11 02c7cffa 02c7cffd [<c000d3ac>] (__dabt_svc) from [<c022fcf8>] (__copy_to_user_std+0xf8/0x330) [<c022fcf8>] (__copy_to_user_std) from [<c00e432c>] +(load_elf_binary+0x920/0x107c)
[<c00e432c>] (load_elf_binary) from [<c00a35bc>] +(search_binary_handler+0x80/0x16c)
[<c00a35bc>] (search_binary_handler) from [<c00a3ac0>] +(do_execveat_common+0x418/0x600)
[<c00a3ac0>] (do_execveat_common) from [<c00a3cd0>] (do_execve+0x28/0x30) [<c00a3cd0>] (do_execve) from [<c000a160>] (ret_fast_syscall+0x0/0x30)

Code: e1a0200d eb00136b e321f093 e59d104c (e5891008)
---[ end trace 4b4f8086ebef98c5 ]---

Fixes e6978e4bf181 ("ARM: save and reset the address limit when entering an exception")

Reported-by Alexander Shiyan <[email protected]>

Tested-by Alexander Shiyan <[email protected]>

Signed-off-by Russell King <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 arch/arm/mm/abort-lv4t.S |   34 ++++++++++++++++++++++++----------
 1 file changed, 24 insertions(+), 10 deletions(-)

arch/arm/mm/abort-lv4t.S +24 ~~-10~~

@@ -7,7 +7,7 @@
  *	   : r4 = aborted context pc
  *	   : r5 = aborted context psr
  *
- * Returns : r4-r5, r10-r11, r13 preserved
+ * Returns : r4-r5, r9-r11, r13 preserved
  *
  * Purpose : obtain information about current aborted instruction.
  * Note: we read user space.  This means we might cause a data

@@ -48,7 +48,10 @@ ENTRY(v4t_late_abort)
 /* c */	b	do_DataAbort			@ ldc	rd, [rn], #m	@ Same as ldr	rd, [rn], #m
 /* d */	b	do_DataAbort			@ ldc	rd, [rn, #m]
 /* e */	b	.data_unknown
-/* f */
+/* f */	b	.data_unknown
+
+.data_unknown_r9:
+	ldr	r9, [sp], #4
 .data_unknown:	@ Part of jumptable
 	mov	r0, r4
 	mov	r1, r8

@@ -57,6 +60,7 @@ ENTRY(v4t_late_abort)
 .data_arm_ldmstm:
 	tst	r8, #1 << 21			@ check writeback bit
 	beq	do_DataAbort			@ no writeback -> no fixup
+	str	r9, [sp, #-4]!
 	mov	r7, #0x11
 	orr	r7, r7, #0x1100
 	and	r6, r8, r7

@@ -75,12 +79,14 @@ ENTRY(v4t_late_abort)
 	subne	r7, r7, r6, lsl #2		@ Undo increment
 	addeq	r7, r7, r6, lsl #2		@ Undo decrement
 	str	r7, [r2, r9, lsr #14]		@ Put register 'Rn'
+	ldr	r9, [sp], #4
 	b	do_DataAbort
 
 .data_arm_lateldrhpre:
 	tst	r8, #1 << 21			@ Check writeback bit
 	beq	do_DataAbort			@ No writeback -> no fixup
 .data_arm_lateldrhpost:
+	str	r9, [sp, #-4]!
 	and	r9, r8, #0x00f			@ get Rm / low nibble of immediate value
 	tst	r8, #1 << 22			@ if (immediate offset)
 	andne	r6, r8, #0xf00			@ { immediate high nibble

@@ -93,6 +99,7 @@ ENTRY(v4t_late_abort)
 	subne	r7, r7, r6			@ Undo incrmenet
 	addeq	r7, r7, r6			@ Undo decrement
 	str	r7, [r2, r9, lsr #14]		@ Put register 'Rn'
+	ldr	r9, [sp], #4
 	b	do_DataAbort
 
 .data_arm_lateldrpreconst:

@@ -101,12 +108,14 @@ ENTRY(v4t_late_abort)
 .data_arm_lateldrpostconst:
 	movs	r6, r8, lsl #20			@ Get offset
 	beq	do_DataAbort			@ zero -> no fixup
+	str	r9, [sp, #-4]!
 	and	r9, r8, #15 << 16		@ Extract 'n' from instruction
 	ldr	r7, [r2, r9, lsr #14]		@ Get register 'Rn'
 	tst	r8, #1 << 23			@ Check U bit
 	subne	r7, r7, r6, lsr #20		@ Undo increment
 	addeq	r7, r7, r6, lsr #20		@ Undo decrement
 	str	r7, [r2, r9, lsr #14]		@ Put register 'Rn'
+	ldr	r9, [sp], #4
 	b	do_DataAbort
 
 .data_arm_lateldrprereg:

@@ -115,6 +124,7 @@ ENTRY(v4t_late_abort)
 .data_arm_lateldrpostreg:
 	and	r7, r8, #15			@ Extract 'm' from instruction
 	ldr	r6, [r2, r7, lsl #2]		@ Get register 'Rm'
+	str	r9, [sp, #-4]!
 	mov	r9, r8, lsr #7			@ get shift count
 	ands	r9, r9, #31
 	and	r7, r8, #0x70			@ get shift type

@@ -126,33 +136,33 @@ ENTRY(v4t_late_abort)
 	b	.data_arm_apply_r6_and_rn
 	b	.data_arm_apply_r6_and_rn	@ 1: LSL #0
 	nop
-	b	.data_unknown			@ 2: MUL?
+	b	.data_unknown_r9		@ 2: MUL?
 	nop
-	b	.data_unknown			@ 3: MUL?
+	b	.data_unknown_r9		@ 3: MUL?
 	nop
 	mov	r6, r6, lsr r9			@ 4: LSR #!0
 	b	.data_arm_apply_r6_and_rn
 	mov	r6, r6, lsr #32			@ 5: LSR #32
 	b	.data_arm_apply_r6_and_rn
-	b	.data_unknown			@ 6: MUL?
+	b	.data_unknown_r9		@ 6: MUL?
 	nop
-	b	.data_unknown			@ 7: MUL?
+	b	.data_unknown_r9		@ 7: MUL?
 	nop
 	mov	r6, r6, asr r9			@ 8: ASR #!0
 	b	.data_arm_apply_r6_and_rn
 	mov	r6, r6, asr #32			@ 9: ASR #32
 	b	.data_arm_apply_r6_and_rn
-	b	.data_unknown			@ A: MUL?
+	b	.data_unknown_r9		@ A: MUL?
 	nop
-	b	.data_unknown			@ B: MUL?
+	b	.data_unknown_r9		@ B: MUL?
 	nop
 	mov	r6, r6, ror r9			@ C: ROR #!0
 	b	.data_arm_apply_r6_and_rn
 	mov	r6, r6, rrx			@ D: RRX
 	b	.data_arm_apply_r6_and_rn
-	b	.data_unknown			@ E: MUL?
+	b	.data_unknown_r9		@ E: MUL?
 	nop
-	b	.data_unknown			@ F: MUL?
+	b	.data_unknown_r9		@ F: MUL?
 
 .data_thumb_abort:
 	ldrh	r8, [r4]			@ read instruction

@@ -190,6 +200,7 @@ ENTRY(v4t_late_abort)
 .data_thumb_pushpop:
 	tst	r8, #1 << 10
 	beq	.data_unknown
+	str	r9, [sp, #-4]!
 	and	r6, r8, #0x55			@ hweight8(r8) + R bit
 	and	r9, r8, #0xaa
 	add	r6, r6, r9, lsr #1

@@ -204,9 +215,11 @@ ENTRY(v4t_late_abort)
 	addeq	r7, r7, r6, lsl #2		@ increment SP if PUSH
 	subne	r7, r7, r6, lsl #2		@ decrement SP if POP
 	str	r7, [r2, #13 << 2]
+	ldr	r9, [sp], #4
 	b	do_DataAbort
 
 .data_thumb_ldmstm:
+	str	r9, [sp, #-4]!
 	and	r6, r8, #0x55			@ hweight8(r8)
 	and	r9, r8, #0xaa
 	add	r6, r6, r9, lsr #1

@@ -219,4 +232,5 @@ ENTRY(v4t_late_abort)
 	and	r6, r6, #15			@ number of regs to transfer
 	sub	r7, r7, r6, lsl #2		@ always decrement
 	str	r7, [r2, r9, lsr #6]
+	ldr	r9, [sp], #4
 	b	do_DataAbort

Greg Kroah-Hartman

author maintainer

2016-11-09 11:11 UTC #117 lore raw

PATCH 134/138 kvm: x86: Check memopp before dereference (CVE-2016-8630)

4.8-stable review patch. If anyone has any objections, please let me know.

------------------

From: Owen Hofmann <[email protected]>

commit d9092f52d7e61dd1557f2db2400ddb430e85937e upstream.

Commit 41061cdb98 ("KVM: emulate: do not initialize memopp") removes a check for non-NULL under incorrect assumptions. An undefined instruction with a ModR/M byte with Mod=0 and R/M-5 (e.g. 0xc7 0x15) will attempt to dereference a null pointer here.

Fixes 41061cdb98a0bec464278b4db8e894a3121671f5

Message-Id: <[email protected]>

Signed-off-by Owen Hofmann <[email protected]>

Signed-off-by Paolo Bonzini <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 arch/x86/kvm/emulate.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

arch/x86/kvm/emulate.c +1 -1

@@ -5045,7 +5045,7 @@ done_prefixes:
 	/* Decode and fetch the destination operand: register or memory. */
 	rc = decode_operand(ctxt, &ctxt->dst, (ctxt->d >> DstShift) & OpMask);
 
-	if (ctxt->rip_relative)
+	if (ctxt->rip_relative && likely(ctxt->memopp))
 		ctxt->memopp->addr.mem.ea = address_mask(ctxt,
 					ctxt->memopp->addr.mem.ea + ctxt->_eip);

Greg Kroah-Hartman

author maintainer

2016-11-09 10:46 UTC #118 lore raw

PATCH 135/138 btrfs: qgroup: Prevent qgroup->reserved from going subzero

4.8-stable review patch. If anyone has any objections, please let me know.

------------------

From: Goldwyn Rodrigues <[email protected]>

commit 0b34c261e235a5c74dcf78bd305845bd15fe2b42 upstream.

While free'ing qgroup->reserved resources, we much check if the page has not been invalidated by a truncate operation by checking if the page is still dirty before reducing the qgroup resources. Resources in such a case are free'd when the entire extent is released by delayed_ref.

This fixes a double accounting while releasing resources in case of truncating a file, reproduced by the following testcase.

SCRATCH_DEV=/dev/vdb
SCRATCH_MNT=/mnt
mkfs.btrfs -f $SCRATCH_DEV
mount -t btrfs $SCRATCH_DEV $SCRATCH_MNT
cd $SCRATCH_MNT
btrfs quota enable $SCRATCH_MNT
btrfs subvolume create a
btrfs qgroup limit 500m a $SCRATCH_MNT
sync
for c in {1..15}; do
dd if=/dev/zero bs=1M count=40 of=$SCRATCH_MNT/a/file; done

sleep 10
sync
sleep 5

touch $SCRATCH_MNT/a/newfile

echo "Removing file"
rm $SCRATCH_MNT/a/file

Fixes b9d0b38928 ("btrfs: Add handler for invalidate page")

Signed-off-by Goldwyn Rodrigues <[email protected]>

Reviewed-by Qu Wenruo <[email protected]>

Signed-off-by David Sterba <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 fs/btrfs/inode.c |    9 +++++++--
 1 file changed, 7 insertions(+), 2 deletions(-)

fs/btrfs/inode.c +7 -2

@@ -8915,9 +8915,14 @@ again:
 	 *    So even we call qgroup_free_data(), it won't decrease reserved
 	 *    space.
 	 * 2) Not written to disk
-	 *    This means the reserved space should be freed here.
+	 *    This means the reserved space should be freed here. However,
+	 *    if a truncate invalidates the page (by clearing PageDirty)
+	 *    and the page is accounted for while allocating extent
+	 *    in btrfs_check_data_free_space() we let delayed_ref to
+	 *    free the entire extent.
 	 */
-	btrfs_qgroup_free_data(inode, page_start, PAGE_SIZE);
+	if (PageDirty(page))
+		btrfs_qgroup_free_data(inode, page_start, PAGE_SIZE);
 	if (!inode_evicting) {
 		clear_extent_bit(tree, page_start, page_end,
 				 EXTENT_LOCKED | EXTENT_DIRTY |

Greg Kroah-Hartman

author maintainer

2016-11-09 11:11 UTC #119 lore raw

PATCH 136/138 ubi: fastmap: Fix add_vol() return value test in ubi_attach_fastmap()

4.8-stable review patch. If anyone has any objections, please let me know.

------------------

From: Boris Brezillon <[email protected]>

commit 40b6e61ac72e99672e47cdb99c8d7d226004169b upstream.

Commit e96a8a3bb671 ("UBI: Fastmap: Do not add vol if it already exists") introduced a bug by changing the possible error codes returned by add_vol():
- this function no longer returns NULL in case of allocation failure but return ERR_PTR(-ENOMEM)
- when a duplicate entry in the volume RB tree is found it returns ERR_PTR(-EEXIST) instead of ERR_PTR(-EINVAL)

Fix the tests done on add_vol() return val to match this new behavior.

Fixes e96a8a3bb671 ("UBI: Fastmap: Do not add vol if it already exists")

Reported-by Dan Carpenter <[email protected]>

Signed-off-by Boris Brezillon <[email protected]>

Acked-by Sheng Yong <[email protected]>

Signed-off-by Richard Weinberger <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/mtd/ubi/fastmap.c |   10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

drivers/mtd/ubi/fastmap.c +5 -5

@@ -751,11 +751,11 @@ static int ubi_attach_fastmap(struct ubi
 			     fmvhdr->vol_type,
 			     be32_to_cpu(fmvhdr->last_eb_bytes));
 
-		if (!av)
-			goto fail_bad;
-		if (PTR_ERR(av) == -EINVAL) {
-			ubi_err(ubi, "volume (ID %i) already exists",
-				fmvhdr->vol_id);
+		if (IS_ERR(av)) {
+			if (PTR_ERR(av) == -EEXIST)
+				ubi_err(ubi, "volume (ID %i) already exists",
+					fmvhdr->vol_id);
+
 			goto fail_bad;
 		}

Greg Kroah-Hartman

author maintainer

2016-11-09 10:47 UTC #120 lore raw

PATCH 137/138 cpufreq: intel_pstate: Set P-state upfront in performance mode

4.8-stable review patch. If anyone has any objections, please let me know.

------------------

From: Rafael J. Wysocki <[email protected]>

commit a6c6ead14183ea4ec8ce7551e1f3451024b9c4db upstream.

After commit a4675fbc4a7a (cpufreq: intel_pstate: Replace timers with utilization update callbacks) the cpufreq governor callbacks may not be invoked on NOHZ_FULL CPUs and, in particular, switching to the "performance" policy via sysfs may not have any effect on them. That is a problem, because it usually is desirable to squeeze the last bit of performance out of those CPUs, so work around it by setting the maximum P-state (within the limits) in intel_pstate_set_policy() upfront when the policy is CPUFREQ_POLICY_PERFORMANCE.

Fixes a4675fbc4a7a (cpufreq: intel_pstate: Replace timers with utilization update callbacks)

Signed-off-by Rafael J. Wysocki <[email protected]>

Acked-by Srinivas Pandruvada <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/cpufreq/intel_pstate.c |   29 +++++++++++++++++++++++++----
 1 file changed, 25 insertions(+), 4 deletions(-)

drivers/cpufreq/intel_pstate.c +25 -4

@@ -1133,10 +1133,8 @@ static void intel_pstate_get_min_max(str
 	*min = clamp_t(int, min_perf, cpu->pstate.min_pstate, max_perf);
 }
 
-static void intel_pstate_set_min_pstate(struct cpudata *cpu)
+static void intel_pstate_set_pstate(struct cpudata *cpu, int pstate)
 {
-	int pstate = cpu->pstate.min_pstate;
-
 	trace_cpu_frequency(pstate * cpu->pstate.scaling, cpu->cpu);
 	cpu->pstate.current_pstate = pstate;
 	/*

@@ -1148,6 +1146,20 @@ static void intel_pstate_set_min_pstate(
 		      pstate_funcs.get_val(cpu, pstate));
 }
 
+static void intel_pstate_set_min_pstate(struct cpudata *cpu)
+{
+	intel_pstate_set_pstate(cpu, cpu->pstate.min_pstate);
+}
+
+static void intel_pstate_max_within_limits(struct cpudata *cpu)
+{
+	int min_pstate, max_pstate;
+
+	update_turbo_state();
+	intel_pstate_get_min_max(cpu, &min_pstate, &max_pstate);
+	intel_pstate_set_pstate(cpu, max_pstate);
+}
+
 static void intel_pstate_get_cpu_pstates(struct cpudata *cpu)
 {
 	cpu->pstate.min_pstate = pstate_funcs.get_min();

@@ -1465,7 +1477,7 @@ static int intel_pstate_set_policy(struc
 	pr_debug("set_policy cpuinfo.max %u policy->max %u\n",
 		 policy->cpuinfo.max_freq, policy->max);
 
-	cpu = all_cpu_data[0];
+	cpu = all_cpu_data[policy->cpu];
 	if (cpu->pstate.max_pstate_physical > cpu->pstate.max_pstate &&
 	    policy->max < policy->cpuinfo.max_freq &&
 	    policy->max > cpu->pstate.max_pstate * cpu->pstate.scaling) {

@@ -1509,6 +1521,15 @@ static int intel_pstate_set_policy(struc
 	limits->max_perf = round_up(limits->max_perf, FRAC_BITS);
 
  out:
+	if (policy->policy == CPUFREQ_POLICY_PERFORMANCE) {
+		/*
+		 * NOHZ_FULL CPUs need this as the governor callback may not
+		 * be invoked on them.
+		 */
+		intel_pstate_clear_update_util_hook(policy->cpu);
+		intel_pstate_max_within_limits(cpu);
+	}
+
 	intel_pstate_set_update_util_hook(policy->cpu);
 
 	intel_pstate_hwp_set_policy(policy);

Greg Kroah-Hartman

author maintainer

2016-11-09 11:11 UTC #121 lore raw

PATCH 138/138 HID: usbhid: add ATEN CS962 to list of quirky devices

4.8-stable review patch. If anyone has any objections, please let me know.

------------------

From: Oliver Neukum <[email protected]>

commit cf0ea4da4c7df11f7a508b2f37518e0f117f3791 upstream.

Like many similar devices it needs a quirk to work. Issuing the request gets the device into an irrecoverable state.

Signed-off-by Oliver Neukum <[email protected]>

Signed-off-by Jiri Kosina <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/hid/hid-ids.h           |    1 +
 drivers/hid/usbhid/hid-quirks.c |    1 +
 2 files changed, 2 insertions(+)

drivers/hid/hid-ids.h +1 -0

@@ -179,6 +179,7 @@
 #define USB_DEVICE_ID_ATEN_4PORTKVM	0x2205
 #define USB_DEVICE_ID_ATEN_4PORTKVMC	0x2208
 #define USB_DEVICE_ID_ATEN_CS682	0x2213
+#define USB_DEVICE_ID_ATEN_CS692	0x8021
 
 #define USB_VENDOR_ID_ATMEL		0x03eb
 #define USB_DEVICE_ID_ATMEL_MULTITOUCH	0x211c

drivers/hid/usbhid/hid-quirks.c +1 -0

@@ -63,6 +63,7 @@ static const struct hid_blacklist {
 	{ USB_VENDOR_ID_ATEN, USB_DEVICE_ID_ATEN_4PORTKVM, HID_QUIRK_NOGET },
 	{ USB_VENDOR_ID_ATEN, USB_DEVICE_ID_ATEN_4PORTKVMC, HID_QUIRK_NOGET },
 	{ USB_VENDOR_ID_ATEN, USB_DEVICE_ID_ATEN_CS682, HID_QUIRK_NOGET },
+	{ USB_VENDOR_ID_ATEN, USB_DEVICE_ID_ATEN_CS692, HID_QUIRK_NOGET },
 	{ USB_VENDOR_ID_CH, USB_DEVICE_ID_CH_FIGHTERSTICK, HID_QUIRK_NOGET },
 	{ USB_VENDOR_ID_CH, USB_DEVICE_ID_CH_COMBATSTICK, HID_QUIRK_NOGET },
 	{ USB_VENDOR_ID_CH, USB_DEVICE_ID_CH_FLIGHT_SIM_ECLIPSE_YOKE, HID_QUIRK_NOGET },

Shuah Khan

2016-11-09 18:22 UTC #122 lore raw

Quoted 9 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 4.8.7 release. There are 138 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Fri Nov 11 10:28:05 UTC 2016. Anything received after that time might be too late.
The whole patch series can be found in one patch at:

Quoted 9 lines

	kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.8.7-rc1.gz
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.8.y
and the diffstat can be found below.
thanks,
greg k-h

Compiled and booted on my test system. No dmesg regressions.

thanks,
-- Shuah

Signature · 5 lines

Shuah Khan
Sr. Linux Kernel Developer
Open Source Innovation Group
Samsung Research America(Silicon Valley)
[email protected]

Greg Kroah-Hartman

author maintainer

2016-11-10 11:33 UTC #123 lore raw

Quoted 15 lines · Shuah Khan

Quoted 14 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.8.7 release. There are 138 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Fri Nov 11 10:28:05 UTC 2016. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
	kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.8.7-rc1.gz
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.8.y
and the diffstat can be found below.

Quoted 6 lines

Quoted 4 lines
thanks,
greg k-h
Compiled and booted on my test system. No dmesg regressions.

Thanks for testing these and letting me know.

greg k-h

Guenter Roeck

2016-11-09 19:36 UTC #124 lore raw