linux-stable.git/drivers/usb/core/message.c, branch linux-5.17.y Linux kernel stable tree USB: core: Avoid WARNings for 0-length descriptor requests 2021-06-09T09:11:39+00:00 Alan Stern stern@rowland.harvard.edu 2021-06-07T15:23:07+00:00 60dfe484cef45293e631b3a6e8995f1689818172 The USB core has utility routines to retrieve various types of descriptors. These routines will now provoke a WARN if they are asked to retrieve 0 bytes (USB "receive" requests must not have zero length), so avert this by checking the size argument at the start. CC: Johan Hovold <johan@kernel.org> Reported-and-tested-by: syzbot+7dbcd9ff34dc4ed45240@syzkaller.appspotmail.com Reviewed-by: Johan Hovold <johan@kernel.org> Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/20210607152307.GD1768031@rowland.harvard.edu Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
The USB core has utility routines to retrieve various types of
descriptors.  These routines will now provoke a WARN if they are asked
to retrieve 0 bytes (USB "receive" requests must not have zero
length), so avert this by checking the size argument at the start.

CC: Johan Hovold <johan@kernel.org>
Reported-and-tested-by: syzbot+7dbcd9ff34dc4ed45240@syzkaller.appspotmail.com
Reviewed-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Link: https://lore.kernel.org/r/20210607152307.GD1768031@rowland.harvard.edu
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
USB: core: drop pipe-type check from new control-message helpers 2020-12-07T14:23:24+00:00 Johan Hovold johan@kernel.org 2020-12-04T08:51:08+00:00 7fe53dcbbfbd91ad953022281adcc6cbc9dbc052 The new control-message helpers include a pipe-type check which is almost completely redundant. Control messages are generally sent to the default pipe which always exists and is of the correct type since its endpoint representation is created by USB core as part of enumeration for all devices. There is currently only one instance of a driver in the tree which use a control endpoint other than endpoint 0 (and it does not use the new helpers). Drivers should be testing for the existence of their resources at probe rather than at runtime, but to catch drivers failing to do so USB core already does a sanity check on URB submission and triggers a WARN(). Having the same sanity check done in the helper only suppresses the warning without allowing us to find and fix the drivers. Signed-off-by: Johan Hovold <johan@kernel.org> Link: https://lore.kernel.org/r/20201204085110.20055-2-johan@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
The new control-message helpers include a pipe-type check which is
almost completely redundant.

Control messages are generally sent to the default pipe which always
exists and is of the correct type since its endpoint representation is
created by USB core as part of enumeration for all devices.

There is currently only one instance of a driver in the tree which use
a control endpoint other than endpoint 0 (and it does not use the new
helpers).

Drivers should be testing for the existence of their resources at probe
rather than at runtime, but to catch drivers failing to do so USB core
already does a sanity check on URB submission and triggers a WARN().
Having the same sanity check done in the helper only suppresses the
warning without allowing us to find and fix the drivers.

Signed-off-by: Johan Hovold <johan@kernel.org>
Link: https://lore.kernel.org/r/20201204085110.20055-2-johan@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
USB: core: return -EREMOTEIO on short usb_control_msg_recv() 2020-12-04T15:48:46+00:00 Johan Hovold johan@kernel.org 2020-12-04T08:51:10+00:00 9dc9c8543aa0b9ef8852330b27cd2eef337bea18 Return -EREMOTEIO instead of -EINVAL on short control transfers when using the new usb_control_msg_recv() helper. EINVAL is used to report invalid arguments (e.g. to the helper) and should not be used for unrelated errors. Many driver currently return -EIO on short control transfers but since host-controller drivers already use -EREMOTEIO for short transfers whenever the URB_SHORT_NOT_OK flag is set, let's use that here as well. This also allows usb_control_msg_recv() to eventually use URB_SHORT_NOT_OK without changing the return value again. Signed-off-by: Johan Hovold <johan@kernel.org> Link: https://lore.kernel.org/r/20201204085110.20055-4-johan@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
Return -EREMOTEIO instead of -EINVAL on short control transfers when
using the new usb_control_msg_recv() helper.

EINVAL is used to report invalid arguments (e.g. to the helper) and
should not be used for unrelated errors.

Many driver currently return -EIO on short control transfers but since
host-controller drivers already use -EREMOTEIO for short transfers
whenever the URB_SHORT_NOT_OK flag is set, let's use that here as well.

This also allows usb_control_msg_recv() to eventually use
URB_SHORT_NOT_OK without changing the return value again.

Signed-off-by: Johan Hovold <johan@kernel.org>
Link: https://lore.kernel.org/r/20201204085110.20055-4-johan@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
USB: core: drop short-transfer check from usb_control_msg_send() 2020-12-04T15:48:42+00:00 Johan Hovold johan@kernel.org 2020-12-04T08:51:09+00:00 baf7df456b3848e4b6f8648e754e3a0f77fe700e A failure to send a complete control message is always an error so there's no need to check for short transfers in usb_control_msg_send(). Signed-off-by: Johan Hovold <johan@kernel.org> Link: https://lore.kernel.org/r/20201204085110.20055-3-johan@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
A failure to send a complete control message is always an error so
there's no need to check for short transfers in usb_control_msg_send().

