2018-02-05 18:39:13

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 3.18 00/36] 3.18.94-stable review

This is the start of the stable review cycle for the 3.18.94 release.
There are 36 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 Wed Feb 7 18:23:41 UTC 2018.
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/v3.x/stable-review/patch-3.18.94-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-3.18.y
and the diffstat can be found below.

thanks,

greg k-h

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

Greg Kroah-Hartman <[email protected]>
Linux 3.18.94-rc1

Jesse Chan <[email protected]>
ASoC: pcm512x: add missing MODULE_DESCRIPTION/AUTHOR/LICENSE

Stefan Agner <[email protected]>
spi: imx: do not access registers while clocks disabled

Mark Salyzyn <[email protected]>
selinux: general protection fault in sock_has_perm

Oliver Neukum <[email protected]>
usb: uas: unconditionally bring back host after reset

Hemant Kumar <[email protected]>
usb: f_fs: Prevent gadget unbind if it is already unbound

Johan Hovold <[email protected]>
USB: serial: simple: add Motorola Tetra driver

Shuah Khan <[email protected]>
usbip: list: don't list devices attached to vhci_hcd

Shuah Khan <[email protected]>
usbip: prevent bind loops on devices attached to vhci_hcd

Jia-Ju Bai <[email protected]>
USB: serial: io_edgeport: fix possible sleep-in-atomic

Oliver Neukum <[email protected]>
CDC-ACM: apply quirk for card reader

Hans de Goede <[email protected]>
USB: cdc-acm: Do not log urb submission errors on disconnect

Greg Kroah-Hartman <[email protected]>
USB: serial: pl2303: new device id for Chilitag

Larry Finger <[email protected]>
staging: rtl8188eu: Fix incorrect response to SIOCGIWESSID

Colin Ian King <[email protected]>
usb: gadget: don't dereference g until after it has been null checked

Icenowy Zheng <[email protected]>
media: usbtv: add a new usbid

Gustavo A. R. Silva <[email protected]>
scsi: ufs: ufshcd: fix potential NULL pointer dereference in ufshcd_config_vreg

Tetsuo Handa <[email protected]>
quota: Check for register_shrinker() failure.

Geert Uytterhoeven <[email protected]>
net: ethernet: xilinx: Mark XILINX_LL_TEMAC broken on 64-bit

Robert Lippert <[email protected]>
hwmon: (pmbus) Use 64bit math for DIRECT format values

Andrew Elble <[email protected]>
nfsd: check for use of the closed special stateid

Trond Myklebust <[email protected]>
nfsd: CLOSE SHOULD return the invalid special stateid for NFSv4.x (x>0)

Eduardo Otubo <[email protected]>
xen-netfront: remove warning when unloading module

Wanpeng Li <[email protected]>
KVM: VMX: Fix rflags cache during vCPU reset

Chun-Yeow Yeoh <[email protected]>
mac80211: fix the update of path metric for RANN frame

Michael Lyle <[email protected]>
bcache: check return value of register_shrinker

Wanpeng Li <[email protected]>
KVM: X86: Fix operand/address-size during instruction decoding

Liran Alon <[email protected]>
KVM: x86: Don't re-execute instruction when not passing CR2 value

Liran Alon <[email protected]>
KVM: x86: emulator: Return to user-mode on L1 CPL=0 emulation failure

Lyude Paul <[email protected]>
igb: Free IRQs when device is hotplugged

Jesse Chan <[email protected]>
gpio: iop: add missing MODULE_DESCRIPTION/AUTHOR/LICENSE

Takashi Iwai <[email protected]>
ALSA: seq: Make ioctls race-free

Linus Torvalds <[email protected]>
loop: fix concurrent lo_open/lo_release

Richard Weinberger <[email protected]>
um: Remove copy&paste code from init.h

Richard Weinberger <[email protected]>
um: Stop abusing __KERNEL__

Thomas Meyer <[email protected]>
um: link vmlinux with -no-pie

Dmitry Torokhov <[email protected]>
Input: do not emit unneeded EV_SYN when suspending


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

Diffstat:

Makefile | 4 ++--
arch/um/Makefile | 9 +++++----
arch/um/drivers/mconsole.h | 2 +-
arch/um/include/shared/init.h | 24 ++----------------------
arch/um/include/shared/user.h | 2 +-
arch/x86/include/asm/kvm_host.h | 3 ++-
arch/x86/kvm/emulate.c | 7 +++++++
arch/x86/kvm/vmx.c | 4 ++--
arch/x86/kvm/x86.c | 2 +-
arch/x86/um/shared/sysdep/tls.h | 6 +++---
drivers/block/loop.c | 10 ++++++++--
drivers/gpio/gpio-iop.c | 4 ++++
drivers/hwmon/pmbus/pmbus_core.c | 21 ++++++++++++---------
drivers/input/input.c | 5 ++++-
drivers/md/bcache/btree.c | 5 ++++-
drivers/media/usb/usbtv/usbtv-core.c | 1 +
drivers/net/ethernet/intel/igb/igb_main.c | 2 +-
drivers/net/ethernet/xilinx/Kconfig | 1 +
drivers/net/xen-netfront.c | 18 ++++++++++++++++++
drivers/scsi/ufs/ufshcd.c | 7 +++++--
drivers/spi/spi-imx.c | 15 +++++++++++++--
drivers/staging/rtl8188eu/os_dep/ioctl_linux.c | 14 ++++----------
drivers/usb/class/cdc-acm.c | 5 ++++-
drivers/usb/gadget/composite.c | 7 +++++--
drivers/usb/gadget/function/f_fs.c | 3 ++-
drivers/usb/serial/Kconfig | 1 +
drivers/usb/serial/io_edgeport.c | 1 -
drivers/usb/serial/pl2303.c | 1 +
drivers/usb/serial/pl2303.h | 1 +
drivers/usb/serial/usb-serial-simple.c | 7 +++++++
drivers/usb/storage/uas.c | 7 +++----
fs/nfsd/nfs4state.c | 15 +++++++++++++--
fs/quota/dquot.c | 3 ++-
net/mac80211/mesh_hwmp.c | 15 +++++++++------
security/selinux/hooks.c | 2 ++
sound/core/seq/seq_clientmgr.c | 10 ++++++++--
sound/core/seq/seq_clientmgr.h | 1 +
sound/soc/codecs/pcm512x-spi.c | 4 ++++
tools/usb/usbip/src/usbip_bind.c | 9 +++++++++
tools/usb/usbip/src/usbip_list.c | 9 +++++++++
40 files changed, 182 insertions(+), 85 deletions(-)




2018-02-05 18:34:18

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 3.18 12/36] bcache: check return value of register_shrinker

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

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

From: Michael Lyle <[email protected]>


[ Upstream commit 6c4ca1e36cdc1a0a7a84797804b87920ccbebf51 ]

register_shrinker is now __must_check, so check it to kill a warning.
Caller of bch_btree_cache_alloc in super.c appropriately checks return
value so this is fully plumbed through.

This V2 fixes checkpatch warnings and improves the commit description,
as I was too hasty getting the previous version out.

Signed-off-by: Michael Lyle <[email protected]>
Reviewed-by: Vojtech Pavlik <[email protected]>
Signed-off-by: Jens Axboe <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/md/bcache/btree.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)

--- a/drivers/md/bcache/btree.c
+++ b/drivers/md/bcache/btree.c
@@ -808,7 +808,10 @@ int bch_btree_cache_alloc(struct cache_s
c->shrink.scan_objects = bch_mca_scan;
c->shrink.seeks = 4;
c->shrink.batch = c->btree_pages * 2;
- register_shrinker(&c->shrink);
+
+ if (register_shrinker(&c->shrink))
+ pr_warn("bcache: %s: could not register shrinker",
+ __func__);

return 0;
}



2018-02-05 18:38:06

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 3.18 36/36] ASoC: pcm512x: add missing MODULE_DESCRIPTION/AUTHOR/LICENSE

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

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

From: Jesse Chan <[email protected]>

commit 0cab20cec0b663b7be8e2be5998d5a4113647f86 upstream.

This change resolves a new compile-time warning
when built as a loadable module:

WARNING: modpost: missing MODULE_LICENSE() in sound/soc/codecs/snd-soc-pcm512x-spi.o
see include/linux/module.h for more information

This adds the license as "GPL v2", which matches the header of the file.

MODULE_DESCRIPTION and MODULE_AUTHOR are also added.

Signed-off-by: Jesse Chan <[email protected]>
Signed-off-by: Mark Brown <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
sound/soc/codecs/pcm512x-spi.c | 4 ++++
1 file changed, 4 insertions(+)

--- a/sound/soc/codecs/pcm512x-spi.c
+++ b/sound/soc/codecs/pcm512x-spi.c
@@ -67,3 +67,7 @@ static struct spi_driver pcm512x_spi_dri
};

module_spi_driver(pcm512x_spi_driver);
+
+MODULE_DESCRIPTION("ASoC PCM512x codec driver - SPI");
+MODULE_AUTHOR("Mark Brown <[email protected]>");
+MODULE_LICENSE("GPL v2");



2018-02-05 18:38:19

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 3.18 34/36] selinux: general protection fault in sock_has_perm

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

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

From: Mark Salyzyn <[email protected]>

