Skip to contentSkip to conversation

4.4.92-stable review

PATCH In review Greg Kroah-Hartman 6 participants 55 messages Oct 10, 2017 – Oct 12, 2017 1 message not in the archive Stable branch

lore
Share & tools
lore

Greg Kroah-Hartman

author maintainer
#0 lore raw

cover 4.4.92-stable review

This is the start of the stable review cycle for the 4.4.92 release. There are 47 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 Thu Oct 12 19:50:01 UTC 2017. 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.4.92-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.4.y
and the diffstat can be found below.

thanks,

greg k-h

-------------
Pseudo-Shortlog of commits:

Greg Kroah-Hartman <[email protected]>

    Linux 4.4.92-rc1

Theodore Ts'o <[email protected]>
ext4: don't allow encrypted operations without keys

Jan Kara <[email protected]>
ext4: Don't clear SGID when inheriting ACLs

Jan Kara <[email protected]>
ext4: fix data corruption for mmap writes

Peter Zijlstra <[email protected]>
sched/cpuset/pm: Fix cpuset vs. suspend-resume bugs

Keith Busch <[email protected]>
nvme: protect against simultaneous shutdown invocations

Jani Nikula <[email protected]>
drm/i915/bios: ignore HDMI on port A

Arend Van Spriel <[email protected]>
brcmfmac: setup passive scan if requested by user-space

Andrey Konovalov <[email protected]>
uwb: ensure that endpoint is interrupt

Andrey Konovalov <[email protected]>
uwb: properly check kthread_run return value

Lukas Wunner <[email protected]>

    iio: adc: mcp320x: Fix oops on module unload

Lukas Wunner <[email protected]>

    iio: adc: mcp320x: Fix readout of negative voltages

Dragos Bogdan <[email protected]>
iio: ad7793: Fix the serial interface reset

Matt Fornero <[email protected]>
iio: core: Return error for failed read_reg

Stefan Popa <[email protected]>
staging: iio: ad7192: Fix - use the dedicated reset function avoiding dma from stack.

Dragos Bogdan <[email protected]>
iio: ad_sigma_delta: Implement a dedicated reset function

Christophe JAILLET <[email protected]>
iio: adc: twl4030: Disable the vusb3v1 rugulator in the error handling path of 'twl4030_madc_probe()'

Christophe JAILLET <[email protected]>
iio: adc: twl4030: Fix an error handling path in 'twl4030_madc_probe()'

Mathias Nyman <[email protected]>
xhci: fix finding correct bus_state structure for USB 3.1 hosts

Greg Kroah-Hartman <[email protected]>
USB: fix out-of-bounds in usb_set_configuration

Dmitry Fleytman <[email protected]>
usb: Increase quirk delay for USB devices

Greg Kroah-Hartman <[email protected]>
USB: core: harden cdc_parse_cdc_header

Alan Stern <[email protected]>
USB: uas: fix bug in handling of alternate settings

Martin K. Petersen <[email protected]>
scsi: sd: Do not override max_sectors_kb sysfs setting

Luca Coelho <[email protected]>
iwlwifi: add workaround to disable wide channels in 5GHz

Adrian Salido <[email protected]>
HID: i2c-hid: allocate hid buffers for real worst case

Shu Wang <[email protected]>
ftrace: Fix kmemleak in unregister_ftrace_graph

Alexander Shishkin <[email protected]>
stm class: Fix a use-after-free

Olaf Hering <[email protected]>
Drivers: hv: fcopy: restore correct transfer length

Nicolai Stange <[email protected]>
driver core: platform: Don't read past the end of "driver_override" buffer

Takashi Iwai <[email protected]>
ALSA: usx2y: Suppress kernel warning at page allocation failures

Guneshwor Singh <[email protected]>
ALSA: compress: Remove unused variable

Casey Schaufler <[email protected]>
lsm: fix smack_inode_removexattr and xattr_getsecurity memleak

Alan Stern <[email protected]>
USB: g_mass_storage: Fix deadlock when driver is unbound

Li Jun <[email protected]>
usb: gadget: mass_storage: set msg_registered after msg registered

Dan Carpenter <[email protected]>
USB: devio: Don't corrupt user memory

Alan Stern <[email protected]>
USB: dummy-hcd: Fix erroneous synchronization change

Alan Stern <[email protected]>
USB: dummy-hcd: fix infinite-loop resubmission bug

Alan Stern <[email protected]>
USB: dummy-hcd: fix connection failures (wrong speed)

Jim Dickerson <[email protected]>
usb: pci-quirks.c: Corrected timeout values used in handshake

Takashi Iwai <[email protected]>
ALSA: usb-audio: Check out-of-bounds access by corrupted buffer descriptor

Yoshihiro Shimoda <[email protected]>
usb: renesas_usbhs: fix usbhsf_fifo_clear() for RX direction

Yoshihiro Shimoda <[email protected]>
usb: renesas_usbhs: fix the BCLR setting condition for non-DCP pipe

Alan Stern <[email protected]>
usb-storage: unusual_devs entry to fix write-access regression for Seagate external drives

Nicolas Ferre <[email protected]>
usb: gadget: udc: atmel: set vbus irqflags explicitly

Alan Stern <[email protected]>
USB: gadgetfs: fix copy_to_user while holding spinlock

Alan Stern <[email protected]>
USB: gadgetfs: Fix crash caused by inadequate synchronization

David Eccher <[email protected]>
usb: gadget: inode.c: fix unbalanced spin_lock in ep0_write

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

Diffstat:

 Makefile                                           |  4 +-
 drivers/base/platform.c                            |  3 +-
 drivers/gpu/drm/i915/intel_bios.c                  |  7 +++
 drivers/hid/i2c-hid/i2c-hid.c                      |  3 +-
 drivers/hv/hv_fcopy.c                              |  4 ++
 drivers/hwtracing/stm/core.c                       |  2 +-
 drivers/iio/adc/ad7793.c                           |  4 +-
 drivers/iio/adc/ad_sigma_delta.c                   | 28 +++++++++
 drivers/iio/adc/mcp320x.c                          | 25 +++++---
 drivers/iio/adc/twl4030-madc.c                     | 10 +++-
 drivers/iio/industrialio-core.c                    |  4 +-
 drivers/net/usb/usbnet.c                           |  4 ++
 drivers/net/wireless/brcm80211/brcmfmac/cfg80211.c | 19 ++----
 .../net/wireless/brcm80211/brcmfmac/fwil_types.h   |  5 ++
 drivers/net/wireless/iwlwifi/iwl-nvm-parse.c       | 70 ++++++++++++++++++----
 drivers/nvme/host/nvme.h                           |  2 +
 drivers/nvme/host/pci.c                            |  3 +
 drivers/scsi/sd.c                                  | 19 ++++--
 drivers/staging/iio/adc/ad7192.c                   |  4 +-
 drivers/usb/core/config.c                          | 16 +++--
 drivers/usb/core/devio.c                           |  6 +-
 drivers/usb/core/hub.c                             |  2 +-
 drivers/usb/gadget/function/f_mass_storage.c       | 27 +++------
 drivers/usb/gadget/function/f_mass_storage.h       | 14 -----
 drivers/usb/gadget/legacy/inode.c                  | 49 ++++++++++++---
 drivers/usb/gadget/legacy/mass_storage.c           | 20 +------
 drivers/usb/gadget/udc/atmel_usba_udc.c            |  4 +-
 drivers/usb/gadget/udc/dummy_hcd.c                 | 56 +++++++++++++++--
 drivers/usb/host/pci-quirks.c                      |  8 +--
 drivers/usb/host/xhci.h                            |  2 +-
 drivers/usb/renesas_usbhs/fifo.c                   | 21 ++++++-
 drivers/usb/storage/uas-detect.h                   | 15 ++---
 drivers/usb/storage/uas.c                          | 10 ++--
 drivers/usb/storage/unusual_devs.h                 |  7 +++
 drivers/uwb/hwa-rc.c                               |  2 +
 drivers/uwb/uwbd.c                                 | 12 ++--
 fs/ext4/acl.c                                      | 22 ++++---
 fs/ext4/inode.c                                    | 24 ++++++--
 fs/ext4/namei.c                                    | 12 ++++
 fs/xattr.c                                         |  2 +-
 include/linux/cpuset.h                             |  6 ++
 include/linux/iio/adc/ad_sigma_delta.h             |  3 +
 include/uapi/linux/usb/ch9.h                       |  1 +
 kernel/cpuset.c                                    | 16 ++++-
 kernel/power/process.c                             |  5 +-
 kernel/sched/core.c                                |  7 +--
 kernel/trace/ftrace.c                              | 14 -----
 security/smack/smack_lsm.c                         | 55 ++++++++---------
 sound/core/compress_offload.c                      |  3 +-
 sound/usb/card.c                                   | 20 +++++++
 sound/usb/usx2y/usb_stream.c                       |  6 +-
 51 files changed, 468 insertions(+), 219 deletions(-)
author maintainer
#6 lore raw

PATCH 6/47 usb: renesas_usbhs: fix the BCLR setting condition for non-DCP pipe

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

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

From: Yoshihiro Shimoda <[email protected]>

commit 6124607acc88fffeaadf3aacfeb3cc1304c87387 upstream.

This patch fixes an issue that the driver sets the BCLR bit of {C,Dn}FIFOCTR register to 1 even when it's non-DCP pipe and the FRDY bit of {C,Dn}FIFOCTR register is set to 1.

Fixes e8d548d54968 ("usb: renesas_usbhs: fifo became independent from pipe.")
---
 drivers/usb/renesas_usbhs/fifo.c |   10 ++++++++--
 1 file changed, 8 insertions(+), 2 deletions(-)
