- 14 Dec, 2017 15 commits
-
-
Huacai Chen authored
commit c2e8fbf9 upstream. The rps_resp buffer in ata_device is a DMA target, but it isn't explicitly cacheline aligned. Due to this, adjacent fields can be overwritten with stale data from memory on non-coherent architectures. As a result, the kernel is sometimes unable to communicate with an SATA device behind a SAS expander. Fix this by ensuring that the rps_resp buffer is cacheline aligned. This issue is similar to that fixed by Commit 84bda12a ("libata: align ap->sector_buf") and Commit 4ee34ea3 ("libata: Align ata_device's id on a cacheline"). Signed-off-by:
Huacai Chen <chenhc@lemote.com> Signed-off-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Huacai Chen authored
commit 90addc6b upstream. In non-coherent DMA mode, kernel uses cache flushing operations to maintain I/O coherency, so scsi's block queue should be aligned to the value returned by dma_get_cache_alignment(). Otherwise, If a DMA buffer and a kernel structure share a same cache line, and if the kernel structure has dirty data, cache_invalidate (no writeback) will cause data corruption. Signed-off-by:
-
Christoph Hellwig authored
commit 860dd442 upstream. Provide the dummy version of dma_get_cache_alignment that always returns 1 even if CONFIG_HAS_DMA is not set, so that drivers and subsystems can use it without ifdefs. Signed-off-by:
-
William Breathitt Gray authored
commit 5a244727 upstream. The isa_driver structure for an isa_bus device is stored in the device platform_data member of the respective device structure. This platform_data member may be reset to NULL if isa_driver match callback for the device fails, indicating a device unsupported by the ISA driver. This patch fixes a possible NULL pointer dereference if one of the isa_driver callbacks to attempted for an unsupported device. This error should not occur in practice since ISA devices are typically manually configured and loaded by the users, but we may as well prevent this error from popping up for the 0day testers. Fixes: a5117ba7 ("[PATCH] Driver model: add ISA bus") Signed-off-by:
William Breathitt Gray <vilhelm.gray@gmail.com> Acked-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Paul Meyer authored
commit 297d6b6e upstream. While reading in more than one block (50) of KVP records, the allocation goes per block, but the reads used the total number of allocated records (without resetting the pointer/stream). This causes the records buffer to overrun when the refresh reads more than one block over the previous capacity (e.g. reading more than 100 KVP records whereas the in-memory database was empty before). Fix this by reading the correct number of KVP records from file each time. Signed-off-by:
Paul Meyer <Paul.Meyer@microsoft.com> Signed-off-by:
Long Li <longli@microsoft.com> Signed-off-by:
K. Y. Srinivasan <kys@microsoft.com> Signed-off-by:
-
weiping zhang authored
commit e60ea67b upstream. index can be reused by other virtio device. Signed-off-by:
weiping zhang <zhangweiping@didichuxing.com> Reviewed-by:
Cornelia Huck <cohuck@redhat.com> Signed-off-by:
Michael S. Tsirkin <mst@redhat.com> Signed-off-by:
-
Martin Kelly authored
commit 12147edc upstream. In mcba_usb, we have observed that when you unplug the device, the driver will endlessly resubmit failing URBs, which can cause CPU stalls. This issue is fixed in mcba_usb by catching the codes seen on device disconnect (-EPIPE and -EPROTO). This driver also resubmits in the case of -EPIPE and -EPROTO, so fix it in the same way. Signed-off-by:
Martin Kelly <mkelly@xevo.com> Signed-off-by:
Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by:
-
Martin Kelly authored
commit 7a31ced3 upstream. In mcba_usb, we have observed that when you unplug the device, the driver will endlessly resubmit failing URBs, which can cause CPU stalls. This issue is fixed in mcba_usb by catching the codes seen on device disconnect (-EPIPE and -EPROTO). This driver also resubmits in the case of -EPIPE and -EPROTO, so fix it in the same way. Signed-off-by:
-
Martin Kelly authored
commit bd352e1a upstream. In mcba_usb, we have observed that when you unplug the device, the driver will endlessly resubmit failing URBs, which can cause CPU stalls. This issue is fixed in mcba_usb by catching the codes seen on device disconnect (-EPIPE and -EPROTO). This driver also resubmits in the case of -EPIPE and -EPROTO, so fix it in the same way. Signed-off-by:
-
Martin Kelly authored
commit 6aa8d594 upstream. In mcba_usb, we have observed that when you unplug the device, the driver will endlessly resubmit failing URBs, which can cause CPU stalls. This issue is fixed in mcba_usb by catching the codes seen on device disconnect (-EPIPE and -EPROTO). This driver also resubmits in the case of -EPIPE and -EPROTO, so fix it in the same way. Signed-off-by:
-
Jimmy Assarsson authored
commit 8bd13bd5 upstream. Avoid flooding the kernel log with "Formate error", if incomplete message are received. Signed-off-by:
Jimmy Assarsson <jimmyassarsson@gmail.com> Signed-off-by:
-
Jimmy Assarsson authored
commit e84f44eb upstream. The conditon in the while-loop becomes true when actual_length is less than 2 (MSG_HEADER_LEN). In best case we end up with a former, already dispatched msg, that got msg->len greater than actual_length. This will result in a "Format error" error printout. Problem seen when unplugging a Kvaser USB device connected to a vbox guest. warning: comparison between signed and unsigned integer expressions [-Wsign-compare] Signed-off-by:
-
Jimmy Assarsson authored
commit 435019b4 upstream. The allocated buffer was not freed if usb_submit_urb() failed. Signed-off-by:
-
Oliver Stäbler authored
commit f6c23b17 upstream. After commit d75b1ade ("net: less interrupt masking in NAPI") napi repoll is done only when work_done == budget. So we need to return budget if there are still packets to receive. Signed-off-by:
Oliver Stäbler <oliver.staebler@bytesatwork.ch> Signed-off-by:
-
Yoshihiro Shimoda authored
commit a58204ab upstream. This controller on R-Car Gen3 has 6 pipes that included PIPE 0 for control actually. But, the datasheet has error in writing as it has 31 pipes. (However, the previous code defined 30 pipes wrongly...) Anyway, this patch fixes it. Fixes: 746bfe63 ("usb: gadget: renesas_usb3: add support for Renesas USB3.0 peripheral controller") Signed-off-by:
Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Signed-off-by:
Felipe Balbi <felipe.balbi@linux.intel.com> Signed-off-by:
-
- 09 Dec, 2017 25 commits
-
-
Greg Kroah-Hartman authored
-
Vitaly Kuznetsov authored
commit d86b5672 upstream. Unavoidable crashes in netfront_resume() and netback_changed() after a previous fail in talk_to_netback() (e.g. when we fail to read MAC from xenstore) were discovered. The failure path in talk_to_netback() does unregister/free for netdev but we don't reset drvdata and we try accessing it after resume. Fix the bug by removing the whole xen device completely with device_unregister(), this guarantees we won't have any calls into netfront after a failure. Signed-off-by:
Vitaly Kuznetsov <vkuznets@redhat.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Cc: Ben Hutchings <ben.hutchings@codethink.co.uk> Signed-off-by:
-
Colin Ian King authored
commit 1d5a3158 upstream. The variable temp is incorrectly being updated, instead it should be offset otherwise the loop just reads the same capability value and loops forever. Thanks to Alan Stern for pointing out the correct fix to my original fix. Fix also cleans up clang warning: drivers/usb/host/ehci-dbg.c:840:4: warning: Value stored to 'temp' is never read Fixes: d49d4317 ("USB: misc ehci updates") Signed-off-by:
Colin Ian King <colin.king@canonical.com> Acked-by:
Alan Stern <stern@rowland.harvard.edu> Signed-off-by:
-
Oliver Neukum authored
commit 446f666d upstream. USBDEVFS_URB_ISO_ASAP must be accepted only for ISO endpoints. Improve sanity checking. Reported-by:
Andrey Konovalov <andreyknvl@google.com> Signed-off-by:
Oliver Neukum <oneukum@suse.com> Acked-by:
-
Dan Carpenter authored
commit 57999d11 upstream. There used to be an integer overflow check in proc_do_submiturb() but we removed it. It turns out that it's still required. The uurb->buffer_length variable is a signed integer and it's controlled by the user. It can lead to an integer overflow when we do: num_sgs = DIV_ROUND_UP(uurb->buffer_length, USB_SG_SIZE); If we strip away the macro then that line looks like this: num_sgs = (uurb->buffer_length + USB_SG_SIZE - 1) / USB_SG_SIZE; ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ It's the first addition which can overflow. Fixes: 1129d270 ("USB: Increase usbfs transfer limit") Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Acked-by:
-
Mateusz Berezecki authored
commit 1129d270 upstream. Promote a variable keeping track of USB transfer memory usage to a wider data type and allow for higher bandwidth transfers from a large number of USB devices connected to a single host. Signed-off-by:
Mateusz Berezecki <mateuszb@fastmail.fm> Signed-off-by:
-
Masakazu Mokuno authored
commit 81cf4a45 upstream. As most of BOS descriptors are longer in length than their header 'struct usb_dev_cap_header', comparing solely with it is not sufficient to avoid out-of-bounds access to BOS descriptors. This patch adds descriptor type specific length check in usb_get_bos_descriptor() to fix the issue. Signed-off-by:
Masakazu Mokuno <masakazu.mokuno@gmail.com> Signed-off-by:
-
Yu Chen authored
commit 80e45769 upstream. Check vdev->real_port 0 to avoid panic [ 9.261347] [<ffffff800884a390>] xhci_free_virt_devices_depth_first+0x58/0x108 [ 9.261352] [<ffffff800884a814>] xhci_mem_cleanup+0x1bc/0x570 [ 9.261355] [<ffffff8008842de8>] xhci_stop+0x140/0x1c8 [ 9.261365] [<ffffff80087ed304>] usb_remove_hcd+0xfc/0x1d0 [ 9.261369] [<ffffff80088551c4>] xhci_plat_remove+0x6c/0xa8 [ 9.261377] [<ffffff80086e928c>] platform_drv_remove+0x2c/0x70 [ 9.261384] [<ffffff80086e6ea0>] __device_release_driver+0x80/0x108 [ 9.261387] [<ffffff80086e7a1c>] device_release_driver+0x2c/0x40 [ 9.261392] [<ffffff80086e5f28>] bus_remove_device+0xe0/0x120 [ 9.261396] [<ffffff80086e2e34>] device_del+0x114/0x210 [ 9.261399] [<ffffff80086e9e00>] platform_device_del+0x30/0xa0 [ 9.261403] [<ffffff8008810bdc>] dwc3_otg_work+0x204/0x488 [ 9.261407] [<ffffff80088133fc>] event_work+0x304/0x5b8 [ 9.261414] [<ffffff80080e31b0>] process_one_work+0x148/0x490 [ 9.261417] [<ffffff80080e3548>] worker_thread+0x50/0x4a0 [ 9.261421] [<ffffff80080e9ea0>] kthread+0xe8/0x100 [ 9.261427] [<ffffff8008083680>] ret_from_fork+0x10/0x50 The problem can occur if xhci_plat_remove() is called shortly after xhci_plat_probe(). While xhci_free_virt_devices_depth_first been called before the device has been setup and get real_port initialized. The problem occurred on Hikey960 and was reproduced by Guenter Roeck on Kevin with chromeos-4.4. Fixes: ee8665e2 ("xhci: free xhci virtual devices with leaf nodes first") Cc: Guenter Roeck <groeck@google.com> Reviewed-by:
Guenter Roeck <groeck@chromium.org> Tested-by:
Guenter Roeck <linux@roeck-us.net> Signed-off-by:
Fan Ning <fanning4@hisilicon.com> Signed-off-by:
Li Rui <lirui39@hisilicon.com> Signed-off-by:
yangdi <yangdi10@hisilicon.com> Signed-off-by:
Yu Chen <chenyu56@huawei.com> Signed-off-by:
Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by:
-
Mike Looijmans authored
commit 973593a9 upstream. Sometimes the USB device gets confused about the state of the initialization and the connection fails. In particular, the device thinks that it's already set up and running while the host thinks the device still needs to be configured. To work around this issue, power-cycle the hub's output to issue a sort of "reset" to the device. This makes the device restart its state machine and then the initialization succeeds. This fixes problems where the kernel reports a list of errors like this: usb 1-1.3: device not accepting address 19, error -71 The end result is a non-functioning device. After this patch, the sequence becomes like this: usb 1-1.3: new high-speed USB device number 18 using ci_hdrc usb 1-1.3: device not accepting address 18, error -71 usb 1-1.3: new high-speed USB device number 19 using ci_hdrc usb 1-1.3: device not accepting address 19, error -71 usb 1-1-port3: attempt power cycle usb 1-1.3: new high-speed USB device number 21 using ci_hdrc usb-storage 1-1.3:1.2: USB Mass Storage device detected Signed-off-by:
Mike Looijmans <mike.looijmans@topic.nl> Acked-by:
-
Daniel Vetter authored
commit 24a36734 upstream. This was missed when adding a dma_fence_get call. While at it also remove the kerneldoc for the static inline helper - no point documenting internals down to every detail. Fixes: 30cd85dd ("dma-buf/sync_file: hold reference to fence when creating sync_file") Cc: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Cc: Sean Paul <seanpaul@chromium.org> Cc: linux-doc@vger.kernel.org Cc: Jonathan Corbet <corbet@lwn.net> Cc: Sumit Semwal <sumit.semwal@linaro.org> Signed-off-by:
Daniel Vetter <daniel.vetter@intel.com> Reviewed-by:
Gustavo Padovan <gustavo.padovan@collabora.co.uk> Signed-off-by:
Sumit Semwal <sumit.semwal@linaro.org> Link: http://patchwork.freedesktop.org/patch/msgid/20161209185309.1682-3-daniel.vetter@ffwll.chSigned-off-by:
-
Gustavo Padovan authored
commit 30cd85dd upstream. fence referencing was out of balance. It was not taking any ref to the fence at creating time, but it was putting a reference when freeing the sync file. This patch fixes the balancing issue by getting a reference for the fence when creating the sync_file. Signed-off-by:
Sean Paul <seanpaul@chromium.org> Link: http://patchwork.freedesktop.org/patch/msgid/1476899313-22241-1-git-send-email-gustavo@padovan.orgSigned-off-by:
-
Dominik Behr authored
commit ea4d5a27 upstream. To avoid hanging userspace components that might have been waiting on the active fences of the destroyed timeline we need to signal with error all remaining fences on such timeline. This restore the default behaviour of the Android sw_sync framework, which Android still relies on. It was broken on the dma fence conversion a few years ago and never fixed. v2: Do not bother with cleanup do the list (Chris Wilson) Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Dominik Behr <dbehr@chromium.org> Signed-off-by:
Gustavo Padovan <gustavo.padovan@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170907190246.16425-2-gustavo@padovan.org [s/dma_fence/fence/g - gregkh] Cc: Jisheng Zhang <Jisheng.Zhang@synaptics.com> Signed-off-by:
-
Chris Wilson authored
commit a009e975 upstream. The dma_fence.error field (formerly known as dma_fence.status) is an optional field that may be set by drivers before calling dma_fence_signal(). The field can be used to indicate that the fence was completed in err rather than with success, and is visible to other consumers of the fence and to userspace via sync_file. This patch renames the field from status to error so that its meaning is hopefully more clear (and distinct from dma_fence_get_status() which is a composite between the error state and signal state) and adds a helper that validates the preconditions of when it is suitable to adjust the error field. Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by:
-
Chris Wilson authored
commit d6c99f4b upstream. The fence->status is an optional field that is only valid once the fence has been signaled. (Driver may fill the fence->status with an error code prior to calling dma_fence_signal().) Given the restriction upon its validity, wrap querying of the fence->status into a helper dma_fence_get_status(). Signed-off-by:
-
Chris Wilson authored
commit 83dd1376 upstream. As the fence->status is an optional field that may be set before dma_fence_signal() is called to convey that the fence completed with an error, we have to ensure that it is always set to zero on initialisation so that the typical use (i.e. unset) always flags a successful completion. Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by:
-
Gustavo Padovan authored
commit 3792b7c1 upstream. If userspace already dropped its own reference by closing the sw_sync fence fd we might end up in a deadlock where dma_fence_is_signaled_locked() will trigger the release of the fence and thus try to hold the lock to remove the fence from the list. dma_fence_is_signaled_locked() tries to release/free the fence and hold the lock in the process. We fix that by changing the order operation and clean up the list and rb-tree first. v2: Drop fence get/put dance and manipulate the list first (Chris Wilson) Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
Gustavo Padovan authored
commit 150b6a9d upstream. We are going to use timeline_fence_signaled() in a internal function in the next commit. Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
Chris Wilson authored
commit f1e8c671 upstream. Reduce the list iteration when incrementing the timeline by storing the fences in increasing order. v2: Prevent spinlock recursion on free during create v3: Fixup rebase conflict inside comments that escaped the compiler. Signed-off-by:
-
Chris Wilson authored
commit d3862e44 upstream. The sync_pt were not adding themselves atomically to the timeline lists, corruption imminent. Only a single list is required to track the unsignaled sync_pt, so reduce it and rename the lock more appropriately along with using idiomatic names to distinguish a list from links along it. v2: Prevent spinlock recursion on free during create (next patch) and fixup crossref in kerneldoc Signed-off-by:
-
Chris Wilson authored
commit 3b52ce44 upstream. Since sync_pt is only allocated from a single location and is no longer the base class for fences (that is struct dma_fence) it no longer needs a generic unsized allocator. Signed-off-by:
-
Chris Wilson authored
commit a6aa8fca upstream. If we know the context under which we are called, then we can use the simpler form of spin_lock_irq (saving the save/restore). Signed-off-by:
-
Chris Wilson authored
commit 8f66d3aa upstream. The timeline is u32, which limits any single advance to INT_MAX so that we can detect all fences that need signaling. Signed-off-by:
-
Chris Wilson authored
commit 61894b02 upstream. Use the canonical __dma_fence_is_later() to compare the fence seqno against the timeline seqno to check if the fence is signaled. Signed-off-by:
-
Chris Wilson authored
commit 81114776 upstream. Often we have the task of comparing two seqno known to be on the same context, so provide a common __dma_fence_is_later(). Signed-off-by:
-
Rui Sousa authored
[ Upstream commit 01f8902b ] Fix hardware setup of multicast address hash: - Never clear the hardware hash (to avoid packet loss) - Construct the hash register values in software and then write once to hardware Signed-off-by:
Rui Sousa <rui.sousa@nxp.com> Signed-off-by:
Fugang Duan <fugang.duan@nxp.com> Signed-off-by:
Sasha Levin <alexander.levin@verizon.com> Signed-off-by:
-