In the absence of commit a4298e4522d6 ("net: add SOCK_RCU_FREE socket
flag") and all the associated infrastructure changes to take advantage
of a RCU grace period before freeing, there is a heightened
possibility that a security check is performed while an ill-timed
setsockopt call races in from user space. It then is prudent to null
check sk_security, and if the case, reject the permissions.

Because of the nature of this problem, hard to duplicate, no clear
path, this patch is a simplified band-aid for stable trees lacking the
infrastructure for the series of commits leading up to providing a
suitable RCU grace period. This adjustment is orthogonal to
infrastructure improvements that may nullify the needed check, but
could be added as good code hygiene in all trees.

general protection fault: 0000 [#1] PREEMPT SMP KASAN
CPU: 1 PID: 14233 Comm: syz-executor2 Not tainted 4.4.112-g5f6325b #28
task: ffff8801d1095f00 task.stack: ffff8800b5950000
RIP: 0010:[<ffffffff81b69b7e>] [<ffffffff81b69b7e>] sock_has_perm+0x1fe/0x3e0 security/selinux/hooks.c:4069
RSP: 0018:ffff8800b5957ce0 EFLAGS: 00010202
RAX: dffffc0000000000 RBX: 1ffff10016b2af9f RCX: ffffffff81b69b51
RDX: 0000000000000002 RSI: 0000000000000000 RDI: 0000000000000010
RBP: ffff8800b5957de0 R08: 0000000000000001 R09: 0000000000000001
R10: 0000000000000000 R11: 1ffff10016b2af68 R12: ffff8800b5957db8
R13: 0000000000000000 R14: ffff8800b7259f40 R15: 00000000000000d7
FS: 00007f72f5ae2700(0000) GS:ffff8801db300000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000a2fa38 CR3: 00000001d7980000 CR4: 0000000000160670
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Stack:
ffffffff81b69a1f ffff8800b5957d58 00008000b5957d30 0000000041b58ab3
ffffffff83fc82f2 ffffffff81b69980 0000000000000246 ffff8801d1096770
ffff8801d3165668 ffffffff8157844b ffff8801d1095f00
ffff880000000001
Call Trace:
[<ffffffff81b6a19d>] selinux_socket_setsockopt+0x4d/0x80 security/selinux/hooks.c:4338
[<ffffffff81b4873d>] security_socket_setsockopt+0x7d/0xb0 security/security.c:1257
[<ffffffff82df1ac8>] SYSC_setsockopt net/socket.c:1757 [inline]
[<ffffffff82df1ac8>] SyS_setsockopt+0xe8/0x250 net/socket.c:1746
[<ffffffff83776499>] entry_SYSCALL_64_fastpath+0x16/0x92
Code: c2 42 9b b6 81 be 01 00 00 00 48 c7 c7 a0 cb 2b 84 e8
f7 2f 6d ff 49 8d 7d 10 48 b8 00 00 00 00 00 fc ff df 48 89
fa 48 c1 ea 03 <0f> b6 04 02 84 c0 74 08 3c 03 0f 8e 83 01 00
00 41 8b 75 10 31
RIP [<ffffffff81b69b7e>] sock_has_perm+0x1fe/0x3e0 security/selinux/hooks.c:4069
RSP <ffff8800b5957ce0>
---[ end trace 7b5aaf788fef6174 ]---

Signed-off-by: Mark Salyzyn <[email protected]>
Acked-by: Paul Moore <[email protected]>
Cc: Eric Dumazet <[email protected]>
Cc: Stephen Smalley <[email protected]>
Cc: [email protected]
Cc: [email protected]
Cc: Eric Paris <[email protected]>
Cc: Serge E. Hallyn <[email protected]>
Cc: [email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
security/selinux/hooks.c | 2 ++
1 file changed, 2 insertions(+)

--- a/security/selinux/hooks.c
+++ b/security/selinux/hooks.c
@@ -3969,6 +3969,8 @@ static int sock_has_perm(struct task_str
struct lsm_network_audit net = {0,};
u32 tsid = task_sid(task);

+ if (!sksec)
+ return -EFAULT;
if (sksec->sid == SECINITSID_KERNEL)
return 0;




2018-02-05 18:38:25

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 3.18 33/36] usb: uas: unconditionally bring back host after reset

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

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

From: Oliver Neukum <[email protected]>

commit cbeef22fd611c4f47c494b821b2b105b8af970bb upstream.

Quoting Hans:

If we return 1 from our post_reset handler, then our disconnect handler
will be called immediately afterwards. Since pre_reset blocks all scsi
requests our disconnect handler will then hang in the scsi_remove_host
call.

This is esp. bad because our disconnect handler hanging for ever also
stops the USB subsys from enumerating any new USB devices, causes commands
like lsusb to hang, etc.

In practice this happens when unplugging some uas devices because the hub
code may see the device as needing a warm-reset and calls usb_reset_device
before seeing the disconnect. In this case uas_configure_endpoints fails
with -ENODEV. We do not want to print an error for this, so this commit
also silences the shost_printk for -ENODEV.

ENDQUOTE

However, if we do that we better drop any unconditional execution
and report to the SCSI subsystem that we have undergone a reset
but we are not operational now.

Signed-off-by: Oliver Neukum <[email protected]>
Reported-by: Hans de Goede <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/usb/storage/uas.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)

--- a/drivers/usb/storage/uas.c
+++ b/drivers/usb/storage/uas.c
@@ -1067,20 +1067,19 @@ static int uas_post_reset(struct usb_int
return 0;

err = uas_configure_endpoints(devinfo);
- if (err) {
+ if (err && err != ENODEV)
shost_printk(KERN_ERR, shost,
"%s: alloc streams error %d after reset",
__func__, err);
- return 1;
- }

+ /* we must unblock the host in every case lest we deadlock */
spin_lock_irqsave(shost->host_lock, flags);
scsi_report_bus_reset(shost, 0);
spin_unlock_irqrestore(shost->host_lock, flags);

scsi_unblock_requests(shost);

- return 0;
+ return err ? 1 : 0;
}

static int uas_suspend(struct usb_interface *intf, pm_message_t message)



2018-02-05 18:39:18

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 3.18 31/36] USB: serial: simple: add Motorola Tetra driver

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

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

From: Johan Hovold <[email protected]>

commit 46fe895e22ab3845515ec06b01eaf1282b342e29 upstream.

Add new Motorola Tetra (simple) driver for Motorola Solutions TETRA PEI
devices.

D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1
P: Vendor=0cad ProdID=9011 Rev=24.16
S: Manufacturer=Motorola Solutions Inc.
S: Product=Motorola Solutions TETRA PEI interface
C: #Ifs= 2 Cfg#= 1 Atr=80 MxPwr=500mA
I: If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none)
I: If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none)

Note that these devices do not support the CDC SET_CONTROL_LINE_STATE
request (for any interface).

Reported-by: Max Schulze <[email protected]>
Tested-by: Max Schulze <[email protected]>
Signed-off-by: Johan Hovold <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/usb/serial/Kconfig | 1 +
drivers/usb/serial/usb-serial-simple.c | 7 +++++++
2 files changed, 8 insertions(+)

--- a/drivers/usb/serial/Kconfig
+++ b/drivers/usb/serial/Kconfig
@@ -62,6 +62,7 @@ config USB_SERIAL_SIMPLE
- Fundamental Software dongle.
- HP4x calculators
- a number of Motorola phones
+ - Motorola Tetra devices
- Novatel Wireless GPS receivers
- Siemens USB/MPI adapter.
- ViVOtech ViVOpay USB device.
--- a/drivers/usb/serial/usb-serial-simple.c
+++ b/drivers/usb/serial/usb-serial-simple.c
@@ -72,6 +72,11 @@ DEVICE(vivopay, VIVOPAY_IDS);
{ USB_DEVICE(0x22b8, 0x2c64) } /* Motorola V950 phone */
DEVICE(moto_modem, MOTO_IDS);

+/* Motorola Tetra driver */
+#define MOTOROLA_TETRA_IDS() \
+ { USB_DEVICE(0x0cad, 0x9011) } /* Motorola Solutions TETRA PEI */
+DEVICE(motorola_tetra, MOTOROLA_TETRA_IDS);
+
/* Novatel Wireless GPS driver */
#define NOVATEL_IDS() \
{ USB_DEVICE(0x09d7, 0x0100) } /* NovAtel FlexPack GPS */
@@ -101,6 +106,7 @@ static struct usb_serial_driver * const
&flashloader_device,
&vivopay_device,
&moto_modem_device,
+ &motorola_tetra_device,
&novatel_gps_device,
&hp4x_device,
&suunto_device,
@@ -115,6 +121,7 @@ static const struct usb_device_id id_tab
FLASHLOADER_IDS(),
VIVOPAY_IDS(),
MOTO_IDS(),
+ MOTOROLA_TETRA_IDS(),
NOVATEL_IDS(),
HP4X_IDS(),
SUUNTO_IDS(),



2018-02-05 18:39:26

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 3.18 35/36] spi: imx: do not access registers while clocks disabled

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

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

From: Stefan Agner <[email protected]>

commit d593574aff0ab846136190b1729c151c736727ec upstream.

Since clocks are disabled except during message transfer clocks
are also disabled when spi_imx_remove gets called. Accessing
registers leads to a freeeze at least on a i.MX 6ULL. Enable
clocks before disabling accessing the MXC_CSPICTRL register.

Fixes: 9e556dcc55774 ("spi: spi-imx: only enable the clocks when we start to transfer a message")
Signed-off-by: Stefan Agner <[email protected]>
Signed-off-by: Mark Brown <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/spi/spi-imx.c | 15 +++++++++++++--
1 file changed, 13 insertions(+), 2 deletions(-)

