4.4.92-stable review
Greg Kroah-Hartman
maintainercover 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(-)
Greg Kroah-Hartman
maintainerPATCH 1/47 usb: gadget: inode.c: fix unbalanced spin_lock in ep0_write
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;
Greg Kroah-Hartman
maintainerPATCH 2/47 USB: gadgetfs: Fix crash caused by inadequate synchronization
In reply to Greg Kroah-Hartman4.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_eINIT_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 *gadgspin_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);
Greg Kroah-Hartman
maintainerPATCH 3/47 USB: gadgetfs: fix copy_to_user while holding spinlock
In reply to Greg Kroah-Hartman4.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 */ }
Greg Kroah-Hartman
maintainerPATCH 4/47 usb: gadget: udc: atmel: set vbus irqflags explicitly
In reply to Greg Kroah-Hartman4.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 ;
Greg Kroah-Hartman
maintainerPATCH 5/47 usb-storage: unusual_devs entry to fix write-access regression for Seagate external drives
In reply to Greg Kroah-Hartman4.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",
Greg Kroah-Hartman
maintainerPATCH 6/47 usb: renesas_usbhs: fix the BCLR setting condition for non-DCP pipe
In reply to Greg Kroah-Hartman4.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.
--- 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,
Greg Kroah-Hartman
maintainerPATCH 7/47 usb: renesas_usbhs: fix usbhsf_fifo_clear() for RX direction
In reply to Greg Kroah-Hartman4.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.
--- 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 usbstruct 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
Greg Kroah-Hartman
maintainerPATCH 8/47 ALSA: usb-audio: Check out-of-bounds access by corrupted buffer descriptor
In reply to Greg Kroah-Hartman4.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(structstruct 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(structreturn -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(structcase 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 ;
Greg Kroah-Hartman
maintainerPATCH 9/47 usb: pci-quirks.c: Corrected timeout values used in handshake
In reply to Greg Kroah-Hartman4.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(strucif (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 );
Greg Kroah-Hartman
maintainerPATCH 10/47 USB: dummy-hcd: fix connection failures (wrong speed)
In reply to Greg Kroah-Hartman4.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 platfomemzero_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 platfodev_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 ;
Greg Kroah-Hartman
maintainerPATCH 11/47 USB: dummy-hcd: fix infinite-loop resubmission bug
In reply to Greg Kroah-Hartman4.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 _dspin_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;
Greg Kroah-Hartman
maintainerPATCH 12/47 USB: dummy-hcd: Fix erroneous synchronization change
In reply to Greg Kroah-Hartman4.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.
--- 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_gadstruct 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(stif (!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) */
Greg Kroah-Hartman
maintainerPATCH 13/47 USB: devio: Dont corrupt user memory
In reply to Greg Kroah-Hartman4.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 :
Greg Kroah-Hartman
maintainerPATCH 14/47 usb: gadget: mass_storage: set msg_registered after msg registered
In reply to Greg Kroah-Hartman4.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_compositeusb_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);
Greg Kroah-Hartman
maintainerPATCH 15/47 USB: g_mass_storage: Fix deadlock when driver is unbound
In reply to Greg Kroah-Hartman4.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_luvoid 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_confstatic 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_compositeif (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);
Greg Kroah-Hartman
maintainerPATCH 16/47 lsm: fix smack_inode_removexattr and xattr_getsecurity memleak
In reply to Greg Kroah-Hartman4.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
Greg Kroah-Hartman
maintainerPATCH 17/47 ALSA: compress: Remove unused variable
In reply to Greg Kroah-Hartman4.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]
--- 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,
Greg Kroah-Hartman
maintainerPATCH 18/47 ALSA: usx2y: Suppress kernel warning at page allocation failures
In reply to Greg Kroah-Hartman4.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);
Greg Kroah-Hartman
maintainerPATCH 19/47 driver core: platform: Dont read past the end of "driver_override" buffer
In reply to Greg Kroah-Hartman4.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.
--- 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(strstruct 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 );
Greg Kroah-Hartman
maintainerPATCH 20/47 Drivers: hv: fcopy: restore correct transfer length
In reply to Greg Kroah-Hartman4.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.
--- 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;
Greg Kroah-Hartman
maintainerPATCH 21/47 stm class: Fix a use-after-free
In reply to Greg Kroah-Hartman4.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().
--- 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(structstm_source_link_drop (src); -device_destroy (&stm_source_class, src->dev.devt); +device_unregister (&src->dev); }EXPORT_SYMBOL_GPL (stm_source_unregister_device);
Greg Kroah-Hartman
maintainerPATCH 22/47 ftrace: Fix kmemleak in unregister_ftrace_graph
In reply to Greg Kroah-Hartman4.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
]
--- 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_FILTstatic 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); }
Greg Kroah-Hartman
maintainerPATCH 23/47 HID: i2c-hid: allocate hid buffers for real worst case
In reply to Greg Kroah-Hartman4.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 */
Greg Kroah-Hartman
maintainerPATCH 24/47 iwlwifi: add workaround to disable wide channels in 5GHz
In reply to Greg Kroah-Hartman4.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_nstatic 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(conststatic 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 devicif (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, ciwl_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, ciwl_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 ;
Greg Kroah-Hartman
maintainerPATCH 25/47 scsi: sd: Do not override max_sectors_kb sysfs setting
In reply to Greg Kroah-Hartman4.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 gensd_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);
Greg Kroah-Hartman
maintainerPATCH 26/47 USB: uas: fix bug in handling of alternate settings
In reply to Greg Kroah-Hartman4.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(strustruct 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 usbstruct 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)
Greg Kroah-Hartman
maintainerPATCH 27/47 USB: core: harden cdc_parse_cdc_header
In reply to Greg Kroah-Hartman4.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;
Greg Kroah-Hartman
maintainerPATCH 28/47 usb: Increase quirk delay for USB devices
In reply to Greg Kroah-Hartman4.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
Greg Kroah-Hartman
maintainerPATCH 29/47 USB: fix out-of-bounds in usb_set_configuration
In reply to Greg Kroah-Hartman4.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/*-------------------------------------------------------------------------*/
Greg Kroah-Hartman
maintainerPATCH 30/47 xhci: fix finding correct bus_state structure for USB 3.1 hosts
In reply to Greg Kroah-Hartman4.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 ;
Greg Kroah-Hartman
maintainerPATCH 31/47 iio: adc: twl4030: Fix an error handling path in twl4030_madc_probe()
In reply to Greg Kroah-Hartman4.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.
--- 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)
Greg Kroah-Hartman
maintainerPATCH 32/47 iio: adc: twl4030: Disable the vusb3v1 rugulator in the error handling path of twl4030_madc_probe()
In reply to Greg Kroah-Hartman4.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.
--- 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:
Greg Kroah-Hartman
maintainerPATCH 33/47 iio: ad_sigma_delta: Implement a dedicated reset function
In reply to Greg Kroah-Hartman4.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_deltint 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,
Greg Kroah-Hartman
maintainerPATCH 34/47 staging: iio: ad7192: Fix - use the dedicated reset function avoiding dma from stack.
In reply to Greg Kroah-Hartman4.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_ststruct 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 */
Greg Kroah-Hartman
maintainerPATCH 35/47 iio: core: Return error for failed read_reg
In reply to Greg Kroah-Hartman4.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);
Greg Kroah-Hartman
maintainerPATCH 36/47 iio: ad7793: Fix the serial interface reset
In reply to Greg Kroah-Hartman4.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.
--- 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 */
Greg Kroah-Hartman
maintainerPATCH 37/47 iio: adc: mcp320x: Fix readout of negative voltages
In reply to Greg Kroah-Hartman4.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.
--- 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(structswitch (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_dswitch (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 ;
Greg Kroah-Hartman
maintainerPATCH 38/47 iio: adc: mcp320x: Fix oops on module unload
In reply to Greg Kroah-Hartman4.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)
--- 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;
Greg Kroah-Hartman
maintainerPATCH 39/47 uwb: properly check kthread_run return value
In reply to Greg Kroah-Hartman4.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); }
Greg Kroah-Hartman
maintainerPATCH 40/47 uwb: ensure that endpoint is interrupt
In reply to Greg Kroah-Hartman4.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_interfif (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 ();
Greg Kroah-Hartman
maintainerPATCH 41/47 brcmfmac: setup passive scan if requested by user-space
In reply to Greg Kroah-Hartman4.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 brcmeth_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 (¶ms_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 (¶ms_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
Greg Kroah-Hartman
maintainerPATCH 43/47 nvme: protect against simultaneous shutdown invocations
In reply to Greg Kroah-Hartman4.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 nvmnvme_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 nvmfor (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 *pdINIT_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);
Greg Kroah-Hartman
maintainerPATCH 44/47 sched/cpuset/pm: Fix cpuset vs. suspend-resume bugs
In reply to Greg Kroah-Hartman4.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().
--- 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);
Greg Kroah-Hartman
maintainerPATCH 45/47 ext4: fix data corruption for mmap writes
In reply to Greg Kroah-Hartman4.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 *pstatic 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--;
Greg Kroah-Hartman
maintainerPATCH 46/47 ext4: Dont clear SGID when inheriting ACLs
In reply to Greg Kroah-Hartman4.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.
--- 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, structswitch (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;
Greg Kroah-Hartman
maintainerPATCH 47/47 ext4: dont allow encrypted operations without keys
In reply to Greg Kroah-Hartman4.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 *oldint 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 inodu8 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) &&
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.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-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
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.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-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
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.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-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.
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
A message that is not in the archive (sent off-list or not yet received): [email protected]
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.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-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
Greg Kroah-Hartman
maintainerQuoted 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.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-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
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.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-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 failures1/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 passQuoted 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
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 platformchown01_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