- 16 Mar, 2017 40 commits
-
-
John Brooks authored
commit 5c113b5e upstream. The DHT22 (AM2302) datasheet specifies that the LOW start pulse should not exceed 20ms. However, observations with an oscilloscope of an RPi Model 2B (rev 1.1) communicating with a DHT22 sensor showed that the driver was consistently sending start pulses longer than 20ms: Kernel 4.7.10-v7+ (n=132): Minimum pulse length: 20.20ms Maximum: 29.84ms Mean: 24.96ms StDev: 2.82ms Sensor response rate: 100% Read success rate: 76% On kernel 4.8, the start pulse was so long that the sensor would not even respond 97% of the time: Kernel 4.8.16-v7+ (n=100): Minimum pulse length: 30.4ms Maximum: 74.4ms Mean: 39.3ms StDev: 10.2ms Sensor response rate: 3% Read success rate: 3% The driver would return ETIMEDOUT and write log messages like this: [ 51.430987] dht11 dht11@0: Only 1 signal edges detected [ 66.311019] dht11 dht11@0: Only 0 signal edges detected Replacing msleep(18) with usleep_range(18000, 20000) made the pulse length sane again and restored responsiveness: Kernel 4.8.16-v7+ with usleep_range (n=123): Minimum pulse length: 18.16ms Maximum: 20.20ms Mean: 19.85ms StDev: 0.51ms Sensor response rate: 100% Read success rate: 84% Signed-off-by:
John Brooks <john@fastquake.com> Reviewed-by:
Harald Geyer <harald@ccbib.org> Signed-off-by:
Jonathan Cameron <jic23@kernel.org> [bwh: Backported to 3.16: adjust context] Signed-off-by:
Ben Hutchings <ben@decadent.org.uk>
-
Andy Shevchenko authored
commit 5a00b6c2 upstream. The commit 1c6c6952 ("genirq: Reject bogus threaded irq requests") starts refusing misconfigured interrupt handlers. This makes intel_mid_powerbtn not working anymore. Add a mandatory flag to a threaded IRQ request in the driver. Fixes: 1c6c6952 ("genirq: Reject bogus threaded irq requests") Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> [bwh: Backported to 3.16: adjust context] Signed-off-by:
-
Anton Blanchard authored
commit 178f3582 upstream. IBM bit 31 (for the rest of us - bit 0) is a reserved field in the instruction definition of mtspr and mfspr. Hardware is encouraged to (and does) ignore it. As a result, if userspace executes an mtspr DSCR with the reserved bit set, we get a DSCR facility unavailable exception. The kernel fails to match against the expected value/mask, and we silently return to userspace to try and re-execute the same mtspr DSCR instruction. We loop forever until the process is killed. We should do something here, and it seems mirroring what hardware does is the better option vs killing the process. While here, relax the matching of mfspr PVR too. Signed-off-by:
Anton Blanchard <anton@samba.org> Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au> Signed-off-by:
-
Dave Martin authored
commit 99dfe80a upstream. Ensure that if userspace supplies insufficient data to PTRACE_SETREGSET to fill all the registers, the thread's old registers are preserved. Fixes: c6e6771b ("powerpc: Introduce VSX thread_struct and CONFIG_VSX") Signed-off-by:
Dave Martin <Dave.Martin@arm.com> Signed-off-by:
-
Fabien Parent authored
commit 43849785 upstream. Read access to the SPI flash are broken on da850-evm, i.e. the data read is not what is actually programmed on the flash. According to the datasheet for the M25P64 part present on the da850-evm, if the SPI frequency is higher than 20MHz then the READ command is not usable anymore and only the FAST_READ command can be used to read data. This commit specifies in the DTS that we should use FAST_READ command instead of the READ command. Tested-by:
Kevin Hilman <khilman@baylibre.com> Signed-off-by:
Fabien Parent <fparent@baylibre.com> [nsekhar@ti.com: subject line adjustment] Signed-off-by:
Sekhar Nori <nsekhar@ti.com> Signed-off-by:
Olof Johansson <olof@lixom.net> Signed-off-by:
-
Josef Bacik authored
commit d61b7f97 upstream. A user noticed that write performance was horrible over loopback and we traced it to an inversion of when we need to set MSG_MORE. It should be set when we have more bvec's to send, not when we are on the last bvec. This patch made the test go from 20 iops to 78k iops. Signed-off-by:
Josef Bacik <jbacik@fb.com> Fixes: 429a787b ("nbd: fix use-after-free of rq/bio in the xmit path") Signed-off-by:
Jens Axboe <axboe@fb.com> [bwh: Backported to 3.16: adjust context] Signed-off-by:
-
Jens Axboe authored
commit 429a787b upstream. For writes, we can get a completion in while we're still iterating the request and bio chain. If that happens, we're reading freed memory and we can crash. Break out after the last segment and avoid having the iterator read freed memory. Reviewed-by:
-
Alexey Kodanev authored
commit 0dbd7ff3 upstream. Found that if we run LTP netstress test with large MSS (65K), the first attempt from server to send data comparable to this MSS on fastopen connection will be delayed by the probe timer. Here is an example: < S seq 0:0 win 43690 options [mss 65495 wscale 7 tfo cookie] length 32 > S. seq 0:0 ack 1 win 43690 options [mss 65495 wscale 7] length 0 < . ack 1 win 342 length 0 Inside tcp_sendmsg(), tcp_send_mss() returns max MSS in 'mss_now', as well as in 'size_goal'. This results the segment not queued for transmition until all the data copied from user buffer. Then, inside __tcp_push_pending_frames(), it breaks on send window test and continues with the check probe timer. Fragmentation occurs in tcp_write_wakeup()... +0.2 > P. seq 1:43777 ack 1 win 342 length 43776 < . ack 43777, win 1365 length 0 > P. seq 43777:65001 ack 1 win 342 options [...] length 21224 ... This also contradicts with the fact that we should bound to the half of the window if it is large. Fix this flaw by correctly initializing max_window. Before that, it could have large values that affect further calculations of 'size_goal'. Fixes: 168a8f58 ("tcp: TCP Fast Open Server - main code path") Signed-off-by:
Alexey Kodanev <alexey.kodanev@oracle.com> Acked-by:
Eric Dumazet <edumazet@google.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Mark Rutland authored
commit 7d9e8f71 upstream. Generally, taking an unexpected exception should be a fatal event, and bad_mode is intended to cater for this. However, it should be possible to contain unexpected synchronous exceptions from EL0 without bringing the kernel down, by sending a SIGILL to the task. We tried to apply this approach in commit 9955ac47 ("arm64: don't kill the kernel on a bad esr from el0"), by sending a signal for any bad_mode call resulting from an EL0 exception. However, this also applies to other unexpected exceptions, such as SError and FIQ. The entry paths for these exceptions branch to bad_mode without configuring the link register, and have no kernel_exit. Thus, if we take one of these exceptions from EL0, bad_mode will eventually return to the original user link register value. This patch fixes this by introducing a new bad_el0_sync handler to cater for the recoverable case, and restoring bad_mode to its original state, whereby it calls panic() and never returns. The recoverable case branches to bad_el0_sync with a bl, and returns to userspace via the usual ret_to_user mechanism. Signed-off-by:
Mark Rutland <mark.rutland@arm.com> Fixes: 9955ac47 ("arm64: don't kill the kernel on a bad esr from el0") Reported-by:
Mark Salter <msalter@redhat.com> Cc: Will Deacon <will.deacon@arm.com> Signed-off-by:
Catalin Marinas <catalin.marinas@arm.com> [bwh: Backported to 3.16: - Leave type out of the log message as we don't have esr_get_class_string() - Adjust context] Signed-off-by:
-
Aleksander Morgado authored
commit 24d615a6 upstream. The Dell DW5570 is a re-branded Sierra Wireless MC8805 which will by default boot with vid 0x413c and pid 0x81a3. When triggered QDL download mode, the device switches to pid 0x81a6 and provides the standard TTY used for firmware upgrade. Signed-off-by:
Aleksander Morgado <aleksander@aleksander.es> Signed-off-by:
Johan Hovold <johan@kernel.org> Signed-off-by:
-
Eric Dumazet authored
commit 7be2c82c upstream. Ashizuka reported a highmem oddity and sent a patch for freescale fec driver. But the problem root cause is that core networking stack must ensure no skb with highmem fragment is ever sent through a device that does not assert NETIF_F_HIGHDMA in its features. We need to call illegal_highdma() from harmonize_features() regardless of CSUM checks. Fixes: ec5f0615 ("net: Kill link between CSUM and SG features.") Signed-off-by:
"Ashizuka, Yuusuke" <ashiduka@jp.fujitsu.com> Signed-off-by:
-
Dave Martin authored
commit ad9e202a upstream. We cannot preserve partial fields for hardware breakpoints, because the values written by userspace to the hardware breakpoint registers can't subsequently be recovered intact from the hardware. So, just reject attempts to write incomplete fields with -EINVAL. Fixes: 478fcb2c ("arm64: Debugging support") Signed-off-by:
Will Deacon <Will.Deacon@arm.com> Signed-off-by:
-
Dave Martin authored
commit aeb1f39d upstream. This patch adds an explicit __reserved[] field to user_fpsimd_state to replace what was previously unnamed padding. This ensures that data in this region are propagated across assignment rather than being left possibly uninitialised at the destination. Fixes: 60ffc30d ("arm64: Exception handling") Signed-off-by:
-
Dave Martin authored
commit 9a17b876 upstream. Ensure that if userspace supplies insufficient data to PTRACE_SETREGSET to fill all the registers, the thread's old registers are preserved. Fixes: 478fcb2c ("arm64: Debugging support") Signed-off-by:
-
Jeff Layton authored
commit 6df8c9d8 upstream. sparse says: fs/ceph/mds_client.c:291:23: warning: restricted __le32 degrades to integer fs/ceph/mds_client.c:293:28: warning: restricted __le32 degrades to integer fs/ceph/mds_client.c:294:28: warning: restricted __le32 degrades to integer fs/ceph/mds_client.c:296:28: warning: restricted __le32 degrades to integer The op value is __le32, so we need to convert it before comparing it. Signed-off-by:
Jeff Layton <jlayton@redhat.com> Reviewed-by:
Sage Weil <sage@redhat.com> Signed-off-by:
Ilya Dryomov <idryomov@gmail.com> Signed-off-by:
-
Yegor Yefremov authored
commit befa6011 upstream. In order to make the driver work with the common clock framework, this patch converts the clk_enable()/clk_disable() to clk_prepare_enable()/clk_disable_unprepare(). Also add error checking for clk_prepare_enable(). Signed-off-by:
Yegor Yefremov <yegorslists@googlemail.com> Signed-off-by:
Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by:
-
Einar Jón authored
commit c97c52be upstream. The priv->device pointer for c_can_pci is never set, but it is used without a NULL check in c_can_start(). Setting it in c_can_pci_probe() like c_can_plat_probe() prevents c_can_pci.ko from crashing, with and without CONFIG_PM. This might also cause the pm_runtime_*() functions in c_can.c to actually be executed for c_can_pci devices - they are the only other place where priv->device is used, but they all contain a null check. Signed-off-by:
Einar Jón <tolvupostur@gmail.com> Signed-off-by:
-
Madhavan Srinivasan authored
commit df21d2fa upstream. Test uses PMC2 to count the event. But PMC1 is being initialized. Patch to fix it. Fixes: 3752e453 ('selftests/powerpc: Add tests of PMU EBBs') Signed-off-by:
Madhavan Srinivasan <maddy@linux.vnet.ibm.com> Signed-off-by:
-
Quinn Tran authored
commit fc1ffd6c upstream. During code inspection, while investigating following stack trace seen on one of the test setup, we found out there was possibility of memory leak becuase driver was not unwinding the stack properly. This issue has not been reproduced in a test environment or on a customer setup. Here's stack trace that was seen. [1469877.797315] Call Trace: [1469877.799940] [<ffffffffa03ab6e9>] qla2x00_mem_alloc+0xb09/0x10c0 [qla2xxx] [1469877.806980] [<ffffffffa03ac50a>] qla2x00_probe_one+0x86a/0x1b50 [qla2xxx] [1469877.814013] [<ffffffff813b6d01>] ? __pm_runtime_resume+0x51/0xa0 [1469877.820265] [<ffffffff8157c1f5>] ? _raw_spin_lock_irqsave+0x25/0x90 [1469877.826776] [<ffffffff8157cd2d>] ? _raw_spin_unlock_irqrestore+0x6d/0x80 [1469877.833720] [<ffffffff810741d1>] ? preempt_count_sub+0xb1/0x100 [1469877.839885] [<ffffffff8157cd0c>] ? _raw_spin_unlock_irqrestore+0x4c/0x80 [1469877.846830] [<ffffffff81319b9c>] local_pci_probe+0x4c/0xb0 [1469877.852562] [<ffffffff810741d1>] ? preempt_count_sub+0xb1/0x100 [1469877.858727] [<ffffffff81319c89>] pci_call_probe+0x89/0xb0 Signed-off-by:
Quinn Tran <quinn.tran@cavium.com> Signed-off-by:
Himanshu Madhani <himanshu.madhani@cavium.com> Reviewed-by:
Christoph Hellwig <hch@lst.de> [ bvanassche: Fixed spelling in patch description ] Signed-off-by:
Bart Van Assche <bart.vanassche@sandisk.com> Signed-off-by:
-
Richard Weinberger authored
commit 1cb51a15 upstream. When replaying the journal it can happen that a journal entry points to a garbage collected node. This is the case when a power-cut occurred between a garbage collect run and a commit. In such a case nodes have to be read using the failable read functions to detect whether the found node matches what we expect. One corner case was forgotten, when the journal contains an entry to remove an inode all xattrs have to be removed too. UBIFS models xattr like directory entries, so the TNC code iterates over all xattrs of the inode and removes them too. This code re-uses the functions for walking directories and calls ubifs_tnc_next_ent(). ubifs_tnc_next_ent() expects to be used only after the journal and aborts when a node does not match the expected result. This behavior can render an UBIFS volume unmountable after a power-cut when xattrs are used. Fix this issue by using failable read functions in ubifs_tnc_next_ent() too when replaying the journal. Fixes: 1e51764a ("UBIFS: add new flash file system") Reported-by:
Rock Lee <rockdotlee@gmail.com> Reviewed-by:
David Gstir <david@sigma-star.at> Signed-off-by:
Richard Weinberger <richard@nod.at> Signed-off-by:
-
Joonyoung Shim authored
commit bc7c36ee upstream. When a CPU goes offline a potentially pending timer interrupt is not cleared. When the CPU comes online again then the pending interrupt is delivered before the per cpu clockevent device is initialized. As a consequence the tick interrupt handler dereferences a NULL pointer. [ 51.251378] Unable to handle kernel NULL pointer dereference at virtual address 00000040 [ 51.289348] task: ee942d00 task.stack: ee960000 [ 51.293861] PC is at tick_periodic+0x38/0xb0 [ 51.298102] LR is at tick_handle_periodic+0x1c/0x90 Clear the pending interrupt in the cpu dying path. Fixes: 56a94f13 ("clocksource: exynos_mct: Avoid blocking calls in the cpu hotplug notifier") Reported-by:
Seung-Woo Kim <sw0312.kim@samsung.com> Signed-off-by:
Joonyoung Shim <jy0922.shim@samsung.com> Cc: linux-samsung-soc@vger.kernel.org Cc: cw00.choi@samsung.com Cc: daniel.lezcano@linaro.org Cc: javier@osg.samsung.com Cc: kgene@kernel.org Cc: krzk@kernel.org Cc: linux-arm-kernel@lists.infradead.org Link: http://lkml.kernel.org/r/1484628876-22065-1-git-send-email-jy0922.shim@samsung.comSigned-off-by:
Thomas Gleixner <tglx@linutronix.de> [bwh: Backported to 3.16: add definition of the 'mevt' variable, added earlier upstream] Signed-off-by:
-
Jack Morgenstein authored
commit 9577b174 upstream. When running SRIOV, warnings for SRQ LIMIT events flood the Hypervisor's message log when (correct, normally operating) apps use SRQ LIMIT events as a trigger to post WQEs to SRQs. Add more information to the existing debug printout for SRQ_LIMIT, and output the warning messages only for the SRQ CATAS ERROR event. Fixes: acba2420 ("mlx4_core: Add wrapper functions and comm channel and slave event support to EQs") Fixes: e0debf9c ("mlx4_core: Reduce warning message for SRQ_LIMIT event to debug level") Signed-off-by:
Jack Morgenstein <jackm@dev.mellanox.co.il> Signed-off-by:
Tariq Toukan <tariqt@mellanox.com> Signed-off-by:
-
Jack Morgenstein authored
commit 7c3945bc upstream. Save the qp context flags byte containing the flag disabling vlan stripping in the RESET to INIT qp transition, rather than in the INIT to RTR transition. Per the firmware spec, the flags in this byte are active in the RESET to INIT transition. As a result of saving the flags in the incorrect qp transition, when switching dynamically from VGT to VST and back to VGT, the vlan remained stripped (as is required for VST) and did not return to not-stripped (as is required for VGT). Fixes: f0f829bf ("net/mlx4_core: Add immediate activate for VGT->VST->VGT") Signed-off-by:
-
Jack Morgenstein authored
commit 291c566a upstream. In function mlx4_cq_completion() and mlx4_cq_event(), the radix_tree_lookup requires a rcu_read_lock. This is mandatory: if another core frees the CQ, it could run the radix_tree_node_rcu_free() call_rcu() callback while its being used by the radix tree lookup function. Additionally, in function mlx4_cq_event(), since we are adding the rcu lock around the radix-tree lookup, we no longer need to take the spinlock. Also, the synchronize_irq() call for the async event eliminates the need for incrementing the cq reference count in mlx4_cq_event(). Other changes: 1. In function mlx4_cq_free(), replace spin_lock_irq with spin_lock: we no longer take this spinlock in the interrupt context. The spinlock here, therefore, simply protects against different threads simultaneously invoking mlx4_cq_free() for different cq's. 2. In function mlx4_cq_free(), we move the radix tree delete to before the synchronize_irq() calls. This guarantees that we will not access this cq during any subsequent interrupts, and therefore can safely free the CQ after the synchronize_irq calls. The rcu_read_lock in the interrupt handlers only needs to protect against corrupting the radix tree; the interrupt handlers may access the cq outside the rcu_read_lock due to the synchronize_irq calls which protect against premature freeing of the cq. 3. In function mlx4_cq_event(), we change the mlx_warn message to mlx4_dbg. 4. We leave the cq reference count mechanism in place, because it is still needed for the cq completion tasklet mechanism. Fixes: 6d90aa5c ("net/mlx4_core: Make sure there are no pending async events when freeing CQ") Fixes: 225c7b1f ("IB/mlx4: Add a driver Mellanox ConnectX InfiniBand adapters") Signed-off-by:
Matan Barak <matanb@mellanox.com> Signed-off-by:
-
Ivan Vecera authored
commit fe68d8bf upstream. Return value from be_mcc_notify_wait() contains a base completion status together with an additional status. The base_status() macro need to be used to access base status. Fixes: e3a7ae2c be2net: Changing MAC Address of a VF was broken Cc: Sathya Perla <sathya.perla@broadcom.com> Cc: Ajit Khaparde <ajit.khaparde@broadcom.com> Cc: Sriharsha Basavapatna <sriharsha.basavapatna@broadcom.com> Cc: Somnath Kotur <somnath.kotur@broadcom.com> Signed-off-by:
Ivan Vecera <cera@cera.cz> Signed-off-by:
-
Liping Zhang authored
commit 6443ebc3 upstream. Currently, we check the existing rtable in PREROUTING hook, if RTCF_LOCAL is set, we assume that the packet is loopback. But this assumption is incorrect, for example, a packet encapsulated in ipsec transport mode was received and routed to local, after decapsulation, it would be delivered to local again, and the rtable was not dropped, so RTCF_LOCAL check would trigger. But actually, the packet was not loopback. So for these normal loopback packets, we can check whether the in device is IFF_LOOPBACK or not. For these locally generated broadcast/multicast, we can check whether the skb->pkt_type is PACKET_LOOPBACK or not. Finally, there's a subtle difference between nft fib expr and xtables rpfilter extension, user can add the following nft rule to do strict rpfilter check: # nft add rule x y meta iif eth0 fib saddr . iif oif != eth0 drop So when the packet is loopback, it's better to store the in device instead of the LOOPBACK_IFINDEX, otherwise, after adding the above nft rule, locally generated broad/multicast packets will be dropped incorrectly. Fixes: f83a7ea2 ("netfilter: xt_rpfilter: skip locally generated broadcast/multicast, too") Fixes: f6d0cbcf ("netfilter: nf_tables: add fib expression") Signed-off-by:
Liping Zhang <zlpnobody@gmail.com> Signed-off-by:
Pablo Neira Ayuso <pablo@netfilter.org> [bwh: Backported to 3.16: - Drop changs to nftables - s/xt_in\(par\)/par->in/] Signed-off-by:
-
Florian Fainelli authored
commit 148d3d02 upstream. The __bcm_sysport_tx_reclaim() function is used to reclaim transmit resources in different places within the driver. Most of them should not affect the state of the transit flow control. Introduce bcm_sysport_tx_clean() which cleans the ring, but does not re-enable flow control towards the networking stack, and make bcm_sysport_tx_reclaim() do the actual transmit queue flow control. Fixes: 80105bef ("net: systemport: add Broadcom SYSTEMPORT Ethernet MAC driver") Signed-off-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
-
J. Bruce Fields authored
commit 78794d18 upstream. Context expiry times are in units of seconds since boot, not unix time. The use of get_seconds() here therefore sets the expiry time decades in the future. This prevents timely freeing of contexts destroyed by client RPC_GSS_PROC_DESTROY requests. We'd still free them eventually (when the module is unloaded or the container shut down), but a lot of contexts could pile up before then. Fixes: c5b29f88 "sunrpc: use seconds since boot in expiry cache" Reported-by:
Andy Adamson <andros@netapp.com> Signed-off-by:
J. Bruce Fields <bfields@redhat.com> Signed-off-by:
-
Vlad Tsyrklevich authored
commit 30f939fe upstream. i2c_smbus_xfer() does not always fill an entire block, allowing kernel stack memory disclosure through the temp variable. Clear it before it's read to. Signed-off-by:
Vlad Tsyrklevich <vlad@tsyrklevich.net> Signed-off-by:
Wolfram Sang <wsa@the-dreams.de> Signed-off-by:
-
David Matlack authored
commit cef84c30 upstream. KVM's lapic emulation uses static_key_deferred (apic_{hw,sw}_disabled). These are implemented with delayed_work structs which can still be pending when the KVM module is unloaded. We've seen this cause kernel panics when the kvm_intel module is quickly reloaded. Use the new static_key_deferred_flush() API to flush pending updates on module unload. Signed-off-by:
David Matlack <dmatlack@google.com> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com> Signed-off-by:
-
David Matlack authored
commit b6416e61 upstream. Modules that use static_key_deferred need a way to synchronize with any delayed work that is still pending when the module is unloaded. Introduce static_key_deferred_flush() which flushes any pending jump label updates. Signed-off-by:
Peter Zijlstra (Intel) <peterz@infradead.org> Signed-off-by:
-
Arnd Bergmann authored
commit f0e8faa7 upstream. This function clearly never worked and always returns true, as pointed out by gcc-7: arch/arm/mach-ux500/pm.c: In function 'prcmu_is_cpu_in_wfi': arch/arm/mach-ux500/pm.c:137:212: error: ?: using integer constants in boolean context, the expression will always evaluate to 'true' [-Werror=int-in-bool-context] With the added braces, the condition actually makes sense. Fixes: 34fe6f10 ("mfd : Check if the other db8500 core is in WFI") Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Acked-by:
Daniel Lezcano <daniel.lezcano@linaro.org> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
Stefan Wahren authored
commit 01167c7b upstream. According to the code the intention is to append 8 SCK cycles instead of 4 at end of a MMC_STOP_TRANSMISSION command. But this will never happened because it's an AC command not an ADTC command. So fix this by moving the statement into the right function. Signed-off-by:
Stefan Wahren <stefan.wahren@i2se.com> Fixes: e4243f13 (mmc: mxs-mmc: add mmc host driver for i.MX23/28) Signed-off-by:
Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by:
-
Mathias Nyman authored
commit d6169d04 upstream. If a URB is killed while the host is removed we can end up in a situation where the hub thread takes the roothub device lock, and waits for the URB to be given back by xhci-hcd, blocking the host remove code. xhci-hcd tries to stop the endpoint and give back the urb, but can't as the host is removed from PCI bus at the same time, preventing the normal way of giving back urb. Instead we need to rely on the stop command timeout function to give back the urb. This xhci_stop_endpoint_command_watchdog() timeout function used a XHCI_STATE_DYING flag to indicate if the timeout function is already running, but later this flag has been taking into use in other places to mark that xhci is dying. Remove checks for XHCI_STATE_DYING in xhci_urb_dequeue. We are still checking that reading from pci state does not return 0xffffffff or that host is not halted before trying to stop the endpoint. This whole area of stopping endpoints, giving back URBs, and the wathdog timeout need rework, this fix focuses on solving a specific deadlock issue that we can then send to stable before any major rework. Signed-off-by:
Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> [bwh: Backported to 3.16: the checks look slightly different] Signed-off-by:
-
Bjorn Helgaas authored
commit 89e9f7bc upstream. Martin reported that the Supermicro X8DTH-i/6/iF/6F advertises incorrect host bridge windows via _CRS: pci_root PNP0A08:00: host bridge window [io 0xf000-0xffff] pci_root PNP0A08:01: host bridge window [io 0xf000-0xffff] Both bridges advertise the 0xf000-0xffff window, which cannot be correct. Work around this by ignoring _CRS on this system. The downside is that we may not assign resources correctly to hot-added PCI devices (if they are possible on this system). Link: https://bugzilla.kernel.org/show_bug.cgi?id=42606Reported-by:
Martin Burnicki <martin.burnicki@meinberg.de> Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com> Signed-off-by:
-
Eric Dumazet authored
commit 7cfd5fd5 upstream. On 32bit arches, (skb->end - skb->data) is not 'unsigned int', so we shall use min_t() instead of min() to avoid a compiler error. Fixes: 1272ce87 ("gro: Enter slow-path if there is no tailroom") Reported-by:
kernel test robot <fengguang.wu@intel.com> Signed-off-by:
-
Johan Hovold authored
commit 2d5a9c72 upstream. A short control transfer would currently fail to be detected, something which could lead to stale buffer data being used as valid input. Check for short transfers, and make sure to log any transfer errors. Note that this also avoids leaking heap data to user space (TIOCMGET) and the remote device (break control). Fixes: 6ce76104 ("USB: Driver for CH341 USB-serial adaptor") Signed-off-by:
-
Augusto Mecking Caringi authored
commit c8a6a09c upstream. In ca91cx42_slave_get function, the value pointed by vme_base pointer is set through: *vme_base = ioread32(bridge->base + CA91CX42_VSI_BS[i]); So it must be dereferenced to be used in calculation of pci_base: *pci_base = (dma_addr_t)*vme_base + pci_offset; This bug was caught thanks to the following gcc warning: drivers/vme/bridges/vme_ca91cx42.c: In function ‘ca91cx42_slave_get’: drivers/vme/bridges/vme_ca91cx42.c:467:14: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] *pci_base = (dma_addr_t)vme_base + pci_offset; Signed-off-by:
Augusto Mecking Caringi <augustocaringi@gmail.com> Acked-By:
Martyn Welch <martyn@welchs.me.uk> Signed-off-by:
-
Akinobu Mita authored
commit 802c0388 upstream. The sysrq input handler should be attached to the input device which has a left alt key. On 32-bit kernels, some input devices which has a left alt key cannot attach sysrq handler. Because the keybit bitmap in struct input_device_id for sysrq is not correctly initialized. KEY_LEFTALT is 56 which is greater than BITS_PER_LONG on 32-bit kernels. I found this problem when using a matrix keypad device which defines a KEY_LEFTALT (56) but doesn't have a KEY_O (24 == 56%32). Cc: Jiri Slaby <jslaby@suse.com> Signed-off-by:
Akinobu Mita <akinobu.mita@gmail.com> Acked-by:
Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by:
-
Richard Genoud authored
commit b389f173 upstream. When using RS485 in half duplex, RX should be enabled when TX is finished, and stopped when TX starts. Before commit 0058f087 ("tty/serial: atmel: fix RS485 half duplex with DMA"), RX was not disabled in atmel_start_tx() if the DMA was used. So, collisions could happened. But disabling RX in atmel_start_tx() uncovered another bug: RX was enabled again in the wrong place (in atmel_tx_dma) instead of being enabled when TX is finished (in atmel_complete_tx_dma), so the transmission simply stopped. This bug was not triggered before commit 0058f087 ("tty/serial: atmel: fix RS485 half duplex with DMA") because RX was never disabled before. Moving atmel_start_rx() in atmel_complete_tx_dma() corrects the problem. Reported-by:
Gil Weber <webergil@gmail.com> Fixes: 0058f087Tested-by:
Richard Genoud <richard.genoud@gmail.com> Acked-by:
Alexandre Belloni <alexandre.belloni@free-electrons.com> Signed-off-by:
-