--- a/drivers/spi/spi-imx.c
+++ b/drivers/spi/spi-imx.c
@@ -1220,12 +1220,23 @@ static int spi_imx_remove(struct platfor
{
struct spi_master *master = platform_get_drvdata(pdev);
struct spi_imx_data *spi_imx = spi_master_get_devdata(master);
+ int ret;

spi_bitbang_stop(&spi_imx->bitbang);

+ ret = clk_enable(spi_imx->clk_per);
+ if (ret)
+ return ret;
+
+ ret = clk_enable(spi_imx->clk_ipg);
+ if (ret) {
+ clk_disable(spi_imx->clk_per);
+ return ret;
+ }
+
writel(0, spi_imx->base + MXC_CSPICTRL);
- clk_unprepare(spi_imx->clk_ipg);
- clk_unprepare(spi_imx->clk_per);
+ clk_disable_unprepare(spi_imx->clk_ipg);
+ clk_disable_unprepare(spi_imx->clk_per);
spi_imx_sdma_exit(spi_imx);
spi_master_put(master);




2018-02-05 18:39:42

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 3.18 32/36] usb: f_fs: Prevent gadget unbind if it is already unbound

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

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

From: Hemant Kumar <[email protected]>

commit ce5bf9a50daf2d9078b505aca1cea22e88ecb94a upstream.

Upon usb composition switch there is possibility of ep0 file
release happening after gadget driver bind. In case of composition
switch from adb to a non-adb composition gadget will never gets
bound again resulting into failure of usb device enumeration. Fix
this issue by checking FFS_FL_BOUND flag and avoid extra
gadget driver unbind if it is already done as part of composition
switch.

This fixes adb reconnection error reported on Android running
v4.4 and above kernel versions. Verified on Hikey running vanilla
v4.15-rc7 + few out of tree Mali patches.

Reviewed-at: https://android-review.googlesource.com/#/c/582632/

Cc: Felipe Balbi <[email protected]>
Cc: Greg KH <[email protected]>
Cc: Michal Nazarewicz <[email protected]>
Cc: John Stultz <[email protected]>
Cc: Dmitry Shmidt <[email protected]>
Cc: Badhri <[email protected]>
Cc: Android Kernel Team <[email protected]>
Signed-off-by: Hemant Kumar <[email protected]>
[AmitP: Cherry-picked it from android-4.14 and updated the commit log]
Signed-off-by: Amit Pundir <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

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

--- a/drivers/usb/gadget/function/f_fs.c
+++ b/drivers/usb/gadget/function/f_fs.c
@@ -3438,7 +3438,8 @@ static void ffs_closed(struct ffs_data *
ci = opts->func_inst.group.cg_item.ci_parent->ci_parent;
ffs_dev_unlock();

- unregister_gadget_item(ci);
+ if (test_bit(FFS_FL_BOUND, &ffs->flags))
+ unregister_gadget_item(ci);
return;
done:
ffs_dev_unlock();



2018-02-05 18:40:18

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 3.18 04/36] um: Remove copy&paste code from init.h

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

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

From: Richard Weinberger <[email protected]>

commit 30b11ee9ae23d78de66b9ae315880af17a64ba83 upstream.

As we got rid of the __KERNEL__ abuse, we can directly
include linux/compiler.h now.
This also allows gcc 5 to build UML.

Reported-by: Hans-Werner Hilse <[email protected]>
Signed-off-by: Richard Weinberger <[email protected]>
Cc: Greg Hackmann <[email protected]>
Cc: Bernie Innocenti <[email protected]>
Cc: Lorenzo Colitti <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
arch/um/include/shared/init.h | 22 +---------------------
1 file changed, 1 insertion(+), 21 deletions(-)

--- a/arch/um/include/shared/init.h
+++ b/arch/um/include/shared/init.h
@@ -40,28 +40,8 @@
typedef int (*initcall_t)(void);
typedef void (*exitcall_t)(void);

-#ifdef __UM_HOST__
-#ifndef __section
-# define __section(S) __attribute__ ((__section__(#S)))
-#endif
-
-#if __GNUC__ == 3
-
-#if __GNUC_MINOR__ >= 3
-# define __used __attribute__((__used__))
-#else
-# define __used __attribute__((__unused__))
-#endif
-
-#else
-#if __GNUC__ == 4
-# define __used __attribute__((__used__))
-#endif
-#endif
-
-#else
#include <linux/compiler.h>
-#endif
+
/* These are for everybody (although not all archs will actually
discard it in modules) */
#define __init __section(.init.text)



2018-02-05 18:40:58

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 3.18 08/36] igb: Free IRQs when device is hotplugged

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

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

From: Lyude Paul <[email protected]>

commit 888f22931478a05bc81ceb7295c626e1292bf0ed upstream.

Recently I got a Caldigit TS3 Thunderbolt 3 dock, and noticed that upon
hotplugging my kernel would immediately crash due to igb:

[ 680.825801] kernel BUG at drivers/pci/msi.c:352!
[ 680.828388] invalid opcode: 0000 [#1] SMP
[ 680.829194] Modules linked in: igb(O) thunderbolt i2c_algo_bit joydev vfat fat btusb btrtl btbcm btintel bluetooth ecdh_generic hp_wmi sparse_keymap rfkill wmi_bmof iTCO_wdt intel_rapl x86_pkg_temp_thermal coretemp crc32_pclmul snd_pcm rtsx_pci_ms mei_me snd_timer memstick snd pcspkr mei soundcore i2c_i801 tpm_tis psmouse shpchp wmi tpm_tis_core tpm video hp_wireless acpi_pad rtsx_pci_sdmmc mmc_core crc32c_intel serio_raw rtsx_pci mfd_core xhci_pci xhci_hcd i2c_hid i2c_core [last unloaded: igb]
[ 680.831085] CPU: 1 PID: 78 Comm: kworker/u16:1 Tainted: G O 4.15.0-rc3Lyude-Test+ #6
[ 680.831596] Hardware name: HP HP ZBook Studio G4/826B, BIOS P71 Ver. 01.03 06/09/2017
[ 680.832168] Workqueue: kacpi_hotplug acpi_hotplug_work_fn
[ 680.832687] RIP: 0010:free_msi_irqs+0x180/0x1b0
[ 680.833271] RSP: 0018:ffffc9000030fbf0 EFLAGS: 00010286
[ 680.833761] RAX: ffff8803405f9c00 RBX: ffff88033e3d2e40 RCX: 000000000000002c
[ 680.834278] RDX: 0000000000000000 RSI: 00000000000000ac RDI: ffff880340be2178
[ 680.834832] RBP: 0000000000000000 R08: ffff880340be1ff0 R09: ffff8803405f9c00
[ 680.835342] R10: 0000000000000000 R11: 0000000000000040 R12: ffff88033d63a298
[ 680.835822] R13: ffff88033d63a000 R14: 0000000000000060 R15: ffff880341959000
[ 680.836332] FS: 0000000000000000(0000) GS:ffff88034f440000(0000) knlGS:0000000000000000
[ 680.836817] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 680.837360] CR2: 000055e64044afdf CR3: 0000000001c09002 CR4: 00000000003606e0
[ 680.837954] Call Trace:
[ 680.838853] pci_disable_msix+0xce/0xf0
[ 680.839616] igb_reset_interrupt_capability+0x5d/0x60 [igb]
[ 680.840278] igb_remove+0x9d/0x110 [igb]
[ 680.840764] pci_device_remove+0x36/0xb0
[ 680.841279] device_release_driver_internal+0x157/0x220
[ 680.841739] pci_stop_bus_device+0x7d/0xa0
[ 680.842255] pci_stop_bus_device+0x2b/0xa0
[ 680.842722] pci_stop_bus_device+0x3d/0xa0
[ 680.843189] pci_stop_and_remove_bus_device+0xe/0x20
[ 680.843627] trim_stale_devices+0xf3/0x140
[ 680.844086] trim_stale_devices+0x94/0x140
[ 680.844532] trim_stale_devices+0xa6/0x140
[ 680.845031] ? get_slot_status+0x90/0xc0
[ 680.845536] acpiphp_check_bridge.part.5+0xfe/0x140
[ 680.846021] acpiphp_hotplug_notify+0x175/0x200
[ 680.846581] ? free_bridge+0x100/0x100
[ 680.847113] acpi_device_hotplug+0x8a/0x490
[ 680.847535] acpi_hotplug_work_fn+0x1a/0x30
[ 680.848076] process_one_work+0x182/0x3a0
[ 680.848543] worker_thread+0x2e/0x380
[ 680.848963] ? process_one_work+0x3a0/0x3a0
[ 680.849373] kthread+0x111/0x130
[ 680.849776] ? kthread_create_worker_on_cpu+0x50/0x50
[ 680.850188] ret_from_fork+0x1f/0x30
[ 680.850601] Code: 43 14 85 c0 0f 84 d5 fe ff ff 31 ed eb 0f 83 c5 01 39 6b 14 0f 86 c5 fe ff ff 8b 7b 10 01 ef e8 b7 e4 d2 ff 48 83 78 70 00 74 e3 <0f> 0b 49 8d b5 a0 00 00 00 e8 62 6f d3 ff e9 c7 fe ff ff 48 8b
[ 680.851497] RIP: free_msi_irqs+0x180/0x1b0 RSP: ffffc9000030fbf0

As it turns out, normally the freeing of IRQs that would fix this is called
inside of the scope of __igb_close(). However, since the device is
already gone by the point we try to unregister the netdevice from the
driver due to a hotplug we end up seeing that the netif isn't present
and thus, forget to free any of the device IRQs.

So: make sure that if we're in the process of dismantling the netdev, we
always allow __igb_close() to be called so that IRQs may be freed
normally. Additionally, only allow igb_close() to be called from
__igb_close() if it hasn't already been called for the given adapter.

Signed-off-by: Lyude Paul <[email protected]>
Fixes: 9474933caf21 ("igb: close/suspend race in netif_device_detach")
Cc: Todd Fujinaka <[email protected]>
Cc: Stephen Hemminger <[email protected]>
Tested-by: Aaron Brown <[email protected]>
Signed-off-by: Jeff Kirsher <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/net/ethernet/intel/igb/igb_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/net/ethernet/intel/igb/igb_main.c
+++ b/drivers/net/ethernet/intel/igb/igb_main.c
@@ -3172,7 +3172,7 @@ static int __igb_close(struct net_device

static int igb_close(struct net_device *netdev)
{
- if (netif_device_present(netdev))
+ if (netif_device_present(netdev) || netdev->dismantle)
return __igb_close(netdev, false);
return 0;
}



2018-02-05 18:41:04

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 3.18 07/36] gpio: iop: add missing MODULE_DESCRIPTION/AUTHOR/LICENSE

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

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

From: Jesse Chan <[email protected]>

commit 97b03136e1b637d7a9d2274c099e44ecf23f1103 upstream.

This change resolves a new compile-time warning
when built as a loadable module:

WARNING: modpost: missing MODULE_LICENSE() in drivers/gpio/gpio-iop.o
see include/linux/module.h for more information

This adds the license as "GPL", which matches the header of the file.

MODULE_DESCRIPTION and MODULE_AUTHOR are also added.

Signed-off-by: Jesse Chan <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/gpio/gpio-iop.c | 4 ++++
1 file changed, 4 insertions(+)

--- a/drivers/gpio/gpio-iop.c
+++ b/drivers/gpio/gpio-iop.c
@@ -130,3 +130,7 @@ static int __init iop3xx_gpio_init(void)
return platform_driver_register(&iop3xx_gpio_driver);
}
arch_initcall(iop3xx_gpio_init);
+
+MODULE_DESCRIPTION("GPIO handling for Intel IOP3xx processors");
+MODULE_AUTHOR("Lennert Buytenhek <[email protected]>");
+MODULE_LICENSE("GPL");



2018-02-05 18:41:15

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 3.18 06/36] ALSA: seq: Make ioctls race-free

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

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

From: Takashi Iwai <[email protected]>

commit b3defb791b26ea0683a93a4f49c77ec45ec96f10 upstream.

The ALSA sequencer ioctls have no protection against racy calls while
the concurrent operations may lead to interfere with each other. As
reported recently, for example, the concurrent calls of setting client
pool with a combination of write calls may lead to either the
unkillable dead-lock or UAF.