Signed-off-by: Johan Hovold <johan@kernel.org>
Link: https://lore.kernel.org/r/20201204085110.20055-3-johan@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
usb: core: Replace in_interrupt() in comments 2020-10-28T11:32:59+00:00 Ahmed S. Darwish a.darwish@linutronix.de 2020-10-19T10:06:41+00:00 41631d3616c36305fef7c0e2e6412538a915dc97 The usage of in_interrupt() in drivers is phased out for various reasons. Various comments use !in_interrupt() to describe calling context for functions which might sleep. That's wrong because the calling context has to be preemptible task context, which is not what !in_interrupt() describes. Replace !in_interrupt() with more accurate plain text descriptions. The comment for usb_hcd_poll_rh_status() is misleading as this function is called from all kinds of contexts including preemptible task context. Remove it as there is obviously no restriction. Signed-off-by: Ahmed S. Darwish <a.darwish@linutronix.de> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Alan Stern <stern@rowland.harvard.edu> Cc: linux-usb@vger.kernel.org Link: https://lore.kernel.org/r/20201019101110.851821025@linutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
The usage of in_interrupt() in drivers is phased out for various reasons.

Various comments use !in_interrupt() to describe calling context for
functions which might sleep. That's wrong because the calling context has
to be preemptible task context, which is not what !in_interrupt()
describes.

Replace !in_interrupt() with more accurate plain text descriptions.

The comment for usb_hcd_poll_rh_status() is misleading as this function is
called from all kinds of contexts including preemptible task
context. Remove it as there is obviously no restriction.

Signed-off-by: Ahmed S. Darwish <a.darwish@linutronix.de>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Cc: linux-usb@vger.kernel.org
Link: https://lore.kernel.org/r/20201019101110.851821025@linutronix.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Merge tag 'dma-mapping-5.10' of git://git.infradead.org/users/hch/dma-mapping 2020-10-15T21:43:29+00:00 Linus Torvalds torvalds@linux-foundation.org 2020-10-15T21:43:29+00:00 5a32c3413d3340f90c82c84b375ad4b335a59f28 Pull dma-mapping updates from Christoph Hellwig: - rework the non-coherent DMA allocator - move private definitions out of <linux/dma-mapping.h> - lower CMA_ALIGNMENT (Paul Cercueil) - remove the omap1 dma address translation in favor of the common code - make dma-direct aware of multiple dma offset ranges (Jim Quinlan) - support per-node DMA CMA areas (Barry Song) - increase the default seg boundary limit (Nicolin Chen) - misc fixes (Robin Murphy, Thomas Tai, Xu Wang) - various cleanups * tag 'dma-mapping-5.10' of git://git.infradead.org/users/hch/dma-mapping: (63 commits) ARM/ixp4xx: add a missing include of dma-map-ops.h dma-direct: simplify the DMA_ATTR_NO_KERNEL_MAPPING handling dma-direct: factor out a dma_direct_alloc_from_pool helper dma-direct check for highmem pages in dma_direct_alloc_pages dma-mapping: merge <linux/dma-noncoherent.h> into <linux/dma-map-ops.h> dma-mapping: move large parts of <linux/dma-direct.h> to kernel/dma dma-mapping: move dma-debug.h to kernel/dma/ dma-mapping: remove <asm/dma-contiguous.h> dma-mapping: merge <linux/dma-contiguous.h> into <linux/dma-map-ops.h> dma-contiguous: remove dma_contiguous_set_default dma-contiguous: remove dev_set_cma_area dma-contiguous: remove dma_declare_contiguous dma-mapping: split <linux/dma-mapping.h> cma: decrease CMA_ALIGNMENT lower limit to 2 firewire-ohci: use dma_alloc_pages dma-iommu: implement ->alloc_noncoherent dma-mapping: add new {alloc,free}_noncoherent dma_map_ops methods dma-mapping: add a new dma_alloc_pages API dma-mapping: remove dma_cache_sync 53c700: convert to dma_alloc_noncoherent ... 
Pull dma-mapping updates from Christoph Hellwig:

 - rework the non-coherent DMA allocator

 - move private definitions out of <linux/dma-mapping.h>

 - lower CMA_ALIGNMENT (Paul Cercueil)

 - remove the omap1 dma address translation in favor of the common code

 - make dma-direct aware of multiple dma offset ranges (Jim Quinlan)

 - support per-node DMA CMA areas (Barry Song)

 - increase the default seg boundary limit (Nicolin Chen)

 - misc fixes (Robin Murphy, Thomas Tai, Xu Wang)

 - various cleanups