drivers/usb/renesas_usbhs/fifo.c +8 -2
@@ -285,11 +285,17 @@ static void usbhsf_fifo_clear(struct usb
 			      struct usbhs_fifo *fifo)
 {
 	struct usbhs_priv *priv = usbhs_pipe_to_priv(pipe);
+	int ret = 0;
 
 	if (!usbhs_pipe_is_dcp(pipe))
-		usbhsf_fifo_barrier(priv, fifo);
+		ret = usbhsf_fifo_barrier(priv, fifo);
 
-	usbhs_write(priv, fifo->ctr, BCLR);
+	/*
+	 * if non-DCP pipe, this driver should set BCLR when
+	 * usbhsf_fifo_barrier() returns 0.
+	 */
+	if (!ret)
+		usbhs_write(priv, fifo->ctr, BCLR);
 }
 
 static int usbhsf_fifo_rcv_len(struct usbhs_priv *priv,
author maintainer
#7 lore raw

PATCH 7/47 usb: renesas_usbhs: fix usbhsf_fifo_clear() for RX direction

In reply to Greg Kroah-Hartman

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

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

From: Yoshihiro Shimoda <[email protected]>

commit 0a2ce62b61f2c76d0213edf4e37aaf54a8ddf295 upstream.

This patch fixes an issue that the usbhsf_fifo_clear() is possible to cause 10 msec delay if the pipe is RX direction and empty because the FRDY bit will never be set to 1 in such case.

Fixes e8d548d54968 ("usb: renesas_usbhs: fifo became independent from pipe.")
---
 drivers/usb/renesas_usbhs/fifo.c |   13 +++++++++++--
 1 file changed, 11 insertions(+), 2 deletions(-)
drivers/usb/renesas_usbhs/fifo.c +11 -2
@@ -287,8 +287,17 @@ static void usbhsf_fifo_clear(struct usb
 	struct usbhs_priv *priv = usbhs_pipe_to_priv(pipe);
 	int ret = 0;
 
-	if (!usbhs_pipe_is_dcp(pipe))
-		ret = usbhsf_fifo_barrier(priv, fifo);
+	if (!usbhs_pipe_is_dcp(pipe)) {
+		/*
+		 * This driver checks the pipe condition first to avoid -EBUSY
+		 * from usbhsf_fifo_barrier() with about 10 msec delay in
+		 * the interrupt handler if the pipe is RX direction and empty.
+		 */
+		if (usbhs_pipe_is_dir_in(pipe))
+			ret = usbhs_pipe_is_accessible(pipe);
+		if (!ret)
+			ret = usbhsf_fifo_barrier(priv, fifo);
+	}
 
 	/*
 	 * if non-DCP pipe, this driver should set BCLR when
author maintainer
#9 lore raw

PATCH 9/47 usb: pci-quirks.c: Corrected timeout values used in handshake

In reply to Greg Kroah-Hartman

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

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

From: Jim Dickerson <[email protected]>

commit 114ec3a6f9096d211a4aff4277793ba969a62c73 upstream.

Servers were emitting failed handoff messages but were not waiting the full 1 second as designated in section 4.22.1 of the eXtensible Host Controller Interface specifications. The handshake was using wrong units so calls were made with milliseconds not microseconds. Comments referenced 5 seconds not 1 second as in specs.

The wrong units were also corrected in a second handshake call.

---
 drivers/usb/host/pci-quirks.c |    8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)
drivers/usb/host/pci-quirks.c +4 -4
@@ -969,7 +969,7 @@ EXPORT_SYMBOL_GPL(usb_disable_xhci_ports
  *
  * Takes care of the handoff between the Pre-OS (i.e. BIOS) and the OS.
  * It signals to the BIOS that the OS wants control of the host controller,
- * and then waits 5 seconds for the BIOS to hand over control.
+ * and then waits 1 second for the BIOS to hand over control.
  * If we timeout, assume the BIOS is broken and take control anyway.
  */
 static void quirk_usb_handoff_xhci(struct pci_dev *pdev)
@@ -1015,9 +1015,9 @@ static void quirk_usb_handoff_xhci(struc
 	if (val & XHCI_HC_BIOS_OWNED) {
 		writel(val | XHCI_HC_OS_OWNED, base + ext_cap_offset);
 
-		/* Wait for 5 seconds with 10 microsecond polling interval */
+		/* Wait for 1 second with 10 microsecond polling interval */
 		timeout = handshake(base + ext_cap_offset, XHCI_HC_BIOS_OWNED,
-				0, 5000, 10);
+				0, 1000000, 10);
 
 		/* Assume a buggy BIOS and take HC ownership anyway */
 		if (timeout) {
@@ -1046,7 +1046,7 @@ hc_init:
 	 * operational or runtime registers.  Wait 5 seconds and no more.
 	 */
 	timeout = handshake(op_reg_base + XHCI_STS_OFFSET, XHCI_STS_CNR, 0,
-			5000, 10);
+			5000000, 10);
 	/* Assume a buggy HC and start HC initialization anyway */
 	if (timeout) {
 		val = readl(op_reg_base + XHCI_STS_OFFSET);
author maintainer
#12 lore raw

PATCH 12/47 USB: dummy-hcd: Fix erroneous synchronization change

In reply to Greg Kroah-Hartman

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

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

From: Alan Stern <[email protected]>

commit 7dbd8f4cabd96db5a50513de9d83a8105a5ffc81 upstream.

A recent change to the synchronization in dummy-hcd was incorrect. The issue was that dummy_udc_stop() contained no locking and therefore could race with various gadget driver callbacks, and the fix was to add locking and issue the callbacks with the private spinlock held.

UDC drivers aren't supposed to do this. Gadget driver callback routines are allowed to invoke functions in the UDC driver, and these functions will generally try to acquire the private spinlock. This would deadlock the driver.

The correct solution is to drop the spinlock before issuing callbacks, and avoid races by emulating the synchronize_irq() call that all real UDC drivers must perform in their ->udc_stop() routines after disabling interrupts. This involves adding a flag to dummy-hcd's private structure to keep track of whether interrupts are supposed to be enabled, and adding a counter to keep track of ongoing callbacks so that dummy_udc_stop() can wait for them all to finish.

A real UDC driver won't receive disconnect, reset, suspend, resume, or setup events once it has disabled interrupts. dummy-hcd will receive them but won't try to issue any gadget driver callbacks, which should be just as good.

Fixes f16443a034c7 ("USB: gadgetfs, dummy-hcd, net2280: fix locking for callbacks")
---
 drivers/usb/gadget/udc/dummy_hcd.c |   32 ++++++++++++++++++++++++++++++--
 1 file changed, 30 insertions(+), 2 deletions(-)
drivers/usb/gadget/udc/dummy_hcd.c +30 -2
@@ -255,11 +255,13 @@ struct dummy {
 	 */
 	struct dummy_ep			ep[DUMMY_ENDPOINTS];
 	int				address;
+	int				callback_usage;
 	struct usb_gadget		gadget;
 	struct usb_gadget_driver	*driver;
 	struct dummy_request		fifo_req;
 	u8				fifo_buf[FIFO_SIZE];
 	u16				devstatus;
+	unsigned			ints_enabled:1;
 	unsigned			udc_suspended:1;
 	unsigned			pullup:1;
 
@@ -442,18 +444,27 @@ static void set_link_state(struct dummy_
 				(~dum_hcd->old_status) & dum_hcd->port_status;
 
 		/* Report reset and disconnect events to the driver */
-		if (dum->driver && (disconnect || reset)) {
+		if (dum->ints_enabled && (disconnect || reset)) {
 			stop_activity(dum);
+			++dum->callback_usage;
+			spin_unlock(&dum->lock);
 			if (reset)
 				usb_gadget_udc_reset(&dum->gadget, dum->driver);
 			else
 				dum->driver->disconnect(&dum->gadget);
+			spin_lock(&dum->lock);
+			--dum->callback_usage;
 		}
-	} else if (dum_hcd->active != dum_hcd->old_active) {
+	} else if (dum_hcd->active != dum_hcd->old_active &&
+			dum->ints_enabled) {
+		++dum->callback_usage;
+		spin_unlock(&dum->lock);
 		if (dum_hcd->old_active && dum->driver->suspend)
 			dum->driver->suspend(&dum->gadget);
 		else if (!dum_hcd->old_active &&  dum->driver->resume)
 			dum->driver->resume(&dum->gadget);
+		spin_lock(&dum->lock);
+		--dum->callback_usage;
 	}
 
 	dum_hcd->old_status = dum_hcd->port_status;
@@ -969,8 +980,11 @@ static int dummy_udc_start(struct usb_ga
 	 * can't enumerate without help from the driver we're binding.
 	 */
 
+	spin_lock_irq(&dum->lock);
 	dum->devstatus = 0;
 	dum->driver = driver;
+	dum->ints_enabled = 1;
+	spin_unlock_irq(&dum->lock);
 
 	return 0;
 }
@@ -981,6 +995,16 @@ static int dummy_udc_stop(struct usb_gad
 	struct dummy		*dum = dum_hcd->dum;
 
 	spin_lock_irq(&dum->lock);
+	dum->ints_enabled = 0;
+	stop_activity(dum);
+
+	/* emulate synchronize_irq(): wait for callbacks to finish */
+	while (dum->callback_usage > 0) {
+		spin_unlock_irq(&dum->lock);
+		usleep_range(1000, 2000);
+		spin_lock_irq(&dum->lock);
+	}
+
 	dum->driver = NULL;
 	spin_unlock_irq(&dum->lock);
 
@@ -1526,6 +1550,8 @@ static struct dummy_ep *find_endpoint(st
 	if (!is_active((dum->gadget.speed == USB_SPEED_SUPER ?
 			dum->ss_hcd : dum->hs_hcd)))
 		return NULL;
+	if (!dum->ints_enabled)
+		return NULL;
 	if ((address & ~USB_DIR_IN) == 0)
 		return &dum->ep[0];
 	for (i = 1; i < DUMMY_ENDPOINTS; i++) {
@@ -1867,10 +1893,12 @@ restart:
 			 * until setup() returns; no reentrancy issues etc.
 			 */
 			if (value > 0) {
+				++dum->callback_usage;
 				spin_unlock(&dum->lock);
 				value = dum->driver->setup(&dum->gadget,
 						&setup);
 				spin_lock(&dum->lock);
+				--dum->callback_usage;
 
 				if (value >= 0) {
 					/* no delays (max 64KB data stage) */
author maintainer
#15 lore raw

PATCH 15/47 USB: g_mass_storage: Fix deadlock when driver is unbound

In reply to Greg Kroah-Hartman

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

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

From: Alan Stern <[email protected]>

commit 1fbbb78f25d1291274f320462bf6908906f538db upstream.

As a holdover from the old g_file_storage gadget, the g_mass_storage legacy gadget driver attempts to unregister itself when its main operating thread terminates (if it hasn't been unregistered already). This is not strictly necessary; it was never more than an attempt to have the gadget fail cleanly if something went wrong and the main thread was killed.

However, now that the UDC core manages gadget drivers independently of UDC drivers, this scheme doesn't work any more. A simple test:

modprobe dummy-hcd
modprobe g-mass-storage file=...
rmmod dummy-hcd

ends up in a deadlock with the following backtrace:

sysrq: SysRq : Show Blocked State
task PC stack pid father
file-storage D 0 1130 2 0x00000000

 Call Trace:
  __schedule+0x53e/0x58c
  schedule+0x6e/0x77
  schedule_preempt_disabled+0xd/0xf
  __mutex_lock.isra.1+0x129/0x224
  ? _raw_spin_unlock_irqrestore+0x12/0x14
  __mutex_lock_slowpath+0x12/0x14
  mutex_lock+0x28/0x2b
  usb_gadget_unregister_driver+0x29/0x9b [udc_core]
  usb_composite_unregister+0x10/0x12 [libcomposite]
  msg_cleanup+0x1d/0x20 [g_mass_storage]
  msg_thread_exits+0xd/0xdd7 [g_mass_storage]
  fsg_main_thread+0x1395/0x13d6 [usb_f_mass_storage]
  ? __schedule+0x573/0x58c
  kthread+0xd9/0xdb
  ? do_set_interface+0x25c/0x25c [usb_f_mass_storage]
  ? init_completion+0x1e/0x1e
  ret_from_fork+0x19/0x24
 rmmod           D    0  1155    683 0x00000000
 Call Trace:
  __schedule+0x53e/0x58c
  schedule+0x6e/0x77
  schedule_timeout+0x26/0xbc
  ? __schedule+0x573/0x58c
  do_wait_for_common+0xb3/0x128
  ? usleep_range+0x81/0x81
  ? wake_up_q+0x3f/0x3f
  wait_for_common+0x2e/0x45
  wait_for_completion+0x17/0x19
  fsg_common_put+0x34/0x81 [usb_f_mass_storage]
  fsg_free_inst+0x13/0x1e [usb_f_mass_storage]
  usb_put_function_instance+0x1a/0x25 [libcomposite]
  msg_unbind+0x2a/0x42 [g_mass_storage]
  __composite_unbind+0x4a/0x6f [libcomposite]
  composite_unbind+0x12/0x14 [libcomposite]
  usb_gadget_remove_driver+0x4f/0x77 [udc_core]
  usb_del_gadget_udc+0x52/0xcc [udc_core]
  dummy_udc_remove+0x27/0x2c [dummy_hcd]
  platform_drv_remove+0x1d/0x31
  device_release_driver_internal+0xe9/0x16d
  device_release_driver+0x11/0x13
  bus_remove_device+0xd2/0xe2
  device_del+0x19f/0x221
  ? selinux_capable+0x22/0x27
  platform_device_del+0x21/0x63
  platform_device_unregister+0x10/0x1a
  cleanup+0x20/0x817 [dummy_hcd]
  SyS_delete_module+0x10c/0x197
  ? ____fput+0xd/0xf
  ? task_work_run+0x55/0x62
  ? prepare_exit_to_usermode+0x65/0x75
  do_fast_syscall_32+0x86/0xc3
  entry_SYSENTER_32+0x4e/0x7c

What happens is that removing the dummy-hcd driver causes the UDC core to unbind the gadget driver, which it does while holding the udc_lock mutex. The unbind routine in g_mass_storage tells the main thread to exit and waits for it to terminate.

But as mentioned above, when the main thread exits it tries to unregister the mass-storage function driver. Via the composite framework this ends up calling usb_gadget_unregister_driver(), which tries to acquire the udc_lock mutex. The result is deadlock.

The simplest way to fix the problem is not to be so clever: The main thread doesn't have to unregister the function driver. The side effects won't be so terrible; if the gadget is still attached to a USB host when the main thread is killed, it will appear to the host as though the gadget's firmware has crashed -- a reasonably accurate interpretation, and an all-too-common occurrence for USB mass-storage devices.

In fact, the code to unregister the driver when the main thread exits is specific to g-mass-storage; it is not used when f-mass-storage is included as a function in a larger composite device. Therefore the entire mechanism responsible for this (the fsg_operations structure with its ->thread_exits method, the fsg_common_set_ops() routine, and the msg_thread_exits() callback routine) can all be eliminated. Even the msg_registered bitflag can be removed, because now the driver is unregistered in only one place rather than in two places.

---
 drivers/usb/gadget/function/f_mass_storage.c |   29 +++++++--------------------
 drivers/usb/gadget/function/f_mass_storage.h |   14 -------------
 drivers/usb/gadget/legacy/mass_storage.c     |   26 ++----------------------
 3 files changed, 11 insertions(+), 58 deletions(-)
drivers/usb/gadget/function/f_mass_storage.c +8 -21
@@ -306,8 +306,6 @@ struct fsg_common {
 	struct completion	thread_notifier;
 	struct task_struct	*thread_task;
 
-	/* Callback functions. */
-	const struct fsg_operations	*ops;
 	/* Gadget's private data. */
 	void			*private_data;
 
@@ -2504,6 +2502,7 @@ static void handle_exception(struct fsg_
 static int fsg_main_thread(void *common_)
 {
 	struct fsg_common	*common = common_;
+	int			i;
 
 	/*
 	 * Allow the thread to be killed by a signal, but set the signal mask
@@ -2565,21 +2564,16 @@ static int fsg_main_thread(void *common_
 	common->thread_task = NULL;
 	spin_unlock_irq(&common->lock);
 
-	if (!common->ops || !common->ops->thread_exits
-	 || common->ops->thread_exits(common) < 0) {
-		int i;
-
-		down_write(&common->filesem);
-		for (i = 0; i < ARRAY_SIZE(common->luns); --i) {
-			struct fsg_lun *curlun = common->luns[i];
-			if (!curlun || !fsg_lun_is_open(curlun))
-				continue;
+	/* Eject media from all LUNs */
 
+	down_write(&common->filesem);
+	for (i = 0; i < ARRAY_SIZE(common->luns); i++) {
+		struct fsg_lun *curlun = common->luns[i];
+
+		if (curlun && fsg_lun_is_open(curlun))
 			fsg_lun_close(curlun);
-			curlun->unit_attention_data = SS_MEDIUM_NOT_PRESENT;
-		}
-		up_write(&common->filesem);
 	}
+	up_write(&common->filesem);
 
 	/* Let fsg_unbind() know the thread has exited */
 	complete_and_exit(&common->thread_notifier, 0);
@@ -2785,13 +2779,6 @@ void fsg_common_remove_luns(struct fsg_c
 }
 EXPORT_SYMBOL_GPL(fsg_common_remove_luns);
 
-void fsg_common_set_ops(struct fsg_common *common,
-			const struct fsg_operations *ops)
-{
-	common->ops = ops;
-}
-EXPORT_SYMBOL_GPL(fsg_common_set_ops);
-
 void fsg_common_free_buffers(struct fsg_common *common)
 {
 	_fsg_common_free_buffers(common->buffhds, common->fsg_num_buffers);
drivers/usb/gadget/function/f_mass_storage.h +0 -14
@@ -60,17 +60,6 @@ struct fsg_module_parameters {
 struct fsg_common;
 
 /* FSF callback functions */
-struct fsg_operations {
-	/*
-	 * Callback function to call when thread exits.  If no
-	 * callback is set or it returns value lower then zero MSF
-	 * will force eject all LUNs it operates on (including those
-	 * marked as non-removable or with prevent_medium_removal flag
-	 * set).
-	 */
-	int (*thread_exits)(struct fsg_common *common);
-};
-
 struct fsg_lun_opts {
 	struct config_group group;
 	struct fsg_lun *lun;
@@ -141,9 +130,6 @@ void fsg_common_remove_lun(struct fsg_lu
 
 void fsg_common_remove_luns(struct fsg_common *common);
 
-void fsg_common_set_ops(struct fsg_common *common,
-			const struct fsg_operations *ops);
-
 int fsg_common_create_lun(struct fsg_common *common, struct fsg_lun_config *cfg,
 			  unsigned int id, const char *name,
 			  const char **name_pfx);
drivers/usb/gadget/legacy/mass_storage.c +3 -23
@@ -107,15 +107,6 @@ static unsigned int fsg_num_buffers = CO
 
 FSG_MODULE_PARAMETERS(/* no prefix */, mod_data);
 
-static unsigned long msg_registered;
-static void msg_cleanup(void);
-
-static int msg_thread_exits(struct fsg_common *common)
-{
-	msg_cleanup();
-	return 0;
-}
-
 static int msg_do_config(struct usb_configuration *c)
 {
 	struct fsg_opts *opts;
@@ -154,9 +145,6 @@ static struct usb_configuration msg_conf
 
 static int msg_bind(struct usb_composite_dev *cdev)
 {
-	static const struct fsg_operations ops = {
-		.thread_exits = msg_thread_exits,
-	};
 	struct fsg_opts *opts;
 	struct fsg_config config;
 	int status;
@@ -173,8 +161,6 @@ static int msg_bind(struct usb_composite
 	if (status)
 		goto fail;
 
-	fsg_common_set_ops(opts->common, &ops);
-
 	status = fsg_common_set_cdev(opts->common, cdev, config.can_stall);
 	if (status)
 		goto fail_set_cdev;
@@ -256,18 +242,12 @@ MODULE_LICENSE("GPL");
 
 static int __init msg_init(void)
 {
-	int ret;
-
-	ret = usb_composite_probe(&msg_driver);
-	set_bit(0, &msg_registered);
-
-	return ret;
+	return usb_composite_probe(&msg_driver);
 }
 module_init(msg_init);
 
-static void msg_cleanup(void)
+static void __exit msg_cleanup(void)
 {
-	if (test_and_clear_bit(0, &msg_registered))
-		usb_composite_unregister(&msg_driver);
+	usb_composite_unregister(&msg_driver);
 }
 module_exit(msg_cleanup);
author maintainer
#18 lore raw

PATCH 18/47 ALSA: usx2y: Suppress kernel warning at page allocation failures

In reply to Greg Kroah-Hartman

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

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

From: Takashi Iwai <[email protected]>

commit 7682e399485fe19622b6fd82510b1f4551e48a25 upstream.

The usx2y driver allocates the stream read/write buffers in continuous pages depending on the stream setup, and this may spew the kernel warning messages with a stack trace like:

  WARNING: CPU: 1 PID: 1846 at mm/page_alloc.c:3883
  __alloc_pages_slowpath+0x1ef2/0x2d70
  Modules linked in:
  CPU: 1 PID: 1846 Comm: kworker/1:2 Not tainted
  ....

It may confuse user as if it were any serious error, although this is no fatal error and the driver handles the error case gracefully. Since the driver has already some sanity check of the given size (128 and 256 pages), it can't pass any crazy value. So it's merely page fragmentation.

This patch adds __GFP_NOWARN to each caller for suppressing such kernel warnings. The original issue was spotted by syzkaller.

---
 sound/usb/usx2y/usb_stream.c |    6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)
sound/usb/usx2y/usb_stream.c +4 -2
@@ -191,7 +191,8 @@ struct usb_stream *usb_stream_new(struct
 	}
 
 	pg = get_order(read_size);
-	sk->s = (void *) __get_free_pages(GFP_KERNEL|__GFP_COMP|__GFP_ZERO, pg);
+	sk->s = (void *) __get_free_pages(GFP_KERNEL|__GFP_COMP|__GFP_ZERO|
+					  __GFP_NOWARN, pg);
 	if (!sk->s) {
 		snd_printk(KERN_WARNING "couldn't __get_free_pages()\n");
 		goto out;
@@ -211,7 +212,8 @@ struct usb_stream *usb_stream_new(struct
 	pg = get_order(write_size);
 
 	sk->write_page =
-		(void *)__get_free_pages(GFP_KERNEL|__GFP_COMP|__GFP_ZERO, pg);
+		(void *)__get_free_pages(GFP_KERNEL|__GFP_COMP|__GFP_ZERO|
+					 __GFP_NOWARN, pg);
 	if (!sk->write_page) {
 		snd_printk(KERN_WARNING "couldn't __get_free_pages()\n");
 		usb_stream_free(sk);
author maintainer
#20 lore raw

PATCH 20/47 Drivers: hv: fcopy: restore correct transfer length

In reply to Greg Kroah-Hartman

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

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

From: Olaf Hering <[email protected]>

commit 549e658a0919e355a2b2144dc380b3729bef7f3e upstream.

Till recently the expected length of bytes read by the daemon did depend on the context. It was either hv_start_fcopy or hv_do_fcopy. The daemon had a buffer size of two pages, which was much larger than needed.

Now the expected length of bytes read by the
daemon changed slightly. For START_FILE_COPY it is still the size of hv_start_fcopy. But for WRITE_TO_FILE and the other operations it is as large as the buffer that arrived via vmbus. In case of WRITE_TO_FILE that is slightly larger than a struct hv_do_fcopy. Since the buffer in the daemon was still larger everything was fine.

Currently, the daemon reads only what is actually needed. The new buffer layout is as large as a struct hv_do_fcopy, for the WRITE_TO_FILE operation. Since the kernel expects a slightly larger size, hvt_op_read will return -EINVAL because the daemon will read slightly less than expected. Address this by restoring the expected buffer size in case of WRITE_TO_FILE.

Fixes 'c7e490fc23eb ("Drivers: hv: fcopy: convert to hv_utils_transport")'
Fixes '3f2baa8a7d2e ("Tools: hv: update buffer handling in hv_fcopy_daemon")'
---
 drivers/hv/hv_fcopy.c |    4 ++++
 1 file changed, 4 insertions(+)
drivers/hv/hv_fcopy.c +4 -0
@@ -155,6 +155,10 @@ static void fcopy_send_data(struct work_
 		out_src = smsg_out;
 		break;
 
+	case WRITE_TO_FILE:
+		out_src = fcopy_transaction.fcopy_msg;
+		out_len = sizeof(struct hv_do_fcopy);
+		break;
 	default:
 		out_src = fcopy_transaction.fcopy_msg;
 		out_len = fcopy_transaction.recv_len;
author maintainer
#21 lore raw

PATCH 21/47 stm class: Fix a use-after-free

In reply to Greg Kroah-Hartman

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

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

From: Alexander Shishkin <[email protected]>

commit fd085bb1766d6a598f53af2308374a546a49775a upstream.

For reasons unknown, the stm_source removal path uses device_destroy() to kill the underlying device object. Because device_destroy() uses devt to look for the device to destroy and the fact that stm_source devices don't have one (or all have the same one), it just picks the first device in the class, which may well be the wrong one.

That is, loading stm_console and stm_heartbeat and then removing both will die in dereferencing a freed object.

Since this should have been device_unregister() in the first place, use it instead of device_destroy().

Fixes 7bd1d4093c2 ("stm class: Introduce an abstraction for System Trace Module devices")
---
 drivers/hwtracing/stm/core.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/hwtracing/stm/core.c +1 -1
@@ -952,7 +952,7 @@ void stm_source_unregister_device(struct
 
 	stm_source_link_drop(src);
 
-	device_destroy(&stm_source_class, src->dev.devt);
+	device_unregister(&src->dev);
 }
 EXPORT_SYMBOL_GPL(stm_source_unregister_device);
 
author maintainer
#23 lore raw

PATCH 23/47 HID: i2c-hid: allocate hid buffers for real worst case

In reply to Greg Kroah-Hartman

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

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

From: Adrian Salido <[email protected]>

commit 8320caeeffdefec3b58b9d4a7ed8e1079492fe7b upstream.

The buffer allocation is not currently accounting for an extra byte for the report id. This can cause an out of bounds access in function i2c_hid_set_or_send_report() with reportID > 15.

---
 drivers/hid/i2c-hid/i2c-hid.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/hid/i2c-hid/i2c-hid.c +2 -1
@@ -540,7 +540,8 @@ static int i2c_hid_alloc_buffers(struct
 {
 	/* the worst case is computed from the set_report command with a
 	 * reportID > 15 and the maximum report length */
-	int args_len = sizeof(__u8) + /* optional ReportID byte */
+	int args_len = sizeof(__u8) + /* ReportID */
+		       sizeof(__u8) + /* optional ReportID byte */
 		       sizeof(__u16) + /* data register */
 		       sizeof(__u16) + /* size of the report */
 		       report_size; /* report */
author maintainer
#24 lore raw

PATCH 24/47 iwlwifi: add workaround to disable wide channels in 5GHz

In reply to Greg Kroah-Hartman

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

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

From: Luca Coelho <[email protected]>

commit 01a9c948a09348950515bf2abb6113ed83e696d8 upstream.

The OTP in some SKUs have erroneously allowed 40MHz and 80MHz channels in the 5.2GHz band. The firmware has been modified to not allow this in those SKUs, so the driver needs to do the same otherwise the firmware will assert when we try to use it.

---
 drivers/net/wireless/iwlwifi/iwl-nvm-parse.c |   70 ++++++++++++++++++++++-----
 1 file changed, 58 insertions(+), 12 deletions(-)
drivers/net/wireless/iwlwifi/iwl-nvm-parse.c +58 -12
@@ -73,6 +73,7 @@
 /* NVM offsets (in words) definitions */
 enum wkp_nvm_offsets {
 	/* NVM HW-Section offset (in words) definitions */
+	SUBSYSTEM_ID = 0x0A,
 	HW_ADDR = 0x15,
 
 	/* NVM SW-Section offset (in words) definitions */
@@ -257,13 +258,12 @@ static u32 iwl_get_channel_flags(u8 ch_n
 static int iwl_init_channel_map(struct device *dev, const struct iwl_cfg *cfg,
 				struct iwl_nvm_data *data,
 				const __le16 * const nvm_ch_flags,
-				bool lar_supported)
+				bool lar_supported, bool no_wide_in_5ghz)
 {
 	int ch_idx;
 	int n_channels = 0;
 	struct ieee80211_channel *channel;
 	u16 ch_flags;
-	bool is_5ghz;
 	int num_of_ch, num_2ghz_channels;
 	const u8 *nvm_chan;
 
@@ -278,12 +278,20 @@ static int iwl_init_channel_map(struct d
 	}
 
 	for (ch_idx = 0; ch_idx < num_of_ch; ch_idx++) {
+		bool is_5ghz = (ch_idx >= num_2ghz_channels);
+
 		ch_flags = __le16_to_cpup(nvm_ch_flags + ch_idx);
 
-		if (ch_idx >= num_2ghz_channels &&
-		    !data->sku_cap_band_52GHz_enable)
+		if (is_5ghz && !data->sku_cap_band_52GHz_enable)
 			continue;
 
+		/* workaround to disable wide channels in 5GHz */
+		if (no_wide_in_5ghz && is_5ghz) {
+			ch_flags &= ~(NVM_CHANNEL_40MHZ |
+				     NVM_CHANNEL_80MHZ |
+				     NVM_CHANNEL_160MHZ);
+		}
+
 		if (!lar_supported && !(ch_flags & NVM_CHANNEL_VALID)) {
 			/*
 			 * Channels might become valid later if lar is
@@ -303,8 +311,8 @@ static int iwl_init_channel_map(struct d
 		n_channels++;
 
 		channel->hw_value = nvm_chan[ch_idx];
-		channel->band = (ch_idx < num_2ghz_channels) ?
-				IEEE80211_BAND_2GHZ : IEEE80211_BAND_5GHZ;
+		channel->band = is_5ghz ?
+				IEEE80211_BAND_5GHZ : IEEE80211_BAND_2GHZ;
 		channel->center_freq =
 			ieee80211_channel_to_frequency(
 				channel->hw_value, channel->band);
@@ -316,7 +324,6 @@ static int iwl_init_channel_map(struct d
 		 * is not used in mvm, and is used for backwards compatibility
 		 */
 		channel->max_power = IWL_DEFAULT_MAX_TX_POWER;
-		is_5ghz = channel->band == IEEE80211_BAND_5GHZ;
 
 		/* don't put limitations in case we're using LAR */
 		if (!lar_supported)
@@ -405,7 +412,8 @@ static void iwl_init_vht_hw_capab(const
 static void iwl_init_sbands(struct device *dev, const struct iwl_cfg *cfg,
 			    struct iwl_nvm_data *data,
 			    const __le16 *ch_section,
-			    u8 tx_chains, u8 rx_chains, bool lar_supported)
+			    u8 tx_chains, u8 rx_chains, bool lar_supported,
+			    bool no_wide_in_5ghz)
 {
 	int n_channels;
 	int n_used = 0;
@@ -414,12 +422,14 @@ static void iwl_init_sbands(struct devic
 	if (cfg->device_family != IWL_DEVICE_FAMILY_8000)
 		n_channels = iwl_init_channel_map(
 				dev, cfg, data,
-				&ch_section[NVM_CHANNELS], lar_supported);
+				&ch_section[NVM_CHANNELS], lar_supported,
+				no_wide_in_5ghz);
 	else
 		n_channels = iwl_init_channel_map(
 				dev, cfg, data,
 				&ch_section[NVM_CHANNELS_FAMILY_8000],
-				lar_supported);
+				lar_supported,
+				no_wide_in_5ghz);
 
 	sband = &data->bands[IEEE80211_BAND_2GHZ];
 	sband->band = IEEE80211_BAND_2GHZ;
@@ -582,6 +592,39 @@ static void iwl_set_hw_address_family_80
 
 #define IWL_4165_DEVICE_ID 0x5501
 
+static bool
+iwl_nvm_no_wide_in_5ghz(struct device *dev, const struct iwl_cfg *cfg,
+			const __le16 *nvm_hw)
+{
+	/*
+	 * Workaround a bug in Indonesia SKUs where the regulatory in
+	 * some 7000-family OTPs erroneously allow wide channels in
+	 * 5GHz.  To check for Indonesia, we take the SKU value from
+	 * bits 1-4 in the subsystem ID and check if it is either 5 or
+	 * 9.  In those cases, we need to force-disable wide channels
+	 * in 5GHz otherwise the FW will throw a sysassert when we try
+	 * to use them.
+	 */
+	if (cfg->device_family == IWL_DEVICE_FAMILY_7000) {
+		/*
+		 * Unlike the other sections in the NVM, the hw
+		 * section uses big-endian.
+		 */
+		u16 subsystem_id = be16_to_cpup((const __be16 *)nvm_hw
+						+ SUBSYSTEM_ID);
+		u8 sku = (subsystem_id & 0x1e) >> 1;
+
+		if (sku == 5 || sku == 9) {
+			IWL_DEBUG_EEPROM(dev,
+					 "disabling wide channels in 5GHz (0x%0x %d)\n",
+					 subsystem_id, sku);
+			return true;
+		}
+	}
+
+	return false;
+}
+
 struct iwl_nvm_data *
 iwl_parse_nvm_data(struct device *dev, const struct iwl_cfg *cfg,
 		   const __le16 *nvm_hw, const __le16 *nvm_sw,
@@ -591,6 +634,7 @@ iwl_parse_nvm_data(struct device *dev, c
 		   u32 mac_addr0, u32 mac_addr1, u32 hw_id)
 {
 	struct iwl_nvm_data *data;
+	bool no_wide_in_5ghz = iwl_nvm_no_wide_in_5ghz(dev, cfg, nvm_hw);
 	u32 sku;
 	u32 radio_cfg;
 	u16 lar_config;
@@ -657,7 +701,8 @@ iwl_parse_nvm_data(struct device *dev, c
 		iwl_set_hw_address(cfg, data, nvm_hw);
 
 		iwl_init_sbands(dev, cfg, data, nvm_sw,
-				tx_chains, rx_chains, lar_fw_supported);
+				tx_chains, rx_chains, lar_fw_supported,
+				no_wide_in_5ghz);
 	} else {
 		u16 lar_offset = data->nvm_version < 0xE39 ?
 				 NVM_LAR_OFFSET_FAMILY_8000_OLD :
@@ -673,7 +718,8 @@ iwl_parse_nvm_data(struct device *dev, c
 
 		iwl_init_sbands(dev, cfg, data, regulatory,
 				tx_chains, rx_chains,
-				lar_fw_supported && data->lar_enabled);
+				lar_fw_supported && data->lar_enabled,
+				no_wide_in_5ghz);
 	}
 
 	data->calib_version = 255;
author maintainer
#26 lore raw

PATCH 26/47 USB: uas: fix bug in handling of alternate settings

In reply to Greg Kroah-Hartman

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

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

From: Alan Stern <[email protected]>

commit 786de92b3cb26012d3d0f00ee37adf14527f35c4 upstream.

The uas driver has a subtle bug in the way it handles alternate settings. The uas_find_uas_alt_setting() routine returns an altsetting value (the bAlternateSetting number in the descriptor), but uas_use_uas_driver() then treats that value as an index to the intf->altsetting array, which it isn't.

Normally this doesn't cause any problems because the various alternate settings have bAlternateSetting values 0, 1, 2, ..., so the value is equal to the index in the array. But this is not guaranteed, and Andrey Konovalov used the syzkaller fuzzer with KASAN to get a slab-out-of-bounds error by violating this assumption.

This patch fixes the bug by making uas_find_uas_alt_setting() return a pointer to the altsetting entry rather than either the value or the index. Pointers are less subject to misinterpretation.

---
 drivers/usb/storage/uas-detect.h |   15 ++++++++-------
 drivers/usb/storage/uas.c        |   10 +++++-----
 2 files changed, 13 insertions(+), 12 deletions(-)
drivers/usb/storage/uas-detect.h +8 -7
@@ -9,7 +9,8 @@ static int uas_is_interface(struct usb_h
 		intf->desc.bInterfaceProtocol == USB_PR_UAS);
 }
 
-static int uas_find_uas_alt_setting(struct usb_interface *intf)
+static struct usb_host_interface *uas_find_uas_alt_setting(
+		struct usb_interface *intf)
 {
 	int i;
 
@@ -17,10 +18,10 @@ static int uas_find_uas_alt_setting(stru
 		struct usb_host_interface *alt = &intf->altsetting[i];
 
 		if (uas_is_interface(alt))
-			return alt->desc.bAlternateSetting;
+			return alt;
 	}
 
-	return -ENODEV;
+	return NULL;
 }
 
 static int uas_find_endpoints(struct usb_host_interface *alt,
@@ -58,14 +59,14 @@ static int uas_use_uas_driver(struct usb
 	struct usb_device *udev = interface_to_usbdev(intf);
 	struct usb_hcd *hcd = bus_to_hcd(udev->bus);
 	unsigned long flags = id->driver_info;
-	int r, alt;
-
+	struct usb_host_interface *alt;
+	int r;
 
 	alt = uas_find_uas_alt_setting(intf);
-	if (alt < 0)
+	if (!alt)
 		return 0;
 
-	r = uas_find_endpoints(&intf->altsetting[alt], eps);
+	r = uas_find_endpoints(alt, eps);
 	if (r < 0)
 		return 0;
 
drivers/usb/storage/uas.c +5 -5
@@ -849,14 +849,14 @@ MODULE_DEVICE_TABLE(usb, uas_usb_ids);
 static int uas_switch_interface(struct usb_device *udev,
 				struct usb_interface *intf)
 {
-	int alt;
+	struct usb_host_interface *alt;
 
 	alt = uas_find_uas_alt_setting(intf);
-	if (alt < 0)
-		return alt;
+	if (!alt)
+		return -ENODEV;
 
-	return usb_set_interface(udev,
-			intf->altsetting[0].desc.bInterfaceNumber, alt);
+	return usb_set_interface(udev, alt->desc.bInterfaceNumber,
+			alt->desc.bAlternateSetting);
 }
 
 static int uas_configure_endpoints(struct uas_dev_info *devinfo)
author maintainer
#27 lore raw

PATCH 27/47 USB: core: harden cdc_parse_cdc_header

In reply to Greg Kroah-Hartman

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

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

From: Greg Kroah-Hartman <[email protected]>

commit 2e1c42391ff2556387b3cb6308b24f6f65619feb upstream.

Andrey Konovalov reported a possible out-of-bounds problem for the cdc_parse_cdc_header function. He writes:
It looks like cdc_parse_cdc_header() doesn't validate buflen before accessing buffer[1], buffer[2] and so on. The only check present is while (buflen > 0).

So fix this issue up by properly validating the buffer length matches what the descriptor says it is.

---
 drivers/net/usb/usbnet.c |    4 ++++
 1 file changed, 4 insertions(+)
drivers/net/usb/usbnet.c +4 -0
@@ -1990,6 +1990,10 @@ int cdc_parse_cdc_header(struct usb_cdc_
 			elength = 1;
 			goto next_desc;
 		}
+		if ((buflen < elength) || (elength < 3)) {
+			dev_err(&intf->dev, "invalid descriptor buffer length\n");
+			break;
+		}
 		if (buffer[1] != USB_DT_CS_INTERFACE) {
 			dev_err(&intf->dev, "skipping garbage\n");
 			goto next_desc;
author maintainer
#30 lore raw

PATCH 30/47 xhci: fix finding correct bus_state structure for USB 3.1 hosts

In reply to Greg Kroah-Hartman

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

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

From: Mathias Nyman <[email protected]>

commit 5a838a13c9b4e5dd188b7a6eaeb894e9358ead0c upstream.

xhci driver keeps a bus_state structure for each hcd (usb2 and usb3)

The structure is picked based on hcd speed, but driver only compared for HCD_USB3 speed, returning the wrong bus_state for HCD_USB31 hosts.

This caused null pointer dereference errors in bus_resume function.

---
 drivers/usb/host/xhci.h |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/usb/host/xhci.h +1 -1
@@ -1490,7 +1490,7 @@ struct xhci_bus_state {
 
 static inline unsigned int hcd_index(struct usb_hcd *hcd)
 {
-	if (hcd->speed == HCD_USB3)
+	if (hcd->speed >= HCD_USB3)
 		return 0;
 	else
 		return 1;
author maintainer
#31 lore raw

PATCH 31/47 iio: adc: twl4030: Fix an error handling path in twl4030_madc_probe()

In reply to Greg Kroah-Hartman

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

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

From: Christophe JAILLET <[email protected]>

commit 245a396a9b1a67ac5c3228737c261b3e48708a2a upstream.

If 'devm_regulator_get()' fails, we should go through the existing error handling path instead of returning directly, as done is all the other error handling paths in this function.

Fixes 7cc97d77ee8a ("iio: adc: twl4030: Fix ADC[3:6] readings")
---
 drivers/iio/adc/twl4030-madc.c |    6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)
drivers/iio/adc/twl4030-madc.c +4 -2
@@ -866,8 +866,10 @@ static int twl4030_madc_probe(struct pla
 
 	/* Enable 3v1 bias regulator for MADC[3:6] */
 	madc->usb3v1 = devm_regulator_get(madc->dev, "vusb3v1");
-	if (IS_ERR(madc->usb3v1))
-		return -ENODEV;
+	if (IS_ERR(madc->usb3v1)) {
+		ret = -ENODEV;
+		goto err_i2c;
+	}
 
 	ret = regulator_enable(madc->usb3v1);
 	if (ret)
author maintainer
#32 lore raw

PATCH 32/47 iio: adc: twl4030: Disable the vusb3v1 rugulator in the error handling path of twl4030_madc_probe()

In reply to Greg Kroah-Hartman

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

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

From: Christophe JAILLET <[email protected]>

commit 7f70be6e4025db0551e6863e7eb9cca07122695c upstream.

Commit 7cc97d77ee8a has introduced a call to 'regulator_disable()' in the .remove function.
So we should also have such a call in the .probe function in case of error after a successful 'regulator_enable()' call.

Add a new label for that and use it.

Fixes 7cc97d77ee8a ("iio: adc: twl4030: Fix ADC[3:6] readings")
---
 drivers/iio/adc/twl4030-madc.c |    4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)
drivers/iio/adc/twl4030-madc.c +3 -1
@@ -878,11 +878,13 @@ static int twl4030_madc_probe(struct pla
 	ret = iio_device_register(iio_dev);
 	if (ret) {
 		dev_err(&pdev->dev, "could not register iio device\n");
-		goto err_i2c;
+		goto err_usb3v1;
 	}
 
 	return 0;
 
+err_usb3v1:
+	regulator_disable(madc->usb3v1);
 err_i2c:
 	twl4030_madc_set_current_generator(madc, 0, 0);
 err_current_generator:
author maintainer
#35 lore raw

PATCH 35/47 iio: core: Return error for failed read_reg

In reply to Greg Kroah-Hartman

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

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

From: Matt Fornero <[email protected]>

commit 3d62c78a6eb9a7d67bace9622b66ad51e81c5f9b upstream.

If an IIO device returns an error code for a read access via debugfs, it is currently ignored by the IIO core (other than emitting an error message). Instead, return this error code to user space, so upper layers can detect it correctly.

---
 drivers/iio/industrialio-core.c |    4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)
drivers/iio/industrialio-core.c +3 -1
@@ -221,8 +221,10 @@ static ssize_t iio_debugfs_read_reg(stru
 	ret = indio_dev->info->debugfs_reg_access(indio_dev,
 						  indio_dev->cached_reg_addr,
 						  0, &val);
-	if (ret)
+	if (ret) {
 		dev_err(indio_dev->dev.parent, "%s: read failed\n", __func__);
+		return ret;
+	}
 
 	len = snprintf(buf, sizeof(buf), "0x%X\n", val);
 
author maintainer
#40 lore raw

PATCH 40/47 uwb: ensure that endpoint is interrupt

In reply to Greg Kroah-Hartman

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

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

From: Andrey Konovalov <[email protected]>

commit 70e743e4cec3733dc13559f6184b35d358b9ef3f upstream.

hwarc_neep_init() assumes that endpoint 0 is interrupt, but there's no check for that, which results in a WARNING in USB core code, when a bad USB descriptor is provided from a device:

usb 1-1: BOGUS urb xfer, pipe 1 != type 3

------------[ cut here ]------------
WARNING: CPU: 0 PID: 3 at drivers/usb/core/urb.c:449 usb_submit_urb+0xf8a/0x11d0
Modules linked in:
CPU: 0 PID: 3 Comm: kworker/0:0 Not tainted 4.13.0+ #111
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Workqueue: usb_hub_wq hub_event
task: ffff88006bdc1a00 task.stack: ffff88006bde8000
RIP: 0010:usb_submit_urb+0xf8a/0x11d0 drivers/usb/core/urb.c:448
RSP: 0018:ffff88006bdee3c0 EFLAGS: 00010282
RAX: 0000000000000029 RBX: ffff8800672a7200 RCX: 0000000000000000
RDX: 0000000000000029 RSI: ffff88006c815c78 RDI: ffffed000d7bdc6a
RBP: ffff88006bdee4c0 R08: fffffbfff0fe00ff R09: fffffbfff0fe00ff
R10: 0000000000000018 R11: fffffbfff0fe00fe R12: 1ffff1000d7bdc7f
R13: 0000000000000003 R14: 0000000000000001 R15: ffff88006b02cc90
FS:  0000000000000000(0000) GS:ffff88006c800000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fe4daddf000 CR3: 000000006add6000 CR4: 00000000000006f0
Call Trace:
 hwarc_neep_init+0x4ce/0x9c0 drivers/uwb/hwa-rc.c:710
 uwb_rc_add+0x2fb/0x730 drivers/uwb/lc-rc.c:361
 hwarc_probe+0x34e/0x9b0 drivers/uwb/hwa-rc.c:858
 usb_probe_interface+0x351/0x8d0 drivers/usb/core/driver.c:361
 really_probe drivers/base/dd.c:385
 driver_probe_device+0x610/0xa00 drivers/base/dd.c:529
 __device_attach_driver+0x230/0x290 drivers/base/dd.c:625
 bus_for_each_drv+0x15e/0x210 drivers/base/bus.c:463
 __device_attach+0x269/0x3c0 drivers/base/dd.c:682
 device_initial_probe+0x1f/0x30 drivers/base/dd.c:729
 bus_probe_device+0x1da/0x280 drivers/base/bus.c:523
 device_add+0xcf9/0x1640 drivers/base/core.c:1703
 usb_set_configuration+0x1064/0x1890 drivers/usb/core/message.c:1932
 generic_probe+0x73/0xe0 drivers/usb/core/generic.c:174
 usb_probe_device+0xaf/0xe0 drivers/usb/core/driver.c:266
 really_probe drivers/base/dd.c:385
 driver_probe_device+0x610/0xa00 drivers/base/dd.c:529
 __device_attach_driver+0x230/0x290 drivers/base/dd.c:625
 bus_for_each_drv+0x15e/0x210 drivers/base/bus.c:463
 __device_attach+0x269/0x3c0 drivers/base/dd.c:682
 device_initial_probe+0x1f/0x30 drivers/base/dd.c:729
 bus_probe_device+0x1da/0x280 drivers/base/bus.c:523
 device_add+0xcf9/0x1640 drivers/base/core.c:1703
 usb_new_device+0x7b8/0x1020 drivers/usb/core/hub.c:2457
 hub_port_connect drivers/usb/core/hub.c:4890
 hub_port_connect_change drivers/usb/core/hub.c:4996
 port_event drivers/usb/core/hub.c:5102
 hub_event+0x23c8/0x37c0 drivers/usb/core/hub.c:5182
 process_one_work+0x9fb/0x1570 kernel/workqueue.c:2097
 worker_thread+0x1e4/0x1350 kernel/workqueue.c:2231
 kthread+0x324/0x3f0 kernel/kthread.c:231
 ret_from_fork+0x25/0x30 arch/x86/entry/entry_64.S:425
Code: 48 8b 85 30 ff ff ff 48 8d b8 98 00 00 00 e8 8e 93 07 ff 45 89
e8 44 89 f1 4c 89 fa 48 89 c6 48 c7 c7 a0 e5 55 86 e8 20 08 8f fd <0f>
ff e9 9b f7 ff ff e8 4a 04 d6 fd e9 80 f7 ff ff e8 60 11 a6
---[ end trace 55d741234124cfc3 ]---

Check that endpoint is interrupt.

Found by syzkaller.

---
 drivers/uwb/hwa-rc.c |    2 ++
 1 file changed, 2 insertions(+)
drivers/uwb/hwa-rc.c +2 -0
@@ -827,6 +827,8 @@ static int hwarc_probe(struct usb_interf
 
 	if (iface->cur_altsetting->desc.bNumEndpoints < 1)
 		return -ENODEV;
+	if (!usb_endpoint_xfer_int(&iface->cur_altsetting->endpoint[0].desc))
+		return -ENODEV;
 
 	result = -ENOMEM;
 	uwb_rc = uwb_rc_alloc();
author maintainer
#1 lore raw

PATCH 1/47 usb: gadget: inode.c: fix unbalanced spin_lock in ep0_write

In reply to Greg Kroah-Hartman

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

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

From: David Eccher <[email protected]>

commit b7bd98b7db9fc8fe19da1a5ff0215311c6b95e46 upstream.

Fix bad unlock balance: ep0_write enter with the locks locked from inode.c:1769, hence it must exit with spinlock held to avoid double unlock in dev_config.

---
 drivers/usb/gadget/legacy/inode.c |    3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)
drivers/usb/gadget/legacy/inode.c +1 -2
@@ -1140,10 +1140,9 @@ ep0_write (struct file *fd, const char _
 						dev->gadget->ep0, dev->req,
 						GFP_KERNEL);
 				}
+				spin_lock_irq(&dev->lock);
 				if (retval < 0) {
-					spin_lock_irq (&dev->lock);
 					clean_req (dev->gadget->ep0, dev->req);
-					spin_unlock_irq (&dev->lock);
 				} else
 					retval = len;
 
author maintainer
#10 lore raw

PATCH 10/47 USB: dummy-hcd: fix connection failures (wrong speed)

In reply to Greg Kroah-Hartman

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

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

From: Alan Stern <[email protected]>

commit fe659bcc9b173bcfdd958ce2aec75e47651e74e1 upstream.

The dummy-hcd UDC driver is not careful about the way it handles connection speeds. It ignores the module parameter that is supposed to govern the maximum connection speed and it doesn't set the HCD flags properly for the case where it ends up running at full speed.

The result is that in many cases, gadget enumeration over dummy-hcd fails because the bMaxPacketSize byte in the device descriptor is set incorrectly. For example, the default settings call for a high-speed connection, but the maxpacket value for ep0 ends up being set for a Super-Speed connection.

This patch fixes the problem by initializing the gadget's max_speed and the HCD flags correctly.

---
 drivers/usb/gadget/udc/dummy_hcd.c |   15 +++++++++++----
 1 file changed, 11 insertions(+), 4 deletions(-)
drivers/usb/gadget/udc/dummy_hcd.c +11 -4
@@ -1032,7 +1032,12 @@ static int dummy_udc_probe(struct platfo
 	memzero_explicit(&dum->gadget, sizeof(struct usb_gadget));
 	dum->gadget.name = gadget_name;
 	dum->gadget.ops = &dummy_ops;
-	dum->gadget.max_speed = USB_SPEED_SUPER;
+	if (mod_data.is_super_speed)
+		dum->gadget.max_speed = USB_SPEED_SUPER;
+	else if (mod_data.is_high_speed)
+		dum->gadget.max_speed = USB_SPEED_HIGH;
+	else
+		dum->gadget.max_speed = USB_SPEED_FULL;
 
 	dum->gadget.dev.parent = &pdev->dev;
 	init_dummy_udc_hw(dum);
@@ -2564,8 +2569,6 @@ static struct hc_driver dummy_hcd = {
 	.product_desc =		"Dummy host controller",
 	.hcd_priv_size =	sizeof(struct dummy_hcd),
 
-	.flags =		HCD_USB3 | HCD_SHARED,
-
 	.reset =		dummy_setup,
 	.start =		dummy_start,
 	.stop =			dummy_stop,
@@ -2594,8 +2597,12 @@ static int dummy_hcd_probe(struct platfo
 	dev_info(&pdev->dev, "%s, driver " DRIVER_VERSION "\n", driver_desc);
 	dum = *((void **)dev_get_platdata(&pdev->dev));
 
-	if (!mod_data.is_super_speed)
+	if (mod_data.is_super_speed)
+		dummy_hcd.flags = HCD_USB3 | HCD_SHARED;
+	else if (mod_data.is_high_speed)
 		dummy_hcd.flags = HCD_USB2;
+	else
+		dummy_hcd.flags = HCD_USB11;
 	hs_hcd = usb_create_hcd(&dummy_hcd, &pdev->dev, dev_name(&pdev->dev));
 	if (!hs_hcd)
 		return -ENOMEM;
author maintainer
#11 lore raw

PATCH 11/47 USB: dummy-hcd: fix infinite-loop resubmission bug

In reply to Greg Kroah-Hartman

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

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

From: Alan Stern <[email protected]>

commit 0173a68bfb0ad1c72a6ee39cc485aa2c97540b98 upstream.

The dummy-hcd HCD/UDC emulator tries not to do too much work during each timer interrupt. But it doesn't try very hard; currently all it does is limit the total amount of bulk data transferred. Other transfer types aren't limited, and URBs that transfer no data (because of an error, perhaps) don't count toward the limit, even though on a real USB bus they would consume at least a minimum overhead.

This means it's possible to get the driver stuck in an infinite loop, for example, if the host class driver resubmits an URB every time it completes (which is common for interrupt URBs). Each time the URB is resubmitted it gets added to the end of the pending-URBs list, and dummy-hcd doesn't stop until that list is empty. Andrey Konovalov was able to trigger this failure mode using the syzkaller fuzzer.

This patch fixes the infinite-loop problem by restricting the URBs handled during each timer interrupt to those that were already on the pending list when the interrupt routine started. Newly added URBs won't be processed until the next timer interrupt. The problem of properly accounting for non-bulk bandwidth (as well as packet and transaction overhead) is not addressed here.

---
 drivers/usb/gadget/udc/dummy_hcd.c |    9 +++++++++
 1 file changed, 9 insertions(+)
drivers/usb/gadget/udc/dummy_hcd.c +9 -0
@@ -237,6 +237,8 @@ struct dummy_hcd {
 
 	struct usb_device		*udev;
 	struct list_head		urbp_list;
+	struct urbp			*next_frame_urbp;
+
 	u32				stream_en_ep;
 	u8				num_stream[30 / 2];
 
@@ -1246,6 +1248,8 @@ static int dummy_urb_enqueue(
 
 	list_add_tail(&urbp->urbp_list, &dum_hcd->urbp_list);
 	urb->hcpriv = urbp;
+	if (!dum_hcd->next_frame_urbp)
+		dum_hcd->next_frame_urbp = urbp;
 	if (usb_pipetype(urb->pipe) == PIPE_CONTROL)
 		urb->error_count = 1;		/* mark as a new urb */
 
@@ -1763,6 +1767,7 @@ static void dummy_timer(unsigned long _d
 		spin_unlock_irqrestore(&dum->lock, flags);
 		return;
 	}
+	dum_hcd->next_frame_urbp = NULL;
 
 	for (i = 0; i < DUMMY_ENDPOINTS; i++) {
 		if (!ep_info[i].name)
@@ -1779,6 +1784,10 @@ restart:
 		int			type;
 		int			status = -EINPROGRESS;
 
+		/* stop when we reach URBs queued after the timer interrupt */
+		if (urbp == dum_hcd->next_frame_urbp)
+			break;
+
 		urb = urbp->urb;
 		if (urb->unlinked)
 			goto return_urb;
author maintainer
#13 lore raw

PATCH 13/47 USB: devio: Dont corrupt user memory

In reply to Greg Kroah-Hartman

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

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

From: Dan Carpenter <[email protected]>

commit fa1ed74eb1c233be6131ec92df21ab46499a15b6 upstream.

The user buffer has "uurb->buffer_length" bytes. If the kernel has more information than that, we should truncate it instead of writing past the end of the user's buffer. I added a WARN_ONCE() to help the user debug the issue.

---
 drivers/usb/core/devio.c |    6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)
drivers/usb/core/devio.c +5 -1
@@ -1417,7 +1417,11 @@ static int proc_do_submiturb(struct usb_
 			totlen += isopkt[u].length;
 		}
 		u *= sizeof(struct usb_iso_packet_descriptor);
-		uurb->buffer_length = totlen;
+		if (totlen <= uurb->buffer_length)
+			uurb->buffer_length = totlen;
+		else
+			WARN_ONCE(1, "uurb->buffer_length is too short %d vs %d",
+				  totlen, uurb->buffer_length);
 		break;
 
 	default:
author maintainer
#14 lore raw

PATCH 14/47 usb: gadget: mass_storage: set msg_registered after msg registered

In reply to Greg Kroah-Hartman

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

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

From: Li Jun <[email protected]>

commit 8e55d30322c6a0ef746c256a1beda9c73ecb27a6 upstream.

If there is no UDC available, the msg register will fail and this flag will not be set, but the driver is already added into pending driver list, then the module removal modprobe -r can not remove the driver from the pending list.

---
 drivers/usb/gadget/legacy/mass_storage.c |    8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)
drivers/usb/gadget/legacy/mass_storage.c +6 -2
@@ -210,7 +210,6 @@ static int msg_bind(struct usb_composite
 	usb_composite_overwrite_options(cdev, &coverwrite);
 	dev_info(&cdev->gadget->dev,
 		 DRIVER_DESC ", version: " DRIVER_VERSION "\n");
-	set_bit(0, &msg_registered);
 	return 0;
 
 fail_otg_desc:
@@ -257,7 +256,12 @@ MODULE_LICENSE("GPL");
 
 static int __init msg_init(void)
 {
-	return usb_composite_probe(&msg_driver);
+	int ret;
+
+	ret = usb_composite_probe(&msg_driver);
+	set_bit(0, &msg_registered);
+
+	return ret;
 }
 module_init(msg_init);
 
author maintainer
#17 lore raw

PATCH 17/47 ALSA: compress: Remove unused variable

In reply to Greg Kroah-Hartman

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

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

From: Guneshwor Singh <[email protected]>

commit a931b9ce93841a5b66b709ba5a244276e345e63b upstream.

Commit 04c5d5a430fc ("ALSA: compress: Embed struct device") removed the statement that used 'str' but didn't remove the variable itself. So remove it.

[Adding stable to Cc since pr_debug() may refer to the uninitialized
buffer -- tiwai]

Fixes 04c5d5a430fc ("ALSA: compress: Embed struct device")
---
 sound/core/compress_offload.c |    3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)
sound/core/compress_offload.c +1 -2
@@ -872,14 +872,13 @@ static const struct file_operations snd_
 static int snd_compress_dev_register(struct snd_device *device)
 {
 	int ret = -EINVAL;
-	char str[16];
 	struct snd_compr *compr;
 
 	if (snd_BUG_ON(!device || !device->device_data))
 		return -EBADFD;
 	compr = device->device_data;
 
-	pr_debug("reg %s for device %s, direction %d\n", str, compr->name,
+	pr_debug("reg device %s, direction %d\n", compr->name,
 			compr->direction);
 	/* register compressed device */
 	ret = snd_register_device(SNDRV_DEVICE_TYPE_COMPRESS,
author maintainer
#16 lore raw

PATCH 16/47 lsm: fix smack_inode_removexattr and xattr_getsecurity memleak

In reply to Greg Kroah-Hartman

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

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

From: Casey Schaufler <[email protected]>

commit 57e7ba04d422c3d41c8426380303ec9b7533ded9 upstream.

security_inode_getsecurity() provides the text string value of a security attribute. It does not provide a "secctx".
The code in xattr_getsecurity() that calls security_inode_getsecurity() and then calls security_release_secctx() happened to work because SElinux and Smack treat the attribute and the secctx the same way. It fails for cap_inode_getsecurity(), because that module has no secctx that ever needs releasing. It turns out that Smack is the one that's doing things wrong by not allocating memory when instructed to do so by the "alloc" parameter.

The fix is simple enough. Change the security_release_secctx() to kfree() because it isn't a secctx being returned by security_inode_getsecurity(). Change Smack to allocate the string when told to do so.

Note: this also fixes memory leaks for LSMs which implement inode_getsecurity but not release_secctx, such as capabilities.

---
 fs/xattr.c                 |    2 -
 security/smack/smack_lsm.c |   59 ++++++++++++++++++++-------------------------
 2 files changed, 28 insertions(+), 33 deletions(-)
fs/xattr.c +1 -1
@@ -163,7 +163,7 @@ xattr_getsecurity(struct inode *inode, c
 	}
 	memcpy(value, buffer, len);
 out:
-	security_release_secctx(buffer, len);
+	kfree(buffer);
 out_noalloc:
 	return len;
 }
security/smack/smack_lsm.c +27 -32

77 lines not on this page · raw message

author maintainer
#19 lore raw

PATCH 19/47 driver core: platform: Dont read past the end of "driver_override" buffer

In reply to Greg Kroah-Hartman

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

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

From: Nicolai Stange <[email protected]>

commit bf563b01c2895a4bfd1a29cc5abc67fe706ecffd upstream.

When printing the driver_override parameter when it is 4095 and 4094 bytes long, the printing code would access invalid memory because we need count+1 bytes for printing.

Reject driver_override values of these lengths in driver_override_store().

This is in close analogy to commit 4efe874aace5 ("PCI: Don't read past the end of sysfs "driver_override" buffer") from Sasha Levin.

Fixes 3d713e0e382e ("driver core: platform: add device binding path 'driver_override'")
---
 drivers/base/platform.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/base/platform.c +2 -1
@@ -809,7 +809,8 @@ static ssize_t driver_override_store(str
 	struct platform_device *pdev = to_platform_device(dev);
 	char *driver_override, *old, *cp;
 
-	if (count > PATH_MAX)
+	/* We need to keep extra room for a newline */
+	if (count >= (PAGE_SIZE - 1))
 		return -EINVAL;
 
 	driver_override = kstrndup(buf, count, GFP_KERNEL);
author maintainer
#2 lore raw

PATCH 2/47 USB: gadgetfs: Fix crash caused by inadequate synchronization

In reply to Greg Kroah-Hartman

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

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

From: Alan Stern <[email protected]>

commit 520b72fc64debf8a86c3853b8e486aa5982188f0 upstream.

The gadgetfs driver (drivers/usb/gadget/legacy/inode.c) was written before the UDC and composite frameworks were adopted; it is a legacy driver. As such, it expects that once bound to a UDC controller, it will not be unbound until it unregisters itself.

However, the UDC framework does unbind function drivers while they are still registered. When this happens, it can cause the gadgetfs driver to misbehave or crash. For example, userspace can cause a crash by opening the device file and doing an ioctl call before setting up a configuration (found by Andrey Konovalov using the syzkaller fuzzer).

This patch adds checks and synchronization to prevent these bad behaviors. It adds a udc_usage counter that the driver increments at times when it is using a gadget interface without holding the private spinlock. The unbind routine waits for this counter to go to 0 before returning, thereby ensuring that the UDC is no longer in use.

The patch also adds a check in the dev_ioctl() routine to make sure the driver is bound to a UDC before dereferencing the gadget pointer, and it makes destroy_ep_files() synchronize with the endpoint I/O routines, to prevent the user from accessing an endpoint data structure after it has been removed.

---
 drivers/usb/gadget/legacy/inode.c |   41 +++++++++++++++++++++++++++++++++-----
 1 file changed, 36 insertions(+), 5 deletions(-)
drivers/usb/gadget/legacy/inode.c +36 -5
@@ -27,7 +27,7 @@
 #include <linux/mmu_context.h>
 #include <linux/aio.h>
 #include <linux/uio.h>
-
+#include <linux/delay.h>
 #include <linux/device.h>
 #include <linux/moduleparam.h>
 
@@ -116,6 +116,7 @@ enum ep0_state {
 struct dev_data {
 	spinlock_t			lock;
 	atomic_t			count;
+	int				udc_usage;
 	enum ep0_state			state;		/* P: lock */
 	struct usb_gadgetfs_event	event [N_EVENT];
 	unsigned			ev_next;
@@ -512,9 +513,9 @@ static void ep_aio_complete(struct usb_e
 		INIT_WORK(&priv->work, ep_user_copy_worker);
 		schedule_work(&priv->work);
 	}
-	spin_unlock(&epdata->dev->lock);
 
 	usb_ep_free_request(ep, req);
+	spin_unlock(&epdata->dev->lock);
 	put_ep(epdata);
 }
 
@@ -938,9 +939,11 @@ ep0_read (struct file *fd, char __user *
 			struct usb_request	*req = dev->req;
 
 			if ((retval = setup_req (ep, req, 0)) == 0) {
+				++dev->udc_usage;
 				spin_unlock_irq (&dev->lock);
 				retval = usb_ep_queue (ep, req, GFP_KERNEL);
 				spin_lock_irq (&dev->lock);
+				--dev->udc_usage;
 			}
 			dev->state = STATE_DEV_CONNECTED;
 
@@ -1130,6 +1133,7 @@ ep0_write (struct file *fd, const char _
 			retval = setup_req (dev->gadget->ep0, dev->req, len);
 			if (retval == 0) {
 				dev->state = STATE_DEV_CONNECTED;
+				++dev->udc_usage;
 				spin_unlock_irq (&dev->lock);
 				if (copy_from_user (dev->req->buf, buf, len))
 					retval = -EFAULT;
@@ -1141,6 +1145,7 @@ ep0_write (struct file *fd, const char _
 						GFP_KERNEL);
 				}
 				spin_lock_irq(&dev->lock);
+				--dev->udc_usage;
 				if (retval < 0) {
 					clean_req (dev->gadget->ep0, dev->req);
 				} else
@@ -1239,9 +1244,21 @@ static long dev_ioctl (struct file *fd,
 	struct usb_gadget	*gadget = dev->gadget;
 	long ret = -ENOTTY;
 
-	if (gadget->ops->ioctl)
+	spin_lock_irq(&dev->lock);
+	if (dev->state == STATE_DEV_OPENED ||
+			dev->state == STATE_DEV_UNBOUND) {
+		/* Not bound to a UDC */
+	} else if (gadget->ops->ioctl) {
+		++dev->udc_usage;
+		spin_unlock_irq(&dev->lock);
+
 		ret = gadget->ops->ioctl (gadget, code, value);
 
+		spin_lock_irq(&dev->lock);
+		--dev->udc_usage;
+	}
+	spin_unlock_irq(&dev->lock);
+
 	return ret;
 }
 
@@ -1459,10 +1476,12 @@ delegate:
 				if (value < 0)
 					break;
 
+				++dev->udc_usage;
 				spin_unlock (&dev->lock);
 				value = usb_ep_queue (gadget->ep0, dev->req,
 							GFP_KERNEL);
 				spin_lock (&dev->lock);
+				--dev->udc_usage;
 				if (value < 0) {
 					clean_req (gadget->ep0, dev->req);
 					break;
@@ -1486,8 +1505,12 @@ delegate:
 		req->length = value;
 		req->zero = value < w_length;
 
+		++dev->udc_usage;
 		spin_unlock (&dev->lock);
 		value = usb_ep_queue (gadget->ep0, req, GFP_KERNEL);
+		spin_lock(&dev->lock);
+		--dev->udc_usage;
+		spin_unlock(&dev->lock);
 		if (value < 0) {
 			DBG (dev, "ep_queue --> %d\n", value);
 			req->status = 0;
@@ -1514,21 +1537,24 @@ static void destroy_ep_files (struct dev
 		/* break link to FS */
 		ep = list_first_entry (&dev->epfiles, struct ep_data, epfiles);
 		list_del_init (&ep->epfiles);
+		spin_unlock_irq (&dev->lock);
+
 		dentry = ep->dentry;
 		ep->dentry = NULL;
 		parent = d_inode(dentry->d_parent);
 
 		/* break link to controller */
+		mutex_lock(&ep->lock);
 		if (ep->state == STATE_EP_ENABLED)
 			(void) usb_ep_disable (ep->ep);
 		ep->state = STATE_EP_UNBOUND;
 		usb_ep_free_request (ep->ep, ep->req);
 		ep->ep = NULL;
+		mutex_unlock(&ep->lock);
+
 		wake_up (&ep->wait);
 		put_ep (ep);
 
-		spin_unlock_irq (&dev->lock);
-
 		/* break link to dcache */
 		mutex_lock (&parent->i_mutex);
 		d_delete (dentry);
@@ -1599,6 +1625,11 @@ gadgetfs_unbind (struct usb_gadget *gadg
 
 	spin_lock_irq (&dev->lock);
 	dev->state = STATE_DEV_UNBOUND;
+	while (dev->udc_usage > 0) {
+		spin_unlock_irq(&dev->lock);
+		usleep_range(1000, 2000);
+		spin_lock_irq(&dev->lock);
+	}
 	spin_unlock_irq (&dev->lock);
 
 	destroy_ep_files (dev);
author maintainer
#22 lore raw

PATCH 22/47 ftrace: Fix kmemleak in unregister_ftrace_graph

In reply to Greg Kroah-Hartman

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

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

From: Shu Wang <[email protected]>

commit 2b0b8499ae75df91455bbeb7491d45affc384fb0 upstream.

The trampoline allocated by function tracer was overwriten by function_graph tracer, and caused a memory leak. The save_global_trampoline should have saved the previous trampoline in register_ftrace_graph() and restored it in unregister_ftrace_graph(). But as it is implemented, save_global_trampoline was only used in unregister_ftrace_graph as default value 0, and it overwrote the previous trampoline's value. Causing the previous allocated trampoline to be lost.

kmmeleak backtrace:

    kmemleak_vmalloc+0x77/0xc0
    __vmalloc_node_range+0x1b5/0x2c0
    module_alloc+0x7c/0xd0
    arch_ftrace_update_trampoline+0xb5/0x290
    ftrace_startup+0x78/0x210
    register_ftrace_function+0x8b/0xd0
    function_trace_init+0x4f/0x80
    tracing_set_tracer+0xe6/0x170
    tracing_set_trace_write+0x90/0xd0
    __vfs_write+0x37/0x170
    vfs_write+0xb2/0x1b0
    SyS_write+0x55/0xc0
    do_syscall_64+0x67/0x180
    return_from_SYSCALL_64+0x0/0x6a

[
Looking further into this, I found that this was left over from when the function and function graph tracers shared the same ftrace_ops. But in commit 5f151b2401 ("ftrace: Fix function_profiler and function tracer together"), the two were separated, and the save_global_trampoline no longer was necessary (and it may have been broken back then too). -- Steven Rostedt
]

Fixes 5f151b2401 ("ftrace: Fix function_profiler and function tracer together")
---
 kernel/trace/ftrace.c |   14 --------------
 1 file changed, 14 deletions(-)
kernel/trace/ftrace.c +0 -14
@@ -4315,9 +4315,6 @@ static char ftrace_graph_buf[FTRACE_FILT
 static char ftrace_graph_notrace_buf[FTRACE_FILTER_SIZE] __initdata;
 static int ftrace_set_func(unsigned long *array, int *idx, int size, char *buffer);
 
-static unsigned long save_global_trampoline;
-static unsigned long save_global_flags;
-
 static int __init set_graph_function(char *str)
 {
 	strlcpy(ftrace_graph_buf, str, FTRACE_FILTER_SIZE);
@@ -5907,17 +5904,6 @@ void unregister_ftrace_graph(void)
 	unregister_pm_notifier(&ftrace_suspend_notifier);
 	unregister_trace_sched_switch(ftrace_graph_probe_sched_switch, NULL);
 
-#ifdef CONFIG_DYNAMIC_FTRACE
-	/*
-	 * Function graph does not allocate the trampoline, but
-	 * other global_ops do. We need to reset the ALLOC_TRAMP flag
-	 * if one was used.
-	 */
-	global_ops.trampoline = save_global_trampoline;
-	if (save_global_flags & FTRACE_OPS_FL_ALLOC_TRAMP)
-		global_ops.flags |= FTRACE_OPS_FL_ALLOC_TRAMP;
-#endif
-
  out:
 	mutex_unlock(&ftrace_lock);
 }
author maintainer
#25 lore raw

PATCH 25/47 scsi: sd: Do not override max_sectors_kb sysfs setting

In reply to Greg Kroah-Hartman

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

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

From: Martin K. Petersen <[email protected]>

commit 77082ca503bed061f7fbda7cfd7c93beda967a41 upstream.

A user may lower the max_sectors_kb setting in sysfs to accommodate certain workloads. Previously we would always set the max I/O size to either the block layer default or the optional preferred I/O size reported by the device.

Keep the current heuristics for the initial setting of max_sectors_kb. For subsequent invocations, only update the current queue limit if it exceeds the capabilities of the hardware.

---
 drivers/scsi/sd.c |   19 ++++++++++++++-----
 1 file changed, 14 insertions(+), 5 deletions(-)
drivers/scsi/sd.c +14 -5
@@ -2878,8 +2878,6 @@ static int sd_revalidate_disk(struct gen
 		sd_read_write_same(sdkp, buffer);
 	}
 
-	sdkp->first_scan = 0;
-
 	/*
 	 * We now have all cache related info, determine how we deal
 	 * with flush requests.
@@ -2894,7 +2892,7 @@ static int sd_revalidate_disk(struct gen
 	q->limits.max_dev_sectors = logical_to_sectors(sdp, dev_max);
 
 	/*
-	 * Use the device's preferred I/O size for reads and writes
+	 * Determine the device's preferred I/O size for reads and writes
 	 * unless the reported value is unreasonably small, large, or
 	 * garbage.
 	 */
@@ -2908,8 +2906,19 @@ static int sd_revalidate_disk(struct gen
 		rw_max = min_not_zero(logical_to_sectors(sdp, dev_max),
 				      (sector_t)BLK_DEF_MAX_SECTORS);
 
-	/* Combine with controller limits */
-	q->limits.max_sectors = min(rw_max, queue_max_hw_sectors(q));
+	/* Do not exceed controller limit */
+	rw_max = min(rw_max, queue_max_hw_sectors(q));
+
+	/*
+	 * Only update max_sectors if previously unset or if the current value
+	 * exceeds the capabilities of the hardware.
+	 */
+	if (sdkp->first_scan ||
+	    q->limits.max_sectors > q->limits.max_dev_sectors ||
+	    q->limits.max_sectors > q->limits.max_hw_sectors)
+		q->limits.max_sectors = rw_max;
+
+	sdkp->first_scan = 0;
 
 	set_capacity(disk, logical_to_sectors(sdp, sdkp->capacity));
 	sd_config_write_same(sdkp);
author maintainer
#3 lore raw

PATCH 3/47 USB: gadgetfs: fix copy_to_user while holding spinlock

In reply to Greg Kroah-Hartman

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

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

From: Alan Stern <[email protected]>

commit 6e76c01e71551cb221c1f3deacb9dcd9a7346784 upstream.

The gadgetfs driver as a long-outstanding FIXME, regarding a call of copy_to_user() made while holding a spinlock. This patch fixes the issue by dropping the spinlock and using the dev->udc_usage mechanism introduced by another recent patch to guard against status changes while the lock isn't held.

---
 drivers/usb/gadget/legacy/inode.c |    5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)
drivers/usb/gadget/legacy/inode.c +4 -1
@@ -985,11 +985,14 @@ ep0_read (struct file *fd, char __user *
 				retval = -EIO;
 			else {
 				len = min (len, (size_t)dev->req->actual);
-// FIXME don't call this with the spinlock held ...
+				++dev->udc_usage;
+				spin_unlock_irq(&dev->lock);
 				if (copy_to_user (buf, dev->req->buf, len))
 					retval = -EFAULT;
 				else
 					retval = len;
+				spin_lock_irq(&dev->lock);
+				--dev->udc_usage;
 				clean_req (dev->gadget->ep0, dev->req);
 				/* NOTE userspace can't yet choose to stall */
 			}
author maintainer
#4 lore raw

PATCH 4/47 usb: gadget: udc: atmel: set vbus irqflags explicitly

In reply to Greg Kroah-Hartman

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

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

From: Nicolas Ferre <[email protected]>

commit 6baeda120d90aa637b08f7604de104ab00ce9126 upstream.

The driver triggers actions on both edges of the vbus signal.

The former PIO controller was triggering IRQs on both falling and rising edges by default. Newer PIO controller don't, so it's better to set it explicitly to IRQF_TRIGGER_FALLING | IRQF_TRIGGER_RISING.

Without this patch we may trigger the connection with host but only on some bouncing signal conditions and thus lose connecting events.

---
 drivers/usb/gadget/udc/atmel_usba_udc.c |    4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)
drivers/usb/gadget/udc/atmel_usba_udc.c +3 -1
@@ -28,6 +28,8 @@
 #include <asm/gpio.h>
 
 #include "atmel_usba_udc.h"
+#define USBA_VBUS_IRQFLAGS (IRQF_ONESHOT \
+			   | IRQF_TRIGGER_FALLING | IRQF_TRIGGER_RISING)
 
 #ifdef CONFIG_USB_GADGET_DEBUG_FS
 #include <linux/debugfs.h>
@@ -2185,7 +2187,7 @@ static int usba_udc_probe(struct platfor
 					IRQ_NOAUTOEN);
 			ret = devm_request_threaded_irq(&pdev->dev,
 					gpio_to_irq(udc->vbus_pin), NULL,
-					usba_vbus_irq_thread, IRQF_ONESHOT,
+					usba_vbus_irq_thread, USBA_VBUS_IRQFLAGS,
 					"atmel_usba_udc", udc);
 			if (ret) {
 				udc->vbus_pin = -ENODEV;
author maintainer
#5 lore raw

PATCH 5/47 usb-storage: unusual_devs entry to fix write-access regression for Seagate external drives

In reply to Greg Kroah-Hartman

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

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

From: Alan Stern <[email protected]>

commit 113f6eb6d50cfa5e2a1cdcf1678b12661fa272ab upstream.

Kris Lindgren reports that without the NO_WP_DETECT flag, his Seagate external disk drive fails all write accesses. This regresssion dates back approximately to the start of the 4.x kernel releases.

---
 drivers/usb/storage/unusual_devs.h |    7 +++++++
 1 file changed, 7 insertions(+)
drivers/usb/storage/unusual_devs.h +7 -0
@@ -1379,6 +1379,13 @@ UNUSUAL_DEV( 0x0bc2, 0x3010, 0x0000, 0x0
 		USB_SC_DEVICE, USB_PR_DEVICE, NULL,
 		US_FL_SANE_SENSE ),
 
+/* Reported by Kris Lindgren <[email protected]> */
+UNUSUAL_DEV( 0x0bc2, 0x3332, 0x0000, 0x9999,
+		"Seagate",
+		"External",
+		USB_SC_DEVICE, USB_PR_DEVICE, NULL,
+		US_FL_NO_WP_DETECT ),
+
 UNUSUAL_DEV(  0x0d49, 0x7310, 0x0000, 0x9999,
 		"Maxtor",
 		"USB to SATA",
author maintainer
#8 lore raw

PATCH 8/47 ALSA: usb-audio: Check out-of-bounds access by corrupted buffer descriptor

In reply to Greg Kroah-Hartman

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

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

From: Takashi Iwai <[email protected]>

commit bfc81a8bc18e3c4ba0cbaa7666ff76be2f998991 upstream.

When a USB-audio device receives a maliciously adjusted or corrupted buffer descriptor, the USB-audio driver may access an out-of-bounce value at its parser. This was detected by syzkaller, something like:

  BUG: KASAN: slab-out-of-bounds in usb_audio_probe+0x27b2/0x2ab0
  Read of size 1 at addr ffff88006b83a9e8 by task kworker/0:1/24
  CPU: 0 PID: 24 Comm: kworker/0:1 Not tainted 4.14.0-rc1-42251-gebb2c2437d80 #224
  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
  Workqueue: usb_hub_wq hub_event
  Call Trace:
   __dump_stack lib/dump_stack.c:16
   dump_stack+0x292/0x395 lib/dump_stack.c:52
   print_address_description+0x78/0x280 mm/kasan/report.c:252
   kasan_report_error mm/kasan/report.c:351
   kasan_report+0x22f/0x340 mm/kasan/report.c:409
   __asan_report_load1_noabort+0x19/0x20 mm/kasan/report.c:427
   snd_usb_create_streams sound/usb/card.c:248
   usb_audio_probe+0x27b2/0x2ab0 sound/usb/card.c:605
   usb_probe_interface+0x35d/0x8e0 drivers/usb/core/driver.c:361
   really_probe drivers/base/dd.c:413
   driver_probe_device+0x610/0xa00 drivers/base/dd.c:557
   __device_attach_driver+0x230/0x290 drivers/base/dd.c:653
   bus_for_each_drv+0x161/0x210 drivers/base/bus.c:463
   __device_attach+0x26e/0x3d0 drivers/base/dd.c:710
   device_initial_probe+0x1f/0x30 drivers/base/dd.c:757
   bus_probe_device+0x1eb/0x290 drivers/base/bus.c:523
   device_add+0xd0b/0x1660 drivers/base/core.c:1835
   usb_set_configuration+0x104e/0x1870 drivers/usb/core/message.c:1932
   generic_probe+0x73/0xe0 drivers/usb/core/generic.c:174
   usb_probe_device+0xaf/0xe0 drivers/usb/core/driver.c:266
   really_probe drivers/base/dd.c:413
   driver_probe_device+0x610/0xa00 drivers/base/dd.c:557
   __device_attach_driver+0x230/0x290 drivers/base/dd.c:653
   bus_for_each_drv+0x161/0x210 drivers/base/bus.c:463
   __device_attach+0x26e/0x3d0 drivers/base/dd.c:710
   device_initial_probe+0x1f/0x30 drivers/base/dd.c:757
   bus_probe_device+0x1eb/0x290 drivers/base/bus.c:523
   device_add+0xd0b/0x1660 drivers/base/core.c:1835
   usb_new_device+0x7b8/0x1020 drivers/usb/core/hub.c:2457
   hub_port_connect drivers/usb/core/hub.c:4903
   hub_port_connect_change drivers/usb/core/hub.c:5009
   port_event drivers/usb/core/hub.c:5115
   hub_event+0x194d/0x3740 drivers/usb/core/hub.c:5195
   process_one_work+0xc7f/0x1db0 kernel/workqueue.c:2119
   worker_thread+0x221/0x1850 kernel/workqueue.c:2253
   kthread+0x3a1/0x470 kernel/kthread.c:231
   ret_from_fork+0x2a/0x40 arch/x86/entry/entry_64.S:431

This patch adds the checks of out-of-bounce accesses at appropriate places and bails out when it goes out of the given buffer.

---
 sound/usb/card.c |   20 ++++++++++++++++++++
 1 file changed, 20 insertions(+)
sound/usb/card.c +20 -0
@@ -217,6 +217,7 @@ static int snd_usb_create_streams(struct
 	struct usb_interface_descriptor *altsd;
 	void *control_header;
 	int i, protocol;
+	int rest_bytes;
 
 	/* find audiocontrol interface */
 	host_iface = &usb_ifnum_to_if(dev, ctrlif)->altsetting[0];
@@ -231,6 +232,15 @@ static int snd_usb_create_streams(struct
 		return -EINVAL;
 	}
 
+	rest_bytes = (void *)(host_iface->extra + host_iface->extralen) -
+		control_header;
+
+	/* just to be sure -- this shouldn't hit at all */
+	if (rest_bytes <= 0) {
+		dev_err(&dev->dev, "invalid control header\n");
+		return -EINVAL;
+	}
+
 	switch (protocol) {
 	default:
 		dev_warn(&dev->dev,
@@ -241,11 +251,21 @@ static int snd_usb_create_streams(struct
 	case UAC_VERSION_1: {
 		struct uac1_ac_header_descriptor *h1 = control_header;
 
+		if (rest_bytes < sizeof(*h1)) {
+			dev_err(&dev->dev, "too short v1 buffer descriptor\n");
+			return -EINVAL;
+		}
+
 		if (!h1->bInCollection) {
 			dev_info(&dev->dev, "skipping empty audio interface (v1)\n");
 			return -EINVAL;
 		}
 
+		if (rest_bytes < h1->bLength) {
+			dev_err(&dev->dev, "invalid buffer length (v1)\n");
+			return -EINVAL;
+		}
+
 		if (h1->bLength < sizeof(*h1) + h1->bInCollection) {
 			dev_err(&dev->dev, "invalid UAC_HEADER (v1)\n");
 			return -EINVAL;
author maintainer
#29 lore raw

PATCH 29/47 USB: fix out-of-bounds in usb_set_configuration

In reply to Greg Kroah-Hartman

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

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

From: Greg Kroah-Hartman <[email protected]>

commit bd7a3fe770ebd8391d1c7d072ff88e9e76d063eb upstream.

Andrey Konovalov reported a possible out-of-bounds problem for a USB interface association descriptor. He writes:
It seems there's no proper size check of a USB_DT_INTERFACE_ASSOCIATION descriptor. It's only checked that the size is >= 2 in usb_parse_configuration(), so find_iad() might do out-of-bounds access to intf_assoc->bInterfaceCount.

And he's right, we don't check for crazy descriptors of this type very well, so resolve this problem. Yet another issue found by syzkaller...

---
 drivers/usb/core/config.c    |   14 +++++++++++---
 include/uapi/linux/usb/ch9.h |    1 +
 2 files changed, 12 insertions(+), 3 deletions(-)
drivers/usb/core/config.c +11 -3
@@ -609,15 +609,23 @@ static int usb_parse_configuration(struc
 
 		} else if (header->bDescriptorType ==
 				USB_DT_INTERFACE_ASSOCIATION) {
+			struct usb_interface_assoc_descriptor *d;
+
+			d = (struct usb_interface_assoc_descriptor *)header;
+			if (d->bLength < USB_DT_INTERFACE_ASSOCIATION_SIZE) {
+				dev_warn(ddev,
+					 "config %d has an invalid interface association descriptor of length %d, skipping\n",
+					 cfgno, d->bLength);
+				continue;
+			}
+
 			if (iad_num == USB_MAXIADS) {
 				dev_warn(ddev, "found more Interface "
 					       "Association Descriptors "
 					       "than allocated for in "
 					       "configuration %d\n", cfgno);
 			} else {
-				config->intf_assoc[iad_num] =
-					(struct usb_interface_assoc_descriptor
-					*)header;
+				config->intf_assoc[iad_num] = d;
 				iad_num++;
 			}
 
include/uapi/linux/usb/ch9.h +1 -0
@@ -717,6 +717,7 @@ struct usb_interface_assoc_descriptor {
 	__u8  iFunction;
 } __attribute__ ((packed));
 
+#define USB_DT_INTERFACE_ASSOCIATION_SIZE	8
 
 /*-------------------------------------------------------------------------*/
 
author maintainer
#38 lore raw

PATCH 38/47 iio: adc: mcp320x: Fix oops on module unload

In reply to Greg Kroah-Hartman

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

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

From: Lukas Wunner <[email protected]>

commit 0964e40947a630a2a6f724e968246992f97bcf1c upstream.

The driver calls spi_get_drvdata() in its ->remove hook even though it has never called spi_set_drvdata(). Stack trace for posterity:

Unable to handle kernel NULL pointer dereference at virtual address 00000220
Internal error: Oops: 5 [#1] SMP ARM
[<8072f564>] (mutex_lock) from [<7f1400d0>] (iio_device_unregister+0x24/0x7c [industrialio])
[<7f1400d0>] (iio_device_unregister [industrialio]) from [<7f15e020>] (mcp320x_remove+0x20/0x30 [mcp320x])
[<7f15e020>] (mcp320x_remove [mcp320x]) from [<8055a8cc>] (spi_drv_remove+0x2c/0x44)
[<8055a8cc>] (spi_drv_remove) from [<805087bc>] (__device_release_driver+0x98/0x134)
[<805087bc>] (__device_release_driver) from [<80509180>] (driver_detach+0xdc/0xe0)
[<80509180>] (driver_detach) from [<8050823c>] (bus_remove_driver+0x5c/0xb0)
[<8050823c>] (bus_remove_driver) from [<80509ab0>] (driver_unregister+0x38/0x58)
[<80509ab0>] (driver_unregister) from [<7f15e69c>] (mcp320x_driver_exit+0x14/0x1c [mcp320x])
[<7f15e69c>] (mcp320x_driver_exit [mcp320x]) from [<801a78d0>] (SyS_delete_module+0x184/0x1d0)
[<801a78d0>] (SyS_delete_module) from [<80108100>] (ret_fast_syscall+0x0/0x1c)
Fixes f5ce4a7a9291 ("iio: adc: add driver for MCP3204/08 12-bit ADC")
Cc Oskar Andero <[email protected]>
---
 drivers/iio/adc/mcp320x.c |    1 +
 1 file changed, 1 insertion(+)
drivers/iio/adc/mcp320x.c +1 -0
@@ -310,6 +310,7 @@ static int mcp320x_probe(struct spi_devi
 	indio_dev->name = spi_get_device_id(spi)->name;
 	indio_dev->modes = INDIO_DIRECT_MODE;
 	indio_dev->info = &mcp320x_info;
+	spi_set_drvdata(spi, indio_dev);
 
 	chip_info = &mcp320x_chip_infos[spi_get_device_id(spi)->driver_data];
 	indio_dev->channels = chip_info->channels;
author maintainer
#39 lore raw

PATCH 39/47 uwb: properly check kthread_run return value

In reply to Greg Kroah-Hartman

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

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

From: Andrey Konovalov <[email protected]>

commit bbf26183b7a6236ba602f4d6a2f7cade35bba043 upstream.

uwbd_start() calls kthread_run() and checks that the return value is not NULL. But the return value is not NULL in case kthread_run() fails, it takes the form of ERR_PTR(-EINTR).

Use IS_ERR() instead.

Also add a check to uwbd_stop().

---
 drivers/uwb/uwbd.c |   12 ++++++++----
 1 file changed, 8 insertions(+), 4 deletions(-)
drivers/uwb/uwbd.c +8 -4
@@ -303,18 +303,22 @@ static int uwbd(void *param)
 /** Start the UWB daemon */
 void uwbd_start(struct uwb_rc *rc)
 {
-	rc->uwbd.task = kthread_run(uwbd, rc, "uwbd");
-	if (rc->uwbd.task == NULL)
+	struct task_struct *task = kthread_run(uwbd, rc, "uwbd");
+	if (IS_ERR(task)) {
+		rc->uwbd.task = NULL;
 		printk(KERN_ERR "UWB: Cannot start management daemon; "
 		       "UWB won't work\n");
-	else
+	} else {
+		rc->uwbd.task = task;
 		rc->uwbd.pid = rc->uwbd.task->pid;
+	}
 }
 
 /* Stop the UWB daemon and free any unprocessed events */
 void uwbd_stop(struct uwb_rc *rc)
 {
-	kthread_stop(rc->uwbd.task);
+	if (rc->uwbd.task)
+		kthread_stop(rc->uwbd.task);
 	uwbd_flush(rc);
 }
 
author maintainer
#41 lore raw

PATCH 41/47 brcmfmac: setup passive scan if requested by user-space

In reply to Greg Kroah-Hartman

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

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

From: Arend Van Spriel <[email protected]>

commit 35f62727df0ed8e5e4857e162d94fd46d861f1cf upstream.

The driver was not properly configuring firmware with regard to the type of scan. It always performed an active scan even when user-space was requesting for passive scan, ie. the scan request was done without any SSIDs specified.

---
 drivers/net/wireless/brcm80211/brcmfmac/cfg80211.c   |   19 ++++---------------
 drivers/net/wireless/brcm80211/brcmfmac/fwil_types.h |    5 +++++
 2 files changed, 9 insertions(+), 15 deletions(-)
drivers/net/wireless/brcm80211/brcmfmac/cfg80211.c +4 -15
@@ -876,7 +876,7 @@ static void brcmf_escan_prep(struct brcm
 
 	eth_broadcast_addr(params_le->bssid);
 	params_le->bss_type = DOT11_BSSTYPE_ANY;
-	params_le->scan_type = 0;
+	params_le->scan_type = BRCMF_SCANTYPE_ACTIVE;
 	params_le->channel_num = 0;
 	params_le->nprobes = cpu_to_le32(-1);
 	params_le->active_time = cpu_to_le32(-1);
@@ -884,12 +884,9 @@ static void brcmf_escan_prep(struct brcm
 	params_le->home_time = cpu_to_le32(-1);
 	memset(&params_le->ssid_le, 0, sizeof(params_le->ssid_le));
 
-	/* if request is null exit so it will be all channel broadcast scan */
-	if (!request)
-		return;
-
 	n_ssids = request->n_ssids;
 	n_channels = request->n_channels;
+
 	/* Copy channel array if applicable */
 	brcmf_dbg(SCAN, "### List of channelspecs to scan ### %d\n",
 		  n_channels);
@@ -926,16 +923,8 @@ static void brcmf_escan_prep(struct brcm
 			ptr += sizeof(ssid_le);
 		}
 	} else {
-		brcmf_dbg(SCAN, "Broadcast scan %p\n", request->ssids);
-		if ((request->ssids) && request->ssids->ssid_len) {
-			brcmf_dbg(SCAN, "SSID %s len=%d\n",
-				  params_le->ssid_le.SSID,
-				  request->ssids->ssid_len);
-			params_le->ssid_le.SSID_len =
-				cpu_to_le32(request->ssids->ssid_len);
-			memcpy(&params_le->ssid_le.SSID, request->ssids->ssid,
-				request->ssids->ssid_len);
-		}
+		brcmf_dbg(SCAN, "Performing passive scan\n");
+		params_le->scan_type = BRCMF_SCANTYPE_PASSIVE;
 	}
 	/* Adding mask to channel numbers */
 	params_le->channel_num =
drivers/net/wireless/brcm80211/brcmfmac/fwil_types.h +5 -0
@@ -45,6 +45,11 @@
 #define BRCMF_SCAN_PARAMS_COUNT_MASK	0x0000ffff
 #define BRCMF_SCAN_PARAMS_NSSID_SHIFT	16
 
+/* scan type definitions */
+#define BRCMF_SCANTYPE_DEFAULT		0xFF
+#define BRCMF_SCANTYPE_ACTIVE		0
+#define BRCMF_SCANTYPE_PASSIVE		1
+
 /* primary (ie tx) key */
 #define BRCMF_PRIMARY_KEY		(1 << 1)
 #define DOT11_BSSTYPE_ANY		2
author maintainer
#42 lore raw

PATCH 43/47 nvme: protect against simultaneous shutdown invocations

In reply to Greg Kroah-Hartman

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

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

From: Keith Busch <[email protected]>

commit 77bf25ea70200cddf083f74b7f617e5f07fac8bd upstream.

[Back-ported to 4.4. The difference is the file location of the struct definition that's adding the mutex.

This fixes reported kernel panics in 4.4-stable from simultaneous controller resets that was never supposed to be allowed to happen.]

---
 drivers/nvme/host/nvme.h |    2 ++
 drivers/nvme/host/pci.c  |    3 +++
 2 files changed, 5 insertions(+)
drivers/nvme/host/nvme.h +2 -0
@@ -14,6 +14,7 @@
 #ifndef _NVME_H
 #define _NVME_H
 
+#include <linux/mutex.h>
 #include <linux/nvme.h>
 #include <linux/pci.h>
 #include <linux/kref.h>
@@ -62,6 +63,7 @@ struct nvme_dev {
 	struct work_struct reset_work;
 	struct work_struct probe_work;
 	struct work_struct scan_work;
+	struct mutex shutdown_lock;
 	char name[12];
 	char serial[20];
 	char model[40];
drivers/nvme/host/pci.c +3 -0
@@ -2954,6 +2954,7 @@ static void nvme_dev_shutdown(struct nvm
 
 	nvme_dev_list_remove(dev);
 
+	mutex_lock(&dev->shutdown_lock);
 	if (pci_is_enabled(to_pci_dev(dev->dev))) {
 		nvme_freeze_queues(dev);
 		csts = readl(&dev->bar->csts);
@@ -2972,6 +2973,7 @@ static void nvme_dev_shutdown(struct nvm
 
 	for (i = dev->queue_count - 1; i >= 0; i--)
 		nvme_clear_queue(dev->queues[i]);
+	mutex_unlock(&dev->shutdown_lock);
 }
 
 static void nvme_dev_remove(struct nvme_dev *dev)
@@ -3328,6 +3330,7 @@ static int nvme_probe(struct pci_dev *pd
 
 	INIT_LIST_HEAD(&dev->namespaces);
 	INIT_WORK(&dev->reset_work, nvme_reset_work);
+	mutex_init(&dev->shutdown_lock);
 	dev->dev = get_device(&pdev->dev);
 	pci_set_drvdata(pdev, dev);
 
author maintainer
#43 lore raw

PATCH 44/47 sched/cpuset/pm: Fix cpuset vs. suspend-resume bugs

In reply to Greg Kroah-Hartman

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

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

From: Peter Zijlstra <[email protected]>

commit 50e76632339d4655859523a39249dd95ee5e93e7 upstream.

Cpusets vs. suspend-resume is _completely_ broken. And it got noticed because it now resulted in non-cpuset usage breaking too.

On suspend cpuset_cpu_inactive() doesn't call into cpuset_update_active_cpus() because it doesn't want to move tasks about, there is no need, all tasks are frozen and won't run again until after we've resumed everything.

But this means that when we finally do call into cpuset_update_active_cpus() after resuming the last frozen cpu in cpuset_cpu_active(), the top_cpuset will not have any difference with the cpu_active_mask and this it will not in fact do _anything_.

So the cpuset configuration will not be restored. This was largely hidden because we would unconditionally create identity domains and mobile users would not in fact use cpusets much. And servers what do use cpusets tend to not suspend-resume much.

An addition problem is that we'd not in fact wait for the cpuset work to finish before resuming the tasks, allowing spurious migrations outside of the specified domains.

Fix the rebuild by introducing cpuset_force_rebuild() and fix the ordering with cpuset_wait_for_hotplug().

Cc Andy Lutomirski <[email protected]>
Cc Linus Torvalds <[email protected]>
Cc Mike Galbraith <[email protected]>
Cc Peter Zijlstra <[email protected]>
Cc Rafael J. Wysocki <[email protected]>
Cc Tejun Heo <[email protected]>
Cc Thomas Gleixner <[email protected]>
Fixes deb7aa308ea2 ("cpuset: reorganize CPU / memory hotplug handling")
---
 include/linux/cpuset.h |    6 ++++++
 kernel/cpuset.c        |   16 +++++++++++++++-
 kernel/power/process.c |    5 ++++-
 kernel/sched/core.c    |    7 +++----
 4 files changed, 28 insertions(+), 6 deletions(-)
include/linux/cpuset.h +6 -0
@@ -43,7 +43,9 @@ static inline void cpuset_dec(void)
 
 extern int cpuset_init(void);
 extern void cpuset_init_smp(void);
+extern void cpuset_force_rebuild(void);
 extern void cpuset_update_active_cpus(bool cpu_online);
+extern void cpuset_wait_for_hotplug(void);
 extern void cpuset_cpus_allowed(struct task_struct *p, struct cpumask *mask);
 extern void cpuset_cpus_allowed_fallback(struct task_struct *p);
 extern nodemask_t cpuset_mems_allowed(struct task_struct *p);
@@ -147,11 +149,15 @@ static inline bool cpusets_enabled(void)
 static inline int cpuset_init(void) { return 0; }
 static inline void cpuset_init_smp(void) {}
 
+static inline void cpuset_force_rebuild(void) { }
+
 static inline void cpuset_update_active_cpus(bool cpu_online)
 {
 	partition_sched_domains(1, NULL, NULL);
 }
 
+static inline void cpuset_wait_for_hotplug(void) { }
+
 static inline void cpuset_cpus_allowed(struct task_struct *p,
 				       struct cpumask *mask)
 {
kernel/cpuset.c +15 -1
@@ -2281,6 +2281,13 @@ retry:
 	mutex_unlock(&cpuset_mutex);
 }
 
+static bool force_rebuild;
+
+void cpuset_force_rebuild(void)
+{
+	force_rebuild = true;
+}
+
 /**
  * cpuset_hotplug_workfn - handle CPU/memory hotunplug for a cpuset
  *
@@ -2355,8 +2362,10 @@ static void cpuset_hotplug_workfn(struct
 	}
 
 	/* rebuild sched domains if cpus_allowed has changed */
-	if (cpus_updated)
+	if (cpus_updated || force_rebuild) {
+		force_rebuild = false;
 		rebuild_sched_domains();
+	}
 }
 
 void cpuset_update_active_cpus(bool cpu_online)
@@ -2375,6 +2384,11 @@ void cpuset_update_active_cpus(bool cpu_
 	schedule_work(&cpuset_hotplug_work);
 }
 
+void cpuset_wait_for_hotplug(void)
+{
+	flush_work(&cpuset_hotplug_work);
+}
+
 /*
  * Keep top_cpuset.mems_allowed tracking node_states[N_MEMORY].
  * Call this routine anytime after node_states[N_MEMORY] changes.
kernel/power/process.c +4 -1
@@ -18,8 +18,9 @@
 #include <linux/workqueue.h>
 #include <linux/kmod.h>
 #include <trace/events/power.h>
+#include <linux/cpuset.h>
 
-/* 
+/*
  * Timeout for stopping processes
  */
 unsigned int __read_mostly freeze_timeout_msecs = 20 * MSEC_PER_SEC;
@@ -198,6 +199,8 @@ void thaw_processes(void)
 	__usermodehelper_set_disable_depth(UMH_FREEZING);
 	thaw_workqueues();
 
+	cpuset_wait_for_hotplug();
+
 	read_lock(&tasklist_lock);
 	for_each_process_thread(g, p) {
 		/* No other threads should have PF_SUSPEND_TASK set */
kernel/sched/core.c +3 -4
@@ -7286,17 +7286,16 @@ static int cpuset_cpu_active(struct noti
 		 * operation in the resume sequence, just build a single sched
 		 * domain, ignoring cpusets.
 		 */
-		num_cpus_frozen--;
-		if (likely(num_cpus_frozen)) {
-			partition_sched_domains(1, NULL, NULL);
+		partition_sched_domains(1, NULL, NULL);
+		if (--num_cpus_frozen)
 			break;
-		}
 
 		/*
 		 * This is the last CPU online operation. So fall through and
 		 * restore the original sched domains by considering the
 		 * cpuset configurations.
 		 */
+		cpuset_force_rebuild();
 
 	case CPU_ONLINE:
 		cpuset_update_active_cpus(true);
author maintainer
#44 lore raw

PATCH 45/47 ext4: fix data corruption for mmap writes

In reply to Greg Kroah-Hartman

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

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

From: Jan Kara <[email protected]>

commit a056bdaae7a181f7dcc876cfab2f94538e508709 upstream.

mpage_submit_page() can race with another process growing i_size and writing data via mmap to the written-back page. As mpage_submit_page() samples i_size too early, it may happen that ext4_bio_write_page() zeroes out too large tail of the page and thus corrupts user data.

Fix the problem by sampling i_size only after the page has been write-protected in page tables by clear_page_dirty_for_io() call.

---
 fs/ext4/inode.c |   24 +++++++++++++++++++-----
 1 file changed, 19 insertions(+), 5 deletions(-)
fs/ext4/inode.c +19 -5
@@ -1946,15 +1946,29 @@ static int ext4_writepage(struct page *p
 static int mpage_submit_page(struct mpage_da_data *mpd, struct page *page)
 {
 	int len;
-	loff_t size = i_size_read(mpd->inode);
+	loff_t size;
 	int err;
 
 	BUG_ON(page->index != mpd->first_page);
-	if (page->index == size >> PAGE_CACHE_SHIFT)
-		len = size & ~PAGE_CACHE_MASK;
-	else
-		len = PAGE_CACHE_SIZE;
 	clear_page_dirty_for_io(page);
+	/*
+	 * We have to be very careful here!  Nothing protects writeback path
+	 * against i_size changes and the page can be writeably mapped into
+	 * page tables. So an application can be growing i_size and writing
+	 * data through mmap while writeback runs. clear_page_dirty_for_io()
+	 * write-protects our page in page tables and the page cannot get
+	 * written to again until we release page lock. So only after
+	 * clear_page_dirty_for_io() we are safe to sample i_size for
+	 * ext4_bio_write_page() to zero-out tail of the written page. We rely
+	 * on the barrier provided by TestClearPageDirty in
+	 * clear_page_dirty_for_io() to make sure i_size is really sampled only
+	 * after page tables are updated.
+	 */
+	size = i_size_read(mpd->inode);
+	if (page->index == size >> PAGE_SHIFT)
+		len = size & ~PAGE_MASK;
+	else
+		len = PAGE_SIZE;
 	err = ext4_bio_write_page(&mpd->io_submit, page, len, mpd->wbc, false);
 	if (!err)
 		mpd->wbc->nr_to_write--;
author maintainer
#45 lore raw

PATCH 46/47 ext4: Dont clear SGID when inheriting ACLs

In reply to Greg Kroah-Hartman

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

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

From: Jan Kara <[email protected]>

commit a3bb2d5587521eea6dab2d05326abb0afb460abd upstream.

When new directory 'DIR1' is created in a directory 'DIR0' with SGID bit set, DIR1 is expected to have SGID bit set (and owning group equal to the owning group of 'DIR0'). However when 'DIR0' also has some default ACLs that 'DIR1' inherits, setting these ACLs will result in SGID bit on 'DIR1' to get cleared if user is not member of the owning group.

Fix the problem by moving posix_acl_update_mode() out of __ext4_set_acl() into ext4_set_acl(). That way the function will not be called when inheriting ACLs which is what we want as it prevents SGID bit clearing and the mode has been properly set by posix_acl_create() anyway.

Fixes 073931017b49d9458aa351605b43a7e34598caef
---
 fs/ext4/acl.c |   22 +++++++++++++++-------
 1 file changed, 15 insertions(+), 7 deletions(-)
fs/ext4/acl.c +15 -7
@@ -195,13 +195,6 @@ __ext4_set_acl(handle_t *handle, struct
 	switch (type) {
 	case ACL_TYPE_ACCESS:
 		name_index = EXT4_XATTR_INDEX_POSIX_ACL_ACCESS;
-		if (acl) {
-			error = posix_acl_update_mode(inode, &inode->i_mode, &acl);
-			if (error)
-				return error;
-			inode->i_ctime = ext4_current_time(inode);
-			ext4_mark_inode_dirty(handle, inode);
-		}
 		break;
 
 	case ACL_TYPE_DEFAULT:
@@ -234,6 +227,8 @@ ext4_set_acl(struct inode *inode, struct
 {
 	handle_t *handle;
 	int error, retries = 0;
+	umode_t mode = inode->i_mode;
+	int update_mode = 0;
 
 retry:
 	handle = ext4_journal_start(inode, EXT4_HT_XATTR,
@@ -241,7 +236,20 @@ retry:
 	if (IS_ERR(handle))
 		return PTR_ERR(handle);
 
+	if ((type == ACL_TYPE_ACCESS) && acl) {
+		error = posix_acl_update_mode(inode, &mode, &acl);
+		if (error)
+			goto out_stop;
+		update_mode = 1;
+	}
+
 	error = __ext4_set_acl(handle, inode, type, acl);
+	if (!error && update_mode) {
+		inode->i_mode = mode;
+		inode->i_ctime = ext4_current_time(inode);
+		ext4_mark_inode_dirty(handle, inode);
+	}
+out_stop:
 	ext4_journal_stop(handle);
 	if (error == -ENOSPC && ext4_should_retry_alloc(inode->i_sb, &retries))
 		goto retry;
author maintainer
#46 lore raw

PATCH 47/47 ext4: dont allow encrypted operations without keys

In reply to Greg Kroah-Hartman

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

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

From: Theodore Ts'o <[email protected]>

commit 173b8439e1ba362007315868928bf9d26e5cc5a6 upstream.

While we allow deletes without the key, the following should not be permitted:

# cd /vdc/encrypted-dir-without-key
# ls -l
total 4
-rw-r--r-- 1 root root   0 Dec 27 22:35 6,LKNRJsp209FbXoSvJWzB
-rw-r--r-- 1 root root 286 Dec 27 22:35 uRJ5vJh9gE7vcomYMqTAyD
# mv uRJ5vJh9gE7vcomYMqTAyD  6,LKNRJsp209FbXoSvJWzB
---
 fs/ext4/namei.c |   12 ++++++++++++
 1 file changed, 12 insertions(+)
fs/ext4/namei.c +12 -0
@@ -3506,6 +3506,12 @@ static int ext4_rename(struct inode *old
 	int credits;
 	u8 old_file_type;
 
+	if ((ext4_encrypted_inode(old_dir) &&
+	     !ext4_has_encryption_key(old_dir)) ||
+	    (ext4_encrypted_inode(new_dir) &&
+	     !ext4_has_encryption_key(new_dir)))
+		return -ENOKEY;
+
 	retval = dquot_initialize(old.dir);
 	if (retval)
 		return retval;
@@ -3706,6 +3712,12 @@ static int ext4_cross_rename(struct inod
 	u8 new_file_type;
 	int retval;
 
+	if ((ext4_encrypted_inode(old_dir) &&
+	     !ext4_has_encryption_key(old_dir)) ||
+	    (ext4_encrypted_inode(new_dir) &&
+	     !ext4_has_encryption_key(new_dir)))
+		return -ENOKEY;
+
 	if ((ext4_encrypted_inode(old_dir) ||
 	     ext4_encrypted_inode(new_dir)) &&
 	    (old_dir != new_dir) &&
author maintainer
#33 lore raw

PATCH 33/47 iio: ad_sigma_delta: Implement a dedicated reset function

In reply to Greg Kroah-Hartman

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

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

From: Dragos Bogdan <[email protected]>

commit 7fc10de8d49a748c476532c9d8e8fe19e548dd67 upstream.

Since most of the SD ADCs have the option of reseting the serial interface by sending a number of SCLKs with CS = 0 and DIN = 1, a dedicated function that can do this is usefull.

Needed for the patch: iio: ad7793: Fix the serial interface reset

---
 drivers/iio/adc/ad_sigma_delta.c       |   28 ++++++++++++++++++++++++++++
 include/linux/iio/adc/ad_sigma_delta.h |    3 +++
 2 files changed, 31 insertions(+)
drivers/iio/adc/ad_sigma_delta.c +28 -0
@@ -177,6 +177,34 @@ out:
 }
 EXPORT_SYMBOL_GPL(ad_sd_read_reg);
 
+/**
+ * ad_sd_reset() - Reset the serial interface
+ *
+ * @sigma_delta: The sigma delta device
+ * @reset_length: Number of SCLKs with DIN = 1
+ *
+ * Returns 0 on success, an error code otherwise.
+ **/
+int ad_sd_reset(struct ad_sigma_delta *sigma_delta,
+	unsigned int reset_length)
+{
+	uint8_t *buf;
+	unsigned int size;
+	int ret;
+
+	size = DIV_ROUND_UP(reset_length, 8);
+	buf = kcalloc(size, sizeof(*buf), GFP_KERNEL);
+	if (!buf)
+		return -ENOMEM;
+
+	memset(buf, 0xff, size);
+	ret = spi_write(sigma_delta->spi, buf, size);
+	kfree(buf);
+
+	return ret;
+}
+EXPORT_SYMBOL_GPL(ad_sd_reset);
+
 static int ad_sd_calibrate(struct ad_sigma_delta *sigma_delta,
 	unsigned int mode, unsigned int channel)
 {
include/linux/iio/adc/ad_sigma_delta.h +3 -0
@@ -111,6 +111,9 @@ int ad_sd_write_reg(struct ad_sigma_delt
 int ad_sd_read_reg(struct ad_sigma_delta *sigma_delta, unsigned int reg,
 	unsigned int size, unsigned int *val);
 
+int ad_sd_reset(struct ad_sigma_delta *sigma_delta,
+	unsigned int reset_length);
+
 int ad_sigma_delta_single_conversion(struct iio_dev *indio_dev,
 	const struct iio_chan_spec *chan, int *val);
 int ad_sd_calibrate_all(struct ad_sigma_delta *sigma_delta,
author maintainer
#34 lore raw

PATCH 34/47 staging: iio: ad7192: Fix - use the dedicated reset function avoiding dma from stack.

In reply to Greg Kroah-Hartman

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

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

From: Stefan Popa <[email protected]>

commit f790923f146140a261ad211e5baf75d169f16fb2 upstream.

Depends on: 691c4b95d1 ("iio: ad_sigma_delta: Implement a dedicated reset function")

SPI host drivers can use DMA to transfer data, so the buffer should be properly allocated. Keeping it on the stack could cause an undefined behavior.

The dedicated reset function solves this issue.

---
 drivers/staging/iio/adc/ad7192.c |    4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)
drivers/staging/iio/adc/ad7192.c +1 -3
@@ -205,11 +205,9 @@ static int ad7192_setup(struct ad7192_st
 	struct iio_dev *indio_dev = spi_get_drvdata(st->sd.spi);
 	unsigned long long scale_uv;
 	int i, ret, id;
-	u8 ones[6];
 
 	/* reset the serial interface */
-	memset(&ones, 0xFF, 6);
-	ret = spi_write(st->sd.spi, &ones, 6);
+	ret = ad_sd_reset(&st->sd, 48);
 	if (ret < 0)
 		goto out;
 	usleep_range(500, 1000); /* Wait for at least 500us */
author maintainer
#36 lore raw

PATCH 36/47 iio: ad7793: Fix the serial interface reset

In reply to Greg Kroah-Hartman

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

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

From: Dragos Bogdan <[email protected]>

commit 7ee3b7ebcb74714df6d94c8f500f307e1ee5dda5 upstream.

The serial interface can be reset by writing 32 consecutive 1s to the device. 'ret' was initialized correctly but its value was overwritten when ad7793_check_platform_data() was called. Since a dedicated reset function is present now, it should be used instead.

Fixes 2edb769d246e ("iio:ad7793: Add support for the ad7798 and ad7799")
---
 drivers/iio/adc/ad7793.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/iio/adc/ad7793.c +2 -2
@@ -257,7 +257,7 @@ static int ad7793_setup(struct iio_dev *
 	unsigned int vref_mv)
 {
 	struct ad7793_state *st = iio_priv(indio_dev);
-	int i, ret = -1;
+	int i, ret;
 	unsigned long long scale_uv;
 	u32 id;
 
@@ -266,7 +266,7 @@ static int ad7793_setup(struct iio_dev *
 		return ret;
 
 	/* reset the serial interface */
-	ret = spi_write(st->sd.spi, (u8 *)&ret, sizeof(ret));
+	ret = ad_sd_reset(&st->sd, 32);
 	if (ret < 0)
 		goto out;
 	usleep_range(500, 2000); /* Wait for at least 500us */
author maintainer
#37 lore raw

PATCH 37/47 iio: adc: mcp320x: Fix readout of negative voltages

In reply to Greg Kroah-Hartman

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

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

From: Lukas Wunner <[email protected]>

commit e6f4794371ee7cce1339e7ca9542f1e703c5f84a upstream.

Commit f686a36b4b79 ("iio: adc: mcp320x: Add support for mcp3301") returns a signed voltage from mcp320x_adc_conversion() but neglects that the caller interprets a negative return value as failure. Only mcp3301 (and the upcoming mcp3550/1/3) is affected as the other chips are incapable of measuring negative voltages.

Fix and while at it, add mcp3301 to the list of supported chips at the top of the file.

Fixes f686a36b4b79 ("iio: adc: mcp320x: Add support for mcp3301")
Cc Andrea Galbusera <[email protected]>
---
 drivers/iio/adc/mcp320x.c |   24 +++++++++++++++---------
 1 file changed, 15 insertions(+), 9 deletions(-)
drivers/iio/adc/mcp320x.c +15 -9
@@ -17,6 +17,8 @@
  * MCP3204
  * MCP3208
  * ------------
+ * 13 bit converter
+ * MCP3301
  *
  * Datasheet can be found here:
  * http://ww1.microchip.com/downloads/en/DeviceDoc/21293C.pdf  mcp3001
@@ -96,7 +98,7 @@ static int mcp320x_channel_to_tx_data(in
 }
 
 static int mcp320x_adc_conversion(struct mcp320x *adc, u8 channel,
-				  bool differential, int device_index)
+				  bool differential, int device_index, int *val)
 {
 	int ret;
 
@@ -117,19 +119,25 @@ static int mcp320x_adc_conversion(struct
 
 	switch (device_index) {
 	case mcp3001:
-		return (adc->rx_buf[0] << 5 | adc->rx_buf[1] >> 3);
+		*val = (adc->rx_buf[0] << 5 | adc->rx_buf[1] >> 3);
+		return 0;
 	case mcp3002:
 	case mcp3004:
 	case mcp3008:
-		return (adc->rx_buf[0] << 2 | adc->rx_buf[1] >> 6);
+		*val = (adc->rx_buf[0] << 2 | adc->rx_buf[1] >> 6);
+		return 0;
 	case mcp3201:
-		return (adc->rx_buf[0] << 7 | adc->rx_buf[1] >> 1);
+		*val = (adc->rx_buf[0] << 7 | adc->rx_buf[1] >> 1);
+		return 0;
 	case mcp3202:
 	case mcp3204:
 	case mcp3208:
-		return (adc->rx_buf[0] << 4 | adc->rx_buf[1] >> 4);
+		*val = (adc->rx_buf[0] << 4 | adc->rx_buf[1] >> 4);
+		return 0;
 	case mcp3301:
-		return sign_extend32((adc->rx_buf[0] & 0x1f) << 8 | adc->rx_buf[1], 12);
+		*val = sign_extend32((adc->rx_buf[0] & 0x1f) << 8
+				    | adc->rx_buf[1], 12);
+		return 0;
 	default:
 		return -EINVAL;
 	}
@@ -150,12 +158,10 @@ static int mcp320x_read_raw(struct iio_d
 	switch (mask) {
 	case IIO_CHAN_INFO_RAW:
 		ret = mcp320x_adc_conversion(adc, channel->address,
-			channel->differential, device_index);
-
+			channel->differential, device_index, val);
 		if (ret < 0)
 			goto out;
 
-		*val = ret;
 		ret = IIO_VAL_INT;
 		break;
 
author maintainer
#28 lore raw

PATCH 28/47 usb: Increase quirk delay for USB devices

In reply to Greg Kroah-Hartman

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

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

From: Dmitry Fleytman <[email protected]>

commit b2a542bbb3081dbd64acc8929c140d196664c406 upstream.

Commit e0429362ab15
("usb: Add device quirk for Logitech HD Pro Webcams C920 and C930e") introduced quirk to workaround an issue with some Logitech webcams.

The workaround is introducing delay for some USB operations.

According to our testing, delay introduced by original commit is not long enough and in rare cases we still see issues described by the aforementioned commit.

This patch increases delays introduced by original commit. Having this patch applied we do not see those problems anymore.

---
 drivers/usb/core/config.c |    2 +-
 drivers/usb/core/hub.c    |    2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)
drivers/usb/core/config.c +1 -1
@@ -818,7 +818,7 @@ int usb_get_configuration(struct usb_dev
 		}
 
 		if (dev->quirks & USB_QUIRK_DELAY_INIT)
-			msleep(100);
+			msleep(200);
 
 		result = usb_get_descriptor(dev, USB_DT_CONFIG, cfgno,
 		    bigbuffer, length);
drivers/usb/core/hub.c +1 -1
@@ -4761,7 +4761,7 @@ static void hub_port_connect(struct usb_
 			goto loop;
 
 		if (udev->quirks & USB_QUIRK_DELAY_INIT)
-			msleep(1000);
+			msleep(2000);
 
 		/* consecutive bus-powered hubs aren't reliable; they can
 		 * violate the voltage drop budget.  if the new child has
#47 lore raw
In reply to Greg Kroah-Hartman
Quoted 9 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 4.4.92 release. There are 47 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 Thu Oct 12 19:50:01 UTC 2017. 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.4.92-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.4.y
and the diffstat can be found below.

thanks,

greg k-h

Compiled and booted on my test system. No dmesg and kselftest regressions.

thanks,
-- Shuah

#48 lore raw
In reply to Greg Kroah-Hartman
Quoted 12 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 4.4.92 release. There are 47 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 Thu Oct 12 19:50:01 UTC 2017. 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.4.92-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.4.y
and the diffstat can be found below.

thanks,

greg k-h

On HiKey (arm64) when running ltp-sched with this rc we’re seeing some sort of scheduler issue or maybe some kind of memory corruption.

Raw output of interest :

https://lkft.validation.linaro.org/scheduler/job/46192#L5291

ltp-sched-tests__url: git://github.com/linux-test-project/ltp.git
ltp-sched-tests__version: “20170929"
kernel-config: http://snapshots.linaro.org/openembedded/lkft/morty/hikey/rpb/linaro-hikey-stable-rc-4.4/31/defconfig
build-location: http://snapshots.linaro.org/openembedded/lkft/morty/hikey/rpb/linaro-hikey-stable-rc-4.4/31

#49 lore raw

Hi Greg,

Quoted 26 lines · Tom Gall
Quoted 12 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 4.4.92 release. There are 47 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 Thu Oct 12 19:50:01 UTC 2017. 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.4.92-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.4.y
and the diffstat can be found below.

thanks,

greg k-h

On HiKey (arm64) when running ltp-sched with this rc we’re seeing some sort of scheduler issue or maybe some kind of memory corruption.

Quoted 8 lines

Raw output of interest :

https://lkft.validation.linaro.org/scheduler/job/46192#L5291

ltp-sched-tests__url: git://github.com/linux-test-project/ltp.git
ltp-sched-tests__version: “20170929"
kernel-config: http://snapshots.linaro.org/openembedded/lkft/morty/hikey/rpb/linaro-hikey-stable-rc-4.4/31/defconfig
build-location: http://snapshots.linaro.org/openembedded/lkft/morty/hikey/rpb/linaro-hikey-stable-rc-4.4/31

Comparing with other boards in the test setup, we don't see this issue with x15 (arm), juno (arm64) or x86.

We will investigate to check if any conflicting hikey-specific (non-lts) patches are causing this, or need adaptation to the sched/cpuset patch added in this LTS.

This, IMHO, shouldn't cause us to delay this stable release.

Best,
Sumit.

#50 lore raw
In reply to Greg Kroah-Hartman
Quoted 8 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 4.4.92 release. There are 47 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 Thu Oct 12 19:50:01 UTC 2017. Anything received after that time might be too late.

Build results:

	total: 145 pass: 145 fail: 0
Qemu test results:
	total: 116 pass: 116 fail: 0

Details are available at http://kerneltests.org/builders.

Guenter

#52 lore raw
In reply to a message not in the archive

Let’s try that again with less HTML stupidness ….

Quoted 11 lines · Tom Gall

On Oct 10, 2017, at 2:50 PM, Greg Kroah-Hartman <[email protected]> wrote:

This is the start of the stable review cycle for the 4.4.92 release. There are 47 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 Thu Oct 12 19:50:01 UTC 2017. Anything received after that time might be too late.

The whole patch series can be found in one patch at:

Quoted 8 lines
	kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.92-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.4.y
and the diffstat can be found below.

thanks,

greg k-h

Full test results from Linaro’s test farm for 4.4.

Note there are some further regressions we’ve seen on x15 (arm) beyond the one I reported last night and that Sumit then commented on.

We’ve also moved up to the recently released LTP.

kernel: 4.4.92-rc1
git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.4.y
git commit: c0489dd5896d12b6cc72cde6486333307f99593f
git describe: v4.4.91-48-gc0489dd5896d
Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.4-oe/build/v4.4.91-48-gc0489dd5896d

Regressions (compared to build v4.4.91-34-g55c4daf63a48)
------------------------------------------------------------------------

x15 - arm:
kselftest:
* rtctest

* test src: https://www.kernel.org/pub/linux/kernel/v4.x/linux-4.13.tar.xz
ltp-fs-tests:
* gf18

* test src: git://github.com/linux-test-project/ltp.git
ltp-hugetlb-tests:
* runltp_hugetlb

* test src: git://github.com/linux-test-project/ltp.git

Boards, architectures and test suites:
-------------------------------------

juno-r2 - arm64
* boot - 1 pass
* kselftest - 32 pass - 1 skip - 21 known failures
* libhugetlbfs - 90 pass - 1 skip
* ltp-cap_bounds-tests - 2 pass
* ltp-commands-tests - 25 pass - 13 skip - 6 know failures (looks to be environmental, need to add ksh to test img)
* ltp-containers-tests - 27 pass - 36 skip - 18 known failures (being looked at looks to be setup with veth0)
* ltp-fcntl-locktests-tests - 2 pass
* ltp-filecaps-tests - 2 pass
* ltp-fs-tests - 59 pass - 1 skip - 2 known failures (quota not in test img)
* ltp-fs_bind-tests - 2 pass
* ltp-fs_perms_simple-tests
* ltp-fsx-tests - 2 pass
* ltp-hugetlb-tests - 22 pass
* ltp-io-tests - 3 pass
* ltp-ipc-tests - 9 pass
* ltp-math-tests - 11 pass
* ltp-nptl-tests - 2 pass
* ltp-pty-tests - 4 pass
* ltp-sched-tests - 14 pass
* ltp-securebits-tests - 4 pass
* ltp-timers-tests - 13 pass

x15 - arm
* boot - 1 pass
* kselftest - 31 pass - 1 skip - 21 failures ( regression noted above )
* libhugetlbfs - 1 skip
* ltp-cap_bounds-tests - 2 pass
* ltp-commands-tests - 27 pass - 13 skip - 4 known failures (ksh not in test img)
* ltp-containers-tests - 63 pass - 18 failures (these are being looked at looks like setup issues with veth0)
* ltp-fcntl-locktests-tests - 2 pass
* ltp-filecaps-tests - 2 pass
* ltp-fs-tests - 59 pass - 1 skip - 2 known failures (quota not in test img) - regression noted above
* ltp-fs_bind-tests - 2 pass
* ltp-fs_perms_simple-tests - 19 pass
* ltp-fsx-tests - 2 pass
* ltp-hugetlb-tests - 22 fail (needs triage)
* ltp-io-tests - 3 pass
* ltp-ipc-tests - 9 pass
* ltp-math-tests - 11 pass
* ltp-nptl-tests - 2 pass
* ltp-pty-tests - 4 pass
* ltp-sched-tests - 13 pass - 1 skip
* ltp-securebits-tests - 4 pass
* ltp-syscalls-tests - 1037 pass - 69 skip - 4 known failures
* ltp-timers-tests - 13 pass

dell-poweredge-r200 - x86_64
* boot - 1 pass
* kselftest - 44 pass - 24 known failures
* libhugetlbfs - 76 pass - 1 skip
* ltp-cap_bounds-tests - 1 pass
* ltp-commands-tests - 27 pass - 13 skip - 5 known failures (ksh not in test img)
* ltp-containers-tests - 63 pass - 18 fail (these are being looked at looks like setup issues with veth0)
* ltp-fcntl-locktests-tests - 2 pass
* ltp-filecaps-tests - 2 pass
* ltp-fs-tests - 61 pass - 1 skip
* ltp-fs_bind-tests - 2 pass
* ltp-fs_perms_simple-tests - 19 pass
* ltp-fsx-tests - 2 pass
* ltp-hugetlb-tests - 22 pass
* ltp-io-tests - 3 pass
* ltp-ipc-tests - 9 pass
* ltp-math-tests - 11 pass
* ltp-nptl-tests - 2 pass
* ltp-pty-tests - 4 pass
* ltp-sched-tests - 13 pass - 1 skip
* ltp-securebits-tests - 4 pass
* ltp-syscalls-tests - 960 pass - 164 skip - 13 known failures
* ltp-timers-tests - 13 pass

Documentation - https://collaborate.linaro.org/display/LKFT/Email+Reports

Included and kept separate are hikey results (arm64). I keep these separate as there are additional platform support patches added to the 4.4 LTS in order to make the board work.

Summary
------------------------------------------------------------------------

kernel: 4.4.92-rc1
git repo: https://git.linaro.org/lkft/arm64-stable-rc.git
git tag: 4.4.92-rc1-hikey-20171010
git commit: 61829f776c39db427c8af457c6aca34063fddca3
git describe: 4.4.92-rc1-hikey-20171010
Test details: https://qa-reports.linaro.org/lkft/linaro-hikey-stable-rc-4.4-oe/build/4.4.92-rc1-hikey-20171010

No regressions (compared to build 4.4.92-rc1-hikey-20171009)

Boards, architectures and test suites:
-------------------------------------

hi6220-hikey - arm64
* boot - 1 pass
* kselftest - 32 pass - 1 skip - 21 known failures
* libhugetlbfs - 90 pass - 1 skip
* ltp-cap_bounds-tests - 2 pass
* ltp-commands-tests - 26 pass - 13 skip - 5 known failures (ksh not in test img)
* ltp-containers-tests - 27 pass - 36 skip - 18 fail (these are being looked at looks like setup issues with veth0)
* ltp-fcntl-locktests-tests - 2 pass
* ltp-filecaps-tests - 2 pass
* ltp-fs-tests - 59 pass - 1 skip - 2 known failures (quota not in test img)
* ltp-fs_bind-tests - 2 pass
* ltp-fs_perms_simple-tests - 19 pass
* ltp-fsx-tests - 2 pass
* ltp-hugetlb-tests - 21 pass - 1 skip
* ltp-io-tests - 3 pass
* ltp-ipc-tests - 9 pass
* ltp-math-tests - 11 pass
* ltp-nptl-tests - 2 pass
* ltp-pty-tests - 4 pass
* ltp-securebits-tests - 4 pass
* ltp-syscalls-tests - 980 pass - 125 skip - 4 known failures
* ltp-timers-tests - 13 pass

author maintainer
#53 lore raw
Quoted 23 lines · Tom Gall

Let’s try that again with less HTML stupidness ….

Quoted 18 lines · Tom Gall

On Oct 10, 2017, at 2:50 PM, Greg Kroah-Hartman <[email protected]> wrote:

This is the start of the stable review cycle for the 4.4.92 release. There are 47 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 Thu Oct 12 19:50:01 UTC 2017. 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.4.92-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.4.y
and the diffstat can be found below.

thanks,

Quoted 8 lines
Quoted 1 line

greg k-h

Full test results from Linaro’s test farm for 4.4.

Note there are some further regressions we’ve seen on x15 (arm) beyond the one I reported last night and that Sumit then commented on.

We’ve also moved up to the recently released LTP.

Those two sentances could not possibly be related now, right? :)

You did test the latest version of LTP on a "known good kernel/system", ahead of time? Are these regressions to be expected?

x86 doesn't even look right here:

Quoted 3 lines

dell-poweredge-r200 - x86_64
* boot - 1 pass
* kselftest - 44 pass - 24 known failures

1/3 failure is ok?

Quoted 11 lines

* libhugetlbfs - 76 pass - 1 skip
* ltp-cap_bounds-tests - 1 pass
* ltp-commands-tests - 27 pass - 13 skip - 5 known failures (ksh not in test img)
* ltp-containers-tests - 63 pass - 18 fail (these are being looked at looks like setup issues with veth0)
* ltp-fcntl-locktests-tests - 2 pass
* ltp-filecaps-tests - 2 pass
* ltp-fs-tests - 61 pass - 1 skip
* ltp-fs_bind-tests - 2 pass
* ltp-fs_perms_simple-tests - 19 pass
* ltp-fsx-tests - 2 pass
* ltp-hugetlb-tests - 22 pass

Quoted 8 lines

* ltp-io-tests - 3 pass
* ltp-ipc-tests - 9 pass
* ltp-math-tests - 11 pass
* ltp-nptl-tests - 2 pass
* ltp-pty-tests - 4 pass
* ltp-sched-tests - 13 pass - 1 skip
* ltp-securebits-tests - 4 pass
* ltp-syscalls-tests - 960 pass - 164 skip - 13 known failures

syscalls fail? Why skip so many?

thanks,

greg k-h

#54 lore raw
Quoted 26 lines · Greg Kroah-Hartman
Quoted 25 lines · Tom Gall

Let’s try that again with less HTML stupidness ….

Quoted 19 lines · Tom Gall

On Oct 10, 2017, at 2:50 PM, Greg Kroah-Hartman <[email protected]> wrote:

This is the start of the stable review cycle for the 4.4.92 release. There are 47 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 Thu Oct 12 19:50:01 UTC 2017. 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.4.92-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.4.y
and the diffstat can be found below.

thanks,

greg k-h

Quoted 8 lines
Quoted 6 lines

Full test results from Linaro’s test farm for 4.4.

Note there are some further regressions we’ve seen on x15 (arm) beyond the one I reported last night and that Sumit then commented on.

We’ve also moved up to the recently released LTP.

Those two sentances could not possibly be related now, right? :)

Prior results were just the syscalls portion of LTP. When we expanded to use all of LTP, that's when we also worked in the upgrade to latest LTP. LTP isn't changing
that much.

All the non-syscall results data is new. There's a kink or two to work out there as we get to a
reasonable baseline.

Anything newly reported has been top priority to triage and either get to working to
put on a skip list and we'll come back to get it working.

Quoted 2 lines

You did test the latest version of LTP on a "known good kernel/system", ahead of time?

We're being admittedly aggressive to expand coverage and make results available. Release early and often.

In the future for anything new, I'll call it out.

Quoted 1 line

Are these regressions to be expected?

We'll continue to annotate when errors pop up and note if it's something to be alarmed about.

As I did last night when something looks troubling we're going to speak up. I'd rather
respond with "here's something" instead of keeping completely silent and then that turning out
to really be something. You've got a deadline for comments for a reason.

Hard bugs can take time. More eyes helps.

Regardless I want a reasonable clean baseline for at least 4.14 ASAP and then we get after 4.9 and
4.4.

Quoted 7 lines

x86 doesn't even look right here:

Quoted 3 lines

dell-poweredge-r200 - x86_64
* boot - 1 pass
* kselftest - 44 pass - 24 known failures

1/3 failure is ok?

No it's not.

Running kselftest from the current kernel release on an old 4.4 kernel just isn't going that well.
Tests just don't fail gracefully. People need to care about that when they add to ksefltest.

Let's get 4.14 in order first and then get after this stuff.

Quoted 20 lines
Quoted 11 lines

* libhugetlbfs - 76 pass - 1 skip
* ltp-cap_bounds-tests - 1 pass
* ltp-commands-tests - 27 pass - 13 skip - 5 known failures (ksh not in test img)
* ltp-containers-tests - 63 pass - 18 fail (these are being looked at looks like setup issues with veth0)
* ltp-fcntl-locktests-tests - 2 pass
* ltp-filecaps-tests - 2 pass
* ltp-fs-tests - 61 pass - 1 skip
* ltp-fs_bind-tests - 2 pass
* ltp-fs_perms_simple-tests - 19 pass
* ltp-fsx-tests - 2 pass
* ltp-hugetlb-tests - 22 pass

Quoted 8 lines

* ltp-io-tests - 3 pass
* ltp-ipc-tests - 9 pass
* ltp-math-tests - 11 pass
* ltp-nptl-tests - 2 pass
* ltp-pty-tests - 4 pass
* ltp-sched-tests - 13 pass - 1 skip
* ltp-securebits-tests - 4 pass
* ltp-syscalls-tests - 960 pass - 164 skip - 13 known failures

Quoted 1 line

syscalls fail? Why skip so many?

The known failures are due to our x86 box using an NFS root file system. That won't be the case much longer.

As far as skipping, I'll come back with an answer on that. Skipping isn't always bad if the test isn't really doing something interesting, or doing something that is going to take way too long. etc etc. Anyway I'll come back
with something definitive.

Quoted 3 lines

thanks,

greg k-h

Signature · 9 lines
Regards,
Tom

Director, Linaro Mobile Group
Linaro.org │ Open source software for ARM SoCs
irc: tgall_foo | skype : tom_gall

"Where's the kaboom!? There was supposed to be an earth-shattering
kaboom!" Marvin Martian
#55 lore raw
Quoted 20 lines · Tom Gall
Quoted 20 lines
Quoted 19 lines

* libhugetlbfs - 76 pass - 1 skip
* ltp-cap_bounds-tests - 1 pass
* ltp-commands-tests - 27 pass - 13 skip - 5 known failures (ksh not in test img)
* ltp-containers-tests - 63 pass - 18 fail (these are being looked at looks like setup issues with veth0)
* ltp-fcntl-locktests-tests - 2 pass
* ltp-filecaps-tests - 2 pass
* ltp-fs-tests - 61 pass - 1 skip
* ltp-fs_bind-tests - 2 pass
* ltp-fs_perms_simple-tests - 19 pass
* ltp-fsx-tests - 2 pass
* ltp-hugetlb-tests - 22 pass
* ltp-io-tests - 3 pass
* ltp-ipc-tests - 9 pass
* ltp-math-tests - 11 pass
* ltp-nptl-tests - 2 pass
* ltp-pty-tests - 4 pass
* ltp-sched-tests - 13 pass - 1 skip
* ltp-securebits-tests - 4 pass
* ltp-syscalls-tests - 960 pass - 164 skip - 13 known failures

Quoted 4 lines
Quoted 1 line

syscalls fail? Why skip so many?

The known failures are due to our x86 box using an NFS root file system. That won't be the case much longer.

I'm not sure that is entirely correct. The 'skip' test cases come from LTP itself. A few examples below:

bdflush01 2 TCONF : bdflush01.c:118: syscall(-1) __NR_bdflush not supported on your arch
bdflush01 3 TCONF : bdflush01.c:118: Remaining cases not appropriate for configuration

cacheflush01 1 TCONF : cacheflush01.c:134: syscall(-1) __NR_cacheflush not supported on your arch
cacheflush01 2 TCONF : cacheflush01.c:134: Remaining cases not appropriate for configuration

chown01_16 1 TCONF :
/usr/src/debug/ltp/20170929-r0/git/testcases/kernel/syscalls/chown/../utils/compat_16.h:156:
16-bit version of chown() is not supported on your platform
chown01_16 2 TCONF :
/usr/src/debug/ltp/20170929-r0/git/testcases/kernel/syscalls/chown/../utils/compat_16.h:156:
Remaining cases not appropriate for configuration

and so on. We have the list of tests that are omitted because they cause troubles (prevent test suite to complete). The list is 32 tests long but it doesn't apply to x86. In theory we could prevent LTP from running all tests that it marks 'skip', but would that help anything?

There are around 12 (maybe 13?) tests that fail because we're runnining using NFS root filesystem. As Tom noted, this should be fixed soon.

Best Regards,
milosz