As a slightly big hammer solution, this patch introduces the mutex to
make each ioctl exclusive. Although this may reduce performance via
parallel ioctl calls, usually it's not demanded for sequencer usages,
hence it should be negligible.

Reported-by: Luo Quan <[email protected]>
Reviewed-by: Kees Cook <[email protected]>
Reviewed-by: Greg Kroah-Hartman <[email protected]>
Signed-off-by: Takashi Iwai <[email protected]>
[bwh: Backported to 4.4: ioctl dispatch is done from snd_seq_do_ioctl();
take the mutex and add ret variable there.]
Signed-off-by: Ben Hutchings <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
sound/core/seq/seq_clientmgr.c | 10 ++++++++--
sound/core/seq/seq_clientmgr.h | 1 +
2 files changed, 9 insertions(+), 2 deletions(-)

--- a/sound/core/seq/seq_clientmgr.c
+++ b/sound/core/seq/seq_clientmgr.c
@@ -236,6 +236,7 @@ static struct snd_seq_client *seq_create
rwlock_init(&client->ports_lock);
mutex_init(&client->ports_mutex);
INIT_LIST_HEAD(&client->ports_list_head);
+ mutex_init(&client->ioctl_mutex);

/* find free slot in the client table */
spin_lock_irqsave(&clients_lock, flags);
@@ -2200,6 +2201,7 @@ static int snd_seq_do_ioctl(struct snd_s
void __user *arg)
{
struct seq_ioctl_table *p;
+ int ret;

switch (cmd) {
case SNDRV_SEQ_IOCTL_PVERSION:
@@ -2213,8 +2215,12 @@ static int snd_seq_do_ioctl(struct snd_s
if (! arg)
return -EFAULT;
for (p = ioctl_tables; p->cmd; p++) {
- if (p->cmd == cmd)
- return p->func(client, arg);
+ if (p->cmd == cmd) {
+ mutex_lock(&client->ioctl_mutex);
+ ret = p->func(client, arg);
+ mutex_unlock(&client->ioctl_mutex);
+ return ret;
+ }
}
pr_debug("ALSA: seq unknown ioctl() 0x%x (type='%c', number=0x%02x)\n",
cmd, _IOC_TYPE(cmd), _IOC_NR(cmd));
--- a/sound/core/seq/seq_clientmgr.h
+++ b/sound/core/seq/seq_clientmgr.h
@@ -59,6 +59,7 @@ struct snd_seq_client {
struct list_head ports_list_head;
rwlock_t ports_lock;
struct mutex ports_mutex;
+ struct mutex ioctl_mutex;
int convert32; /* convert 32->64bit */

/* output pool */



2018-02-05 18:41:33

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 3.18 27/36] CDC-ACM: apply quirk for card reader

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

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

From: Oliver Neukum <[email protected]>

commit df1cc78a52491f71d8170d513d0f6f114faa1bda upstream.

This devices drops random bytes from messages if you talk to it
too fast.

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

---
drivers/usb/class/cdc-acm.c | 3 +++
1 file changed, 3 insertions(+)

--- a/drivers/usb/class/cdc-acm.c
+++ b/drivers/usb/class/cdc-acm.c
@@ -1712,6 +1712,9 @@ static const struct usb_device_id acm_id
{ USB_DEVICE(0x0ace, 0x1611), /* ZyDAS 56K USB MODEM - new version */
.driver_info = SINGLE_RX_URB, /* firmware bug */
},
+ { USB_DEVICE(0x11ca, 0x0201), /* VeriFone Mx870 Gadget Serial */
+ .driver_info = SINGLE_RX_URB,
+ },
{ USB_DEVICE(0x22b8, 0x7000), /* Motorola Q Phone */
.driver_info = NO_UNION_NORMAL, /* has no union descriptor */
},



2018-02-05 18:41:33

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 3.18 30/36] usbip: list: dont list devices attached to vhci_hcd

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

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

From: Shuah Khan <[email protected]>

commit ef824501f50846589f02173d73ce3fe6021a9d2a upstream.

usbip host lists devices attached to vhci_hcd on the same server
when user does attach over localhost or specifies the server as the
remote.

usbip attach -r localhost -b busid
or
usbip attach -r servername (or server IP)

Fix it to check and not list devices that are attached to vhci_hcd.

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

---
tools/usb/usbip/src/usbip_list.c | 9 +++++++++
1 file changed, 9 insertions(+)

--- a/tools/usb/usbip/src/usbip_list.c
+++ b/tools/usb/usbip/src/usbip_list.c
@@ -180,6 +180,7 @@ static int list_devices(bool parsable)
const char *busid;
char product_name[128];
int ret = -1;
+ const char *devpath;

/* Create libudev context. */
udev = udev_new();
@@ -202,6 +203,14 @@ static int list_devices(bool parsable)
path = udev_list_entry_get_name(dev_list_entry);
dev = udev_device_new_from_syspath(udev, path);

+ /* Ignore devices attached to vhci_hcd */
+ devpath = udev_device_get_devpath(dev);
+ if (strstr(devpath, USBIP_VHCI_DRV_NAME)) {
+ dbg("Skip the device %s already attached to %s\n",
+ devpath, USBIP_VHCI_DRV_NAME);
+ continue;
+ }
+
/* Get device information. */
idVendor = udev_device_get_sysattr_value(dev, "idVendor");
idProduct = udev_device_get_sysattr_value(dev, "idProduct");



2018-02-05 18:41:36

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 3.18 26/36] USB: cdc-acm: Do not log urb submission errors on disconnect

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

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

From: Hans de Goede <[email protected]>

commit f0386c083c2ce85284dc0b419d7b89c8e567c09f upstream.

When disconnected sometimes the cdc-acm driver logs errors like these:

[20278.039417] cdc_acm 2-2:2.1: urb 9 failed submission with -19
[20278.042924] cdc_acm 2-2:2.1: urb 10 failed submission with -19
[20278.046449] cdc_acm 2-2:2.1: urb 11 failed submission with -19
[20278.049920] cdc_acm 2-2:2.1: urb 12 failed submission with -19
[20278.053442] cdc_acm 2-2:2.1: urb 13 failed submission with -19
[20278.056915] cdc_acm 2-2:2.1: urb 14 failed submission with -19
[20278.060418] cdc_acm 2-2:2.1: urb 15 failed submission with -19

Silence these by not logging errors when the result is -ENODEV.

Signed-off-by: Hans de Goede <[email protected]>
Acked-by: Oliver Neukum <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/usb/class/cdc-acm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/usb/class/cdc-acm.c
+++ b/drivers/usb/class/cdc-acm.c
@@ -381,7 +381,7 @@ static int acm_submit_read_urb(struct ac

res = usb_submit_urb(acm->read_urbs[index], mem_flags);
if (res) {
- if (res != -EPERM) {
+ if (res != -EPERM && res != -ENODEV) {
dev_err(&acm->data->dev,
"%s - usb_submit_urb failed: %d\n",
__func__, res);



2018-02-05 18:41:40

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 3.18 03/36] um: Stop abusing __KERNEL__

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

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

From: Richard Weinberger <[email protected]>

commit 298e20ba8c197e8d429a6c8671550c41c7919033 upstream.

Currently UML is abusing __KERNEL__ to distinguish between
kernel and host code (os-Linux). It is better to use a custom
define such that existing users of __KERNEL__ don't get confused.

Signed-off-by: Richard Weinberger <[email protected]>
Cc: Greg Hackmann <[email protected]>
Cc: Bernie Innocenti <[email protected]>
Cc: Lorenzo Colitti <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
arch/um/Makefile | 7 ++++---
arch/um/drivers/mconsole.h | 2 +-
arch/um/include/shared/init.h | 4 ++--
arch/um/include/shared/user.h | 2 +-
arch/x86/um/shared/sysdep/tls.h | 6 +++---
5 files changed, 11 insertions(+), 10 deletions(-)

--- a/arch/um/Makefile
+++ b/arch/um/Makefile
@@ -68,9 +68,10 @@ KBUILD_CFLAGS += $(CFLAGS) $(CFLAGS-y) -

KBUILD_AFLAGS += $(ARCH_INCLUDE)

-USER_CFLAGS = $(patsubst $(KERNEL_DEFINES),,$(patsubst -D__KERNEL__,,\
- $(patsubst -I%,,$(KBUILD_CFLAGS)))) $(ARCH_INCLUDE) $(MODE_INCLUDE) \
- $(filter -I%,$(CFLAGS)) -D_FILE_OFFSET_BITS=64 -idirafter include
+USER_CFLAGS = $(patsubst $(KERNEL_DEFINES),,$(patsubst -I%,,$(KBUILD_CFLAGS))) \
+ $(ARCH_INCLUDE) $(MODE_INCLUDE) $(filter -I%,$(CFLAGS)) \
+ -D_FILE_OFFSET_BITS=64 -idirafter include \
+ -D__KERNEL__ -D__UM_HOST__

#This will adjust *FLAGS accordingly to the platform.
include $(srctree)/$(ARCH_DIR)/Makefile-os-$(OS)
--- a/arch/um/drivers/mconsole.h
+++ b/arch/um/drivers/mconsole.h
@@ -7,7 +7,7 @@
#ifndef __MCONSOLE_H__
#define __MCONSOLE_H__

-#ifndef __KERNEL__
+#ifdef __UM_HOST__
#include <stdint.h>
#define u32 uint32_t
#endif
--- a/arch/um/include/shared/init.h
+++ b/arch/um/include/shared/init.h
@@ -40,7 +40,7 @@
typedef int (*initcall_t)(void);
typedef void (*exitcall_t)(void);

-#ifndef __KERNEL__
+#ifdef __UM_HOST__
#ifndef __section
# define __section(S) __attribute__ ((__section__(#S)))
#endif
@@ -131,7 +131,7 @@ extern struct uml_param __uml_setup_star
#define __uml_postsetup_call __used __section(.uml.postsetup.init)
#define __uml_exit_call __used __section(.uml.exitcall.exit)

-#ifndef __KERNEL__
+#ifdef __UM_HOST__

#define __define_initcall(level,fn) \
static initcall_t __initcall_##fn __used \
--- a/arch/um/include/shared/user.h
+++ b/arch/um/include/shared/user.h
@@ -17,7 +17,7 @@
#define ARRAY_SIZE(x) (sizeof(x) / sizeof((x)[0]))

/* This is to get size_t */
-#ifdef __KERNEL__
+#ifndef __UM_HOST__
#include <linux/types.h>
#else
#include <stddef.h>
--- a/arch/x86/um/shared/sysdep/tls.h
+++ b/arch/x86/um/shared/sysdep/tls.h
@@ -1,7 +1,7 @@
#ifndef _SYSDEP_TLS_H
#define _SYSDEP_TLS_H

-# ifndef __KERNEL__
+#ifdef __UM_HOST__

/* Change name to avoid conflicts with the original one from <asm/ldt.h>, which
* may be named user_desc (but in 2.4 and in header matching its API was named
@@ -22,11 +22,11 @@ typedef struct um_dup_user_desc {
#endif
} user_desc_t;

-# else /* __KERNEL__ */
+#else /* __UM_HOST__ */

typedef struct user_desc user_desc_t;

-# endif /* __KERNEL__ */
+#endif /* __UM_HOST__ */

extern int os_set_thread_area(user_desc_t *info, int pid);
extern int os_get_thread_area(user_desc_t *info, int pid);



2018-02-05 18:41:52

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 3.18 29/36] usbip: prevent bind loops on devices attached to vhci_hcd

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

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

From: Shuah Khan <[email protected]>

commit ef54cf0c600fb8f5737fb001a9e357edda1a1de8 upstream.

usbip host binds to devices attached to vhci_hcd on the same server
when user does attach over localhost or specifies the server as the
remote.

usbip attach -r localhost -b busid
or
usbip attach -r servername (or server IP)

Unbind followed by bind works, however device is left in a bad state with
accesses via the attached busid result in errors and system hangs during
shutdown.

Fix it to check and bail out if the device is already attached to vhci_hcd.

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

---
tools/usb/usbip/src/usbip_bind.c | 9 +++++++++
1 file changed, 9 insertions(+)

--- a/tools/usb/usbip/src/usbip_bind.c
+++ b/tools/usb/usbip/src/usbip_bind.c
@@ -144,6 +144,7 @@ static int bind_device(char *busid)
int rc;
struct udev *udev;
struct udev_device *dev;
+ const char *devpath;

/* Check whether the device with this bus ID exists. */
udev = udev_new();
@@ -152,8 +153,16 @@ static int bind_device(char *busid)
err("device with the specified bus ID does not exist");
return -1;
}
+ devpath = udev_device_get_devpath(dev);
udev_unref(udev);

+ /* If the device is already attached to vhci_hcd - bail out */
+ if (strstr(devpath, USBIP_VHCI_DRV_NAME)) {
+ err("bind loop detected: device: %s is attached to %s\n",
+ devpath, USBIP_VHCI_DRV_NAME);
+ return -1;
+ }
+
rc = unbind_other(busid);
if (rc == UNBIND_ST_FAILED) {
err("could not unbind driver from device on busid %s", busid);



2018-02-05 18:42:02

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 3.18 28/36] USB: serial: io_edgeport: fix possible sleep-in-atomic

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

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

From: Jia-Ju Bai <[email protected]>

commit c7b8f77872c73f69a16528a9eb87afefcccdc18b upstream.

According to drivers/usb/serial/io_edgeport.c, the driver may sleep
under a spinlock.
The function call path is:
edge_bulk_in_callback (acquire the spinlock)
process_rcvd_data
process_rcvd_status
change_port_settings
send_iosp_ext_cmd
write_cmd_usb
usb_kill_urb --> may sleep

To fix it, the redundant usb_kill_urb() is removed from the error path
after usb_submit_urb() fails.

This possible bug is found by my static analysis tool (DSAC) and checked
by my code review.

Signed-off-by: Jia-Ju Bai <[email protected]>
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Johan Hovold <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/usb/serial/io_edgeport.c | 1 -
1 file changed, 1 deletion(-)

--- a/drivers/usb/serial/io_edgeport.c
+++ b/drivers/usb/serial/io_edgeport.c
@@ -2219,7 +2219,6 @@ static int write_cmd_usb(struct edgeport
/* something went wrong */
dev_err(dev, "%s - usb_submit_urb(write command) failed, status = %d\n",
__func__, status);
- usb_kill_urb(urb);
usb_free_urb(urb);
atomic_dec(&CmdUrbs);
return status;



2018-02-05 18:42:13

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 3.18 22/36] media: usbtv: add a new usbid

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

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

From: Icenowy Zheng <[email protected]>


[ Upstream commit 04226916d2360f56d57ad00bc48d2d1854d1e0b0 ]

A new usbid of UTV007 is found in a newly bought device.

The usbid is 1f71:3301.

The ID on the chip is:
UTV007
A89029.1
1520L18K1

Both video and audio is tested with the modified usbtv driver.

Signed-off-by: Icenowy Zheng <[email protected]>
Acked-by: Lubomir Rintel <[email protected]>
Signed-off-by: Mauro Carvalho Chehab <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/media/usb/usbtv/usbtv-core.c | 1 +
1 file changed, 1 insertion(+)

--- a/drivers/media/usb/usbtv/usbtv-core.c
+++ b/drivers/media/usb/usbtv/usbtv-core.c
@@ -127,6 +127,7 @@ static void usbtv_disconnect(struct usb_

static struct usb_device_id usbtv_id_table[] = {
{ USB_DEVICE(0x1b71, 0x3002) },
+ { USB_DEVICE(0x1f71, 0x3301) },
{}
};
MODULE_DEVICE_TABLE(usb, usbtv_id_table);



2018-02-05 18:42:16

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 3.18 24/36] staging: rtl8188eu: Fix incorrect response to SIOCGIWESSID

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

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

From: Larry Finger <[email protected]>


[ Upstream commit b77992d2df9e47144354d1b25328b180afa33442 ]

When not associated with an AP, wifi device drivers should respond to the
SIOCGIWESSID ioctl with a zero-length string for the SSID, which is the
behavior expected by dhcpcd.

Currently, this driver returns an error code (-1) from the ioctl call,
which causes dhcpcd to assume that the device is not a wireless interface
and therefore it fails to work correctly with it thereafter.

This problem was reported and tested at
https://github.com/lwfinger/rtl8188eu/issues/234.

Signed-off-by: Larry Finger <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/staging/rtl8188eu/os_dep/ioctl_linux.c | 14 ++++----------
1 file changed, 4 insertions(+), 10 deletions(-)

--- a/drivers/staging/rtl8188eu/os_dep/ioctl_linux.c
+++ b/drivers/staging/rtl8188eu/os_dep/ioctl_linux.c
@@ -1396,19 +1396,13 @@ static int rtw_wx_get_essid(struct net_d
if ((check_fwstate(pmlmepriv, _FW_LINKED)) ||
(check_fwstate(pmlmepriv, WIFI_ADHOC_MASTER_STATE))) {
len = pcur_bss->Ssid.SsidLength;
-
- wrqu->essid.length = len;
-
memcpy(extra, pcur_bss->Ssid.Ssid, len);
-
- wrqu->essid.flags = 1;
} else {
- ret = -1;
- goto exit;
+ len = 0;
+ *extra = 0;
}
-
-exit:
-
+ wrqu->essid.length = len;
+ wrqu->essid.flags = 1;

return ret;
}



2018-02-05 18:43:28

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 3.18 19/36] net: ethernet: xilinx: Mark XILINX_LL_TEMAC broken on 64-bit

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

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

From: Geert Uytterhoeven <[email protected]>


[ Upstream commit 15bfe05c8d6386f1a90e9340d15336e85e32aad6 ]

On 64-bit (e.g. powerpc64/allmodconfig):

drivers/net/ethernet/xilinx/ll_temac_main.c: In function 'temac_start_xmit_done':
drivers/net/ethernet/xilinx/ll_temac_main.c:633:22: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
dev_kfree_skb_irq((struct sk_buff *)cur_p->app4);
^

cdmac_bd.app4 is u32, so it is too small to hold a kernel pointer.

Note that several other fields in struct cdmac_bd are also too small to
hold physical addresses on 64-bit platforms.

Signed-off-by: Geert Uytterhoeven <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/net/ethernet/xilinx/Kconfig | 1 +
1 file changed, 1 insertion(+)

--- a/drivers/net/ethernet/xilinx/Kconfig
+++ b/drivers/net/ethernet/xilinx/Kconfig
@@ -36,6 +36,7 @@ config XILINX_AXI_EMAC
config XILINX_LL_TEMAC
tristate "Xilinx LL TEMAC (LocalLink Tri-mode Ethernet MAC) driver"
depends on (PPC || MICROBLAZE)
+ depends on !64BIT || BROKEN
select PHYLIB
---help---
This driver supports the Xilinx 10/100/1000 LocalLink TEMAC



2018-02-05 18:43:28

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 3.18 23/36] usb: gadget: dont dereference g until after it has been null checked

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

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

