summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)AuthorFilesLines
2017-11-11netxen: fix incorrect loop counter decrementColin Ian King1-1/+1
commit a120d9ab65354727559b9db75ded8071b7ef19e2 upstream. The loop counter k is currently being decremented from zero which is incorrect. Fix this by incrementing k instead Detected by CoverityScan, CID#401847 ("Infinite loop") Fixes: 83f18a557c6d ("netxen_nic: fw dump support") Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2017-11-11parisc: pci memory bar assignment fails with 64bit kernels on dino/cujoThomas Bogendoerfer1-1/+1
commit 4098116039911e8870d84c975e2ec22dab65a909 upstream. For 64bit kernels the lmmio_space_offset of the host bridge window isn't set correctly on systems with dino/cujo PCI host bridges. This leads to not assigned memory bars and failing drivers, which need to use these bars. Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de> Acked-by: Helge Deller <deller@gmx.de> Signed-off-by: Helge Deller <deller@gmx.de> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2017-11-11usb: quirks: Add no-lpm quirk for Moshi USB to Ethernet AdapterKai-Heng Feng1-0/+3
commit 7496cfe5431f21da5d27a8388c326397e3f0a5db upstream. Moshi USB to Ethernet Adapter internally uses a Genesys Logic hub to connect to Realtek r8153. The Realtek r8153 ethernet does not work on the internal hub, no-lpm quirk can make it work. Since another r8153 dongle at my hand does not have the issue, so add the quirk to the Genesys Logic hub instead. Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2017-11-11USB: Check for dropped connection before switching to full speedAlan Stern1-4/+6
commit 94c43b9897abf4ea366ed4dba027494e080c7050 upstream. Some buggy USB disk adapters disconnect and reconnect multiple times during the enumeration procedure. This may lead to a device connecting at full speed instead of high speed, because when the USB stack sees that a device isn't able to enumerate at high speed, it tries to hand the connection over to a full-speed companion controller. The logic for doing this is careful to check that the device is still connected. But this check is inadequate if the device disconnects and reconnects before the check is done. The symptom is that a device works, but much more slowly than it is capable of operating. The situation was made worse recently by commit 22547c4cc4fe ("usb: hub: Wait for connection to be reestablished after port reset"), which increases the delay following a reset before a disconnect is recognized, thus giving the device more time to reconnect. This patch makes the check more robust. If the device was disconnected at any time during enumeration, we will now skip the full-speed handover. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Reported-and-tested-by: Zdenek Kabelac <zkabelac@redhat.com> Reviewed-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2017-11-11usb:xhci:Add quirk for Certain failing HP keyboard on reset after resumeSandeep Singh2-5/+13
commit e788787ef4f9c24aafefc480a8da5f92b914e5e6 upstream. Certain HP keyboards would keep inputting a character automatically which is the wake-up key after S3 resume On some AMD platforms USB host fails to respond (by holding resume-K) to USB device (an HP keyboard) resume request within 1ms (TURSM) and ensures that resume is signaled for at least 20 ms (TDRSMDN), which is defined in USB 2.0 spec. The result is that the keyboard is out of function. In SNPS USB design, the host responds to the resume request only after system gets back to S0 and the host gets to functional after the internal HW restore operation that is more than 1 second after the initial resume request from the USB device. As a workaround for specific keyboard ID(HP Keyboards), applying port reset after resume when the keyboard is plugged in. Signed-off-by: Sandeep Singh <Sandeep.Singh@amd.com> Signed-off-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com> cc: Nehal Shah <Nehal-bakulchandra.Shah@amd.com> Reviewed-by: Felipe Balbi <felipe.balbi@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2017-11-11scsi: st: fix blk_get_queue usageBodo Stroesser1-2/+2
commit 180efde0a3f43dbe533e4be203c2918793482d4e upstream. If blk_queue_get() in st_probe fails, disk->queue must not be set to SDp->request_queue, as that would result in put_disk() dropping a not taken reference. Thus, disk->queue should be set only after a successful blk_queue_get(). Fixes: 2b5bebccd282 ("st: Take additional queue ref in st_probe") Signed-off-by: Bodo Stroesser <bstroesser@ts.fujitsu.com> Acked-by: Shirish Pargaonkar <spargaonkar@suse.com> Signed-off-by: Hannes Reinecke <hare@suse.com> Reviewed-by: Ewan D. Milne <emilne@redhat.com> Acked-by: Kai Mäkisara <kai.makisara@kolumbus.fi> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2017-11-11s390/qeth: fix L3 next-hop in xmit qeth hdrJulian Wiedmann1-2/+2
commit ec2c6726322f0d270bab477e4904bf9496f70ee5 upstream. On L3, the qeth_hdr struct needs to be filled with the next-hop IP address. The current code accesses rtable->rt_gateway without checking that rtable is a valid address. The accidental access to a lowcore area results in a random next-hop address in the qeth_hdr. rtable (or more precisely, skb_dst(skb)) can be NULL in rare cases (for instance together with AF_PACKET sockets). This patch adds the missing NULL-ptr checks. Signed-off-by: Julian Wiedmann <jwi@linux.vnet.ibm.com> Signed-off-by: Ursula Braun <ubraun@linux.vnet.ibm.com> Fixes: 87e7597b5a3 qeth: Move away from using neighbour entries in qeth_l3_fill_header() Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2017-11-11irqchip: brcmstb-l2: Define an irq_pm_shutdown functionFlorian Fainelli1-0/+1
commit c017d21147848fe017772764a77a7f32c5b017f9 upstream. The Broadcom STB platforms support S5 and we allow specific hardware wake-up events to take us out of this state. Because we were not defining an irq_pm_shutdown() function pointer, we would not be correctly masking non-wakeup events, which would result in spurious wake-ups from sources that were not explicitly configured for wake-up. Fixes: 7f646e92766e ("irqchip: brcmstb-l2: Add Broadcom Set Top Box Level-2 interrupt controller") Acked-by: Gregory Fong <gregory.0xf0@gmail.com> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2017-11-11iscsi-target: Fix iscsi_np reset hung task during parallel deleteNicholas Bellinger3-2/+7
commit 978d13d60c34818a41fc35962602bdfa5c03f214 upstream. This patch fixes a bug associated with iscsit_reset_np_thread() that can occur during parallel configfs rmdir of a single iscsi_np used across multiple iscsi-target instances, that would result in hung task(s) similar to below where configfs rmdir process context was blocked indefinately waiting for iscsi_np->np_restart_comp to finish: [ 6726.112076] INFO: task dcp_proxy_node_:15550 blocked for more than 120 seconds. [ 6726.119440] Tainted: G W O 4.1.26-3321 #2 [ 6726.125045] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 6726.132927] dcp_proxy_node_ D ffff8803f202bc88 0 15550 1 0x00000000 [ 6726.140058] ffff8803f202bc88 ffff88085c64d960 ffff88083b3b1ad0 ffff88087fffeb08 [ 6726.147593] ffff8803f202c000 7fffffffffffffff ffff88083f459c28 ffff88083b3b1ad0 [ 6726.155132] ffff88035373c100 ffff8803f202bca8 ffffffff8168ced2 ffff8803f202bcb8 [ 6726.162667] Call Trace: [ 6726.165150] [<ffffffff8168ced2>] schedule+0x32/0x80 [ 6726.170156] [<ffffffff8168f5b4>] schedule_timeout+0x214/0x290 [ 6726.176030] [<ffffffff810caef2>] ? __send_signal+0x52/0x4a0 [ 6726.181728] [<ffffffff8168d7d6>] wait_for_completion+0x96/0x100 [ 6726.187774] [<ffffffff810e7c80>] ? wake_up_state+0x10/0x10 [ 6726.193395] [<ffffffffa035d6e2>] iscsit_reset_np_thread+0x62/0xe0 [iscsi_target_mod] [ 6726.201278] [<ffffffffa0355d86>] iscsit_tpg_disable_portal_group+0x96/0x190 [iscsi_target_mod] [ 6726.210033] [<ffffffffa0363f7f>] lio_target_tpg_store_enable+0x4f/0xc0 [iscsi_target_mod] [ 6726.218351] [<ffffffff81260c5a>] configfs_write_file+0xaa/0x110 [ 6726.224392] [<ffffffff811ea364>] vfs_write+0xa4/0x1b0 [ 6726.229576] [<ffffffff811eb111>] SyS_write+0x41/0xb0 [ 6726.234659] [<ffffffff8169042e>] system_call_fastpath+0x12/0x71 It would happen because each iscsit_reset_np_thread() sets state to ISCSI_NP_THREAD_RESET, sends SIGINT, and then blocks waiting for completion on iscsi_np->np_restart_comp. However, if iscsi_np was active processing a login request and more than a single iscsit_reset_np_thread() caller to the same iscsi_np was blocked on iscsi_np->np_restart_comp, iscsi_np kthread process context in __iscsi_target_login_thread() would flush pending signals and only perform a single completion of np->np_restart_comp before going back to sleep within transport specific iscsit_transport->iscsi_accept_np code. To address this bug, add a iscsi_np->np_reset_count and update __iscsi_target_login_thread() to keep completing np->np_restart_comp until ->np_reset_count has reached zero. Reported-by: Gary Guo <ghg@datera.io> Tested-by: Gary Guo <ghg@datera.io> Cc: Mike Christie <mchristi@redhat.com> Cc: Hannes Reinecke <hare@suse.de> Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org> [bwh: Backported to 3.16: adjust filename] Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2017-11-11IB/uverbs: Fix device cleanupYishai Hadas1-2/+1
commit efdd6f53b10aead0f5cf19a93dd3eb268ac0d991 upstream. Uverbs device should be cleaned up only when there is no potential usage of. As part of ib_uverbs_remove_one which might be triggered upon reset flow the device reference count is decreased as expected and leave the final cleanup to the FDs that were opened. Current code increases reference count upon opening a new command FD and decreases it upon closing the file. The event FD is opened internally and rely on the command FD by taking on it a reference count. In case that the command FD was closed and just later the event FD we may ensure that the device resources as of srcu are still alive as they are still in use. Fixing the above by moving the reference count decreasing to the place where the command FD is really freed instead of doing that when it was just closed. fixes: 036b10635739 ("IB/uverbs: Enable device removal when there are active user space applications") Signed-off-by: Yishai Hadas <yishaih@mellanox.com> Reviewed-by: Matan Barak <matanb@mellanox.com> Reviewed-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com> Tested-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com> Signed-off-by: Leon Romanovsky <leon@kernel.org> Signed-off-by: Doug Ledford <dledford@redhat.com> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2017-11-11RDMA/uverbs: Prevent leak of reserved fieldLeon Romanovsky1-1/+1
commit f7a6cb7b38c6845b26aaa8bbdf519ff6e3090831 upstream. initialize to zero the response structure to prevent the leakage of "resp.reserved" field. drivers/infiniband/core/uverbs_cmd.c:1178 ib_uverbs_resize_cq() warn: check that 'resp.reserved' doesn't leak information Fixes: 33b9b3ee9709 ("IB: Add userspace support for resizing CQs") Signed-off-by: Leon Romanovsky <leonro@mellanox.com> Reviewed-by: Dennis Dalessandro <dennis.dalessandro@intel.com> Signed-off-by: Doug Ledford <dledford@redhat.com> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2017-11-11net/mlx4_en: Fix wrong indication of Wake-on-LAN (WoL) supportInbar Karmy4-7/+15
commit c994f778bb1cca8ebe7a4e528cefec233e93b5cc upstream. Currently when WoL is supported but disabled, ethtool reports: "Supports Wake-on: d". Fix the indication of Wol support, so that the indication remains "g" all the time if the NIC supports WoL. Tested: As accepted, when NIC supports WoL- ethtool reports: Supports Wake-on: g Wake-on: d when NIC doesn't support WoL- ethtool reports: Supports Wake-on: d Wake-on: d Fixes: 14c07b1358ed ("mlx4: Wake on LAN support") Signed-off-by: Inbar Karmy <inbark@mellanox.com> Signed-off-by: Tariq Toukan <tariqt@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net> [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2017-11-11gpio: tegra: fix unbalanced chained_irq_enter/exitMichał Mirosław1-3/+3
commit 9e9509e38fbe034782339eb09c915f0b5765ff69 upstream. When more than one GPIO IRQs are triggered simultaneously, tegra_gpio_irq_handler() called chained_irq_exit() multiple times for one chained_irq_enter(). Fixes: 3c92db9ac0ca3eee8e46e2424b6c074e2e394ad9 Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl> [Also changed the variable to a bool] Signed-off-by: Linus Walleij <linus.walleij@linaro.org> [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2017-11-11ixgbe: Initialize 64-bit stats seqcountsFlorian Fainelli1-0/+4
commit 7c3a4626eb65e78ebe208f48ffa21a5002f7f38e upstream. On 32-bit hosts and with CONFIG_DEBUG_LOCK_ALLOC we should be seeing a lockdep splat indicating this seqcount is not correctly initialized, fix that. Fixes: 4197aa7bb818 ("ixgbevf: provide 64 bit statistics") Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2017-11-11i40e: Initialize 64-bit statistics TX ring seqcountFlorian Fainelli1-0/+2
commit 7d6d067790289e4f61f59fa60550ca5918aa25bd upstream. On 32-bit hosts and with CONFIG_DEBUG_LOCK_ALLOC we should be seeing a lockdep splat indicating this seqcount is not correctly initialized, fix that. Fixes: 980e9b118642 ("i40e: Add support for 64 bit netstats") Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2017-11-11b44: Initialize 64-bit stats seqcountFlorian Fainelli1-0/+1
commit e43c9f23efadade684773a855675c99da278c862 upstream. On 32-bit hosts and with CONFIG_DEBUG_LOCK_ALLOC we should be seeing a lockdep splat indicating this seqcount is not correctly initialized, fix that. Fixes: eeda8585522b ("b44: add 64 bit stats") Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Acked-by: Michael Chan <michael.chan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2017-11-11drm/msm: fix an integer overflow testDan Carpenter1-1/+1
commit 65e93108891e571f177c202add9288eda9ac4100 upstream. We recently added an integer overflow check but it needs an additional tweak to work properly on 32 bit systems. The problem is that we're doing the right hand side of the assignment as type unsigned long so the max it will have an integer overflow instead of being larger than SIZE_MAX. That means the "sz > SIZE_MAX" condition is never true even on 32 bit systems. We need to first cast it to u64 and then do the math. Fixes: 4a630fadbb29 ("drm/msm: Fix potential buffer overflow issue") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Acked-by: Jordan Crouse <jcrouse@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com> [bwh: Backported to 3.16: submit_create() only supports a variable number of bos] Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2017-11-11drm/msm: Fix potential buffer overflow issueKasin Li1-2/+5
commit 4a630fadbb29d9efaedb525f1a8f7449ad107641 upstream. In function submit_create, if nr_cmds or nr_bos is assigned with negative value, the allocated buffer may be small than intended. Using this buffer will lead to buffer overflow issue. Signed-off-by: Kasin Li <donglil@codeaurora.org> Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com> [bwh: Backported to 3.16: submit_create() only supports a variable number of bos] Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2017-11-11USB: serial: option: add D-Link DWM-222 device IDHector Martin1-0/+2
commit fd1b8668af59a11bb754a6c9b0051c6c5ce73b74 upstream. Add device id for D-Link DWM-222. Signed-off-by: Hector Martin <marcan@marcan.st> Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2017-11-11iwlwifi: mvm: set the RTS_MIMO_PROT bit in flag mask when sending sta to fwNaftali Goldstein1-1/+2
commit 8addabf8e6e299f790038fdc92ddceaaf76adab8 upstream. Set the STA_FLG_RTS_MIMO_PROT bit in station_flags_msk of the add sta command, so that when smps mode changes, the FW will know about it. In particular, in AP mode, clients are added upon receival of an auth request, at which point there's no knowledge of the client's smps mode. When the assoc request arrives, the add_sta command is resent to modify the station parameters. At this point the driver knows the smps mode, but since the corresponding bit in the mask is not set, the fw doesn't update this field so there's no rts protection for mimo. Fixes: 5bc5aaad407c ("iwlwifi: mvm: set up initial SMPS/NSS station info") Signed-off-by: Naftali Goldstein <naftali.goldstein@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> [bwh: Backported to 3.16: adjust filename, context, indentation] Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2017-11-11pinctrl: sunxi: add a missing function of A10/A20 pinctrl driverIcenowy Zheng1-0/+1
commit d81ece747d8727bb8b1cfc9a20dbe62f09a4e35a upstream. The PH16 pin has a function with mux id 0x5, which is the DET pin of the "sim" (smart card reader) IP block. This function is missing in old versions of A10/A20 SoCs' datasheets and user manuals, so it's also missing in the old drivers. The newest A10 Datasheet V1.70 and A20 Datasheet V1.41 contain this pin function, and it's discovered during implementing R40 pinctrl driver. Add it to the driver. As we now merged A20 pinctrl driver to the A10 one, we need to only fix the A10 driver now. Fixes: f2821b1ca3a2 ("pinctrl: sunxi: Move Allwinner A10 pinctrl driver to a driver of its own") Signed-off-by: Icenowy Zheng <icenowy@aosc.io> Reviewed-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2017-11-11uas: Add US_FL_IGNORE_RESIDUE for Initio Corporation INIC-3069Alan Swanson1-2/+2
commit 89f23d51defcb94a5026d4b5da13faf4e1150a6f upstream. Similar to commit d595259fbb7a ("usb-storage: Add ignore-residue quirk for Initio INIC-3619") for INIC-3169 in unusual_devs.h but INIC-3069 already present in unusual_uas.h. Both in same controller IC family. Issue is that MakeMKV fails during key exchange with installed bluray drive with following error: 002004:0000 Error 'Scsi error - ILLEGAL REQUEST:COPY PROTECTION KEY EXCHANGE FAILURE - KEY NOT ESTABLISHED' occurred while issuing SCSI command AD010..080002400 to device 'SG:dev_11:0' Signed-off-by: Alan Swanson <reiver@improbability.net> Acked-by: Oliver Neukum <oneukum@suse.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2017-11-11USB: hcd: Mark secondary HCD as dead if the primary one diedRafael J. Wysocki1-0/+2
commit cd5a6a4fdaba150089af2afc220eae0fef74878a upstream. Make usb_hc_died() clear the HCD_FLAG_RH_RUNNING flag for the shared HCD and set HCD_FLAG_DEAD for it, in analogy with what is done for the primary one. Among other thigs, this prevents check_root_hub_suspended() from returning -EBUSY for dead HCDs which helps to work around system suspend issues in some situations. This actually fixes occasional suspend failures on one of my test machines. Suggested-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2017-11-11net/mlx5: Fix command bad flow on command entry allocation failureMoshe Shemesh1-2/+17
commit 219c81f7d1d5a89656cb3b53d3b4e11e93608d80 upstream. When driver fail to allocate an entry to send command to FW, it must notify the calling function and release the memory allocated for this command. Fixes: e126ba97dba9e ('mlx5: Add driver for Mellanox Connect-IB adapters') Signed-off-by: Moshe Shemesh <moshe@mellanox.com> Cc: kernel-team@fb.com Signed-off-by: Saeed Mahameed <saeedm@mellanox.com> [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2017-11-11iommu/amd: Fix schedule-while-atomic BUG in initialization codeJoerg Roedel1-1/+1
commit 74ddda71f44c84af62f736a77fb9fcebe5bb436a upstream. The register_syscore_ops() function takes a mutex and might sleep. In the IOMMU initialization code it is invoked during irq-remapping setup already, where irqs are disabled. This causes a schedule-while-atomic bug: BUG: sleeping function called from invalid context at kernel/locking/mutex.c:747 in_atomic(): 0, irqs_disabled(): 1, pid: 1, name: swapper/0 no locks held by swapper/0/1. irq event stamp: 304 hardirqs last enabled at (303): [<ffffffff818a87b6>] _raw_spin_unlock_irqrestore+0x36/0x60 hardirqs last disabled at (304): [<ffffffff8235d440>] enable_IR_x2apic+0x79/0x196 softirqs last enabled at (36): [<ffffffff818ae75f>] __do_softirq+0x35f/0x4ec softirqs last disabled at (31): [<ffffffff810c1955>] irq_exit+0x105/0x120 CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.13.0-rc2.1.el7a.test.x86_64.debug #1 Hardware name: PowerEdge C6145 /040N24, BIOS 3.5.0 10/28/2014 Call Trace: dump_stack+0x85/0xca ___might_sleep+0x22a/0x260 __might_sleep+0x4a/0x80 __mutex_lock+0x58/0x960 ? iommu_completion_wait.part.17+0xb5/0x160 ? register_syscore_ops+0x1d/0x70 ? iommu_flush_all_caches+0x120/0x150 mutex_lock_nested+0x1b/0x20 register_syscore_ops+0x1d/0x70 state_next+0x119/0x910 iommu_go_to_state+0x29/0x30 amd_iommu_enable+0x13/0x23 Fix it by moving the register_syscore_ops() call to the next initialization step, which runs with irqs enabled. Reported-by: Artem Savkov <asavkov@redhat.com> Tested-by: Artem Savkov <asavkov@redhat.com> Acked-by: Thomas Gleixner <tglx@linutronix.de> Fixes: 2c0ae1720c09 ('iommu/amd: Convert iommu initialization to state machine') Signed-off-by: Joerg Roedel <jroedel@suse.de> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2017-11-11media: platform: davinci: return -EINVAL for VPFE_CMD_S_CCDC_RAW_PARAMS ioctlPrabhakar Lad1-20/+2
commit da05d52d2f0f6bd61094a0cd045fed94bf7d673a upstream. this patch makes sure VPFE_CMD_S_CCDC_RAW_PARAMS ioctl no longer works for vpfe_capture driver with a minimal patch suitable for backporting. - This ioctl was never in public api and was only defined in kernel header. - The function set_params constantly mixes up pointers and phys_addr_t numbers. - This is part of a 'VPFE_CMD_S_CCDC_RAW_PARAMS' ioctl command that is described as an 'experimental ioctl that will change in future kernels'. - The code to allocate the table never gets called after we copy_from_user the user input over the kernel settings, and then compare them for inequality. - We then go on to use an address provided by user space as both the __user pointer for input and pass it through phys_to_virt to come up with a kernel pointer to copy the data to. This looks like a trivially exploitable root hole. Due to these reasons we make sure this ioctl now returns -EINVAL and backport this patch as far as possible. Fixes: 5f15fbb68fd7 ("V4L/DVB (12251): v4l: dm644x ccdc module for vpfe capture driver") Signed-off-by: Lad, Prabhakar <prabhakar.csengg@gmail.com> Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2017-11-11media: lirc: LIRC_GET_REC_RESOLUTION should return microsecondsSean Young1-1/+1
commit 9f5039ba440e499d85c29b1ddbc3cbc9dc90e44b upstream. Since commit e8f4818895b3 ("[media] lirc: advertise LIRC_CAN_GET_REC_RESOLUTION and improve") lircd uses the ioctl LIRC_GET_REC_RESOLUTION to determine the shortest pulse or space that the hardware can detect. This breaks decoding in lirc because lircd expects the answer in microseconds, but nanoseconds is returned. Reported-by: Derek <user.vdr@gmail.com> Tested-by: Derek <user.vdr@gmail.com> Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com> [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2017-11-11md/raid5: add thread_group worker async_tx_issue_pending_allOfer Heifetz1-0/+2
commit 7e96d559634b73a8158ee99a7abece2eacec2668 upstream. Since thread_group worker and raid5d kthread are not in sync, if worker writes stripe before raid5d then requests will be waiting for issue_pendig. Issue observed when building raid5 with ext4, in some build runs jbd2 would get hung and requests were waiting in the HW engine waiting to be issued. Fix this by adding a call to async_tx_issue_pending_all in the raid5_do_work. Signed-off-by: Ofer Heifetz <oferh@marvell.com> Signed-off-by: Shaohua Li <shli@fb.com> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2017-11-11IB/ipoib: Remove double pointer assigningLeon Romanovsky1-1/+0
commit 1b355094b308f3377c8f574ce86135ee159c6285 upstream. There is no need to assign "p" pointer twice. This patch fixes the following smatch warning: drivers/infiniband/ulp/ipoib/ipoib_cm.c:517 ipoib_cm_rx_handler() warn: missing break? reassigning 'p->id' Fixes: 839fcaba355a ("IPoIB: Connected mode experimental support") Signed-off-by: Leon Romanovsky <leonro@mellanox.com> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2017-11-11IB/ipoib: Set IPOIB_NEIGH_TBL_FLUSH after flushed completion initializationFeras Daoud1-1/+1
commit d2e46fccc3e3d73a741efe433f00960331280696 upstream. Set IPOIB_NEIGH_TBL_FLUSH bit after initializing the neighbor flushed completion, otherwise the garbage collector may signal a completion while it is not initialized yet. Fixes: b63b70d87741 ("IPoIB: Use a private hash table for path lookup in xmit path") Signed-off-by: Feras Daoud <ferasda@mellanox.com> Signed-off-by: Alex Vesker <valex@mellanox.com> Signed-off-by: Leon Romanovsky <leon@kernel.org> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2017-11-11IB/ipoib: Prevent setting negative values to max_nonsrq_conn_qpAlex Vesker1-0/+1
commit 11f74b40359b19f760964e71d04882a6caf530cc upstream. Don't allow negative values to max_nonsrq_conn_qp. There is no functional impact on a negative value but it is logicically incorrect. Fixes: 68e995a29572 ("IPoIB/cm: Add connected mode support for devices without SRQs") Signed-off-by: Alex Vesker <valex@mellanox.com> Signed-off-by: Leon Romanovsky <leon@kernel.org> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2017-11-11iwlwifi: dvm: prevent an out of bounds accessEmmanuel Grumbach1-1/+1
commit 0b0f934e92a8eaed2e6c48a50eae6f84661f74f3 upstream. iwlagn_check_ratid_empty takes the tid as a parameter, but it doesn't check that it is not IWL_TID_NON_QOS. Since IWL_TID_NON_QOS = 8 and iwl_priv::tid_data is an array with 8 entries, accessing iwl_priv::tid_data[IWL_TID_NON_QOS] is a bad idea. This happened in iwlagn_rx_reply_tx. Since iwlagn_check_ratid_empty is relevant only to check whether we can open A-MPDU, this flow is irrelevant if tid is IWL_TID_NON_QOS. Call iwlagn_check_ratid_empty only inside the if (tid != IWL_TID_NON_QOS) a few lines earlier in the function. Reported-by: Seraphime Kirkovski <kirkseraph@gmail.com> Tested-by: Seraphime Kirkovski <kirkseraph@gmail.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> [bwh: Backported to 3.16: adjust filename] Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2017-11-11RDMA/core: Initialize port_num in qp_attrIsmail, Mustafa1-0/+2
commit a62ab66b13a0f9bcb17b7b761f6670941ed5cd62 upstream. Initialize the port_num for iWARP in rdma_init_qp_attr. Fixes: 5ecce4c9b17b("Check port number supplied by user verbs cmds") Reviewed-by: Steve Wise <swise@opengridcomputing.com> Signed-off-by: Mustafa Ismail <mustafa.ismail@intel.com> Tested-by: Mike Marciniszyn <mike.marciniszyn@intel.com> Signed-off-by: Doug Ledford <dledford@redhat.com> [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2017-11-11RDMA/uverbs: Fix the check for port numberIsmail, Mustafa1-1/+2
commit 5a7a88f1b488e4ee49eb3d5b82612d4d9ffdf2c3 upstream. The port number is only valid if IB_QP_PORT is set in the mask. So only check port number if it is valid to prevent modify_qp from failing due to an invalid port number. Fixes: 5ecce4c9b17b("Check port number supplied by user verbs cmds") Reviewed-by: Steve Wise <swise@opengridcomputing.com> Signed-off-by: Mustafa Ismail <mustafa.ismail@intel.com> Tested-by: Mike Marciniszyn <mike.marciniszyn@intel.com> Signed-off-by: Doug Ledford <dledford@redhat.com> [bwh: Backported to 3.16: command structure is cmd not cmd->base] Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2017-11-11RDMA/ocrdma: Fix error codes in ocrdma_create_srq()Dan Carpenter1-0/+1
commit f0c6e88288d65c93bbc7da4fb6f7d51b2733228a upstream. If either of these allocations fail then we return ERR_PTR(0). That's equivalent to NULL and results in a NULL pointer dereference in the caller. Fixes: fe2caefcdf58 ("RDMA/ocrdma: Add driver for Emulex OneConnect IBoE RDMA adapter") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Doug Ledford <dledford@redhat.com> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2017-11-11RDMA/ocrdma: Fix an error code in ocrdma_alloc_pd()Dan Carpenter1-1/+2
commit dd75cfa6d3216c79c695f5af13e52208afe374ad upstream. We should preserve the original "status" error code instead of resetting it to zero. Returning ERR_PTR(0) is the same as NULL and results in a NULL dereference in the callers. I added a printk() on error instead. Fixes: 45e86b33ec8b ("RDMA/ocrdma: Cache recv DB until QP moved to RTR") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Doug Ledford <dledford@redhat.com> [bwh: Backported to 3.16: keep calling ocrdma_mbx_dealloc_pd()] Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2017-11-11IB/cxgb3: Fix error codes in iwch_alloc_mr()Dan Carpenter1-2/+3
commit 9064d6055c14f700aa13f7c72fd3e63d12bee643 upstream. We accidentally don't set the error code on some error paths. It means return ERR_PTR(0) which is NULL and results in a NULL dereference in the caller. Fixes: 13a239330abd ("RDMA/cxgb3: Don't ignore insert_handle() failures") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Acked-by: Steve Wise <swise@opengridcomputing.com> Signed-off-by: Doug Ledford <dledford@redhat.com> [bwh: Backported to 3.16: drop inapplicable hunk] Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2017-11-11cxgb4: Fix error codes in c4iw_create_cq()Dan Carpenter1-0/+1
commit 6ebedacbb44602d4dec3348dee5ec31dd9b09521 upstream. If one of these kmalloc() calls fails then we return ERR_PTR(0) which is NULL. It results in a NULL dereference in the callers. Fixes: cfdda9d76436 ("RDMA/cxgb4: Add driver for Chelsio T4 RNIC") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Acked-by: Steve Wise <swise@opengridcomputing.com> Signed-off-by: Doug Ledford <dledford@redhat.com> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2017-11-11xhci: fix memleak in xhci_run()Shu Wang1-1/+3
commit d6f5f071f1e13cadecf8aef1faa7e5d6fbc9f33b upstream. Found this issue by kmemleak. xhci_run() did not check return val and free command for xhci_queue_vendor_command() unreferenced object 0xffff88011c0be500 (size 64): comm "kworker/0:1", pid 58, jiffies 4294670908 (age 50.420s) hex dump (first 32 bytes): backtrace: [<ffffffff8176166a>] kmemleak_alloc+0x4a/0xa0 [<ffffffff8121801a>] kmem_cache_alloc_trace+0xca/0x1d0 [<ffffffff81576bf4>] xhci_alloc_command+0x44/0x130 [<ffffffff8156f1cc>] xhci_run+0x4cc/0x630 [<ffffffff8153b84b>] usb_add_hcd+0x3bb/0x950 [<ffffffff8154eac8>] usb_hcd_pci_probe+0x188/0x500 [<ffffffff815851ac>] xhci_pci_probe+0x2c/0x220 [<ffffffff813d2ca5>] local_pci_probe+0x45/0xa0 [<ffffffff810a54e4>] work_for_cpu_fn+0x14/0x20 [<ffffffff810a8409>] process_one_work+0x149/0x360 [<ffffffff810a8d08>] worker_thread+0x1d8/0x3c0 [<ffffffff810ae7d9>] kthread+0x109/0x140 [<ffffffff8176d585>] ret_from_fork+0x25/0x30 [<ffffffffffffffff>] 0xffffffffffffffff Signed-off-by: Shu Wang <shuwang@redhat.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2017-11-11xhci: fix 20000ms port resume timeoutMathias Nyman1-0/+3
commit a54408d0a004757789863d74e29c2297edae0b4d upstream. A uncleared PLC (port link change) bit will prevent furuther port event interrupts for that port. Leaving it uncleared caused get_port_status() to timeout after 20000ms while waiting to get the final port event interrupt for resume -> U0 state change. This is a targeted fix for a specific case where we get a port resume event racing with xhci resume. The port event interrupt handler notices xHC is not yet running and bails out early, leaving PLC uncleared. The whole xhci port resuming needs more attention, but while working on it it anyways makes sense to always ensure PLC is cleared in get_port_status before setting a new link state and waiting for its completion. Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2017-11-11xhci: Bad Ethernet performance plugged in ASM1042A hostJiahau Chang5-0/+69
commit 9da5a1092b13468839b1a864b126cacfb72ad016 upstream. When USB Ethernet is plugged in ASMEDIA ASM1042A xHCI host, bad performance was manifesting in Web browser use (like download large file such as ISO image). It is known limitation of ASM1042A that is not compatible with driver scheduling, As a workaround we can modify flow control handling of ASM1042A. The register we modify is changes the behavior [use quirk bit 28, usleep_range 40-60us, empty non-pci function -Mathias] Signed-off-by: Jiahau Chang <Lars_chang@asmedia.com.tw> Signed-off-by: Ian Pilcher <arequipeno@gmail.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2017-11-11xhci: Fix NULL pointer dereference when cleaning up streams for removed hostMathias Nyman1-4/+7
commit 4b895868bb2da60a386a17cde3bf9ecbc70c79f4 upstream. This off by one in stream_id indexing caused NULL pointer dereference and soft lockup on machines with USB attached SCSI devices connected to a hotpluggable xhci controller. The code that cleans up pending URBs for dead hosts tried to dereference a stream ring at the invalid stream_id 0. ep->stream_info->stream_rings[0] doesn't point to a ring. Start looping stream_id from 1 like in all the other places in the driver, and check that the ring exists before trying to kill URBs on it. Reported-by: rocko r <rockorequin@gmail.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2017-11-11libata: array underflow in ata_find_dev()Dan Carpenter1-2/+4
commit 59a5e266c3f5c1567508888dd61a45b86daed0fa upstream. My static checker complains that "devno" can be negative, meaning that we read before the start of the loop. I've looked at the code, and I think the warning is right. This come from /proc so it's root only or it would be quite a quite a serious bug. The call tree looks like this: proc_scsi_write() <- gets id and channel from simple_strtoul() -> scsi_add_single_device() <- calls shost->transportt->user_scan() -> ata_scsi_user_scan() -> ata_find_dev() Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Tejun Heo <tj@kernel.org> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2017-11-11usb: renesas_usbhs: gadget: disable all eps when the driver stopsYoshihiro Shimoda1-7/+24
commit b8b9c974afee685789fcbb191b52d1790be3608c upstream. A gadget driver will not disable eps immediately when ->disconnect() is called. But, since this driver assumes all eps stop after the ->disconnect(), unexpected behavior happens (especially in system suspend). So, this patch disables all eps in usbhsg_try_stop(). After disabling eps by renesas_usbhs driver, since some functions will be called by both a gadget and renesas_usbhs driver, renesas_usbhs driver should protect uep->pipe. To protect uep->pipe easily, this patch adds a new lock in struct usbhsg_uep. Fixes: 2f98382dc ("usb: renesas_usbhs: Add Renesas USBHS Gadget") Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2017-11-11usb: renesas_usbhs: fix usbhsc_resume() for !USBHSF_RUNTIME_PWCTRLYoshihiro Shimoda1-1/+3
commit 59a0879a0e17b2e43ecdc5e3299da85b8410d7ce upstream. This patch fixes an issue that some registers may be not initialized after resume if the USBHSF_RUNTIME_PWCTRL is not set. Otherwise, if a cable is not connected, the driver will not enable INTENB0.VBSE after resume. And then, the driver cannot detect the VBUS. Fixes: ca8a282a5373 ("usb: gadget: renesas_usbhs: add suspend/resume support") Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2017-11-11usb: renesas_usbhs: gadget: Fix NULL pointer dereference in usbhsg_ep_dequeue()Yoshihiro Shimoda1-2/+9
commit c9eb29503e9655e70448bbbf3697d08a56d24854 upstream. This patch fixes an issue that NULL pointer dereference happens when a gadget driver calls usb_ep_dequeue() for ep0 after disconnected a usb cable. This is because that usbhsg_try_stop() will call usbhsg_ep_disable(&dcp->ep) when a usb cable is disconnected and the pipe of dcp (ep0) is set to NULL. Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Signed-off-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2017-11-11usb: renesas_usbhs: gadget: fix re-enabling pipe without re-connectingYoshihiro Shimoda3-1/+14
commit dfb87b8bfe09f933abaf387693992089f6f9053e upstream. This patch fixes an issue that the renesas_usbhs driver in gadget mode cannot work correctly even if I disabled DMAC of the driver when I used the g_zero driver and the testusb tool. When a usb cable is re-connected, the renesas_usbhs driver calls the usbhsp_flags_init() (via usbhs_hotplug() --> usbhs_mod_call(start) --> usbhsg_try_start() --> usbhs_pipe_init()). However, the driver doesn't call the usbhsp_flags_init() when usbhsg_ep_disable() is called. So, if a gadget driver calls usb_ep_enable() and usb_ep_disable() again and again, the renesas_usbhs driver will output the following log: renesas_usbhs renesas_usbhs: can't get pipe (BULK) renesas_usbhs renesas_usbhs: wrong recip request Acked-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Signed-off-by: Felipe Balbi <balbi@ti.com> [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2017-11-11staging: rtl8188eu: add TL-WN722N v2 supportMichael Gugino1-0/+1
commit 5a1d4c5dd4eb2f1f8a9b30e61762f3b3b564df70 upstream. Add support for USB Device TP-Link TL-WN722N v2. VendorID: 0x2357, ProductID: 0x010c Signed-off-by: Michael Gugino <michael.gugino.2@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2017-11-11drm/vmwgfx: Fix gcc-7.1.1 warningSinclair Yeh1-1/+1
commit fcfffdd8f98ac305285dca568b5065ef86be6458 upstream. The current code does not look correct, and the reason for it is probably lost. Since this now generates a compiler warning, fix it to what makes sense. Reported-by: Arnd Bergmann <arnd@arndb.de> Reported-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Sinclair Yeh <syeh@vmware.com> Reviewed-by: Brian Paul <brianp@vmware.com> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2017-11-11spmi: Include OF based modalias in device ueventBjorn Andersson1-0/+12
commit d50daa2af2618dab6d21634e65a5fbcf4ae437d6 upstream. Include the OF-based modalias in the uevent sent when registering SPMI devices, so that user space has a chance to autoload the kernel module for the device. Tested-by: Rob Clark <robdclark@gmail.com> Reported-by: Rob Clark <robdclark@gmail.com> Reviewed-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>