* tag 'dma-mapping-5.10' of git://git.infradead.org/users/hch/dma-mapping: (63 commits)
  ARM/ixp4xx: add a missing include of dma-map-ops.h
  dma-direct: simplify the DMA_ATTR_NO_KERNEL_MAPPING handling
  dma-direct: factor out a dma_direct_alloc_from_pool helper
  dma-direct check for highmem pages in dma_direct_alloc_pages
  dma-mapping: merge <linux/dma-noncoherent.h> into <linux/dma-map-ops.h>
  dma-mapping: move large parts of <linux/dma-direct.h> to kernel/dma
  dma-mapping: move dma-debug.h to kernel/dma/
  dma-mapping: remove <asm/dma-contiguous.h>
  dma-mapping: merge <linux/dma-contiguous.h> into <linux/dma-map-ops.h>
  dma-contiguous: remove dma_contiguous_set_default
  dma-contiguous: remove dev_set_cma_area
  dma-contiguous: remove dma_declare_contiguous
  dma-mapping: split <linux/dma-mapping.h>
  cma: decrease CMA_ALIGNMENT lower limit to 2
  firewire-ohci: use dma_alloc_pages
  dma-iommu: implement ->alloc_noncoherent
  dma-mapping: add new {alloc,free}_noncoherent dma_map_ops methods
  dma-mapping: add a new dma_alloc_pages API
  dma-mapping: remove dma_cache_sync
  53c700: convert to dma_alloc_noncoherent
  ...
USB: correct API of usb_control_msg_send/recv 2020-09-25T14:33:58+00:00 Oliver Neukum oneukum@suse.com 2020-09-23T13:43:42+00:00 ddd1198e3e0935066d6e309180d49f64ef4fa702 They need to specify how memory is to be allocated, as control messages need to work in contexts that require GFP_NOIO. Signed-off-by: Oliver Neukum <oneukum@suse.com> Link: https://lore.kernel.org/r/20200923134348.23862-9-oneukum@suse.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
They need to specify how memory is to be allocated,
as control messages need to work in contexts that require GFP_NOIO.

Signed-off-by: Oliver Neukum <oneukum@suse.com>
Link: https://lore.kernel.org/r/20200923134348.23862-9-oneukum@suse.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Merge branch 'master' of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux into dma-mapping-for-next 2020-09-25T04:19:19+00:00 Christoph Hellwig hch@lst.de 2020-09-25T04:19:19+00:00 8c1c6c7588b2faf9dd45fb3cfb7497fd09bbfe7c Pull in the latest 5.9 tree for the commit to revert the V4L2_FLAG_MEMORY_NON_CONSISTENT uapi addition. 
Pull in the latest 5.9 tree for the commit to revert the
V4L2_FLAG_MEMORY_NON_CONSISTENT uapi addition.
usb: don't inherity DMA properties for USB devices 2020-09-17T16:43:25+00:00 Christoph Hellwig hch@lst.de 2020-09-10T16:03:49+00:00 6eb0233ec2d0df288fe8515d5b0b2b15562e05bb As the comment in usb_alloc_dev correctly states, drivers can't use the DMA API on usb device, and at least calling dma_set_mask on them is highly dangerous. Unlike what the comment states upper level drivers also can't really use the presence of a dma mask to check for DMA support, as the dma_mask is set by default for most busses. Setting the dma_mask comes from "[PATCH] usbcore dma updates (and doc)" in BitKeeper times, as it seems like it was primarily for setting the NETIF_F_HIGHDMA flag in USB drivers, something that has long been fixed up since. Setting the dma_pfn_offset comes from commit b44bbc46a8bb ("usb: core: setup dma_pfn_offset for USB devices and, interfaces"), which worked around the fact that the scsi_calculate_bounce_limits functions wasn't going through the proper driver interface to query DMA information, but that function was removed in commit 21e07dba9fb1 ("scsi: reduce use of block bounce buffers") years ago. Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
As the comment in usb_alloc_dev correctly states, drivers can't use
the DMA API on usb device, and at least calling dma_set_mask on them
is highly dangerous.  Unlike what the comment states upper level drivers
also can't really use the presence of a dma mask to check for DMA
support, as the dma_mask is set by default for most busses.

Setting the dma_mask comes from "[PATCH] usbcore dma updates (and doc)"
in BitKeeper times, as it seems like it was primarily for setting the
NETIF_F_HIGHDMA flag in USB drivers, something that has long been
fixed up since.

Setting the dma_pfn_offset comes from commit b44bbc46a8bb
("usb: core: setup dma_pfn_offset for USB devices and, interfaces"),
which worked around the fact that the scsi_calculate_bounce_limits
functions wasn't going through the proper driver interface to query
DMA information, but that function was removed in commit 21e07dba9fb1
("scsi: reduce use of block bounce buffers") years ago.

Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
USB: core: message.c: use usb_control_msg_send() in a few places 2020-09-16T09:02:35+00:00 Greg Kroah-Hartman gregkh@linuxfoundation.org 2020-09-14T15:37:48+00:00 297e84c04d76b9fdbac463e6378f5db7e9283ecd There are a few calls to usb_control_msg() that can be converted to use usb_control_msg_send() instead, so do that in order to make the error checking a bit simpler. Cc: Alan Stern <stern@rowland.harvard.edu> Cc: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20200914153756.3412156-4-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
There are a few calls to usb_control_msg() that can be converted to use
usb_control_msg_send() instead, so do that in order to make the error
checking a bit simpler.

Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20200914153756.3412156-4-gregkh@linuxfoundation.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>