From: Colin Ian King <[email protected]>


[ Upstream commit b2fc059fa549fe6881d4c1f8d698b0f50bcd16ec ]

Avoid dereferencing pointer g until after g has been sanity null checked;
move the assignment of cdev much later when it is required into a more
local scope.

Detected by CoverityScan, CID#1222135 ("Dereference before null check")

Fixes: b785ea7ce662 ("usb: gadget: composite: fix ep->maxburst initialization")
Signed-off-by: Colin Ian King <[email protected]>
Signed-off-by: Felipe Balbi <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/usb/gadget/composite.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)

--- a/drivers/usb/gadget/composite.c
+++ b/drivers/usb/gadget/composite.c
@@ -103,7 +103,6 @@ int config_ep_by_speed(struct usb_gadget
struct usb_function *f,
struct usb_ep *_ep)
{
- struct usb_composite_dev *cdev = get_gadget_data(g);
struct usb_endpoint_descriptor *chosen_desc = NULL;
struct usb_descriptor_header **speed_desc = NULL;

@@ -170,8 +169,12 @@ ep_found:
_ep->maxburst = comp_desc->bMaxBurst + 1;
break;
default:
- if (comp_desc->bMaxBurst != 0)
+ if (comp_desc->bMaxBurst != 0) {
+ struct usb_composite_dev *cdev;
+
+ cdev = get_gadget_data(g);
ERROR(cdev, "ep0 bMaxBurst must be 0\n");
+ }
_ep->maxburst = 1;
break;
}



2018-02-05 18:43:43

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 3.18 21/36] scsi: ufs: ufshcd: fix potential NULL pointer dereference in ufshcd_config_vreg

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

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

From: "Gustavo A. R. Silva" <[email protected]>


[ Upstream commit 727535903bea924c4f73abb202c4b3e85fff0ca4 ]

