summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* SUNRPC: Avoid RPC delays when exiting suspendTrond Myklebust2019-11-061-1/+1
| | | | | | | | | | | | | | Jon Hunter: "I have been tracking down another suspend/NFS related issue where again I am seeing random delays exiting suspend. The delays can be up to a couple minutes in the worst case and this is causing a suspend test we have to fail." Change the use of a deferrable work to a standard delayed one. Reported-by: Jon Hunter <jonathanh@nvidia.com> Tested-by: Jon Hunter <jonathanh@nvidia.com> Fixes: 7e0a0e38fcfea ("SUNRPC: Replace the queue timer with a delayed work function") Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
* NFS: Add a tracepoint in nfs_fh_to_dentry()Trond Myklebust2019-11-032-0/+34
| | | | | | | Add a tracepoint in nfs_fh_to_dentry() for debugging issues with bad userspace filehandles. Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
* NFSv4: Don't retry the GETATTR on old stateid in nfs4_delegreturn_done()Trond Myklebust2019-11-031-0/+4
| | | | | | | | If the server returns NFS4ERR_OLD_STATEID, then just skip retrying the GETATTR when replaying the delegreturn compound. We know nothing will have changed on the server. Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
* NFSv4: Handle NFS4ERR_OLD_STATEID in delegreturnTrond Myklebust2019-11-032-4/+4
| | | | | | | | | | | | | | | | | If the server returns NFS4ERR_OLD_STATEID in response to our delegreturn, we want to sync to the most recent seqid for the delegation stateid. However if we are already at the most recent, we have two possibilities: - an OPEN reply is still outstanding and will return a new seqid - an earlier OPEN reply was dropped on the floor due to a timeout. In the latter case, we may end up unable to complete the delegreturn, so we want to bump the seqid to a value greater than the cached value. While this may cause us to lose the delegation in the former case, it should now be safe to assume that the client will replay the OPEN if necessary in order to get a new valid stateid. Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
* NFSv4: Fix races between open and delegreturnTrond Myklebust2019-11-031-35/+29
| | | | | | | | | | | If the server returns the same delegation in an open that we just used in a delegreturn, we need to ensure we don't apply that stateid if the delegreturn has freed it on the server. To do so, we ensure that we do not free the storage for the delegation until either it is replaced by a new one, or we throw the inode out of cache. Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
* NFS: nfs_inode_find_state_and_recover() fix stateid matchingTrond Myklebust2019-11-033-4/+12
| | | | | | | | In nfs_inode_find_state_and_recover() we want to mark for recovery only those stateids that match or are older than the supplied stateid parameter. Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
* NFSv4: Fix nfs4_inode_make_writeable()Trond Myklebust2019-11-031-4/+12
| | | | | | | | Fix the checks in nfs4_inode_make_writeable() to ignore the case where we hold no delegations. Currently, in such a case, we automatically flush writes. Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
* NFSv4: nfs4_return_incompatible_delegation() should check delegation validityTrond Myklebust2019-11-031-1/+1
| | | | | | | Ensure that we check that the delegation is valid in nfs4_return_incompatible_delegation() before we try to return it. Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
* NFSv4: Don't reclaim delegations that have been returned or revokedTrond Myklebust2019-11-031-1/+1
| | | | | | | If the delegation has already been revoked, we want to avoid reclaiming it on reboot. Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
* NFSv4: Ignore requests to return the delegation if it was revokedTrond Myklebust2019-11-031-3/+4
| | | | | | | | If the delegation was revoked, or is already being returned, just clear the NFS_DELEGATION_RETURN and NFS_DELEGATION_RETURN_IF_CLOSED flags and keep going. Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
* NFSv4: Revoke the delegation on success in nfs4_delegreturn_done()Trond Myklebust2019-11-033-0/+38
| | | | | | If the delegation was successfully returned, then mark it as revoked. Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
* NFSv4: Update the stateid seqid in nfs_revoke_delegation()Trond Myklebust2019-11-031-2/+13
| | | | | | | If we revoke a delegation, but the stateid's seqid is newer, then ensure we update the seqid when marking the delegation as revoked. Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
* NFSv4: Clear the NFS_DELEGATION_REVOKED flag in nfs_update_inplace_delegation()Trond Myklebust2019-11-031-0/+1
| | | | | | | If the server sent us a new delegation stateid that is more recent than the one that got revoked, then clear the NFS_DELEGATION_REVOKED flag. Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
* NFSv4: Hold the delegation spinlock when updating the seqidTrond Myklebust2019-11-031-0/+2
| | | | Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
* NFSv4: Don't remove the delegation from the super_list more than onceTrond Myklebust2019-11-031-0/+4
| | | | | | | Add a check to ensure that we haven't already removed the delegation from the inode after we take all the relevant locks. Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
* NFS: Rename nfs_inode_return_delegation_noreclaim()Trond Myklebust2019-11-033-7/+10
| | | | | | | | Rename nfs_inode_return_delegation_noreclaim() to nfs_inode_evict_delegation(), which better describes what it does. Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
* NFSv4: fail nfs4_refresh_delegation_stateid() when the delegation was revokedTrond Myklebust2019-11-031-1/+2
| | | | | | If the delegation was revoked, we don't want to retry the delegreturn. Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
* NFSv4: Delegation recalls should not find revoked delegationsTrond Myklebust2019-11-031-1/+2
| | | | | | | If we're processsing a delegation recall, ignore the delegations that have already been revoked or returned. Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
* NFSv4: nfs4_callback_getattr() should ignore revoked delegationsTrond Myklebust2019-11-031-3/+1
| | | | | | If the delegation has been revoked, ignore it. Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
* NFSv4: Fix delegation handling in update_open_stateid()Trond Myklebust2019-11-031-2/+2
| | | | | | | If the delegation is marked as being revoked, then don't use it in the open state structure. Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
* NFSv4.1: Don't rebind to the same source port when reconnecting to the serverTrond Myklebust2019-11-038-5/+20
| | | | | | | | | | | | | | NFSv2, v3 and NFSv4 servers often have duplicate replay caches that look at the source port when deciding whether or not an RPC call is a replay of a previous call. This requires clients to perform strange TCP gymnastics in order to ensure that when they reconnect to the server, they bind to the same source port. NFSv4.1 and NFSv4.2 have sessions that provide proper replay semantics, that do not look at the source port of the connection. This patch therefore ensures they can ignore the rebind requirement. Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
* NFS/pnfs: Separate NFSv3 DS and MDS trafficTrond Myklebust2019-11-033-0/+8
| | | | | | | | | | | If a NFSv3 server is being used as both a DS and as a regular NFSv3 server, we may want to keep the IO traffic on a separate TCP connection, since it will typically have very different timeout characteristics. This patch therefore sets up a flag to separate the two modes of operation for the nfs_client. Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
* pNFS: nfs3_set_ds_client should set NFS_CS_NOPINGTrond Myklebust2019-11-031-0/+2
| | | | | | | | Connecting to the DS is a non-interactive, asynchronous task, so there is no reason to fire up an extra RPC null ping in order to ensure that the server is up. Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
* NFS: Add a flag to tell nfs_client to set RPC_CLNT_CREATE_NOPINGTrond Myklebust2019-11-032-0/+3
| | | | | | | Add a flag to tell the nfs_client it should set RPC_CLNT_CREATE_NOPING when creating the rpc client. Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
* NFS: Use non-atomic bit ops when initialising struct nfs_client_initdataTrond Myklebust2019-11-032-4/+4
| | | | | | | We don't need atomic bit ops when initialising a local structure on the stack. Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
* NFSv3: Clean up timespec encodeTrond Myklebust2019-11-032-9/+5
| | | | | | | Simplify the struct iattr timestamp encoding by skipping the step of an intermediate struct timespec. Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
* NFSv2: Clean up timespec encodeTrond Myklebust2019-11-031-12/+7
| | | | | | | Simplify the struct iattr timestamp encoding by skipping the step of an intermediate struct timespec. Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
* NFSv2: Fix a typo in encode_sattr()Trond Myklebust2019-11-031-1/+1
| | | | | | | Encode the mtime correctly. Fixes: 95582b0083883 ("vfs: change inode times to use struct timespec64") Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
* NFSv4: NFSv4 callbacks also support 64-bit timestampsTrond Myklebust2019-11-033-7/+7
| | | | | | | Convert the NFSv4 callbacks to use struct timestamp64, rather than truncating times to 32-bit values. Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
* NFSv4: Encode 64-bit timestampsTrond Myklebust2019-11-031-6/+3
| | | | | | | NFSv4 supports 64-bit timestamps, so there is no point in converting the struct iattr timestamps to 32-bits before encoding. Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
* NFS: Convert struct nfs_fattr to use struct timespec64Trond Myklebust2019-11-037-44/+44
| | | | | | | NFSv4 supports 64-bit times, so we should switch to using struct timespec64 when decoding attributes. Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
* NFS: If nfs_mountpoint_expiry_timeout < 0, do not expire submountsTrond Myklebust2019-11-031-0/+3
| | | | | | | If we set nfs_mountpoint_expiry_timeout to a negative value, then allow that to imply that we do not expire NFSv4 submounts. Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
* Linux 5.4-rc6v5.4-rc6Linus Torvalds2019-11-031-1/+1
|
* Merge tag 'usb-5.4-rc6' of ↵Linus Torvalds2019-11-0327-97/+267
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb Pull USB fixes from Greg KH: "The USB sub-maintainers woke up this past week and sent a bunch of tiny fixes. Here are a lot of small patches that that resolve a bunch of reported issues in the USB core, drivers, serial drivers, gadget drivers, and of course, xhci :) All of these have been in linux-next with no reported issues" * tag 'usb-5.4-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb: (31 commits) usb: dwc3: gadget: fix race when disabling ep with cancelled xfers usb: cdns3: gadget: Fix g_audio use case when connected to Super-Speed host usb: cdns3: gadget: reset EP_CLAIMED flag while unloading USB: serial: whiteheat: fix line-speed endianness USB: serial: whiteheat: fix potential slab corruption USB: gadget: Reject endpoints with 0 maxpacket value UAS: Revert commit 3ae62a42090f ("UAS: fix alignment of scatter/gather segments") usb-storage: Revert commit 747668dbc061 ("usb-storage: Set virt_boundary_mask to avoid SG overflows") usbip: Fix free of unallocated memory in vhci tx usbip: tools: Fix read_usb_vudc_device() error path handling usb: xhci: fix __le32/__le64 accessors in debugfs code usb: xhci: fix Immediate Data Transfer endianness xhci: Fix use-after-free regression in xhci clear hub TT implementation USB: ldusb: fix control-message timeout USB: ldusb: use unsigned size format specifiers USB: ldusb: fix ring-buffer locking USB: Skip endpoints with 0 maxpacket length usb: cdns3: gadget: Don't manage pullups usb: dwc3: remove the call trace of USBx_GFLADJ usb: gadget: configfs: fix concurrent issue between composite APIs ...
| * usb: dwc3: gadget: fix race when disabling ep with cancelled xfersFelipe Balbi2019-10-311-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | When disabling an endpoint which has cancelled requests, we should make sure to giveback requests that are currently pending in the cancelled list, otherwise we may fall into a situation where command completion interrupt fires after endpoint has been disabled, therefore causing a splat. Fixes: fec9095bdef4 "usb: dwc3: gadget: remove wait_end_transfer" Reported-by: Roger Quadros <rogerq@ti.com> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com> Link: https://lore.kernel.org/r/20191031090713.1452818-1-felipe.balbi@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * usb: cdns3: gadget: Fix g_audio use case when connected to Super-Speed hostRoger Quadros2019-10-301-5/+26
| | | | | | | | | | | | | | | | | | | | | | Take into account gadget driver's speed limit when programming controller speed. Fixes: 7733f6c32e36 ("usb: cdns3: Add Cadence USB3 DRD Driver") Signed-off-by: Roger Quadros <rogerq@ti.com> Acked-by: Peter Chen <peter.chen@nxp.com> Link: https://lore.kernel.org/r/20191030121607.21739-1-rogerq@ti.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * usb: cdns3: gadget: reset EP_CLAIMED flag while unloadingSanket Parmar2019-10-301-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | EP_CLAIMED flag is used to track the claimed endpoints. While unloading the module, Reset EP_CLAIMED flag for all enabled endpoints. So that it can be reused. Signed-off-by: Sanket Parmar <sparmar@cadence.com> Acked-by: Peter Chen <peter.chen@nxp.com> Reviewed-by: Roger Quadros <rogerq@ti.com> Acked-by: Felipe Balbi <balbi@kernel.org> Link: https://lore.kernel.org/r/20191029122441.5816-1-sparmar@cadence.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * USB: serial: whiteheat: fix line-speed endiannessJohan Hovold2019-10-302-4/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | Add missing endianness conversion when setting the line speed so that this driver might work also on big-endian machines. Also use an unsigned format specifier in the corresponding debug message. Signed-off-by: Johan Hovold <johan@kernel.org> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20191029102354.2733-3-johan@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * USB: serial: whiteheat: fix potential slab corruptionJohan Hovold2019-10-301-0/+4
| | | | | | | | | | | | | | | | | | | | | | Fix a user-controlled slab buffer overflow due to a missing sanity check on the bulk-out transfer buffer used for control requests. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable <stable@vger.kernel.org> Signed-off-by: Johan Hovold <johan@kernel.org> Link: https://lore.kernel.org/r/20191029102354.2733-2-johan@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * USB: gadget: Reject endpoints with 0 maxpacket valueAlan Stern2019-10-291-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Endpoints with a maxpacket length of 0 are probably useless. They can't transfer any data, and it's not at all unlikely that a UDC will crash or hang when trying to handle a non-zero-length usb_request for such an endpoint. Indeed, dummy-hcd gets a divide error when trying to calculate the remainder of a transfer length by the maxpacket value, as discovered by the syzbot fuzzer. Currently the gadget core does not check for endpoints having a maxpacket value of 0. This patch adds a check to usb_ep_enable(), preventing such endpoints from being used. As far as I know, none of the gadget drivers in the kernel tries to create an endpoint with maxpacket = 0, but until now there has been nothing to prevent userspace programs under gadgetfs or configfs from doing it. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Reported-and-tested-by: syzbot+8ab8bf161038a8768553@syzkaller.appspotmail.com CC: <stable@vger.kernel.org> Acked-by: Felipe Balbi <balbi@kernel.org> Link: https://lore.kernel.org/r/Pine.LNX.4.44L0.1910281052370.1485-100000@iolanthe.rowland.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * UAS: Revert commit 3ae62a42090f ("UAS: fix alignment of scatter/gather ↵Alan Stern2019-10-281-20/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | segments") Commit 3ae62a42090f ("UAS: fix alignment of scatter/gather segments"), copying a similar commit for usb-storage, attempted to solve a problem involving scatter-gather I/O and USB/IP by setting the virt_boundary_mask for mass-storage devices. However, it now turns out that the analogous change in usb-storage interacted badly with commit 09324d32d2a0 ("block: force an unlimited segment size on queues with a virt boundary"), which was added later. A typical error message is: ehci-pci 0000:00:13.2: swiotlb buffer is full (sz: 327680 bytes), total 32768 (slots), used 97 (slots) There is no longer any reason to keep the virt_boundary_mask setting in the uas driver. It was needed in the first place only for handling devices with a block size smaller than the maxpacket size and where the host controller was not capable of fully general scatter-gather operation (that is, able to merge two SG segments into a single USB packet). But: High-speed or slower connections never use a bulk maxpacket value larger than 512; The SCSI layer does not handle block devices with a block size smaller than 512 bytes; All the host controllers capable of SuperSpeed operation can handle fully general SG; Since commit ea44d190764b ("usbip: Implement SG support to vhci-hcd and stub driver") was merged, the USB/IP driver can also handle SG. Therefore all supported device/controller combinations should be okay with no need for any special virt_boundary_mask. So in order to head off potential problems similar to those affecting usb-storage, this patch reverts commit 3ae62a42090f. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> CC: Oliver Neukum <oneukum@suse.com> CC: <stable@vger.kernel.org> Acked-by: Christoph Hellwig <hch@lst.de> Fixes: 3ae62a42090f ("UAS: fix alignment of scatter/gather segments") Link: https://lore.kernel.org/r/Pine.LNX.4.44L0.1910231132470.1878-100000@iolanthe.rowland.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * usb-storage: Revert commit 747668dbc061 ("usb-storage: Set ↵Alan Stern2019-10-281-10/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | virt_boundary_mask to avoid SG overflows") Commit 747668dbc061 ("usb-storage: Set virt_boundary_mask to avoid SG overflows") attempted to solve a problem involving scatter-gather I/O and USB/IP by setting the virt_boundary_mask for mass-storage devices. However, it now turns out that this interacts badly with commit 09324d32d2a0 ("block: force an unlimited segment size on queues with a virt boundary"), which was added later. A typical error message is: ehci-pci 0000:00:13.2: swiotlb buffer is full (sz: 327680 bytes), total 32768 (slots), used 97 (slots) There is no longer any reason to keep the virt_boundary_mask setting for usb-storage. It was needed in the first place only for handling devices with a block size smaller than the maxpacket size and where the host controller was not capable of fully general scatter-gather operation (that is, able to merge two SG segments into a single USB packet). But: High-speed or slower connections never use a bulk maxpacket value larger than 512; The SCSI layer does not handle block devices with a block size smaller than 512 bytes; All the host controllers capable of SuperSpeed operation can handle fully general SG; Since commit ea44d190764b ("usbip: Implement SG support to vhci-hcd and stub driver") was merged, the USB/IP driver can also handle SG. Therefore all supported device/controller combinations should be okay with no need for any special virt_boundary_mask. So in order to fix the swiotlb problem, this patch reverts commit 747668dbc061. Reported-and-tested-by: Piergiorgio Sartor <piergiorgio.sartor@nexgo.de> Link: https://marc.info/?l=linux-usb&m=157134199501202&w=2 Signed-off-by: Alan Stern <stern@rowland.harvard.edu> CC: Seth Bollinger <Seth.Bollinger@digi.com> CC: <stable@vger.kernel.org> Fixes: 747668dbc061 ("usb-storage: Set virt_boundary_mask to avoid SG overflows") Acked-by: Christoph Hellwig <hch@lst.de> Link: https://lore.kernel.org/r/Pine.LNX.4.44L0.1910211145520.1673-100000@iolanthe.rowland.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * usbip: Fix free of unallocated memory in vhci txSuwan Kim2019-10-281-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | iso_buffer should be set to NULL after use and free in the while loop. In the case of isochronous URB in the while loop, iso_buffer is allocated and after sending it to server, buffer is deallocated. And then, if the next URB in the while loop is not a isochronous pipe, iso_buffer still holds the previously deallocated buffer address and kfree tries to free wrong buffer address. Fixes: ea44d190764b ("usbip: Implement SG support to vhci-hcd and stub driver") Reported-by: kbuild test robot <lkp@intel.com> Reported-by: Julia Lawall <julia.lawall@lip6.fr> Signed-off-by: Suwan Kim <suwan.kim027@gmail.com> Reviewed-by: Julia Lawall <julia.lawall@lip6.fr> Acked-by: Shuah Khan <skhan@linuxfoundation.org> Link: https://lore.kernel.org/r/20191022093017.8027-1-suwan.kim027@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * usbip: tools: Fix read_usb_vudc_device() error path handlingGwanYeong Kim2019-10-281-2/+4
| | | | | | | | | | | | | | | | | | | | | | This isn't really accurate right. fread() doesn't always return 0 in error. It could return < number of elements and set errno. Signed-off-by: GwanYeong Kim <gy741.kim@gmail.com> Acked-by: Shuah Khan <skhan@linuxfoundation.org> Link: https://lore.kernel.org/r/20191018032223.4644-1-gy741.kim@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * usb: xhci: fix __le32/__le64 accessors in debugfs codeBen Dooks (Codethink)2019-10-281-12/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It looks like some of the xhci debug code is passing u32 to functions directly from __le32/__le64 fields. Fix this by using le{32,64}_to_cpu() on these to fix the following sparse warnings; xhci-debugfs.c:205:62: warning: incorrect type in argument 1 (different base types) xhci-debugfs.c:205:62: expected unsigned int [usertype] field0 xhci-debugfs.c:205:62: got restricted __le32 xhci-debugfs.c:206:62: warning: incorrect type in argument 2 (different base types) xhci-debugfs.c:206:62: expected unsigned int [usertype] field1 xhci-debugfs.c:206:62: got restricted __le32 ... [Trim down commit message, sparse warnings were similar -Mathias] Cc: <stable@vger.kernel.org> # 4.15+ Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/1572013829-14044-4-git-send-email-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * usb: xhci: fix Immediate Data Transfer endiannessSamuel Holland2019-10-281-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The arguments to queue_trb are always byteswapped to LE for placement in the ring, but this should not happen in the case of immediate data; the bytes copied out of transfer_buffer are already in the correct order. Add a complementary byteswap so the bytes end up in the ring correctly. This was observed on BE ppc64 with a "Texas Instruments TUSB73x0 SuperSpeed USB 3.0 xHCI Host Controller [104c:8241]" as a ch341 usb-serial adapter ("1a86:7523 QinHeng Electronics HL-340 USB-Serial adapter") always transmitting the same character (generally NUL) over the serial link regardless of the key pressed. Cc: <stable@vger.kernel.org> # 5.2+ Fixes: 33e39350ebd2 ("usb: xhci: add Immediate Data Transfer support") Signed-off-by: Samuel Holland <samuel@sholland.org> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/1572013829-14044-3-git-send-email-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * xhci: Fix use-after-free regression in xhci clear hub TT implementationMathias Nyman2019-10-281-9/+45
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit ef513be0a905 ("usb: xhci: Add Clear_TT_Buffer") schedules work to clear TT buffer, but causes a use-after-free regression at the same time Make sure hub_tt_work finishes before endpoint is disabled, otherwise the work will dereference already freed endpoint and device related pointers. This was triggered when usb core failed to read the configuration descriptor of a FS/LS device during enumeration. xhci driver queued clear_tt_work while usb core freed and reallocated a new device for the next enumeration attempt. EHCI driver implents ehci_endpoint_disable() that makes sure clear_tt_work has finished before it returns, but xhci lacks this support. usb core will call hcd->driver->endpoint_disable() callback before disabling endpoints, so we want this in xhci as well. The added xhci_endpoint_disable() is based on ehci_endpoint_disable() Fixes: ef513be0a905 ("usb: xhci: Add Clear_TT_Buffer") Cc: <stable@vger.kernel.org> # v5.3 Reported-by: Johan Hovold <johan@kernel.org> Suggested-by: Johan Hovold <johan@kernel.org> Reviewed-by: Johan Hovold <johan@kernel.org> Tested-by: Johan Hovold <johan@kernel.org> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/1572013829-14044-2-git-send-email-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * USB: ldusb: fix control-message timeoutJohan Hovold2019-10-281-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | USB control-message timeouts are specified in milliseconds, not jiffies. Waiting 83 minutes for a transfer to complete is a bit excessive. Fixes: 2824bd250f0b ("[PATCH] USB: add ldusb driver") Cc: stable <stable@vger.kernel.org> # 2.6.13 Reported-by: syzbot+a4fbb3bb76cda0ea4e58@syzkaller.appspotmail.com Signed-off-by: Johan Hovold <johan@kernel.org> Link: https://lore.kernel.org/r/20191022153127.22295-1-johan@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * USB: ldusb: use unsigned size format specifiersJohan Hovold2019-10-281-3/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A recent info-leak bug manifested itself along with warning about a negative buffer overflow: ldusb 1-1:0.28: Read buffer overflow, -131383859965943 bytes dropped when it was really a rather large positive one. A sanity check that prevents this has now been put in place, but let's fix up the size format specifiers, which should all be unsigned. Signed-off-by: Johan Hovold <johan@kernel.org> Link: https://lore.kernel.org/r/20191022143203.5260-3-johan@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * USB: ldusb: fix ring-buffer lockingJohan Hovold2019-10-281-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The custom ring-buffer implementation was merged without any locking or explicit memory barriers, but a spinlock was later added by commit 9d33efd9a791 ("USB: ldusb bugfix"). The lock did not cover the update of the tail index once the entry had been processed, something which could lead to memory corruption on weakly ordered architectures or due to compiler optimisations. Specifically, a completion handler running on another CPU might observe the incremented tail index and update the entry before ld_usb_read() is done with it. Fixes: 2824bd250f0b ("[PATCH] USB: add ldusb driver") Fixes: 9d33efd9a791 ("USB: ldusb bugfix") Cc: stable <stable@vger.kernel.org> # 2.6.13 Signed-off-by: Johan Hovold <johan@kernel.org> Link: https://lore.kernel.org/r/20191022143203.5260-2-johan@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
generated by cgit v1.2.3 (git 2.25.1) at 2025-01-24 13:32:29 +0000