This is the start of the stable review cycle for the 4.14.1 release. There are 31 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 Tue Nov 21 14:59:32 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.14.1-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.14.y and the diffstat can be found below.
thanks,
greg k-h
------------- Pseudo-Shortlog of commits:
Greg Kroah-Hartman gregkh@linuxfoundation.org Linux 4.14.1-rc1
Johan Hovold johan@kernel.org spi: fix use-after-free at controller deregistration
Hans de Goede hdegoede@redhat.com staging: rtl8188eu: Revert 4 commits breaking ARP
Hans de Goede hdegoede@redhat.com staging: vboxvideo: Fix reporting invalid suggested-offset-properties
Johan Hovold johan@kernel.org staging: greybus: spilib: fix use-after-free after deregistration
Gilad Ben-Yossef gilad@benyossef.com staging: ccree: fix 64 bit scatter/gather DMA ops
Huacai Chen chenhc@lemote.com staging: sm750fb: Fix parameter mistake in poke32
Aditya Shankar aditya.shankar@microchip.com staging: wilc1000: Fix bssid buffer offset in Txq
Bjorn Andersson bjorn.andersson@linaro.org rpmsg: glink: Add missing MODULE_LICENSE
Jason Gerecke killertofu@gmail.com HID: wacom: generic: Recognize WACOM_HID_WD_PEN as a type of pen collection
Sébastien Szymanski sebastien.szymanski@armadeus.com HID: cp2112: add HIDRAW dependency
Hans de Goede hdegoede@redhat.com platform/x86: peaq_wmi: Fix missing terminating entry for peaq_dmi_table
Hans de Goede hdegoede@redhat.com platform/x86: peaq-wmi: Add DMI check before binding to the WMI interface
Yazen Ghannam yazen.ghannam@amd.com x86/MCE/AMD: Always give panic severity for UC errors in kernel context
Andy Lutomirski luto@kernel.org selftests/x86/protection_keys: Fix syscall NR redefinition warnings
Johan Hovold johan@kernel.org USB: serial: garmin_gps: fix memory leak on probe errors
Johan Hovold johan@kernel.org USB: serial: garmin_gps: fix I/O after failed probe and remove
Douglas Fischer douglas.fischer@outlook.com USB: serial: qcserial: add pid/vid for Sierra Wireless EM7355 fw update
Lu Baolu baolu.lu@linux.intel.com USB: serial: Change DbC debug device binding ID
Johan Hovold johan@kernel.org USB: serial: metro-usb: stop I/O after failed open
Andrew Gabbasov andrew_gabbasov@mentor.com usb: gadget: f_fs: Fix use-after-free in ffs_free_inst
Bernhard Rosenkraenzer bernhard.rosenkranzer@linaro.org USB: Add delay-init quirk for Corsair K70 LUX keyboards
Alan Stern stern@rowland.harvard.edu USB: usbfs: compute urb->actual_length for isochronous
Lu Baolu baolu.lu@linux.intel.com USB: early: Use new USB product ID and strings for DbC device
raveendra padasalagi raveendra.padasalagi@broadcom.com crypto: brcm - Explicity ACK mailbox message
Eric Biggers ebiggers@google.com crypto: dh - Don't permit 'key' or 'g' size longer than 'p'
Eric Biggers ebiggers@google.com crypto: dh - Don't permit 'p' to be 0
Eric Biggers ebiggers@google.com crypto: dh - Fix double free of ctx->p
Andrey Konovalov andreyknvl@google.com media: dib0700: fix invalid dvb_detach argument
Arvind Yadav arvind.yadav.cs@gmail.com media: imon: Fix null-ptr-deref in imon_probe
Adam Wallis awallis@codeaurora.org dmaengine: dmatest: warn user when dma test times out
Qiuxu Zhuo qiuxu.zhuo@intel.com EDAC, sb_edac: Don't create a second memory controller if HA1 is not present
-------------
Diffstat:
Makefile | 4 +- arch/x86/kernel/cpu/mcheck/mce-severity.c | 7 +- crypto/dh.c | 33 ++++----- crypto/dh_helper.c | 16 ++++ drivers/crypto/bcm/cipher.c | 101 ++++++++++++-------------- drivers/dma/dmatest.c | 1 + drivers/edac/sb_edac.c | 9 ++- drivers/hid/Kconfig | 2 +- drivers/hid/wacom_wac.h | 1 + drivers/media/rc/imon.c | 5 ++ drivers/media/usb/dvb-usb/dib0700_devices.c | 24 +++--- drivers/platform/x86/peaq-wmi.c | 19 +++++ drivers/rpmsg/qcom_glink_native.c | 3 + drivers/spi/spi.c | 5 +- drivers/staging/ccree/cc_lli_defs.h | 2 +- drivers/staging/greybus/spilib.c | 8 +- drivers/staging/rtl8188eu/core/rtw_recv.c | 83 ++++++++++++--------- drivers/staging/rtl8188eu/os_dep/mon.c | 34 ++------- drivers/staging/sm750fb/ddk750_chip.h | 2 +- drivers/staging/vboxvideo/vbox_drv.h | 8 +- drivers/staging/vboxvideo/vbox_irq.c | 4 +- drivers/staging/vboxvideo/vbox_mode.c | 26 +++++-- drivers/staging/wilc1000/wilc_wlan.c | 2 +- drivers/usb/core/devio.c | 14 ++++ drivers/usb/core/quirks.c | 3 + drivers/usb/early/xhci-dbc.h | 6 +- drivers/usb/gadget/function/f_fs.c | 1 + drivers/usb/serial/garmin_gps.c | 22 +++++- drivers/usb/serial/metro-usb.c | 11 ++- drivers/usb/serial/qcserial.c | 1 + drivers/usb/serial/usb_debug.c | 4 +- tools/testing/selftests/x86/protection_keys.c | 24 ++++-- 32 files changed, 289 insertions(+), 196 deletions(-)
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Qiuxu Zhuo qiuxu.zhuo@intel.com
commit 15cc3ae001873845b5d842e212478a6570c7d938 upstream.
Yi Zhang reported the following failure on a 2-socket Haswell (E5-2603v3) server (DELL PowerEdge 730xd):
EDAC sbridge: Some needed devices are missing EDAC MC: Removed device 0 for sb_edac.c Haswell SrcID#0_Ha#0: DEV 0000:7f:12.0 EDAC MC: Removed device 1 for sb_edac.c Haswell SrcID#1_Ha#0: DEV 0000:ff:12.0 EDAC sbridge: Couldn't find mci handler EDAC sbridge: Couldn't find mci handler EDAC sbridge: Failed to register device with error -19.
The refactored sb_edac driver creates the IMC1 (the 2nd memory controller) if any IMC1 device is present. In this case only HA1_TA of IMC1 was present, but the driver expected to find HA1/HA1_TM/HA1_TAD[0-3] devices too, leading to the above failure.
The document [1] says the 'E5-2603 v3' CPU has 4 memory channels max. Yi Zhang inserted one DIMM per channel for each CPU, and did random error address injection test with this patch:
4024 addresses fell in TOLM hole area 12715 addresses fell in CPU_SrcID#0_Ha#0_Chan#0_DIMM#0 12774 addresses fell in CPU_SrcID#0_Ha#0_Chan#1_DIMM#0 12798 addresses fell in CPU_SrcID#0_Ha#0_Chan#2_DIMM#0 12913 addresses fell in CPU_SrcID#0_Ha#0_Chan#3_DIMM#0 12674 addresses fell in CPU_SrcID#1_Ha#0_Chan#0_DIMM#0 12686 addresses fell in CPU_SrcID#1_Ha#0_Chan#1_DIMM#0 12882 addresses fell in CPU_SrcID#1_Ha#0_Chan#2_DIMM#0 12934 addresses fell in CPU_SrcID#1_Ha#0_Chan#3_DIMM#0 106400 addresses were injected totally.
The test result shows that all the 4 channels belong to IMC0 per CPU, so the server really only has one IMC per CPU.
In the 1st page of chapter 2 in datasheet [2], it also says 'E5-2600 v3' implements either one or two IMCs. For CPUs with one IMC, IMC1 is not used and should be ignored.
Thus, do not create a second memory controller if the key HA1 is absent.
[1] http://ark.intel.com/products/83349/Intel-Xeon-Processor-E5-2603-v3-15M-Cach... [2] https://www.intel.com/content/dam/www/public/us/en/documents/datasheets/xeon...
Reported-and-tested-by: Yi Zhang yizhan@redhat.com Signed-off-by: Qiuxu Zhuo qiuxu.zhuo@intel.com Cc: Tony Luck tony.luck@intel.com Cc: linux-edac linux-edac@vger.kernel.org Link: http://lkml.kernel.org/r/20170913104214.7325-1-qiuxu.zhuo@intel.com [ Massage commit message. ] Signed-off-by: Borislav Petkov bp@suse.de Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org
--- drivers/edac/sb_edac.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-)
--- a/drivers/edac/sb_edac.c +++ b/drivers/edac/sb_edac.c @@ -462,6 +462,7 @@ static const struct pci_id_table pci_dev static const struct pci_id_descr pci_dev_descr_ibridge[] = { /* Processor Home Agent */ { PCI_DESCR(PCI_DEVICE_ID_INTEL_IBRIDGE_IMC_HA0, 0, IMC0) }, + { PCI_DESCR(PCI_DEVICE_ID_INTEL_IBRIDGE_IMC_HA1, 1, IMC1) },
/* Memory controller */ { PCI_DESCR(PCI_DEVICE_ID_INTEL_IBRIDGE_IMC_HA0_TA, 0, IMC0) }, @@ -472,7 +473,6 @@ static const struct pci_id_descr pci_dev { PCI_DESCR(PCI_DEVICE_ID_INTEL_IBRIDGE_IMC_HA0_TAD3, 0, IMC0) },
/* Optional, mode 2HA */ - { PCI_DESCR(PCI_DEVICE_ID_INTEL_IBRIDGE_IMC_HA1, 1, IMC1) }, { PCI_DESCR(PCI_DEVICE_ID_INTEL_IBRIDGE_IMC_HA1_TA, 1, IMC1) }, { PCI_DESCR(PCI_DEVICE_ID_INTEL_IBRIDGE_IMC_HA1_RAS, 1, IMC1) }, { PCI_DESCR(PCI_DEVICE_ID_INTEL_IBRIDGE_IMC_HA1_TAD0, 1, IMC1) }, @@ -2291,6 +2291,13 @@ static int sbridge_get_onedevice(struct next_imc: sbridge_dev = get_sbridge_dev(bus, dev_descr->dom, multi_bus, sbridge_dev); if (!sbridge_dev) { + /* If the HA1 wasn't found, don't create EDAC second memory controller */ + if (dev_descr->dom == IMC1 && devno != 1) { + edac_dbg(0, "Skip IMC1: %04x:%04x (since HA1 was absent)\n", + PCI_VENDOR_ID_INTEL, dev_descr->dev_id); + pci_dev_put(pdev); + return 0; + }
if (dev_descr->dom == SOCK) goto out_imc;
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Adam Wallis awallis@codeaurora.org
commit a9df21e34b422f79d9a9fa5c3eff8c2a53491be6 upstream.
Commit adfa543e7314 ("dmatest: don't use set_freezable_with_signal()") introduced a bug (that is in fact documented by the patch commit text) that leaves behind a dangling pointer. Since the done_wait structure is allocated on the stack, future invocations to the DMATEST can produce undesirable results (e.g., corrupted spinlocks). Ideally, this would be cleaned up in the thread handler, but at the very least, the kernel is left in a very precarious scenario that can lead to some long debug sessions when the crash comes later.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=197605 Signed-off-by: Adam Wallis awallis@codeaurora.org Signed-off-by: Vinod Koul vinod.koul@intel.com Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org
--- drivers/dma/dmatest.c | 1 + 1 file changed, 1 insertion(+)
--- a/drivers/dma/dmatest.c +++ b/drivers/dma/dmatest.c @@ -702,6 +702,7 @@ static int dmatest_func(void *data) * free it this time?" dancing. For now, just * leave it dangling. */ + WARN(1, "dmatest: Kernel stack may be corrupted!!\n"); dmaengine_unmap_put(um); result("test timed out", total_tests, src_off, dst_off, len, 0);
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Arvind Yadav arvind.yadav.cs@gmail.com
commit 58fd55e838276a0c13d1dc7c387f90f25063cbf3 upstream.
It seems that the return value of usb_ifnum_to_if() can be NULL and needs to be checked.
Signed-off-by: Arvind Yadav arvind.yadav.cs@gmail.com Tested-by: Andrey Konovalov andreyknvl@google.com Signed-off-by: Sean Young sean@mess.org Signed-off-by: Mauro Carvalho Chehab mchehab@osg.samsung.com Cc: Ben Hutchings ben.hutchings@codethink.co.uk Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org
--- drivers/media/rc/imon.c | 5 +++++ 1 file changed, 5 insertions(+)
--- a/drivers/media/rc/imon.c +++ b/drivers/media/rc/imon.c @@ -2517,6 +2517,11 @@ static int imon_probe(struct usb_interfa mutex_lock(&driver_lock);
first_if = usb_ifnum_to_if(usbdev, 0); + if (!first_if) { + ret = -ENODEV; + goto fail; + } + first_if_ctx = usb_get_intfdata(first_if);
if (ifnum == 0) {
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Andrey Konovalov andreyknvl@google.com
commit eb0c19942288569e0ae492476534d5a485fb8ab4 upstream.
dvb_detach(arg) calls symbol_put_addr(arg), where arg should be a pointer to a function. Right now a pointer to state->dib7000p_ops is passed to dvb_detach(), which causes a BUG() in symbol_put_addr() as discovered by syzkaller. Pass state->dib7000p_ops.set_wbd_ref instead.
------------[ cut here ]------------ kernel BUG at kernel/module.c:1081! invalid opcode: 0000 [#1] PREEMPT SMP KASAN Modules linked in: CPU: 1 PID: 1151 Comm: kworker/1:1 Tainted: G W 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 task: ffff88006a336300 task.stack: ffff88006a7c8000 RIP: 0010:symbol_put_addr+0x54/0x60 kernel/module.c:1083 RSP: 0018:ffff88006a7ce210 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff880062a8d190 RCX: 0000000000000000 RDX: dffffc0000000020 RSI: ffffffff85876d60 RDI: ffff880062a8d190 RBP: ffff88006a7ce218 R08: 1ffff1000d4f9c12 R09: 1ffff1000d4f9ae4 R10: 1ffff1000d4f9bed R11: 0000000000000000 R12: ffff880062a8d180 R13: 00000000ffffffed R14: ffff880062a8d190 R15: ffff88006947c000 FS: 0000000000000000(0000) GS:ffff88006c900000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f6416532000 CR3: 00000000632f5000 CR4: 00000000000006e0 Call Trace: stk7070p_frontend_attach+0x515/0x610 drivers/media/usb/dvb-usb/dib0700_devices.c:1013 dvb_usb_adapter_frontend_init+0x32b/0x660 drivers/media/usb/dvb-usb/dvb-usb-dvb.c:286 dvb_usb_adapter_init drivers/media/usb/dvb-usb/dvb-usb-init.c:86 dvb_usb_init drivers/media/usb/dvb-usb/dvb-usb-init.c:162 dvb_usb_device_init+0xf70/0x17f0 drivers/media/usb/dvb-usb/dvb-usb-init.c:277 dib0700_probe+0x171/0x5a0 drivers/media/usb/dvb-usb/dib0700_core.c:886 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 Code: ff ff 48 85 c0 74 24 48 89 c7 e8 48 ea ff ff bf 01 00 00 00 e8 de 20 e3 ff 65 8b 05 b7 2f c2 7e 85 c0 75 c9 e8 f9 0b c1 ff eb c2 <0f> 0b 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 b8 00 00 RIP: symbol_put_addr+0x54/0x60 RSP: ffff88006a7ce210 ---[ end trace b75b357739e7e116 ]---
Signed-off-by: Andrey Konovalov andreyknvl@google.com Cc: Ben Hutchings ben.hutchings@codethink.co.uk Signed-off-by: Mauro Carvalho Chehab mchehab@s-opensource.com Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org
--- drivers/media/usb/dvb-usb/dib0700_devices.c | 24 ++++++++++++------------ 1 file changed, 12 insertions(+), 12 deletions(-)
--- a/drivers/media/usb/dvb-usb/dib0700_devices.c +++ b/drivers/media/usb/dvb-usb/dib0700_devices.c @@ -291,7 +291,7 @@ static int stk7700P2_frontend_attach(str stk7700d_dib7000p_mt2266_config) != 0) { err("%s: state->dib7000p_ops.i2c_enumeration failed. Cannot continue\n", __func__); - dvb_detach(&state->dib7000p_ops); + dvb_detach(state->dib7000p_ops.set_wbd_ref); return -ENODEV; } } @@ -325,7 +325,7 @@ static int stk7700d_frontend_attach(stru stk7700d_dib7000p_mt2266_config) != 0) { err("%s: state->dib7000p_ops.i2c_enumeration failed. Cannot continue\n", __func__); - dvb_detach(&state->dib7000p_ops); + dvb_detach(state->dib7000p_ops.set_wbd_ref); return -ENODEV; } } @@ -478,7 +478,7 @@ static int stk7700ph_frontend_attach(str &stk7700ph_dib7700_xc3028_config) != 0) { err("%s: state->dib7000p_ops.i2c_enumeration failed. Cannot continue\n", __func__); - dvb_detach(&state->dib7000p_ops); + dvb_detach(state->dib7000p_ops.set_wbd_ref); return -ENODEV; }
@@ -1010,7 +1010,7 @@ static int stk7070p_frontend_attach(stru &dib7070p_dib7000p_config) != 0) { err("%s: state->dib7000p_ops.i2c_enumeration failed. Cannot continue\n", __func__); - dvb_detach(&state->dib7000p_ops); + dvb_detach(state->dib7000p_ops.set_wbd_ref); return -ENODEV; }
@@ -1068,7 +1068,7 @@ static int stk7770p_frontend_attach(stru &dib7770p_dib7000p_config) != 0) { err("%s: state->dib7000p_ops.i2c_enumeration failed. Cannot continue\n", __func__); - dvb_detach(&state->dib7000p_ops); + dvb_detach(state->dib7000p_ops.set_wbd_ref); return -ENODEV; }
@@ -3056,7 +3056,7 @@ static int nim7090_frontend_attach(struc
if (state->dib7000p_ops.i2c_enumeration(&adap->dev->i2c_adap, 1, 0x10, &nim7090_dib7000p_config) != 0) { err("%s: state->dib7000p_ops.i2c_enumeration failed. Cannot continue\n", __func__); - dvb_detach(&state->dib7000p_ops); + dvb_detach(state->dib7000p_ops.set_wbd_ref); return -ENODEV; } adap->fe_adap[0].fe = state->dib7000p_ops.init(&adap->dev->i2c_adap, 0x80, &nim7090_dib7000p_config); @@ -3109,7 +3109,7 @@ static int tfe7090pvr_frontend0_attach(s /* initialize IC 0 */ if (state->dib7000p_ops.i2c_enumeration(&adap->dev->i2c_adap, 1, 0x20, &tfe7090pvr_dib7000p_config[0]) != 0) { err("%s: state->dib7000p_ops.i2c_enumeration failed. Cannot continue\n", __func__); - dvb_detach(&state->dib7000p_ops); + dvb_detach(state->dib7000p_ops.set_wbd_ref); return -ENODEV; }
@@ -3139,7 +3139,7 @@ static int tfe7090pvr_frontend1_attach(s i2c = state->dib7000p_ops.get_i2c_master(adap->dev->adapter[0].fe_adap[0].fe, DIBX000_I2C_INTERFACE_GPIO_6_7, 1); if (state->dib7000p_ops.i2c_enumeration(i2c, 1, 0x10, &tfe7090pvr_dib7000p_config[1]) != 0) { err("%s: state->dib7000p_ops.i2c_enumeration failed. Cannot continue\n", __func__); - dvb_detach(&state->dib7000p_ops); + dvb_detach(state->dib7000p_ops.set_wbd_ref); return -ENODEV; }
@@ -3214,7 +3214,7 @@ static int tfe7790p_frontend_attach(stru 1, 0x10, &tfe7790p_dib7000p_config) != 0) { err("%s: state->dib7000p_ops.i2c_enumeration failed. Cannot continue\n", __func__); - dvb_detach(&state->dib7000p_ops); + dvb_detach(state->dib7000p_ops.set_wbd_ref); return -ENODEV; } adap->fe_adap[0].fe = state->dib7000p_ops.init(&adap->dev->i2c_adap, @@ -3309,7 +3309,7 @@ static int stk7070pd_frontend_attach0(st stk7070pd_dib7000p_config) != 0) { err("%s: state->dib7000p_ops.i2c_enumeration failed. Cannot continue\n", __func__); - dvb_detach(&state->dib7000p_ops); + dvb_detach(state->dib7000p_ops.set_wbd_ref); return -ENODEV; }
@@ -3384,7 +3384,7 @@ static int novatd_frontend_attach(struct stk7070pd_dib7000p_config) != 0) { err("%s: state->dib7000p_ops.i2c_enumeration failed. Cannot continue\n", __func__); - dvb_detach(&state->dib7000p_ops); + dvb_detach(state->dib7000p_ops.set_wbd_ref); return -ENODEV; } } @@ -3620,7 +3620,7 @@ static int pctv340e_frontend_attach(stru
if (state->dib7000p_ops.dib7000pc_detection(&adap->dev->i2c_adap) == 0) { /* Demodulator not found for some reason? */ - dvb_detach(&state->dib7000p_ops); + dvb_detach(state->dib7000p_ops.set_wbd_ref); return -ENODEV; }
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Eric Biggers ebiggers@google.com
commit 12d41a023efb01b846457ccdbbcbe2b65a87d530 upstream.
When setting the secret with the software Diffie-Hellman implementation, if allocating 'g' failed (e.g. if it was longer than MAX_EXTERN_MPI_BITS), then 'p' was freed twice: once immediately, and once later when the crypto_kpp tfm was destroyed.
Fix it by using dh_free_ctx() (renamed to dh_clear_ctx()) in the error paths, as that correctly sets the pointers to NULL.
KASAN report:
MPI: mpi too large (32760 bits) ================================================================== BUG: KASAN: use-after-free in mpi_free+0x131/0x170 Read of size 4 at addr ffff88006c7cdf90 by task reproduce_doubl/367
CPU: 1 PID: 367 Comm: reproduce_doubl Not tainted 4.14.0-rc7-00040-g05298abde6fe #7 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 Call Trace: dump_stack+0xb3/0x10b ? mpi_free+0x131/0x170 print_address_description+0x79/0x2a0 ? mpi_free+0x131/0x170 kasan_report+0x236/0x340 ? akcipher_register_instance+0x90/0x90 __asan_report_load4_noabort+0x14/0x20 mpi_free+0x131/0x170 ? akcipher_register_instance+0x90/0x90 dh_exit_tfm+0x3d/0x140 crypto_kpp_exit_tfm+0x52/0x70 crypto_destroy_tfm+0xb3/0x250 __keyctl_dh_compute+0x640/0xe90 ? kasan_slab_free+0x12f/0x180 ? dh_data_from_key+0x240/0x240 ? key_create_or_update+0x1ee/0xb20 ? key_instantiate_and_link+0x440/0x440 ? lock_contended+0xee0/0xee0 ? kfree+0xcf/0x210 ? SyS_add_key+0x268/0x340 keyctl_dh_compute+0xb3/0xf1 ? __keyctl_dh_compute+0xe90/0xe90 ? SyS_add_key+0x26d/0x340 ? entry_SYSCALL_64_fastpath+0x5/0xbe ? trace_hardirqs_on_caller+0x3f4/0x560 SyS_keyctl+0x72/0x2c0 entry_SYSCALL_64_fastpath+0x1f/0xbe RIP: 0033:0x43ccf9 RSP: 002b:00007ffeeec96158 EFLAGS: 00000246 ORIG_RAX: 00000000000000fa RAX: ffffffffffffffda RBX: 000000000248b9b9 RCX: 000000000043ccf9 RDX: 00007ffeeec96170 RSI: 00007ffeeec96160 RDI: 0000000000000017 RBP: 0000000000000046 R08: 0000000000000000 R09: 0248b9b9143dc936 R10: 0000000000001000 R11: 0000000000000246 R12: 0000000000000000 R13: 0000000000409670 R14: 0000000000409700 R15: 0000000000000000
Allocated by task 367: save_stack_trace+0x16/0x20 kasan_kmalloc+0xeb/0x180 kmem_cache_alloc_trace+0x114/0x300 mpi_alloc+0x4b/0x230 mpi_read_raw_data+0xbe/0x360 dh_set_secret+0x1dc/0x460 __keyctl_dh_compute+0x623/0xe90 keyctl_dh_compute+0xb3/0xf1 SyS_keyctl+0x72/0x2c0 entry_SYSCALL_64_fastpath+0x1f/0xbe
Freed by task 367: save_stack_trace+0x16/0x20 kasan_slab_free+0xab/0x180 kfree+0xb5/0x210 mpi_free+0xcb/0x170 dh_set_secret+0x2d7/0x460 __keyctl_dh_compute+0x623/0xe90 keyctl_dh_compute+0xb3/0xf1 SyS_keyctl+0x72/0x2c0 entry_SYSCALL_64_fastpath+0x1f/0xbe
Fixes: 802c7f1c84e4 ("crypto: dh - Add DH software implementation") Signed-off-by: Eric Biggers ebiggers@google.com Reviewed-by: Tudor Ambarus tudor.ambarus@microchip.com Signed-off-by: Herbert Xu herbert@gondor.apana.org.au Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org
--- crypto/dh.c | 33 +++++++++++++-------------------- 1 file changed, 13 insertions(+), 20 deletions(-)
--- a/crypto/dh.c +++ b/crypto/dh.c @@ -21,19 +21,12 @@ struct dh_ctx { MPI xa; };
-static inline void dh_clear_params(struct dh_ctx *ctx) +static void dh_clear_ctx(struct dh_ctx *ctx) { mpi_free(ctx->p); mpi_free(ctx->g); - ctx->p = NULL; - ctx->g = NULL; -} - -static void dh_free_ctx(struct dh_ctx *ctx) -{ - dh_clear_params(ctx); mpi_free(ctx->xa); - ctx->xa = NULL; + memset(ctx, 0, sizeof(*ctx)); }
/* @@ -71,10 +64,8 @@ static int dh_set_params(struct dh_ctx * return -EINVAL;
ctx->g = mpi_read_raw_data(params->g, params->g_size); - if (!ctx->g) { - mpi_free(ctx->p); + if (!ctx->g) return -EINVAL; - }
return 0; } @@ -86,21 +77,23 @@ static int dh_set_secret(struct crypto_k struct dh params;
/* Free the old MPI key if any */ - dh_free_ctx(ctx); + dh_clear_ctx(ctx);
if (crypto_dh_decode_key(buf, len, ¶ms) < 0) - return -EINVAL; + goto err_clear_ctx;
if (dh_set_params(ctx, ¶ms) < 0) - return -EINVAL; + goto err_clear_ctx;
ctx->xa = mpi_read_raw_data(params.key, params.key_size); - if (!ctx->xa) { - dh_clear_params(ctx); - return -EINVAL; - } + if (!ctx->xa) + goto err_clear_ctx;
return 0; + +err_clear_ctx: + dh_clear_ctx(ctx); + return -EINVAL; }
static int dh_compute_value(struct kpp_request *req) @@ -158,7 +151,7 @@ static void dh_exit_tfm(struct crypto_kp { struct dh_ctx *ctx = dh_get_ctx(tfm);
- dh_free_ctx(ctx); + dh_clear_ctx(ctx); }
static struct kpp_alg dh = {
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Eric Biggers ebiggers@google.com
commit 199512b1234f09e44d592153ec82b44212b2f0c4 upstream.
If 'p' is 0 for the software Diffie-Hellman implementation, then dh_max_size() returns 0. In the case of KEYCTL_DH_COMPUTE, this causes ZERO_SIZE_PTR to be passed to sg_init_one(), which with CONFIG_DEBUG_SG=y triggers the 'BUG_ON(!virt_addr_valid(buf));' in sg_set_buf().
Fix this by making crypto_dh_decode_key() reject 0 for 'p'. p=0 makes no sense for any DH implementation because 'p' is supposed to be a prime number. Moreover, 'mod 0' is not mathematically defined.
Bug report:
kernel BUG at ./include/linux/scatterlist.h:140! invalid opcode: 0000 [#1] SMP KASAN CPU: 0 PID: 27112 Comm: syz-executor2 Not tainted 4.14.0-rc7-00010-gf5dbb5d0ce32-dirty #7 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.3-20171021_125229-anatol 04/01/2014 task: ffff88006caac0c0 task.stack: ffff88006c7c8000 RIP: 0010:sg_set_buf include/linux/scatterlist.h:140 [inline] RIP: 0010:sg_init_one+0x1b3/0x240 lib/scatterlist.c:156 RSP: 0018:ffff88006c7cfb08 EFLAGS: 00010216 RAX: 0000000000010000 RBX: ffff88006c7cfe30 RCX: 00000000000064ee RDX: ffffffff81cf64c3 RSI: ffffc90000d72000 RDI: ffffffff92e937e0 RBP: ffff88006c7cfb30 R08: ffffed000d8f9fab R09: ffff88006c7cfd30 R10: 0000000000000005 R11: ffffed000d8f9faa R12: ffff88006c7cfd30 R13: 0000000000000000 R14: 0000000000000010 R15: ffff88006c7cfc50 FS: 00007fce190fa700(0000) GS:ffff88003ea00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fffc6b33db8 CR3: 000000003cf64000 CR4: 00000000000006f0 Call Trace: __keyctl_dh_compute+0xa95/0x19b0 security/keys/dh.c:360 keyctl_dh_compute+0xac/0x100 security/keys/dh.c:434 SYSC_keyctl security/keys/keyctl.c:1745 [inline] SyS_keyctl+0x72/0x2c0 security/keys/keyctl.c:1641 entry_SYSCALL_64_fastpath+0x1f/0xbe RIP: 0033:0x4585c9 RSP: 002b:00007fce190f9bd8 EFLAGS: 00000216 ORIG_RAX: 00000000000000fa RAX: ffffffffffffffda RBX: 0000000000738020 RCX: 00000000004585c9 RDX: 000000002000d000 RSI: 0000000020000ff4 RDI: 0000000000000017 RBP: 0000000000000046 R08: 0000000020008000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000216 R12: 00007fff6e610cde R13: 00007fff6e610cdf R14: 00007fce190fa700 R15: 0000000000000000 Code: 03 0f b6 14 02 48 89 f8 83 e0 07 83 c0 03 38 d0 7c 04 84 d2 75 33 5b 45 89 6c 24 14 41 5c 41 5d 41 5e 41 5f 5d c3 e8 fd 8f 68 ff <0f> 0b e8 f6 8f 68 ff 0f 0b e8 ef 8f 68 ff 0f 0b e8 e8 8f 68 ff 20 RIP: sg_set_buf include/linux/scatterlist.h:140 [inline] RSP: ffff88006c7cfb08 RIP: sg_init_one+0x1b3/0x240 lib/scatterlist.c:156 RSP: ffff88006c7cfb08
Fixes: 802c7f1c84e4 ("crypto: dh - Add DH software implementation") Reviewed-by: Tudor Ambarus tudor.ambarus@microchip.com Signed-off-by: Eric Biggers ebiggers@google.com Signed-off-by: Herbert Xu herbert@gondor.apana.org.au Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org
--- crypto/dh_helper.c | 8 ++++++++ 1 file changed, 8 insertions(+)
--- a/crypto/dh_helper.c +++ b/crypto/dh_helper.c @@ -90,6 +90,14 @@ int crypto_dh_decode_key(const char *buf params->p = (void *)(ptr + params->key_size); params->g = (void *)(ptr + params->key_size + params->p_size);
+ /* + * Don't permit 'p' to be 0. It's not a prime number, and it's subject + * to corner cases such as 'mod 0' being undefined or + * crypto_kpp_maxsize() returning 0. + */ + if (memchr_inv(params->p, 0, params->p_size) == NULL) + return -EINVAL; + return 0; } EXPORT_SYMBOL_GPL(crypto_dh_decode_key);
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Eric Biggers ebiggers@google.com
commit ccd9888f14a8019c0bbdeeae758aba1f58693712 upstream.
The "qat-dh" DH implementation assumes that 'key' and 'g' can be copied into a buffer with size 'p_size'. However it was never checked that that was actually the case, which most likely allowed users to cause a buffer underflow via KEYCTL_DH_COMPUTE.
Fix this by updating crypto_dh_decode_key() to verify this precondition for all DH implementations.
Fixes: c9839143ebbf ("crypto: qat - Add DH support") Signed-off-by: Eric Biggers ebiggers@google.com Reviewed-by: Tudor Ambarus tudor.ambarus@microchip.com Signed-off-by: Herbert Xu herbert@gondor.apana.org.au Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org
--- crypto/dh_helper.c | 8 ++++++++ 1 file changed, 8 insertions(+)
--- a/crypto/dh_helper.c +++ b/crypto/dh_helper.c @@ -83,6 +83,14 @@ int crypto_dh_decode_key(const char *buf if (secret.len != crypto_dh_key_len(params)) return -EINVAL;
+ /* + * Don't permit the buffer for 'key' or 'g' to be larger than 'p', since + * some drivers assume otherwise. + */ + if (params->key_size > params->p_size || + params->g_size > params->p_size) + return -EINVAL; + /* Don't allocate memory. Set pointers to data within * the given buffer */
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: raveendra padasalagi raveendra.padasalagi@broadcom.com
commit f0e2ce58f853634d7ad1a418a49bd5fbd556227c upstream.
Add support to explicity ACK mailbox message because after sending message we can know the send status via error attribute of brcm_message.
This is needed to support "txdone_ack" supported in mailbox controller driver.
Fixes: 9d12ba86f818 ("crypto: brcm - Add Broadcom SPU driver") Signed-off-by: Raveendra Padasalagi raveendra.padasalagi@broadcom.com Reviewed-by: Anup Patel anup.patel@broadcom.com Reviewed-by: Scott Branden scott.branden@broadcom.com Signed-off-by: Herbert Xu herbert@gondor.apana.org.au Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org
--- drivers/crypto/bcm/cipher.c | 101 ++++++++++++++++++++------------------------ 1 file changed, 46 insertions(+), 55 deletions(-)
--- a/drivers/crypto/bcm/cipher.c +++ b/drivers/crypto/bcm/cipher.c @@ -256,6 +256,44 @@ spu_ablkcipher_tx_sg_create(struct brcm_ return 0; }
+static int mailbox_send_message(struct brcm_message *mssg, u32 flags, + u8 chan_idx) +{ + int err; + int retry_cnt = 0; + struct device *dev = &(iproc_priv.pdev->dev); + + err = mbox_send_message(iproc_priv.mbox[chan_idx], mssg); + if (flags & CRYPTO_TFM_REQ_MAY_SLEEP) { + while ((err == -ENOBUFS) && (retry_cnt < SPU_MB_RETRY_MAX)) { + /* + * Mailbox queue is full. Since MAY_SLEEP is set, assume + * not in atomic context and we can wait and try again. + */ + retry_cnt++; + usleep_range(MBOX_SLEEP_MIN, MBOX_SLEEP_MAX); + err = mbox_send_message(iproc_priv.mbox[chan_idx], + mssg); + atomic_inc(&iproc_priv.mb_no_spc); + } + } + if (err < 0) { + atomic_inc(&iproc_priv.mb_send_fail); + return err; + } + + /* Check error returned by mailbox controller */ + err = mssg->error; + if (unlikely(err < 0)) { + dev_err(dev, "message error %d", err); + /* Signal txdone for mailbox channel */ + } + + /* Signal txdone for mailbox channel */ + mbox_client_txdone(iproc_priv.mbox[chan_idx], err); + return err; +} + /** * handle_ablkcipher_req() - Submit as much of a block cipher request as fits in * a single SPU request message, starting at the current position in the request @@ -293,7 +331,6 @@ static int handle_ablkcipher_req(struct u32 pad_len; /* total length of all padding */ bool update_key = false; struct brcm_message *mssg; /* mailbox message */ - int retry_cnt = 0;
/* number of entries in src and dst sg in mailbox message. */ u8 rx_frag_num = 2; /* response header and STATUS */ @@ -462,24 +499,9 @@ static int handle_ablkcipher_req(struct if (err) return err;
- err = mbox_send_message(iproc_priv.mbox[rctx->chan_idx], mssg); - if (req->base.flags & CRYPTO_TFM_REQ_MAY_SLEEP) { - while ((err == -ENOBUFS) && (retry_cnt < SPU_MB_RETRY_MAX)) { - /* - * Mailbox queue is full. Since MAY_SLEEP is set, assume - * not in atomic context and we can wait and try again. - */ - retry_cnt++; - usleep_range(MBOX_SLEEP_MIN, MBOX_SLEEP_MAX); - err = mbox_send_message(iproc_priv.mbox[rctx->chan_idx], - mssg); - atomic_inc(&iproc_priv.mb_no_spc); - } - } - if (unlikely(err < 0)) { - atomic_inc(&iproc_priv.mb_send_fail); + err = mailbox_send_message(mssg, req->base.flags, rctx->chan_idx); + if (unlikely(err < 0)) return err; - }
return -EINPROGRESS; } @@ -710,7 +732,6 @@ static int handle_ahash_req(struct iproc u32 spu_hdr_len; unsigned int digestsize; u16 rem = 0; - int retry_cnt = 0;
/* * number of entries in src and dst sg. Always includes SPU msg header. @@ -904,24 +925,10 @@ static int handle_ahash_req(struct iproc if (err) return err;
- err = mbox_send_message(iproc_priv.mbox[rctx->chan_idx], mssg); - if (req->base.flags & CRYPTO_TFM_REQ_MAY_SLEEP) { - while ((err == -ENOBUFS) && (retry_cnt < SPU_MB_RETRY_MAX)) { - /* - * Mailbox queue is full. Since MAY_SLEEP is set, assume - * not in atomic context and we can wait and try again. - */ - retry_cnt++; - usleep_range(MBOX_SLEEP_MIN, MBOX_SLEEP_MAX); - err = mbox_send_message(iproc_priv.mbox[rctx->chan_idx], - mssg); - atomic_inc(&iproc_priv.mb_no_spc); - } - } - if (err < 0) { - atomic_inc(&iproc_priv.mb_send_fail); + err = mailbox_send_message(mssg, req->base.flags, rctx->chan_idx); + if (unlikely(err < 0)) return err; - } + return -EINPROGRESS; }
@@ -1320,7 +1327,6 @@ static int handle_aead_req(struct iproc_ int assoc_nents = 0; bool incl_icv = false; unsigned int digestsize = ctx->digestsize; - int retry_cnt = 0;
/* number of entries in src and dst sg. Always includes SPU msg header. */ @@ -1558,24 +1564,9 @@ static int handle_aead_req(struct iproc_ if (err) return err;
- err = mbox_send_message(iproc_priv.mbox[rctx->chan_idx], mssg); - if (req->base.flags & CRYPTO_TFM_REQ_MAY_SLEEP) { - while ((err == -ENOBUFS) && (retry_cnt < SPU_MB_RETRY_MAX)) { - /* - * Mailbox queue is full. Since MAY_SLEEP is set, assume - * not in atomic context and we can wait and try again. - */ - retry_cnt++; - usleep_range(MBOX_SLEEP_MIN, MBOX_SLEEP_MAX); - err = mbox_send_message(iproc_priv.mbox[rctx->chan_idx], - mssg); - atomic_inc(&iproc_priv.mb_no_spc); - } - } - if (err < 0) { - atomic_inc(&iproc_priv.mb_send_fail); + err = mailbox_send_message(mssg, req->base.flags, rctx->chan_idx); + if (unlikely(err < 0)) return err; - }
return -EINPROGRESS; } @@ -4537,7 +4528,7 @@ static int spu_mb_init(struct device *de mcl->dev = dev; mcl->tx_block = false; mcl->tx_tout = 0; - mcl->knows_txdone = false; + mcl->knows_txdone = true; mcl->rx_callback = spu_rx_callback; mcl->tx_done = NULL;
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Lu Baolu baolu.lu@linux.intel.com
commit c67678ec78eff9cf1e7e997fe6c37c9fcccfc5b8 upstream.
The DbC register set defines an interface for system software to specify the vendor id and product id for the debug device. These two values will be presented by the debug device in its device descriptor idVendor and idProduct fields.
The current used product ID is a place holder. We now have a valid one. The description strings are changed accordingly.
This patch should be back-ported to kernels as old as v4.12, that contain the commit aeb9dd1de98c ("usb/early: Add driver for xhci debug capability").
Signed-off-by: Lu Baolu baolu.lu@linux.intel.com Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org
--- drivers/usb/early/xhci-dbc.h | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
--- a/drivers/usb/early/xhci-dbc.h +++ b/drivers/usb/early/xhci-dbc.h @@ -90,8 +90,8 @@ struct xdbc_context {
#define XDBC_INFO_CONTEXT_SIZE 48 #define XDBC_MAX_STRING_LENGTH 64 -#define XDBC_STRING_MANUFACTURER "Linux" -#define XDBC_STRING_PRODUCT "Remote GDB" +#define XDBC_STRING_MANUFACTURER "Linux Foundation" +#define XDBC_STRING_PRODUCT "Linux USB GDB Target" #define XDBC_STRING_SERIAL "0001"
struct xdbc_strings { @@ -103,7 +103,7 @@ struct xdbc_strings {
#define XDBC_PROTOCOL 1 /* GNU Remote Debug Command Set */ #define XDBC_VENDOR_ID 0x1d6b /* Linux Foundation 0x1d6b */ -#define XDBC_PRODUCT_ID 0x0004 /* __le16 idProduct; device 0004 */ +#define XDBC_PRODUCT_ID 0x0011 /* __le16 idProduct; device 0011 */ #define XDBC_DEVICE_REV 0x0010 /* 0.10 */
/*
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alan Stern stern@rowland.harvard.edu
commit 2ef47001b3ee3ded579b7532ebdcf8680e4d8c54 upstream.
The USB kerneldoc says that the actual_length field "is read in non-iso completion functions", but the usbfs driver uses it for all URB types in processcompl(). Since not all of the host controller drivers set actual_length for isochronous URBs, programs using usbfs with some host controllers don't work properly. For example, Minas reports that a USB camera controlled by libusb doesn't work properly with a dwc2 controller.
It doesn't seem worthwhile to change the HCDs and the documentation, since the in-kernel USB class drivers evidently don't rely on actual_length for isochronous transfers. The easiest solution is for usbfs to calculate the actual_length value for itself, by adding up the lengths of the individual packets in an isochronous transfer.
Signed-off-by: Alan Stern stern@rowland.harvard.edu CC: Minas Harutyunyan Minas.Harutyunyan@synopsys.com Reported-and-tested-by: wlf wulf@rock-chips.com Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org
--- drivers/usb/core/devio.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+)
--- a/drivers/usb/core/devio.c +++ b/drivers/usb/core/devio.c @@ -1833,6 +1833,18 @@ static int proc_unlinkurb(struct usb_dev return 0; }
+static void compute_isochronous_actual_length(struct urb *urb) +{ + unsigned int i; + + if (urb->number_of_packets > 0) { + urb->actual_length = 0; + for (i = 0; i < urb->number_of_packets; i++) + urb->actual_length += + urb->iso_frame_desc[i].actual_length; + } +} + static int processcompl(struct async *as, void __user * __user *arg) { struct urb *urb = as->urb; @@ -1840,6 +1852,7 @@ static int processcompl(struct async *as void __user *addr = as->userurb; unsigned int i;
+ compute_isochronous_actual_length(urb); if (as->userbuffer && urb->actual_length) { if (copy_urb_data_to_user(as->userbuffer, urb)) goto err_out; @@ -2008,6 +2021,7 @@ static int processcompl_compat(struct as void __user *addr = as->userurb; unsigned int i;
+ compute_isochronous_actual_length(urb); if (as->userbuffer && urb->actual_length) { if (copy_urb_data_to_user(as->userbuffer, urb)) return -EFAULT;
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Bernhard Rosenkraenzer bernhard.rosenkranzer@linaro.org
commit a0fea6027f19c62727315aba1a7fae75a9caa842 upstream.
Without this patch, K70 LUX keyboards don't work, saying usb 3-3: unable to read config index 0 descriptor/all usb 3-3: can't read configurations, error -110 usb usb3-port3: unable to enumerate USB device
Signed-off-by: Bernhard Rosenkraenzer Bernhard.Rosenkranzer@linaro.org Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org
--- drivers/usb/core/quirks.c | 3 +++ 1 file changed, 3 insertions(+)
--- a/drivers/usb/core/quirks.c +++ b/drivers/usb/core/quirks.c @@ -221,6 +221,9 @@ static const struct usb_device_id usb_qu /* Corsair Strafe RGB */ { USB_DEVICE(0x1b1c, 0x1b20), .driver_info = USB_QUIRK_DELAY_INIT },
+ /* Corsair K70 LUX */ + { USB_DEVICE(0x1b1c, 0x1b36), .driver_info = USB_QUIRK_DELAY_INIT }, + /* MIDI keyboard WORLDE MINI */ { USB_DEVICE(0x1c75, 0x0204), .driver_info = USB_QUIRK_CONFIG_INTF_STRINGS },
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Andrew Gabbasov andrew_gabbasov@mentor.com
commit cdafb6d8b8da7fde266f79b3287ac221aa841879 upstream.
KASAN enabled configuration reports an error
BUG: KASAN: use-after-free in ffs_free_inst+... [usb_f_fs] at addr ... Write of size 8 by task ...
This is observed after "ffs-test" is run and interrupted. If after that functionfs is unmounted and g_ffs module is unloaded, that use-after-free occurs during g_ffs module removal.
Although the report indicates ffs_free_inst() function, the actual use-after-free condition occurs in _ffs_free_dev() function, which is probably inlined into ffs_free_inst().
This happens due to keeping the ffs_data reference in device structure during functionfs unmounting, while ffs_data itself is freed as no longer needed. The fix is to clear that reference in ffs_closed() function, which is a counterpart of ffs_ready(), where the reference is stored.
Fixes: 3262ad824307 ("usb: gadget: f_fs: Stop ffs_closed NULL pointer dereference") Signed-off-by: Andrew Gabbasov andrew_gabbasov@mentor.com Acked-by: Felipe Balbi felipe.balbi@linux.intel.com Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org
--- drivers/usb/gadget/function/f_fs.c | 1 + 1 file changed, 1 insertion(+)
--- a/drivers/usb/gadget/function/f_fs.c +++ b/drivers/usb/gadget/function/f_fs.c @@ -3677,6 +3677,7 @@ static void ffs_closed(struct ffs_data * goto done;
ffs_obj->desc_ready = false; + ffs_obj->ffs_data = NULL;
if (test_and_clear_bit(FFS_FL_CALL_CLOSED_CALLBACK, &ffs->flags) && ffs_obj->ffs_closed_callback)
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Johan Hovold johan@kernel.org
commit 2339536d229df25c71c0900fc619289229bfecf6 upstream.
Make sure to kill the interrupt-in URB after a failed open request. Apart from saving power (and avoiding stale input after a later successful open), this also prevents a NULL-deref in the completion handler if the port is manually unbound.
Reviewed-by: Greg Kroah-Hartman gregkh@linuxfoundation.org Fixes: 704577861d5e ("USB: serial: metro-usb: get data from device in Uni-Directional mode.") Signed-off-by: Johan Hovold johan@kernel.org Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org
--- drivers/usb/serial/metro-usb.c | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-)
--- a/drivers/usb/serial/metro-usb.c +++ b/drivers/usb/serial/metro-usb.c @@ -189,7 +189,7 @@ static int metrousb_open(struct tty_stru dev_err(&port->dev, "%s - failed submitting interrupt in urb, error code=%d\n", __func__, result); - goto exit; + return result; }
/* Send activate cmd to device */ @@ -198,9 +198,14 @@ static int metrousb_open(struct tty_stru dev_err(&port->dev, "%s - failed to configure device, error code=%d\n", __func__, result); - goto exit; + goto err_kill_urb; } -exit: + + return 0; + +err_kill_urb: + usb_kill_urb(port->interrupt_in_urb); + return result; }
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Lu Baolu baolu.lu@linux.intel.com
commit 12f28144cf2cf69e1520e238eee7c384719ca44b upstream.
The product ID for "Linux USB GDB Target device" has been changed. Change the driver binding table accordingly.
This patch should be back-ported to kernels as old as v4.12, that contain the commit 57fb47279a04 ("usb/serial: Add DBC debug device support to usb_debug").
Cc: Johan Hovold johan@kernel.org Signed-off-by: Lu Baolu baolu.lu@linux.intel.com Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org
--- drivers/usb/serial/usb_debug.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/usb/serial/usb_debug.c +++ b/drivers/usb/serial/usb_debug.c @@ -34,13 +34,13 @@ static const struct usb_device_id id_tab };
static const struct usb_device_id dbc_id_table[] = { - { USB_DEVICE(0x1d6b, 0x0004) }, + { USB_DEVICE(0x1d6b, 0x0011) }, { }, };
static const struct usb_device_id id_table_combined[] = { { USB_DEVICE(0x0525, 0x127a) }, - { USB_DEVICE(0x1d6b, 0x0004) }, + { USB_DEVICE(0x1d6b, 0x0011) }, { }, }; MODULE_DEVICE_TABLE(usb, id_table_combined);
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Douglas Fischer douglas.fischer@outlook.com
commit 771394a54148f18926ca86414e51c69eda27d0cd upstream.
Add USB PID/VID for Sierra Wireless EM7355 LTE modem QDL firmware update mode.
Signed-off-by: Douglas Fischer douglas.fischer@outlook.com Signed-off-by: Johan Hovold johan@kernel.org Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org
--- drivers/usb/serial/qcserial.c | 1 + 1 file changed, 1 insertion(+)
--- a/drivers/usb/serial/qcserial.c +++ b/drivers/usb/serial/qcserial.c @@ -148,6 +148,7 @@ static const struct usb_device_id id_tab {DEVICE_SWI(0x1199, 0x68a2)}, /* Sierra Wireless MC7710 */ {DEVICE_SWI(0x1199, 0x68c0)}, /* Sierra Wireless MC7304/MC7354 */ {DEVICE_SWI(0x1199, 0x901c)}, /* Sierra Wireless EM7700 */ + {DEVICE_SWI(0x1199, 0x901e)}, /* Sierra Wireless EM7355 QDL */ {DEVICE_SWI(0x1199, 0x901f)}, /* Sierra Wireless EM7355 */ {DEVICE_SWI(0x1199, 0x9040)}, /* Sierra Wireless Modem */ {DEVICE_SWI(0x1199, 0x9041)}, /* Sierra Wireless MC7305/MC7355 */
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Johan Hovold johan@kernel.org
commit 19a565d9af6e0d828bd0d521d3bafd5017f4ce52 upstream.
Make sure to stop any submitted interrupt and bulk-out URBs before returning after failed probe and when the port is being unbound to avoid later NULL-pointer dereferences in the completion callbacks.
Also fix up the related and broken I/O cancellation on failed open and on close. (Note that port->write_urb was never submitted.)
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reviewed-by: Greg Kroah-Hartman gregkh@linuxfoundation.org Signed-off-by: Johan Hovold johan@kernel.org Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org
--- drivers/usb/serial/garmin_gps.c | 16 +++++++++++++--- 1 file changed, 13 insertions(+), 3 deletions(-)
--- a/drivers/usb/serial/garmin_gps.c +++ b/drivers/usb/serial/garmin_gps.c @@ -138,6 +138,7 @@ struct garmin_data { __u8 privpkt[4*6]; spinlock_t lock; struct list_head pktlist; + struct usb_anchor write_urbs; };
@@ -905,7 +906,7 @@ static int garmin_init_session(struct us sizeof(GARMIN_START_SESSION_REQ), 0);
if (status < 0) - break; + goto err_kill_urbs; }
if (status > 0) @@ -913,6 +914,12 @@ static int garmin_init_session(struct us }
return status; + +err_kill_urbs: + usb_kill_anchored_urbs(&garmin_data_p->write_urbs); + usb_kill_urb(port->interrupt_in_urb); + + return status; }
@@ -930,7 +937,6 @@ static int garmin_open(struct tty_struct spin_unlock_irqrestore(&garmin_data_p->lock, flags);
/* shutdown any bulk reads that might be going on */ - usb_kill_urb(port->write_urb); usb_kill_urb(port->read_urb);
if (garmin_data_p->state == STATE_RESET) @@ -953,7 +959,7 @@ static void garmin_close(struct usb_seri
/* shutdown our urbs */ usb_kill_urb(port->read_urb); - usb_kill_urb(port->write_urb); + usb_kill_anchored_urbs(&garmin_data_p->write_urbs);
/* keep reset state so we know that we must start a new session */ if (garmin_data_p->state != STATE_RESET) @@ -1037,12 +1043,14 @@ static int garmin_write_bulk(struct usb_ }
/* send it down the pipe */ + usb_anchor_urb(urb, &garmin_data_p->write_urbs); status = usb_submit_urb(urb, GFP_ATOMIC); if (status) { dev_err(&port->dev, "%s - usb_submit_urb(write bulk) failed with status = %d\n", __func__, status); count = status; + usb_unanchor_urb(urb); kfree(buffer); }
@@ -1401,6 +1409,7 @@ static int garmin_port_probe(struct usb_ garmin_data_p->state = 0; garmin_data_p->flags = 0; garmin_data_p->count = 0; + init_usb_anchor(&garmin_data_p->write_urbs); usb_set_serial_port_data(port, garmin_data_p);
status = garmin_init_session(port); @@ -1413,6 +1422,7 @@ static int garmin_port_remove(struct usb { struct garmin_data *garmin_data_p = usb_get_serial_port_data(port);
+ usb_kill_anchored_urbs(&garmin_data_p->write_urbs); usb_kill_urb(port->interrupt_in_urb); del_timer_sync(&garmin_data_p->timer); kfree(garmin_data_p);
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Johan Hovold johan@kernel.org
commit 74d471b598444b7f2d964930f7234779c80960a0 upstream.
Make sure to free the port private data before returning after a failed probe attempt.
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reviewed-by: Greg Kroah-Hartman gregkh@linuxfoundation.org Signed-off-by: Johan Hovold johan@kernel.org Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org
--- drivers/usb/serial/garmin_gps.c | 6 ++++++ 1 file changed, 6 insertions(+)
--- a/drivers/usb/serial/garmin_gps.c +++ b/drivers/usb/serial/garmin_gps.c @@ -1413,6 +1413,12 @@ static int garmin_port_probe(struct usb_ usb_set_serial_port_data(port, garmin_data_p);
status = garmin_init_session(port); + if (status) + goto err_free; + + return 0; +err_free: + kfree(garmin_data_p);
return status; }
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Andy Lutomirski luto@kernel.org
commit 693cb5580fdb026922363aa103add64b3ecd572e upstream.
On new enough glibc, the pkey syscalls numbers are available. Check first before defining them to avoid warnings like:
protection_keys.c:198:0: warning: "SYS_pkey_alloc" redefined
Signed-off-by: Andy Lutomirski luto@kernel.org Cc: Borislav Petkov bpetkov@suse.de Cc: Dave Hansen dave.hansen@intel.com Cc: Linus Torvalds torvalds@linux-foundation.org Cc: Peter Zijlstra peterz@infradead.org Cc: Thomas Gleixner tglx@linutronix.de Link: http://lkml.kernel.org/r/1fbef53a9e6befb7165ff855fc1a7d4788a191d6.1509794321... Signed-off-by: Ingo Molnar mingo@kernel.org Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org
--- tools/testing/selftests/x86/protection_keys.c | 24 ++++++++++++++++++------ 1 file changed, 18 insertions(+), 6 deletions(-)
--- a/tools/testing/selftests/x86/protection_keys.c +++ b/tools/testing/selftests/x86/protection_keys.c @@ -189,17 +189,29 @@ void lots_o_noops_around_write(int *writ #define u64 uint64_t
#ifdef __i386__ -#define SYS_mprotect_key 380 -#define SYS_pkey_alloc 381 -#define SYS_pkey_free 382 + +#ifndef SYS_mprotect_key +# define SYS_mprotect_key 380 +#endif +#ifndef SYS_pkey_alloc +# define SYS_pkey_alloc 381 +# define SYS_pkey_free 382 +#endif #define REG_IP_IDX REG_EIP #define si_pkey_offset 0x14 + #else -#define SYS_mprotect_key 329 -#define SYS_pkey_alloc 330 -#define SYS_pkey_free 331 + +#ifndef SYS_mprotect_key +# define SYS_mprotect_key 329 +#endif +#ifndef SYS_pkey_alloc +# define SYS_pkey_alloc 330 +# define SYS_pkey_free 331 +#endif #define REG_IP_IDX REG_RIP #define si_pkey_offset 0x20 + #endif
void dump_mem(void *dumpme, int len_bytes)
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Yazen Ghannam yazen.ghannam@amd.com
commit d65dfc81bb3894fdb68cbc74bbf5fb48d2354071 upstream.
The AMD severity grading function was introduced in kernel 4.1. The current logic can possibly give MCE_AR_SEVERITY for uncorrectable errors in kernel context. The system may then get stuck in a loop as memory_failure() will try to handle the bad kernel memory and find it busy.
Return MCE_PANIC_SEVERITY for all UC errors IN_KERNEL context on AMD systems.
After:
b2f9d678e28c ("x86/mce: Check for faults tagged in EXTABLE_CLASS_FAULT exception table entries")
was accepted in v4.6, this issue was masked because of the tail-end attempt at kernel mode recovery in the #MC handler.
However, uncorrectable errors IN_KERNEL context should always be considered unrecoverable and cause a panic.
Signed-off-by: Yazen Ghannam yazen.ghannam@amd.com Signed-off-by: Borislav Petkov bp@suse.de Cc: Linus Torvalds torvalds@linux-foundation.org Cc: Peter Zijlstra peterz@infradead.org Cc: Thomas Gleixner tglx@linutronix.de Cc: Tony Luck tony.luck@intel.com Cc: linux-edac linux-edac@vger.kernel.org Fixes: bf80bbd7dcf5 (x86/mce: Add an AMD severities-grading function) Link: http://lkml.kernel.org/r/20171106174633.13576-1-bp@alien8.de Signed-off-by: Ingo Molnar mingo@kernel.org Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org
--- arch/x86/kernel/cpu/mcheck/mce-severity.c | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-)
--- a/arch/x86/kernel/cpu/mcheck/mce-severity.c +++ b/arch/x86/kernel/cpu/mcheck/mce-severity.c @@ -245,6 +245,9 @@ static int mce_severity_amd(struct mce *
if (m->status & MCI_STATUS_UC) {
+ if (ctx == IN_KERNEL) + return MCE_PANIC_SEVERITY; + /* * On older systems where overflow_recov flag is not present, we * should simply panic if an error overflow occurs. If @@ -255,10 +258,6 @@ static int mce_severity_amd(struct mce * if (mce_flags.smca) return mce_severity_amd_smca(m, ctx);
- /* software can try to contain */ - if (!(m->mcgstatus & MCG_STATUS_RIPV) && (ctx == IN_KERNEL)) - return MCE_PANIC_SEVERITY; - /* kill current process */ return MCE_AR_SEVERITY; } else {
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Hans de Goede hdegoede@redhat.com
commit 3b95206110a2c13076c3a7fa8ddeae36c2dbcf42 upstream.
It seems that the WMI GUID used by the PEAQ 2-in-1 WMI hotkeys is not as unique as a GUID should be and is used on some other devices too.
This is causing spurious key-press reports on these other devices.
This commits adds a DMI check to the PEAQ 2-in-1 WMI hotkeys driver to ensure that it is actually running on a PEAQ 2-in-1, fixing the spurious key-presses on these other devices.
BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1497861 BugLink: https://bugzilla.suse.com/attachment.cgi?id=743182 Signed-off-by: Hans de Goede hdegoede@redhat.com Signed-off-by: Andy Shevchenko andriy.shevchenko@linux.intel.com Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org
--- drivers/platform/x86/peaq-wmi.c | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+)
--- a/drivers/platform/x86/peaq-wmi.c +++ b/drivers/platform/x86/peaq-wmi.c @@ -8,6 +8,7 @@ */
#include <linux/acpi.h> +#include <linux/dmi.h> #include <linux/input-polldev.h> #include <linux/kernel.h> #include <linux/module.h> @@ -64,8 +65,22 @@ static void peaq_wmi_poll(struct input_p } }
+/* Some other devices (Shuttle XS35) use the same WMI GUID for other purposes */ +static const struct dmi_system_id peaq_dmi_table[] = { + { + .matches = { + DMI_MATCH(DMI_SYS_VENDOR, "PEAQ"), + DMI_MATCH(DMI_PRODUCT_NAME, "PEAQ PMM C1010 MD99187"), + }, + }, +}; + static int __init peaq_wmi_init(void) { + /* WMI GUID is not unique, also check for a DMI match */ + if (!dmi_check_system(peaq_dmi_table)) + return -ENODEV; + if (!wmi_has_guid(PEAQ_DOLBY_BUTTON_GUID)) return -ENODEV;
@@ -86,6 +101,9 @@ static int __init peaq_wmi_init(void)
static void __exit peaq_wmi_exit(void) { + if (!dmi_check_system(peaq_dmi_table)) + return; + if (!wmi_has_guid(PEAQ_DOLBY_BUTTON_GUID)) return;
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Hans de Goede hdegoede@redhat.com
commit d6fa71f1c003fb2bc824276bb424a4171f9a717f upstream.
Add missing terminating entry to peaq_dmi_table.
Fixes: 3b95206110a2 ("platform/x86: peaq-wmi: Add DMI check before ...") Reported-by: Fengguang Wu fengguang.wu@intel.com Signed-off-by: Hans de Goede hdegoede@redhat.com Signed-off-by: Andy Shevchenko andriy.shevchenko@linux.intel.com Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org
--- drivers/platform/x86/peaq-wmi.c | 1 + 1 file changed, 1 insertion(+)
--- a/drivers/platform/x86/peaq-wmi.c +++ b/drivers/platform/x86/peaq-wmi.c @@ -73,6 +73,7 @@ static const struct dmi_system_id peaq_d DMI_MATCH(DMI_PRODUCT_NAME, "PEAQ PMM C1010 MD99187"), }, }, + {} };
static int __init peaq_wmi_init(void)
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jason Gerecke killertofu@gmail.com
commit 885e89f601a52cc6fb025b009df58ba83d142734 upstream.
The WACOM_PEN_FIELD macro is used to determine if a given HID field should be associated with pen input. This field includes several known collection types that Wacom pen data is contained in, but the WACOM_HID_WD_PEN application collection type is notably missing. This can result in fields within this kind of collection being completely ignored by the `wacom_usage_mapping` function, preventing the later '*_event' functions from being notified about changes to their value.
Fixes: c9c095874a ("HID: wacom: generic: Support and use 'Custom HID' mode and usages") Fixes: ac2423c975 ("HID: wacom: generic: add vendor defined touch") Reviewed-by: Ping Cheng ping.cheng@wacom.com Reviewed-by: Benjamin Tissoires benjamin.tissoires@redhat.com Signed-off-by: Jason Gerecke jason.gerecke@wacom.com Signed-off-by: Jiri Kosina jkosina@suse.cz Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org
--- drivers/hid/wacom_wac.h | 1 + 1 file changed, 1 insertion(+)
--- a/drivers/hid/wacom_wac.h +++ b/drivers/hid/wacom_wac.h @@ -166,6 +166,7 @@ ((f)->physical == HID_DG_PEN) || \ ((f)->application == HID_DG_PEN) || \ ((f)->application == HID_DG_DIGITIZER) || \ + ((f)->application == WACOM_HID_WD_PEN) || \ ((f)->application == WACOM_HID_WD_DIGITIZER) || \ ((f)->application == WACOM_HID_G9_PEN) || \ ((f)->application == WACOM_HID_G11_PEN))
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Bjorn Andersson bjorn.andersson@linaro.org
commit 1e0d5615bbc37deb7732491798abccf8d3c3d244 upstream.
The qcom_glink_native driver is missing a MODULE_LICENSE(), correct this.
Fixes: 835764ddd9af ("rpmsg: glink: Move the common glink protocol implementation to glink_native.c") Reported-by: Randy Dunlap rdunlap@infradead.org Signed-off-by: Bjorn Andersson bjorn.andersson@linaro.org Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org
--- drivers/rpmsg/qcom_glink_native.c | 3 +++ 1 file changed, 3 insertions(+)
--- a/drivers/rpmsg/qcom_glink_native.c +++ b/drivers/rpmsg/qcom_glink_native.c @@ -1616,3 +1616,6 @@ void qcom_glink_native_unregister(struct device_unregister(glink->dev); } EXPORT_SYMBOL_GPL(qcom_glink_native_unregister); + +MODULE_DESCRIPTION("Qualcomm GLINK driver"); +MODULE_LICENSE("GPL v2");
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Aditya Shankar aditya.shankar@microchip.com
commit 1bbf6a6d4091affb27ec0a19d7aa7887ce72f610 upstream.
Commit 46949b48568b ("staging: wilc1000: New cfg packet format in handle_set_wfi_drv_handler") updated the frame format sent from host to the firmware. The code to update the bssid offset in the new frame was part of a second patch in the series which did not make it in and thus causes connection problems after associating to an AP.
This fix adds the proper offset of the bssid value in the Tx queue buffer to fix the connection issues.
Fixes: 46949b48568b ("staging: wilc1000: New cfg packet format in handle_set_wfi_drv_handler") Signed-off-by: Aditya Shankar Aditya.Shankar@microchip.com Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org
--- drivers/staging/wilc1000/wilc_wlan.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/staging/wilc1000/wilc_wlan.c +++ b/drivers/staging/wilc1000/wilc_wlan.c @@ -714,7 +714,7 @@ int wilc_wlan_handle_txq(struct net_devi char *bssid = ((struct tx_complete_data *)(tqe->priv))->bssid;
buffer_offset = ETH_ETHERNET_HDR_OFFSET; - memcpy(&txb[offset + 4], bssid, 6); + memcpy(&txb[offset + 8], bssid, 6); } else { buffer_offset = HOST_HDR_OFFSET; }
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Huacai Chen chenhc@lemote.com
commit 16808dcf605e6302319a8c3266789b76d4c0983b upstream.
In commit c075b6f2d357ea9 ("staging: sm750fb: Replace POKE32 and PEEK32 by inline functions"), POKE32 has been replaced by the inline function poke32. But it exchange the "addr" and "data" parameters by mistake, so fix it.
Fixes: c075b6f2d357ea9 ("staging: sm750fb: Replace POKE32 and PEEK32 by inline functions"), Signed-off-by: Huacai Chen chenhc@lemote.com Signed-off-by: Liangliang Huang huangll@lemote.com Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org
--- drivers/staging/sm750fb/ddk750_chip.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/staging/sm750fb/ddk750_chip.h +++ b/drivers/staging/sm750fb/ddk750_chip.h @@ -18,7 +18,7 @@ static inline u32 peek32(u32 addr) return readl(addr + mmio750); }
-static inline void poke32(u32 data, u32 addr) +static inline void poke32(u32 addr, u32 data) { writel(data, addr + mmio750); }
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Gilad Ben-Yossef gilad@benyossef.com
commit e0b3f39092a1cff5548cbaf40096ec25e7721de6 upstream.
Fix a wrong offset used in splitting a 64 DMA address to MSB/LSB parts needed for scatter/gather HW descriptors causing operations relying on them to fail on 64 bit platforms.
Fixes: c6f7f2f4591f ("staging: ccree: refactor LLI access macros") Reported-by: Stuart Yoder stuart.yoder@arm.com Signed-off-by: Gilad Ben-Yossef gilad@benyossef.com Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org
--- drivers/staging/ccree/cc_lli_defs.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/staging/ccree/cc_lli_defs.h +++ b/drivers/staging/ccree/cc_lli_defs.h @@ -59,7 +59,7 @@ static inline void cc_lli_set_addr(u32 * lli_p[LLI_WORD0_OFFSET] = (addr & U32_MAX); #ifdef CONFIG_ARCH_DMA_ADDR_T_64BIT lli_p[LLI_WORD1_OFFSET] &= ~LLI_HADDR_MASK; - lli_p[LLI_WORD1_OFFSET] |= FIELD_PREP(LLI_HADDR_MASK, (addr >> 16)); + lli_p[LLI_WORD1_OFFSET] |= FIELD_PREP(LLI_HADDR_MASK, (addr >> 32)); #endif /* CONFIG_ARCH_DMA_ADDR_T_64BIT */ }
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Johan Hovold johan@kernel.org
commit 770b03c2ca4aa44d226cf248f86aa23e546147d0 upstream.
Remove erroneous spi_master_put() after controller deregistration which would access the already freed spi controller.
Note that spi_unregister_master() drops our only controller reference.
Fixes: ba3e67001b42 ("greybus: SPI: convert to a gpbridge driver") Signed-off-by: Johan Hovold johan@kernel.org Reviewed-by: Rui Miguel Silva rmfrfs@gmail.com Acked-by: Viresh Kumar viresh.kumar@linaro.org Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org
--- drivers/staging/greybus/spilib.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-)
--- a/drivers/staging/greybus/spilib.c +++ b/drivers/staging/greybus/spilib.c @@ -544,12 +544,15 @@ int gb_spilib_master_init(struct gb_conn
return 0;
-exit_spi_unregister: - spi_unregister_master(master); exit_spi_put: spi_master_put(master);
return ret; + +exit_spi_unregister: + spi_unregister_master(master); + + return ret; } EXPORT_SYMBOL_GPL(gb_spilib_master_init);
@@ -558,7 +561,6 @@ void gb_spilib_master_exit(struct gb_con struct spi_master *master = gb_connection_get_data(connection);
spi_unregister_master(master); - spi_master_put(master); } EXPORT_SYMBOL_GPL(gb_spilib_master_exit);
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Hans de Goede hdegoede@redhat.com
commit ce10d7b4e8e3574b9616e54a09d64521b9aeb8b6 upstream.
The x and y hints receives from the host are unsigned 32 bit integers and they get set to -1 (0xffffffff) when invalid. Before this commit the vboxvideo driver was storing them in an u16 causing the -1 to be truncated to 65535 which, once reported to userspace, was breaking gnome 3.26+ in Wayland mode.
This commit stores the host values in 32 bit variables, removing the truncation and checks for -1, replacing it with 0 as -1 is not a valid suggested-offset-property value. Likewise the properties are now initialized to 0 instead of -1, since -1 is not a valid value. This fixes gnome 3.26+ in Wayland mode not working with the vboxvideo driver.
Reported-by: Gianfranco Costamagna locutusofborg@debian.org Cc: Michael Thayer michael.thayer@oracle.com Signed-off-by: Hans de Goede hdegoede@redhat.com Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org
--- drivers/staging/vboxvideo/vbox_drv.h | 8 ++++---- drivers/staging/vboxvideo/vbox_irq.c | 4 ++-- drivers/staging/vboxvideo/vbox_mode.c | 26 ++++++++++++++++++-------- 3 files changed, 24 insertions(+), 14 deletions(-)
--- a/drivers/staging/vboxvideo/vbox_drv.h +++ b/drivers/staging/vboxvideo/vbox_drv.h @@ -137,8 +137,8 @@ struct vbox_connector { char name[32]; struct vbox_crtc *vbox_crtc; struct { - u16 width; - u16 height; + u32 width; + u32 height; bool disconnected; } mode_hint; }; @@ -150,8 +150,8 @@ struct vbox_crtc { unsigned int crtc_id; u32 fb_offset; bool cursor_enabled; - u16 x_hint; - u16 y_hint; + u32 x_hint; + u32 y_hint; };
struct vbox_encoder { --- a/drivers/staging/vboxvideo/vbox_irq.c +++ b/drivers/staging/vboxvideo/vbox_irq.c @@ -150,8 +150,8 @@ static void vbox_update_mode_hints(struc
disconnected = !(hints->enabled); crtc_id = vbox_conn->vbox_crtc->crtc_id; - vbox_conn->mode_hint.width = hints->cx & 0x8fff; - vbox_conn->mode_hint.height = hints->cy & 0x8fff; + vbox_conn->mode_hint.width = hints->cx; + vbox_conn->mode_hint.height = hints->cy; vbox_conn->vbox_crtc->x_hint = hints->dx; vbox_conn->vbox_crtc->y_hint = hints->dy; vbox_conn->mode_hint.disconnected = disconnected; --- a/drivers/staging/vboxvideo/vbox_mode.c +++ b/drivers/staging/vboxvideo/vbox_mode.c @@ -553,12 +553,22 @@ static int vbox_get_modes(struct drm_con ++num_modes; } vbox_set_edid(connector, preferred_width, preferred_height); - drm_object_property_set_value( - &connector->base, vbox->dev->mode_config.suggested_x_property, - vbox_connector->vbox_crtc->x_hint); - drm_object_property_set_value( - &connector->base, vbox->dev->mode_config.suggested_y_property, - vbox_connector->vbox_crtc->y_hint); + + if (vbox_connector->vbox_crtc->x_hint != -1) + drm_object_property_set_value(&connector->base, + vbox->dev->mode_config.suggested_x_property, + vbox_connector->vbox_crtc->x_hint); + else + drm_object_property_set_value(&connector->base, + vbox->dev->mode_config.suggested_x_property, 0); + + if (vbox_connector->vbox_crtc->y_hint != -1) + drm_object_property_set_value(&connector->base, + vbox->dev->mode_config.suggested_y_property, + vbox_connector->vbox_crtc->y_hint); + else + drm_object_property_set_value(&connector->base, + vbox->dev->mode_config.suggested_y_property, 0);
return num_modes; } @@ -640,9 +650,9 @@ static int vbox_connector_init(struct dr
drm_mode_create_suggested_offset_properties(dev); drm_object_attach_property(&connector->base, - dev->mode_config.suggested_x_property, -1); + dev->mode_config.suggested_x_property, 0); drm_object_attach_property(&connector->base, - dev->mode_config.suggested_y_property, -1); + dev->mode_config.suggested_y_property, 0); drm_connector_register(connector);
drm_mode_connector_attach_encoder(connector, encoder);
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Hans de Goede hdegoede@redhat.com
commit 66d32fdcbf03851724a8b551d490ae1ddfe6eef2 upstream.
Commit 2ba8444c97b1 ("staging:r8188eu: move IV/ICV trimming into decrypt() and also place it after rtl88eu_mon_recv_hook()") breaks ARP.
After this commit ssh-ing to a laptop with r8188eu wifi no longer works if the machine connecting has never communicated with the laptop before. This is 100% reproducable using "arp -d <ipv4> && ssh <ipv4>" to ssh to a laptop with r8188eu wifi.
This commit reverts 4 commits in total:
1. Commit 79650ffde38e ("staging:r8188eu: trim IV/ICV fields in validate_recv_data_frame()") This commit depends on 2 of the other commits being reverted.
2. Commit 02b19b4c4920 ("staging:r8188eu: inline unprotect_frame() in mon_recv_decrypted_recv()") The inline code is wrong the un-inlined version contains: if (skb->len < hdr_len + iv_len + icv_len) return; ... Where as the inline-ed code introduced by this commit does: if (skb->len < hdr_len + iv_len + icv_len) { ... Note the same check, but now to actually continue doing ... instead of to not do it, so this commit is no good.
3. Commit d86e16da6a5d ("staging:r8188eu: use different mon_recv_decrypted() inside rtl88eu_mon_recv_hook() and rtl88eu_mon_xmit_hook().") This commit introduced a 1:1 copy of a function so that one of the 2 copies can be modified in the 2 commits we're already reverting.
4. Commit 2ba8444c97b1 ("staging:r8188eu: move IV/ICV trimming into decrypt() and also place it after rtl88eu_mon_recv_hook()") This is the commit actually breaking ARP.
Note this commit is a straight-forward squash of the revert of these 4 commits, without any changes.
Cc: Ivan Safonov insafonov@gmail.com Signed-off-by: Hans de Goede hdegoede@redhat.com Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org
--- drivers/staging/rtl8188eu/core/rtw_recv.c | 83 ++++++++++++++++++------------ drivers/staging/rtl8188eu/os_dep/mon.c | 34 +----------- 2 files changed, 55 insertions(+), 62 deletions(-)
--- a/drivers/staging/rtl8188eu/core/rtw_recv.c +++ b/drivers/staging/rtl8188eu/core/rtw_recv.c @@ -259,10 +259,12 @@ static int recvframe_chkmic(struct adapt }
/* icv_len included the mic code */ - datalen = precvframe->pkt->len-prxattrib->hdrlen - 8; + datalen = precvframe->pkt->len-prxattrib->hdrlen - + prxattrib->iv_len-prxattrib->icv_len-8; pframe = precvframe->pkt->data; - payload = pframe+prxattrib->hdrlen; + payload = pframe+prxattrib->hdrlen+prxattrib->iv_len;
+ RT_TRACE(_module_rtl871x_recv_c_, _drv_info_, ("\n prxattrib->iv_len=%d prxattrib->icv_len=%d\n", prxattrib->iv_len, prxattrib->icv_len)); rtw_seccalctkipmic(mickey, pframe, payload, datalen, &miccode[0], (unsigned char)prxattrib->priority); /* care the length of the data */
@@ -407,15 +409,9 @@ static struct recv_frame *decryptor(stru default: break; } - if (res != _FAIL) { - memmove(precv_frame->pkt->data + precv_frame->attrib.iv_len, precv_frame->pkt->data, precv_frame->attrib.hdrlen); - skb_pull(precv_frame->pkt, precv_frame->attrib.iv_len); - skb_trim(precv_frame->pkt, precv_frame->pkt->len - precv_frame->attrib.icv_len); - } } else if (prxattrib->bdecrypted == 1 && prxattrib->encrypt > 0 && - (psecuritypriv->busetkipkey == 1 || prxattrib->encrypt != _TKIP_)) { - psecuritypriv->hw_decrypted = true; - } + (psecuritypriv->busetkipkey == 1 || prxattrib->encrypt != _TKIP_)) + psecuritypriv->hw_decrypted = true;
if (res == _FAIL) { rtw_free_recvframe(return_packet, &padapter->recvpriv.free_recv_queue); @@ -456,7 +452,7 @@ static struct recv_frame *portctrl(struc
if (auth_alg == 2) { /* get ether_type */ - ptr = ptr + pfhdr->attrib.hdrlen + LLC_HEADER_SIZE; + ptr = ptr + pfhdr->attrib.hdrlen + LLC_HEADER_SIZE + pfhdr->attrib.iv_len; memcpy(&be_tmp, ptr, 2); ether_type = ntohs(be_tmp);
@@ -1138,8 +1134,6 @@ static int validate_recv_data_frame(stru }
if (pattrib->privacy) { - struct sk_buff *skb = precv_frame->pkt; - RT_TRACE(_module_rtl871x_recv_c_, _drv_info_, ("validate_recv_data_frame:pattrib->privacy=%x\n", pattrib->privacy)); RT_TRACE(_module_rtl871x_recv_c_, _drv_info_, ("\n ^^^^^^^^^^^IS_MCAST(pattrib->ra(0x%02x))=%d^^^^^^^^^^^^^^^6\n", pattrib->ra[0], IS_MCAST(pattrib->ra)));
@@ -1148,13 +1142,6 @@ static int validate_recv_data_frame(stru RT_TRACE(_module_rtl871x_recv_c_, _drv_info_, ("\n pattrib->encrypt=%d\n", pattrib->encrypt));
SET_ICE_IV_LEN(pattrib->iv_len, pattrib->icv_len, pattrib->encrypt); - - if (pattrib->bdecrypted == 1 && pattrib->encrypt > 0) { - memmove(skb->data + pattrib->iv_len, - skb->data, pattrib->hdrlen); - skb_pull(skb, pattrib->iv_len); - skb_trim(skb, skb->len - pattrib->icv_len); - } } else { pattrib->encrypt = 0; pattrib->iv_len = 0; @@ -1274,7 +1261,6 @@ static int validate_recv_frame(struct ad * Hence forward the frame to the monitor anyway to preserve the order * in which frames were received. */ - rtl88eu_mon_recv_hook(adapter->pmondev, precv_frame);
exit: @@ -1296,8 +1282,11 @@ static int wlanhdr_to_ethhdr(struct recv u8 *ptr = precvframe->pkt->data; struct rx_pkt_attrib *pattrib = &precvframe->attrib;
- psnap = (struct ieee80211_snap_hdr *)(ptr+pattrib->hdrlen); - psnap_type = ptr+pattrib->hdrlen + SNAP_SIZE; + if (pattrib->encrypt) + skb_trim(precvframe->pkt, precvframe->pkt->len - pattrib->icv_len); + + psnap = (struct ieee80211_snap_hdr *)(ptr+pattrib->hdrlen + pattrib->iv_len); + psnap_type = ptr+pattrib->hdrlen + pattrib->iv_len+SNAP_SIZE; /* convert hdr + possible LLC headers into Ethernet header */ if ((!memcmp(psnap, rtw_rfc1042_header, SNAP_SIZE) && (!memcmp(psnap_type, SNAP_ETH_TYPE_IPX, 2) == false) && @@ -1310,9 +1299,12 @@ static int wlanhdr_to_ethhdr(struct recv bsnaphdr = false; }
- rmv_len = pattrib->hdrlen + (bsnaphdr ? SNAP_SIZE : 0); + rmv_len = pattrib->hdrlen + pattrib->iv_len + (bsnaphdr ? SNAP_SIZE : 0); len = precvframe->pkt->len - rmv_len;
+ RT_TRACE(_module_rtl871x_recv_c_, _drv_info_, + ("\n===pattrib->hdrlen: %x, pattrib->iv_len:%x===\n\n", pattrib->hdrlen, pattrib->iv_len)); + memcpy(&be_tmp, ptr+rmv_len, 2); eth_type = ntohs(be_tmp); /* pattrib->ether_type */ pattrib->eth_type = eth_type; @@ -1337,6 +1329,7 @@ static struct recv_frame *recvframe_defr struct __queue *defrag_q) { struct list_head *plist, *phead; + u8 wlanhdr_offset; u8 curfragnum; struct recv_frame *pfhdr, *pnfhdr; struct recv_frame *prframe, *pnextrframe; @@ -1385,7 +1378,12 @@ static struct recv_frame *recvframe_defr /* copy the 2nd~n fragment frame's payload to the first fragment */ /* get the 2nd~last fragment frame's payload */
- skb_pull(pnextrframe->pkt, pnfhdr->attrib.hdrlen); + wlanhdr_offset = pnfhdr->attrib.hdrlen + pnfhdr->attrib.iv_len; + + skb_pull(pnextrframe->pkt, wlanhdr_offset); + + /* append to first fragment frame's tail (if privacy frame, pull the ICV) */ + skb_trim(prframe->pkt, prframe->pkt->len - pfhdr->attrib.icv_len);
/* memcpy */ memcpy(skb_tail_pointer(pfhdr->pkt), pnfhdr->pkt->data, @@ -1393,7 +1391,7 @@ static struct recv_frame *recvframe_defr
skb_put(prframe->pkt, pnfhdr->pkt->len);
- pfhdr->attrib.icv_len = 0; + pfhdr->attrib.icv_len = pnfhdr->attrib.icv_len; plist = plist->next; }
@@ -1519,6 +1517,11 @@ static int amsdu_to_msdu(struct adapter nr_subframes = 0; pattrib = &prframe->attrib;
+ skb_pull(prframe->pkt, prframe->attrib.hdrlen); + + if (prframe->attrib.iv_len > 0) + skb_pull(prframe->pkt, prframe->attrib.iv_len); + a_len = prframe->pkt->len;
pdata = prframe->pkt->data; @@ -1887,6 +1890,24 @@ static int process_recv_indicatepkts(str return retval; }
+static int recv_func_prehandle(struct adapter *padapter, + struct recv_frame *rframe) +{ + int ret = _SUCCESS; + struct __queue *pfree_recv_queue = &padapter->recvpriv.free_recv_queue; + + /* check the frame crtl field and decache */ + ret = validate_recv_frame(padapter, rframe); + if (ret != _SUCCESS) { + RT_TRACE(_module_rtl871x_recv_c_, _drv_info_, ("recv_func: validate_recv_frame fail! drop pkt\n")); + rtw_free_recvframe(rframe, pfree_recv_queue);/* free this recv_frame */ + goto exit; + } + +exit: + return ret; +} + static int recv_func_posthandle(struct adapter *padapter, struct recv_frame *prframe) { @@ -1939,7 +1960,6 @@ static int recv_func(struct adapter *pad struct rx_pkt_attrib *prxattrib = &rframe->attrib; struct security_priv *psecuritypriv = &padapter->securitypriv; struct mlme_priv *mlmepriv = &padapter->mlmepriv; - struct __queue *pfree_recv_queue = &padapter->recvpriv.free_recv_queue;
/* check if need to handle uc_swdec_pending_queue*/ if (check_fwstate(mlmepriv, WIFI_STATION_STATE) && psecuritypriv->busetkipkey) { @@ -1951,12 +1971,9 @@ static int recv_func(struct adapter *pad } }
- /* check the frame crtl field and decache */ - ret = validate_recv_frame(padapter, rframe); - if (ret != _SUCCESS) { - RT_TRACE(_module_rtl871x_recv_c_, _drv_info_, ("recv_func: validate_recv_frame fail! drop pkt\n")); - rtw_free_recvframe(rframe, pfree_recv_queue);/* free this recv_frame */ - } else { + ret = recv_func_prehandle(padapter, rframe); + + if (ret == _SUCCESS) { /* check if need to enqueue into uc_swdec_pending_queue*/ if (check_fwstate(mlmepriv, WIFI_STATION_STATE) && !IS_MCAST(prxattrib->ra) && prxattrib->encrypt > 0 && --- a/drivers/staging/rtl8188eu/os_dep/mon.c +++ b/drivers/staging/rtl8188eu/os_dep/mon.c @@ -66,34 +66,6 @@ static void mon_recv_decrypted(struct ne netif_rx(skb); }
-static void mon_recv_decrypted_recv(struct net_device *dev, const u8 *data, - int data_len) -{ - struct sk_buff *skb; - struct ieee80211_hdr *hdr; - int hdr_len; - - skb = netdev_alloc_skb(dev, data_len); - if (!skb) - return; - memcpy(skb_put(skb, data_len), data, data_len); - - /* - * Frame data is not encrypted. Strip off protection so - * userspace doesn't think that it is. - */ - - hdr = (struct ieee80211_hdr *)skb->data; - hdr_len = ieee80211_hdrlen(hdr->frame_control); - - if (ieee80211_has_protected(hdr->frame_control)) - hdr->frame_control &= ~cpu_to_le16(IEEE80211_FCTL_PROTECTED); - - skb->ip_summed = CHECKSUM_UNNECESSARY; - skb->protocol = eth_type_trans(skb, dev); - netif_rx(skb); -} - static void mon_recv_encrypted(struct net_device *dev, const u8 *data, int data_len) { @@ -110,6 +82,7 @@ static void mon_recv_encrypted(struct ne void rtl88eu_mon_recv_hook(struct net_device *dev, struct recv_frame *frame) { struct rx_pkt_attrib *attr; + int iv_len, icv_len; int data_len; u8 *data;
@@ -122,8 +95,11 @@ void rtl88eu_mon_recv_hook(struct net_de data = frame->pkt->data; data_len = frame->pkt->len;
+ /* Broadcast and multicast frames don't have attr->{iv,icv}_len set */ + SET_ICE_IV_LEN(iv_len, icv_len, attr->encrypt); + if (attr->bdecrypted) - mon_recv_decrypted_recv(dev, data, data_len); + mon_recv_decrypted(dev, data, data_len, iv_len, icv_len); else mon_recv_encrypted(dev, data, data_len); }
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Johan Hovold johan@kernel.org
commit 67f7b2781fafcc0f52464880154b320fea1ae982 upstream.
The controller is typically freed as part of device_unregister() so store the bus id before deregistration to avoid use-after-free when the id is later released.
Fixes: 9b61e302210e ("spi: Pick spi bus number from Linux idr or spi alias") Signed-off-by: Johan Hovold johan@kernel.org Signed-off-by: Mark Brown broonie@kernel.org Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org
--- drivers/spi/spi.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)
--- a/drivers/spi/spi.c +++ b/drivers/spi/spi.c @@ -2245,11 +2245,12 @@ static int __unregister(struct device *d void spi_unregister_controller(struct spi_controller *ctlr) { struct spi_controller *found; + int id = ctlr->bus_num; int dummy;
/* First make sure that this controller was ever added */ mutex_lock(&board_lock); - found = idr_find(&spi_master_idr, ctlr->bus_num); + found = idr_find(&spi_master_idr, id); mutex_unlock(&board_lock); if (found != ctlr) { dev_dbg(&ctlr->dev, @@ -2269,7 +2270,7 @@ void spi_unregister_controller(struct sp device_unregister(&ctlr->dev); /* free bus id */ mutex_lock(&board_lock); - idr_remove(&spi_master_idr, ctlr->bus_num); + idr_remove(&spi_master_idr, id); mutex_unlock(&board_lock); } EXPORT_SYMBOL_GPL(spi_unregister_controller);
On 11/19/2017 06:59 AM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.14.1 release. There are 31 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 Tue Nov 21 14:59:32 UTC 2017. Anything received after that time might be too late.
Build results: total: 145 pass: 143 fail: 2 Failed builds: sparc32:allmodconfig sparc64:allmodconfig Qemu test results: total: 123 pass: 123 fail: 0
Building sparc32:allmodconfig ... failed -------------- Error log: /opt/buildbot/slave/stable-queue-4.14/build/drivers/net/ethernet/intel/i40e/i40e_ethtool.c: In function 'i40e_set_priv_flags': /opt/buildbot/slave/stable-queue-4.14/build/drivers/net/ethernet/intel/i40e/i40e_ethtool.c:4150:2: error: implicit declaration of function 'cmpxchg64'
Building sparc64:allmodconfig ... failed -------------- Error log: In file included from /opt/buildbot/slave/stable-queue-4.14/build/arch/sparc/include/asm/mmu_context.h:5:0, from /opt/buildbot/slave/stable-queue-4.14/build/include/linux/mmu_context.h:5, from /opt/buildbot/slave/stable-queue-4.14/build/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h:29, from /opt/buildbot/slave/stable-queue-4.14/build/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c:23: /opt/buildbot/slave/stable-queue-4.14/build/arch/sparc/include/asm/mmu_context_64.h:23:37: error: unknown type name 'per_cpu_secondary_mm' [and more]
The errors are inherited from upstream (4.14) and have since been fixed there.
23198ddffb6c sparc32: Add cmpxchg64(). 01c3f0a42a2a sparc64: mmu_context: Add missing include files
Guenter
On Mon, 2017-11-20 at 06:27 -0800, Guenter Roeck wrote:
On 11/19/2017 06:59 AM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.14.1 release. There are 31 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 Tue Nov 21 14:59:32 UTC 2017. Anything received after that time might be too late.
Build results: total: 145 pass: 143 fail: 2 Failed builds: sparc32:allmodconfig sparc64:allmodconfig Qemu test results: total: 123 pass: 123 fail: 0
Building sparc32:allmodconfig ... failed
Error log: /opt/buildbot/slave/stable-queue-4.14/build/drivers/net/ethernet/intel/i40e/i40e_ethtool.c: In function 'i40e_set_priv_flags': /opt/buildbot/slave/stable-queue-4.14/build/drivers/net/ethernet/intel/i40e/i40e_ethtool.c:4150:2: error: implicit declaration of function 'cmpxchg64'
Building sparc64:allmodconfig ... failed
Error log: In file included from /opt/buildbot/slave/stable-queue-4.14/build/arch/sparc/include/asm/mmu_context.h:5:0, from /opt/buildbot/slave/stable-queue-4.14/build/include/linux/mmu_context.h:5, from /opt/buildbot/slave/stable-queue-4.14/build/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h:29, from /opt/buildbot/slave/stable-queue-4.14/build/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c:23: /opt/buildbot/slave/stable-queue-4.14/build/arch/sparc/include/asm/mmu_context_64.h:23:37: error: unknown type name 'per_cpu_secondary_mm' [and more]
The errors are inherited from upstream (4.14) and have since been fixed there.
23198ddffb6c sparc32: Add cmpxchg64(). 01c3f0a42a2a sparc64: mmu_context: Add missing include files
Not all 32-bit configurations can provide cmpxchg64(). i40e's use of cmpxchg64() appears to be fixed by:
b74f571f59a8 i40e/i40evf: organize and re-number feature flags b48be9978e4b i40e: fix flags declaration
Ben.
Guenter
On Tue, Nov 21, 2017 at 03:26:10PM +0000, Ben Hutchings wrote:
On Mon, 2017-11-20 at 06:27 -0800, Guenter Roeck wrote:
On 11/19/2017 06:59 AM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.14.1 release. There are 31 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 Tue Nov 21 14:59:32 UTC 2017. Anything received after that time might be too late.
Build results: total: 145 pass: 143 fail: 2 Failed builds: sparc32:allmodconfig sparc64:allmodconfig Qemu test results: total: 123 pass: 123 fail: 0
Building sparc32:allmodconfig ... failed
Error log: /opt/buildbot/slave/stable-queue-4.14/build/drivers/net/ethernet/intel/i40e/i40e_ethtool.c: In function 'i40e_set_priv_flags': /opt/buildbot/slave/stable-queue-4.14/build/drivers/net/ethernet/intel/i40e/i40e_ethtool.c:4150:2: error: implicit declaration of function 'cmpxchg64'
Building sparc64:allmodconfig ... failed
Error log: In file included from /opt/buildbot/slave/stable-queue-4.14/build/arch/sparc/include/asm/mmu_context.h:5:0, from /opt/buildbot/slave/stable-queue-4.14/build/include/linux/mmu_context.h:5, from /opt/buildbot/slave/stable-queue-4.14/build/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h:29, from /opt/buildbot/slave/stable-queue-4.14/build/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c:23: /opt/buildbot/slave/stable-queue-4.14/build/arch/sparc/include/asm/mmu_context_64.h:23:37: error: unknown type name 'per_cpu_secondary_mm' [and more]
The errors are inherited from upstream (4.14) and have since been fixed there.
23198ddffb6c sparc32: Add cmpxchg64(). 01c3f0a42a2a sparc64: mmu_context: Add missing include files
Not all 32-bit configurations can provide cmpxchg64(). i40e's use of cmpxchg64() appears to be fixed by:
b74f571f59a8 i40e/i40evf: organize and re-number feature flags b48be9978e4b i40e: fix flags declaration
So without those patches, are any specific arches/configs broken for 4.14?
thanks,
greg k-h
On Tue, 2017-11-21 at 17:35 +0100, Greg Kroah-Hartman wrote:
On Tue, Nov 21, 2017 at 03:26:10PM +0000, Ben Hutchings wrote:
[...]
Not all 32-bit configurations can provide cmpxchg64(). i40e's use of cmpxchg64() appears to be fixed by:
b74f571f59a8 i40e/i40evf: organize and re-number feature flags b48be9978e4b i40e: fix flags declaration
So without those patches, are any specific arches/configs broken for 4.14?
32-bit parisc is.
Ben.
On Tue, Nov 21, 2017 at 04:46:18PM +0000, Ben Hutchings wrote:
On Tue, 2017-11-21 at 17:35 +0100, Greg Kroah-Hartman wrote:
On Tue, Nov 21, 2017 at 03:26:10PM +0000, Ben Hutchings wrote:
[...]
Not all 32-bit configurations can provide cmpxchg64(). i40e's use of cmpxchg64() appears to be fixed by:
b74f571f59a8 i40e/i40evf: organize and re-number feature flags b48be9978e4b i40e: fix flags declaration
So without those patches, are any specific arches/configs broken for 4.14?
32-bit parisc is.
Ok, but that's a horrid hack on the i40e driver, it just happens to move the bitfield to a 32bit variable. Can't we just provide a "real" cmpxchg64() for 32-bit parisc? Or mark this driver as not buildable on that platform?
I doubt anyone is doing 40gb networking on parisc :)
thanks,
greg k-h
On Tue, 2017-11-21 at 18:09 +0100, Greg Kroah-Hartman wrote:
On Tue, Nov 21, 2017 at 04:46:18PM +0000, Ben Hutchings wrote:
On Tue, 2017-11-21 at 17:35 +0100, Greg Kroah-Hartman wrote:
On Tue, Nov 21, 2017 at 03:26:10PM +0000, Ben Hutchings wrote:
[...]
Not all 32-bit configurations can provide cmpxchg64(). i40e's use of cmpxchg64() appears to be fixed by:
b74f571f59a8 i40e/i40evf: organize and re-number feature flags b48be9978e4b i40e: fix flags declaration
So without those patches, are any specific arches/configs broken for 4.14?
32-bit parisc is.
Ok, but that's a horrid hack on the i40e driver, it just happens to move the bitfield to a 32bit variable. Can't we just provide a "real" cmpxchg64() for 32-bit parisc?
No. There is a generic implementation of cmpxchg64() but it is only suitable for non-SMP configurations.
Or mark this driver as not buildable on that platform?
I suggested adding a 'depends 64BIT' but got no response.
Ben.
I doubt anyone is doing 40gb networking on parisc :)
thanks,
greg k-h
On Tue, Nov 21, 2017 at 07:07:14PM +0000, Ben Hutchings wrote:
On Tue, 2017-11-21 at 18:09 +0100, Greg Kroah-Hartman wrote:
On Tue, Nov 21, 2017 at 04:46:18PM +0000, Ben Hutchings wrote:
On Tue, 2017-11-21 at 17:35 +0100, Greg Kroah-Hartman wrote:
On Tue, Nov 21, 2017 at 03:26:10PM +0000, Ben Hutchings wrote:
[...]
Not all 32-bit configurations can provide cmpxchg64(). i40e's use of cmpxchg64() appears to be fixed by:
b74f571f59a8 i40e/i40evf: organize and re-number feature flags b48be9978e4b i40e: fix flags declaration
So without those patches, are any specific arches/configs broken for 4.14?
32-bit parisc is.
Ok, but that's a horrid hack on the i40e driver, it just happens to move the bitfield to a 32bit variable. Can't we just provide a "real" cmpxchg64() for 32-bit parisc?
No. There is a generic implementation of cmpxchg64() but it is only suitable for non-SMP configurations.
Dave implemented the following for sparc32 (in arch/sparc/lib/atomic32.c).
u64 __cmpxchg_u64(u64 *ptr, u64 old, u64 new) { unsigned long flags; u64 prev;
spin_lock_irqsave(ATOMIC_HASH(ptr), flags); if ((prev = *ptr) == old) *ptr = new; spin_unlock_irqrestore(ATOMIC_HASH(ptr), flags); return prev; } EXPORT_SYMBOL(__cmpxchg_u64);
Maybe something like this would work for other 32 bit architectures as well ?
Guenter
On Tue, 2017-11-21 at 11:38 -0800, Guenter Roeck wrote:
On Tue, Nov 21, 2017 at 07:07:14PM +0000, Ben Hutchings wrote:
On Tue, 2017-11-21 at 18:09 +0100, Greg Kroah-Hartman wrote:
On Tue, Nov 21, 2017 at 04:46:18PM +0000, Ben Hutchings wrote:
On Tue, 2017-11-21 at 17:35 +0100, Greg Kroah-Hartman wrote:
On Tue, Nov 21, 2017 at 03:26:10PM +0000, Ben Hutchings wrote:
[...]
Not all 32-bit configurations can provide cmpxchg64(). i40e's use of cmpxchg64() appears to be fixed by:
b74f571f59a8 i40e/i40evf: organize and re-number feature flags b48be9978e4b i40e: fix flags declaration
So without those patches, are any specific arches/configs broken for 4.14?
32-bit parisc is.
Ok, but that's a horrid hack on the i40e driver, it just happens to move the bitfield to a 32bit variable. Can't we just provide a "real" cmpxchg64() for 32-bit parisc?
No. There is a generic implementation of cmpxchg64() but it is only suitable for non-SMP configurations.
Dave implemented the following for sparc32 (in arch/sparc/lib/atomic32.c).
u64 __cmpxchg_u64(u64 *ptr, u64 old, u64 new) { unsigned long flags; u64 prev;
spin_lock_irqsave(ATOMIC_HASH(ptr), flags); if ((prev = *ptr) == old) *ptr = new; spin_unlock_irqrestore(ATOMIC_HASH(ptr), flags); return prev; } EXPORT_SYMBOL(__cmpxchg_u64);
Maybe something like this would work for other 32 bit architectures as well ?
Yes, you're right, and we even have generic code for this in lib/atomic64.c - but only for atomic64_t, not u64.
Ben.
On Wed, Nov 22, 2017 at 04:06:42PM +0000, Ben Hutchings wrote:
On Tue, 2017-11-21 at 11:38 -0800, Guenter Roeck wrote:
On Tue, Nov 21, 2017 at 07:07:14PM +0000, Ben Hutchings wrote:
On Tue, 2017-11-21 at 18:09 +0100, Greg Kroah-Hartman wrote:
On Tue, Nov 21, 2017 at 04:46:18PM +0000, Ben Hutchings wrote:
On Tue, 2017-11-21 at 17:35 +0100, Greg Kroah-Hartman wrote:
On Tue, Nov 21, 2017 at 03:26:10PM +0000, Ben Hutchings wrote:
[...]
> Not all 32-bit configurations can provide cmpxchg64(). i40e's use of > cmpxchg64() appears to be fixed by: > > b74f571f59a8 i40e/i40evf: organize and re-number feature flags > b48be9978e4b i40e: fix flags declaration
So without those patches, are any specific arches/configs broken for 4.14?
32-bit parisc is.
Ok, but that's a horrid hack on the i40e driver, it just happens to move the bitfield to a 32bit variable. Can't we just provide a "real" cmpxchg64() for 32-bit parisc?
No. There is a generic implementation of cmpxchg64() but it is only suitable for non-SMP configurations.
Dave implemented the following for sparc32 (in arch/sparc/lib/atomic32.c).
u64 __cmpxchg_u64(u64 *ptr, u64 old, u64 new) { unsigned long flags; u64 prev;
spin_lock_irqsave(ATOMIC_HASH(ptr), flags); if ((prev = *ptr) == old) *ptr = new; spin_unlock_irqrestore(ATOMIC_HASH(ptr), flags); return prev; } EXPORT_SYMBOL(__cmpxchg_u64);
Maybe something like this would work for other 32 bit architectures as well ?
Yes, you're right, and we even have generic code for this in lib/atomic64.c - but only for atomic64_t, not u64.
Ok, so, suggestions? Is this actually a real issue that anyone is hitting? If they are, is it just a test-build, or a real-world-I-need-this-driver situation?
thanks,
greg k-h
On Wed, Nov 22, 2017 at 06:00:23PM +0100, Greg Kroah-Hartman wrote:
On Wed, Nov 22, 2017 at 04:06:42PM +0000, Ben Hutchings wrote:
On Tue, 2017-11-21 at 11:38 -0800, Guenter Roeck wrote:
On Tue, Nov 21, 2017 at 07:07:14PM +0000, Ben Hutchings wrote:
On Tue, 2017-11-21 at 18:09 +0100, Greg Kroah-Hartman wrote:
On Tue, Nov 21, 2017 at 04:46:18PM +0000, Ben Hutchings wrote:
On Tue, 2017-11-21 at 17:35 +0100, Greg Kroah-Hartman wrote: > On Tue, Nov 21, 2017 at 03:26:10PM +0000, Ben Hutchings wrote:
[...] > > Not all 32-bit configurations can provide cmpxchg64(). i40e's use of > > cmpxchg64() appears to be fixed by: > > > > b74f571f59a8 i40e/i40evf: organize and re-number feature flags > > b48be9978e4b i40e: fix flags declaration > > So without those patches, are any specific arches/configs broken for > 4.14?
32-bit parisc is.
Ok, but that's a horrid hack on the i40e driver, it just happens to move the bitfield to a 32bit variable. Can't we just provide a "real" cmpxchg64() for 32-bit parisc?
No. There is a generic implementation of cmpxchg64() but it is only suitable for non-SMP configurations.
Dave implemented the following for sparc32 (in arch/sparc/lib/atomic32.c).
u64 __cmpxchg_u64(u64 *ptr, u64 old, u64 new) { unsigned long flags; u64 prev;
spin_lock_irqsave(ATOMIC_HASH(ptr), flags); if ((prev = *ptr) == old) *ptr = new; spin_unlock_irqrestore(ATOMIC_HASH(ptr), flags); return prev; } EXPORT_SYMBOL(__cmpxchg_u64);
Maybe something like this would work for other 32 bit architectures as well ?
Yes, you're right, and we even have generic code for this in lib/atomic64.c - but only for atomic64_t, not u64.
Ok, so, suggestions? Is this actually a real issue that anyone is hitting? If they are, is it just a test-build, or a real-world-I-need-this-driver situation?
Long term it would be beneficial to have generic support for cmpxchg_u64 for all architectures, but I have no real idea (nor strong opinion) if that would be useful to backport.
Big question here is if anyone uses the i40e driver in v4.14 on any of the affected systems, and/or if anyone does regular test builds which now fail (and if there is interest in keeping those test builds going). I'd guess no one uses the driver on an affected system, or at least no one cared enough to fix the problem while v4.14 was in rc.
This leaves the testing question, which I can't really answer. Are people still interested in test image build results ?
Guenter
On Sun, Nov 19, 2017 at 03:59:34PM +0100, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.14.1 release. There are 31 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 Tue Nov 21 14:59:32 UTC 2017. Anything received after that time might be too late.
Updated test results (v4.14-34-g00d25fc):
Build results: total: 145 pass: 145 fail: 0 Qemu test results: total: 123 pass: 123 fail: 0
Details are available at http://kerneltests.org/builders.
Guenter
On Mon, Nov 20, 2017 at 10:21:24AM -0800, Guenter Roeck wrote:
On Sun, Nov 19, 2017 at 03:59:34PM +0100, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.14.1 release. There are 31 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 Tue Nov 21 14:59:32 UTC 2017. Anything received after that time might be too late.
Updated test results (v4.14-34-g00d25fc):
Build results: total: 145 pass: 145 fail: 0 Qemu test results: total: 123 pass: 123 fail: 0
Details are available at http://kerneltests.org/builders.
Wonderful, thanks for testing!
greg k-h
On 11/19/2017 07:59 AM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.14.1 release. There are 31 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 Tue Nov 21 14:59:32 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.14.1-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.14.y and the diffstat can be found below.
thanks,
greg k-h
Compiled and booted on my test system. No dmesg regressions.
thanks, -- Shuah
On Mon, Nov 20, 2017 at 02:19:56PM -0700, Shuah Khan wrote:
On 11/19/2017 07:59 AM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.14.1 release. There are 31 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 Tue Nov 21 14:59:32 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.14.1-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.14.y and the diffstat can be found below.
thanks,
greg k-h
Compiled and booted on my test system. No dmesg regressions.
Wonderful, thanks for testing all of these and letting me know.
greg k-h
linux-stable-mirror@lists.linaro.org
-
Ben Hutchings -
Greg Kroah-Hartman -
Guenter Roeck -
Shuah Khan