_vreg_ is being dereferenced before it is null checked, hence there is a
potential null pointer dereference.

Fix this by moving the pointer dereference after _vreg_ has been null
checked.

This issue was detected with the help of Coccinelle.

Fixes: aa4976130934 ("ufs: Add regulator enable support")
Signed-off-by: Gustavo A. R. Silva <[email protected]>
Reviewed-by: Subhash Jadavani <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/scsi/ufs/ufshcd.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)

--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -4287,12 +4287,15 @@ static int ufshcd_config_vreg(struct dev
struct ufs_vreg *vreg, bool on)
{
int ret = 0;
- struct regulator *reg = vreg->reg;
- const char *name = vreg->name;
+ struct regulator *reg;
+ const char *name;
int min_uV, uA_load;

BUG_ON(!vreg);

+ reg = vreg->reg;
+ name = vreg->name;
+
if (regulator_count_voltages(reg) > 0) {
min_uV = on ? vreg->min_uV : 0;
ret = regulator_set_voltage(reg, min_uV, vreg->max_uV);



2018-02-05 18:43:54

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 3.18 20/36] quota: Check for register_shrinker() failure.

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

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

From: Tetsuo Handa <[email protected]>


[ Upstream commit 88bc0ede8d35edc969350852894dc864a2dc1859 ]

register_shrinker() might return -ENOMEM error since Linux 3.12.
Call panic() as with other failure checks in this function if
register_shrinker() failed.

Fixes: 1d3d4437eae1 ("vmscan: per-node deferred work")
Signed-off-by: Tetsuo Handa <[email protected]>
Cc: Jan Kara <[email protected]>
Cc: Michal Hocko <[email protected]>
Reviewed-by: Michal Hocko <[email protected]>
Signed-off-by: Jan Kara <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
fs/quota/dquot.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)

--- a/fs/quota/dquot.c
+++ b/fs/quota/dquot.c
@@ -2730,7 +2730,8 @@ static int __init dquot_init(void)
printk("Dquot-cache hash table entries: %ld (order %ld, %ld bytes)\n",
nr_hash, order, (PAGE_SIZE << order));

- register_shrinker(&dqcache_shrinker);
+ if (register_shrinker(&dqcache_shrinker))
+ panic("Cannot register dquot shrinker");

return 0;
}



2018-02-05 18:44:24

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 3.18 16/36] nfsd: CLOSE SHOULD return the invalid special stateid for NFSv4.x (x>0)

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

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

From: Trond Myklebust <[email protected]>


[ Upstream commit fb500a7cfee7f2f447d2bbf30cb59629feab6ac1 ]

Signed-off-by: Trond Myklebust <[email protected]>
Signed-off-by: J. Bruce Fields <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
fs/nfsd/nfs4state.c | 8 ++++++++
1 file changed, 8 insertions(+)

--- a/fs/nfsd/nfs4state.c
+++ b/fs/nfsd/nfs4state.c
@@ -62,6 +62,9 @@ static const stateid_t zero_stateid = {
static const stateid_t currentstateid = {
.si_generation = 1,
};
+static const stateid_t close_stateid = {
+ .si_generation = 0xffffffffU,
+};

static u64 current_sessionid = 1;

@@ -4901,6 +4904,11 @@ nfsd4_close(struct svc_rqst *rqstp, stru

nfsd4_close_open_stateid(stp);

+ /* See RFC5661 sectionm 18.2.4 */
+ if (stp->st_stid.sc_client->cl_minorversion)
+ memcpy(&close->cl_stateid, &close_stateid,
+ sizeof(close->cl_stateid));
+
/* put reference from nfs4_preprocess_seqid_op */
nfs4_put_stid(&stp->st_stid);
out:



2018-02-05 18:44:28

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 3.18 02/36] um: link vmlinux with -no-pie

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

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

From: Thomas Meyer <[email protected]>

commit 883354afbc109c57f925ccc19840055193da0cc0 upstream.

Debian's gcc defaults to pie. The global Makefile already defines the -fno-pie option.
Link UML dynamic kernel image also with -no-pie to fix the build.

Signed-off-by: Thomas Meyer <[email protected]>
Signed-off-by: Richard Weinberger <[email protected]>
Cc: Bernie Innocenti <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
arch/um/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/arch/um/Makefile
+++ b/arch/um/Makefile
@@ -116,7 +116,7 @@ archheaders:
archprepare: include/generated/user_constants.h

LINK-$(CONFIG_LD_SCRIPT_STATIC) += -static
-LINK-$(CONFIG_LD_SCRIPT_DYN) += -Wl,-rpath,/lib
+LINK-$(CONFIG_LD_SCRIPT_DYN) += -Wl,-rpath,/lib $(call cc-option, -no-pie)

CFLAGS_NO_HARDENING := $(call cc-option, -fno-PIC,) $(call cc-option, -fno-pic,) \
$(call cc-option, -fno-stack-protector,) \



2018-02-05 18:45:03

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 3.18 18/36] hwmon: (pmbus) Use 64bit math for DIRECT format values

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

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

From: Robert Lippert <[email protected]>


[ Upstream commit bd467e4eababe4c04272c1e646f066db02734c79 ]

Power values in the 100s of watt range can easily blow past
32bit math limits when processing everything in microwatts.

Use 64bit math instead to avoid these issues on common 32bit ARM
BMC platforms.

Fixes: 442aba78728e ("hwmon: PMBus device driver")
Signed-off-by: Robert Lippert <[email protected]>
Signed-off-by: Guenter Roeck <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/hwmon/pmbus/pmbus_core.c | 21 ++++++++++++---------
1 file changed, 12 insertions(+), 9 deletions(-)

--- a/drivers/hwmon/pmbus/pmbus_core.c
+++ b/drivers/hwmon/pmbus/pmbus_core.c
@@ -20,6 +20,7 @@
*/

#include <linux/kernel.h>
+#include <linux/math64.h>
#include <linux/module.h>
#include <linux/init.h>
#include <linux/err.h>
@@ -443,8 +444,8 @@ static long pmbus_reg2data_linear(struct
static long pmbus_reg2data_direct(struct pmbus_data *data,
struct pmbus_sensor *sensor)
{
- long val = (s16) sensor->data;
- long m, b, R;
+ s64 b, val = (s16)sensor->data;
+ s32 m, R;

m = data->info->m[sensor->class];
b = data->info->b[sensor->class];
@@ -472,11 +473,12 @@ static long pmbus_reg2data_direct(struct
R--;
}
while (R < 0) {
- val = DIV_ROUND_CLOSEST(val, 10);
+ val = div_s64(val + 5LL, 10L); /* round closest */
R++;
}

- return (val - b) / m;
+ val = div_s64(val - b, m);
+ return clamp_val(val, LONG_MIN, LONG_MAX);
}

/*
@@ -588,7 +590,8 @@ static u16 pmbus_data2reg_linear(struct
static u16 pmbus_data2reg_direct(struct pmbus_data *data,
struct pmbus_sensor *sensor, long val)
{
- long m, b, R;
+ s64 b, val64 = val;
+ s32 m, R;

m = data->info->m[sensor->class];
b = data->info->b[sensor->class];
@@ -605,18 +608,18 @@ static u16 pmbus_data2reg_direct(struct
R -= 3; /* Adjust R and b for data in milli-units */
b *= 1000;
}
- val = val * m + b;
+ val64 = val64 * m + b;

while (R > 0) {
- val *= 10;
+ val64 *= 10;
R--;
}
while (R < 0) {
- val = DIV_ROUND_CLOSEST(val, 10);
+ val64 = div_s64(val64 + 5LL, 10L); /* round closest */
R++;
}

- return val;
+ return (u16)clamp_val(val64, S16_MIN, S16_MAX);
}

static u16 pmbus_data2reg_vid(struct pmbus_data *data,



2018-02-05 18:45:09

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 3.18 15/36] xen-netfront: remove warning when unloading module

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

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

From: Eduardo Otubo <[email protected]>


[ Upstream commit 5b5971df3bc2775107ddad164018a8a8db633b81 ]

v2:
* Replace busy wait with wait_event()/wake_up_all()
* Cannot garantee that at the time xennet_remove is called, the
xen_netback state will not be XenbusStateClosed, so added a
condition for that
* There's a small chance for the xen_netback state is
XenbusStateUnknown by the time the xen_netfront switches to Closed,
so added a condition for that.

When unloading module xen_netfront from guest, dmesg would output
warning messages like below:

[ 105.236836] xen:grant_table: WARNING: g.e. 0x903 still in use!
[ 105.236839] deferring g.e. 0x903 (pfn 0x35805)

This problem relies on netfront and netback being out of sync. By the time
netfront revokes the g.e.'s netback didn't have enough time to free all of
them, hence displaying the warnings on dmesg.

The trick here is to make netfront to wait until netback frees all the g.e.'s
and only then continue to cleanup for the module removal, and this is done by
manipulating both device states.

Signed-off-by: Eduardo Otubo <[email protected]>
Acked-by: Juergen Gross <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/net/xen-netfront.c | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)

--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -85,6 +85,8 @@ struct netfront_cb {
/* IRQ name is queue name with "-tx" or "-rx" appended */
#define IRQ_NAME_SIZE (QUEUE_NAME_SIZE + 3)

+static DECLARE_WAIT_QUEUE_HEAD(module_unload_q);
+
struct netfront_stats {
u64 rx_packets;
u64 tx_packets;
@@ -2080,10 +2082,12 @@ static void netback_changed(struct xenbu
break;

case XenbusStateClosed:
+ wake_up_all(&module_unload_q);
if (dev->state == XenbusStateClosed)
break;
/* Missed the backend's CLOSING state -- fallthrough */
case XenbusStateClosing:
+ wake_up_all(&module_unload_q);
xenbus_frontend_closed(dev);
break;
}
@@ -2305,6 +2309,20 @@ static int xennet_remove(struct xenbus_d

dev_dbg(&dev->dev, "%s\n", dev->nodename);

+ if (xenbus_read_driver_state(dev->otherend) != XenbusStateClosed) {
+ xenbus_switch_state(dev, XenbusStateClosing);
+ wait_event(module_unload_q,
+ xenbus_read_driver_state(dev->otherend) ==
+ XenbusStateClosing);
+
+ xenbus_switch_state(dev, XenbusStateClosed);
+ wait_event(module_unload_q,
+ xenbus_read_driver_state(dev->otherend) ==
+ XenbusStateClosed ||
+ xenbus_read_driver_state(dev->otherend) ==
+ XenbusStateUnknown);
+ }
+
xennet_disconnect_backend(info);

xennet_sysfs_delif(info->netdev);



2018-02-05 18:45:52

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 3.18 13/36] mac80211: fix the update of path metric for RANN frame

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

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

From: Chun-Yeow Yeoh <[email protected]>


[ Upstream commit fbbdad5edf0bb59786a51b94a9d006bc8c2da9a2 ]

The previous path metric update from RANN frame has not considered
the own link metric toward the transmitting mesh STA. Fix this.

Reported-by: Michael65535
Signed-off-by: Chun-Yeow Yeoh <[email protected]>
Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
net/mac80211/mesh_hwmp.c | 15 +++++++++------
1 file changed, 9 insertions(+), 6 deletions(-)

--- a/net/mac80211/mesh_hwmp.c
+++ b/net/mac80211/mesh_hwmp.c
@@ -763,7 +763,7 @@ static void hwmp_rann_frame_process(stru
struct mesh_path *mpath;
u8 ttl, flags, hopcount;
const u8 *orig_addr;
- u32 orig_sn, metric, metric_txsta, interval;
+ u32 orig_sn, new_metric, orig_metric, last_hop_metric, interval;
bool root_is_gate;

ttl = rann->rann_ttl;
@@ -774,7 +774,7 @@ static void hwmp_rann_frame_process(stru
interval = le32_to_cpu(rann->rann_interval);
hopcount = rann->rann_hopcount;
hopcount++;
- metric = le32_to_cpu(rann->rann_metric);
+ orig_metric = le32_to_cpu(rann->rann_metric);

/* Ignore our own RANNs */
if (ether_addr_equal(orig_addr, sdata->vif.addr))
@@ -791,7 +791,10 @@ static void hwmp_rann_frame_process(stru
return;
}

- metric_txsta = airtime_link_metric_get(local, sta);
+ last_hop_metric = airtime_link_metric_get(local, sta);
+ new_metric = orig_metric + last_hop_metric;
+ if (new_metric < orig_metric)
+ new_metric = MAX_METRIC;

mpath = mesh_path_lookup(sdata, orig_addr);
if (!mpath) {
@@ -804,7 +807,7 @@ static void hwmp_rann_frame_process(stru
}

if (!(SN_LT(mpath->sn, orig_sn)) &&
- !(mpath->sn == orig_sn && metric < mpath->rann_metric)) {
+ !(mpath->sn == orig_sn && new_metric < mpath->rann_metric)) {
rcu_read_unlock();
return;
}
@@ -822,7 +825,7 @@ static void hwmp_rann_frame_process(stru
}

mpath->sn = orig_sn;
- mpath->rann_metric = metric + metric_txsta;
+ mpath->rann_metric = new_metric;
mpath->is_root = true;
/* Recording RANNs sender address to send individually
* addressed PREQs destined for root mesh STA */
@@ -842,7 +845,7 @@ static void hwmp_rann_frame_process(stru
mesh_path_sel_frame_tx(MPATH_RANN, flags, orig_addr,
orig_sn, 0, NULL, 0, broadcast_addr,
hopcount, ttl, interval,
- metric + metric_txsta, 0, sdata);
+ new_metric, 0, sdata);
}

rcu_read_unlock();



2018-02-05 18:46:05

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 3.18 01/36] Input: do not emit unneeded EV_SYN when suspending

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

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

From: Dmitry Torokhov <[email protected]>

commit 00159f19a5057cb779146afce1cceede692af346 upstream.

Do not emit EV_SYN/SYN_REPORT on suspend if there were no keys that are
still pressed as we are suspending the device (and in all other cases when
input core is forcibly releasing keys via input_dev_release_keys() call).

Reviewed-by: Benson Leung <[email protected]>
Signed-off-by: Dmitry Torokhov <[email protected]>
Signed-off-by: Bo Hu <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

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

--- a/drivers/input/input.c
+++ b/drivers/input/input.c
@@ -668,6 +668,7 @@ EXPORT_SYMBOL(input_close_device);
*/
static void input_dev_release_keys(struct input_dev *dev)
{
+ bool need_sync = false;
int code;

if (is_event_supported(EV_KEY, dev->evbit, EV_MAX)) {
@@ -675,9 +676,11 @@ static void input_dev_release_keys(struc
if (is_event_supported(code, dev->keybit, KEY_MAX) &&
__test_and_clear_bit(code, dev->key)) {
input_pass_event(dev, EV_KEY, code, 0);
+ need_sync = true;
}
}
- input_pass_event(dev, EV_SYN, SYN_REPORT, 1);
+ if (need_sync)
+ input_pass_event(dev, EV_SYN, SYN_REPORT, 1);
}
}




2018-02-05 18:46:25

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 3.18 17/36] nfsd: check for use of the closed special stateid

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

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

From: Andrew Elble <[email protected]>


[ Upstream commit ae254dac721d44c0bfebe2795df87459e2e88219 ]

Prevent the use of the closed (invalid) special stateid by clients.

Signed-off-by: Andrew Elble <[email protected]>
Signed-off-by: J. Bruce Fields <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
fs/nfsd/nfs4state.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)

--- a/fs/nfsd/nfs4state.c
+++ b/fs/nfsd/nfs4state.c
@@ -71,6 +71,7 @@ static u64 current_sessionid = 1;
#define ZERO_STATEID(stateid) (!memcmp((stateid), &zero_stateid, sizeof(stateid_t)))
#define ONE_STATEID(stateid) (!memcmp((stateid), &one_stateid, sizeof(stateid_t)))
#define CURRENT_STATEID(stateid) (!memcmp((stateid), &currentstateid, sizeof(stateid_t)))
+#define CLOSE_STATEID(stateid) (!memcmp((stateid), &close_stateid, sizeof(stateid_t)))

/* forward declarations */
static bool check_for_locks(struct nfs4_file *fp, struct nfs4_lockowner *lowner);
@@ -4414,7 +4415,8 @@ static __be32 nfsd4_validate_stateid(str
struct nfs4_stid *s;
__be32 status = nfserr_bad_stateid;

- if (ZERO_STATEID(stateid) || ONE_STATEID(stateid))
+ if (ZERO_STATEID(stateid) || ONE_STATEID(stateid) ||
+ CLOSE_STATEID(stateid))
return status;
/* Client debugging aid. */
if (!same_clid(&stateid->si_opaque.so_clid, &cl->cl_clientid)) {
@@ -4472,7 +4474,8 @@ nfsd4_lookup_stateid(struct nfsd4_compou
else if (typemask & NFS4_DELEG_STID)
typemask |= NFS4_REVOKED_DELEG_STID;

- if (ZERO_STATEID(stateid) || ONE_STATEID(stateid))
+ if (ZERO_STATEID(stateid) || ONE_STATEID(stateid) ||
+ CLOSE_STATEID(stateid))
return nfserr_bad_stateid;
status = lookup_clientid(&stateid->si_opaque.so_clid, cstate, nn);
if (status == nfserr_stale_clientid) {



2018-02-05 21:36:40

by Guenter Roeck

[permalink] [raw]
Subject: Re: [PATCH 3.18 00/36] 3.18.94-stable review

On Mon, Feb 05, 2018 at 10:23:28AM -0800, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 3.18.94 release.
> There are 36 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 Wed Feb 7 18:23:41 UTC 2018.
> Anything received after that time might be too late.
>

You'll also need upstream commit 0b5aedfe0e66 ("um: Fix out-of-tree build") to
fix out-of-tree builds for um.

Guenter

2018-02-05 22:17:19

by Shuah Khan

[permalink] [raw]
Subject: Re: [PATCH 3.18 00/36] 3.18.94-stable review

On 02/05/2018 11:23 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 3.18.94 release.
> There are 36 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 Wed Feb 7 18:23:41 UTC 2018.
> 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/v3.x/stable-review/patch-3.18.94-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-3.18.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>

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

thanks,
-- Shuah


2018-02-06 10:29:24

by Greg Kroah-Hartman

[permalink] [raw]
Subject: Re: [PATCH 3.18 00/36] 3.18.94-stable review

On Mon, Feb 05, 2018 at 01:35:44PM -0800, Guenter Roeck wrote:
> On Mon, Feb 05, 2018 at 10:23:28AM -0800, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 3.18.94 release.
> > There are 36 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 Wed Feb 7 18:23:41 UTC 2018.
> > Anything received after that time might be too late.
> >
>
> You'll also need upstream commit 0b5aedfe0e66 ("um: Fix out-of-tree build") to
> fix out-of-tree builds for um.

Ah crap, I knew there was a reason I didn't do a 3.18.y release last
cycle, and it was because I needed to fix up the um build :(

I'll go queue up this patch now, thanks for letting me know.

greg k-h

2018-02-06 10:35:12

by Greg Kroah-Hartman

[permalink] [raw]
Subject: Re: [PATCH 3.18 00/36] 3.18.94-stable review

On Tue, Feb 06, 2018 at 06:48:53AM +0000, Harsh Shandilya wrote:
> On Tue 6 Feb, 2018, 12:09 AM Greg Kroah-Hartman, <[email protected]>
> wrote:
>
> > This is the start of the stable review cycle for the 3.18.94 release.
> > There are 36 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 Wed Feb 7 18:23:41 UTC 2018.
> > 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/v3.x/stable-review/patch-3.18.94-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-3.18.y
> > and the diffstat can be found below.
> >
> > thanks,
> >
> > greg k-h
> >
>
> Builds and boots on the OnePlus 3T, no regressions noticed.

Yeah! That device is the only reason I keep this tree alive :)

thanks for testing and letting me know.

greg k-h

2018-02-06 13:14:54

by Greg Kroah-Hartman

[permalink] [raw]
Subject: Re: [PATCH 3.18 00/36] 3.18.94-stable review

On Tue, Feb 06, 2018 at 11:42:15AM +0000, Harsh Shandilya wrote:
> On Tue 6 Feb, 2018, 4:04 PM Greg Kroah-Hartman, <[email protected]>
> wrote:
>
> > On Tue, Feb 06, 2018 at 06:48:53AM +0000, Harsh Shandilya wrote:
> > > On Tue 6 Feb, 2018, 12:09 AM Greg Kroah-Hartman, <
> > [email protected]>
> > > wrote:
> > >
> > > > This is the start of the stable review cycle for the 3.18.94 release.
> > > > There are 36 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 Wed Feb 7 18:23:41 UTC 2018.
> > > > 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/v3.x/stable-review/patch-3.18.94-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-3.18.y
> > > > and the diffstat can be found below.
> > > >
> > > > thanks,
> > > >
> > > > greg k-h
> > > >
> > >
> > > Builds and boots on the OnePlus 3T, no regressions noticed.
> >
> > Yeah! That device is the only reason I keep this tree alive :)
> >
> > thanks for testing and letting me know.
> >
> > greg k-h
> >
>
> Guess I should drop my kernel tree for the device and save you the pain of
> maintaining 3.18 :P

Heh, maybe :)

> Atleast CAF has been keeping up with upstream now thanks to your
> kernel-common merges so there's still hope for MSM platform users :)

That's good to see. Now if only those platform users would actually
update their kernels to these new versions :(

> P.S. common merge should go in cleanly, both the merge conflicts I had were
> from CAF changes.

Thanks for letting me know, that's great to hear as I just had a
question from some companies who are worried that taking stable patches
will cause tons of merge issues. It hasn't in my experience, and seeing
reports of this from others is great news.

thanks,

greg k-h

2018-02-06 14:31:38

by Guenter Roeck

[permalink] [raw]
Subject: Re: [PATCH 3.18 00/36] 3.18.94-stable review

On 02/05/2018 10:23 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 3.18.94 release.
> There are 36 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 Wed Feb 7 18:23:41 UTC 2018.
> Anything received after that time might be too late.
>

For v3.18.93-38-g9193bae:

Build results:
total: 136 pass: 136 fail: 0
Qemu test results:
total: 112 pass: 112 fail: 0

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

Guenter

2018-02-06 14:49:40

by Guenter Roeck

[permalink] [raw]
Subject: Re: [PATCH 3.18 00/36] 3.18.94-stable review

On 02/06/2018 05:14 AM, Greg Kroah-Hartman wrote:
> On Tue, Feb 06, 2018 at 11:42:15AM +0000, Harsh Shandilya wrote:
>> On Tue 6 Feb, 2018, 4:04 PM Greg Kroah-Hartman, <[email protected]>
>> wrote:
>>
>>> On Tue, Feb 06, 2018 at 06:48:53AM +0000, Harsh Shandilya wrote:
>>>> On Tue 6 Feb, 2018, 12:09 AM Greg Kroah-Hartman, <
>>> [email protected]>
>>>> wrote:
>>>>
>>>>> This is the start of the stable review cycle for the 3.18.94 release.
>>>>> There are 36 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 Wed Feb 7 18:23:41 UTC 2018.
>>>>> 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/v3.x/stable-review/patch-3.18.94-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-3.18.y
>>>>> and the diffstat can be found below.
>>>>>
>>>>> thanks,
>>>>>
>>>>> greg k-h
>>>>>
>>>>
>>>> Builds and boots on the OnePlus 3T, no regressions noticed.
>>>
>>> Yeah! That device is the only reason I keep this tree alive :)
>>>
>>> thanks for testing and letting me know.
>>>
>>> greg k-h
>>>
>>
>> Guess I should drop my kernel tree for the device and save you the pain of
>> maintaining 3.18 :P
>
> Heh, maybe :)
>
>> Atleast CAF has been keeping up with upstream now thanks to your
>> kernel-common merges so there's still hope for MSM platform users :)
>
> That's good to see. Now if only those platform users would actually
> update their kernels to these new versions :(
>
>> P.S. common merge should go in cleanly, both the merge conflicts I had were
>> from CAF changes.
>
> Thanks for letting me know, that's great to hear as I just had a
> question from some companies who are worried that taking stable patches
> will cause tons of merge issues. It hasn't in my experience, and seeing
> reports of this from others is great news.
>

From merging v4.4 and v4.14 into the respective ChromeOS branches, I would conclude
that merging is for the most part easy. Major source of conflicts, if they happen,
is that we may already have picked up additional commits from upstream.

This is only true, though, if merges are done on a release-by-release basis
and if the merge happens shortly after a stable release is available. Otherwise,
as time goes by, merges become more and more difficult (almost exponentially
over time). Wait for more than 2-3 months between merges and it becomes almost
impossible.

For reference, the top of tree for both branches is
v4.14.16-3823-g597d36f1d331
v4.4.114-12977-ga207b53fe939
meaning there are _lots_ of patches on top of the mainline stable releases.

Also, overall, the rate of regressions is quite low (if I recall correctly,
somewhere between 3 and 5 in chromeos-4.4, and one so far in chromeos-4.14,
ie below 0.1%).

Guenter

2018-02-06 17:01:56

by Greg Kroah-Hartman

[permalink] [raw]
Subject: Re: [PATCH 3.18 00/36] 3.18.94-stable review

On Tue, Feb 06, 2018 at 06:29:16AM -0800, Guenter Roeck wrote:
> On 02/05/2018 10:23 AM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 3.18.94 release.
> > There are 36 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 Wed Feb 7 18:23:41 UTC 2018.
> > Anything received after that time might be too late.
> >
>
> For v3.18.93-38-g9193bae:
>
> Build results:
> total: 136 pass: 136 fail: 0
> Qemu test results:
> total: 112 pass: 112 fail: 0
>
> Details are available at http://kerneltests.org/builders.

Yeah, it's fixed! :)

thanks for testing all of these and letting me know.

greg k-h

2018-02-07 14:39:11

by Greg Kroah-Hartman

[permalink] [raw]
Subject: Re: [PATCH 3.18 00/36] 3.18.94-stable review

On Tue, Feb 06, 2018 at 06:48:17AM -0800, Guenter Roeck wrote:
> On 02/06/2018 05:14 AM, Greg Kroah-Hartman wrote:
> > Thanks for letting me know, that's great to hear as I just had a
> > question from some companies who are worried that taking stable patches
> > will cause tons of merge issues. It hasn't in my experience, and seeing
> > reports of this from others is great news.
> >
>
> From merging v4.4 and v4.14 into the respective ChromeOS branches, I would conclude
> that merging is for the most part easy. Major source of conflicts, if they happen,
> is that we may already have picked up additional commits from upstream.
>
> This is only true, though, if merges are done on a release-by-release basis
> and if the merge happens shortly after a stable release is available. Otherwise,
> as time goes by, merges become more and more difficult (almost exponentially
> over time). Wait for more than 2-3 months between merges and it becomes almost
> impossible.
>
> For reference, the top of tree for both branches is
> v4.14.16-3823-g597d36f1d331
> v4.4.114-12977-ga207b53fe939

Ugh, 12k patches is not trivial, gotta love those graphic drivers :(

> meaning there are _lots_ of patches on top of the mainline stable releases.
>
> Also, overall, the rate of regressions is quite low (if I recall correctly,
> somewhere between 3 and 5 in chromeos-4.4, and one so far in chromeos-4.14,
> ie below 0.1%).

Thanks a lot for the feedback, this helps out a lot when talking to
companies that are "afraid" of doing merges with stable.

Based on this, one phone vendor just forward merged their 4.4.y based
tree to the latest release in a few hours with no reported problems at
all, so it has already helped out with tangable results.

thanks,

greg k-h

2018-02-07 16:56:43

by Guenter Roeck

[permalink] [raw]
Subject: Re: [PATCH 3.18 00/36] 3.18.94-stable review

On Wed, Feb 07, 2018 at 06:37:06AM -0800, Greg Kroah-Hartman wrote:
> On Tue, Feb 06, 2018 at 06:48:17AM -0800, Guenter Roeck wrote:
> > On 02/06/2018 05:14 AM, Greg Kroah-Hartman wrote:
> > > Thanks for letting me know, that's great to hear as I just had a
> > > question from some companies who are worried that taking stable patches
> > > will cause tons of merge issues. It hasn't in my experience, and seeing
> > > reports of this from others is great news.
> > >
> >
> > From merging v4.4 and v4.14 into the respective ChromeOS branches, I would conclude
> > that merging is for the most part easy. Major source of conflicts, if they happen,
> > is that we may already have picked up additional commits from upstream.
> >
> > This is only true, though, if merges are done on a release-by-release basis
> > and if the merge happens shortly after a stable release is available. Otherwise,
> > as time goes by, merges become more and more difficult (almost exponentially
> > over time). Wait for more than 2-3 months between merges and it becomes almost
> > impossible.
> >
> > For reference, the top of tree for both branches is
> > v4.14.16-3823-g597d36f1d331
> > v4.4.114-12977-ga207b53fe939
>
> Ugh, 12k patches is not trivial, gotta love those graphic drivers :(
>
That, plus a gazillion backports, plus vendor specific out-of-tree wireless
drivers, plus all the Android stuff. No, there is no "love" involved, only
annoyance :-(.

> > meaning there are _lots_ of patches on top of the mainline stable releases.
> >
> > Also, overall, the rate of regressions is quite low (if I recall correctly,
> > somewhere between 3 and 5 in chromeos-4.4, and one so far in chromeos-4.14,
> > ie below 0.1%).
>
> Thanks a lot for the feedback, this helps out a lot when talking to
> companies that are "afraid" of doing merges with stable.
>
> Based on this, one phone vendor just forward merged their 4.4.y based
> tree to the latest release in a few hours with no reported problems at
> all, so it has already helped out with tangable results.
>
Excellent. More test coverage!

Guenter

2018-02-07 23:19:38

by Greg Kroah-Hartman

[permalink] [raw]
Subject: Re: [PATCH 3.18 00/36] 3.18.94-stable review

On Wed, Feb 07, 2018 at 03:19:07PM +0000, Harsh Shandilya wrote:
> On Tue 6 Feb, 2018, 12:09 AM Greg Kroah-Hartman, <[email protected]>
> wrote:
>
> > This is the start of the stable review cycle for the 3.18.94 release.
> > There are 36 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 Wed Feb 7 18:23:41 UTC 2018.
> > Anything received after that time might be too late.
> >
>
> Let's find out if I am too late.
>
> https://www.spinics.net/lists/stable/msg213160.html will have to be lined
> up for 3.18.94, or to .95 if I'm late since it's fixing a erroneous
> backport from 3.18.93 which went unnoticed until after release. The email
> bringing it up and the subsequent patch were probably lost in the usual
> stable noise. I have applied it to the CAF tree for the oneplus3 and
> verified that it does not break compilation or userspace for arm64.

It will be queued up for the next release, I missed it this time, sorry.

greg k-h