src/sys/dev/usb/usb_dev.c, branch release/12.3.0

usb(4): Fix for use after free in combination with EVDEV_SUPPORT.

2021-11-03T17:39:23Z

When EVDEV_SUPPORT was introduced, the USB transfers may be running after the main FIFO is closed. In connection to this a race may appear which can lead to use-after-free scenarios. Fix this for all FIFO consumers by initializing and resetting the FIFO queues under the lock used by the client. Then the client driver will see an empty queue in all cases a race may appear. Approved by: re@ (gjb) Found by: pho@ Sponsored by: NVIDIA Networking (cherry picked from commit aad0c65d6b37364d8ba92ecb8c85e004398a5194) (cherry picked from commit bb9bee1ffbb27f903bfd2c11d681d331bea727ea)

MFC r363420:

2020-07-29T14:30:42Z

usb(4): Stop checking for failures from malloc(M_WAITOK).

Do pass removing some write-only variables from the kernel.

2017-12-25T04:48:39Z

This reduces noise when kernel is compiled by newer GCC versions, such as one used by external toolchain ports. Reviewed by: kib, andrew(sys/arm and sys/arm64), emaste(partial), erj(partial) Reviewed by: jhb (sys/dev/pci/* sys/kern/vfs_aio.c and sys/kern/kern_synch.c) Differential Revision: https://reviews.freebsd.org/D10385

sys/dev: further adoption of SPDX licensing ID tags.

2017-11-27T14:52:40Z

Mainly focus on files that use BSD 2-Clause license, however the tool I was using misidentified many licenses so this was mostly a manual - error prone - task. The Software Package Data Exchange (SPDX) group provides a specification to make it easier for automated tools to detect and summarize well known opensource licenses. We are gradually adopting the specification, noting that the tags are considered only advisory and do not, in any way, superceed or replace the license texts.

Improve USB polling mode by not locking any mutexes, asserting any

2016-09-14T12:07:34Z

mutexes or using any callouts when active. Trying to lock a mutex when KDB is active or the scheduler is stopped can result in infinite wait loops. The same goes for calling callout related functions which in turn lock mutexes. If the USB controller at which a USB keyboard is connected is idle when KDB is entered, polling the USB keyboard via USB will always succeed. Else polling may fail depending on which state the USB subsystem and USB interrupt handler is in. This is unavoidable unless KDB can wait for USB interrupt threads to complete before stalling the CPU(s). Tested by: Bruce Evans MFC after: 4 weeks

Check for signals when locking the USB enumeration thread from

2016-05-25T07:48:36Z

userspace, so that USB applications can be killed if an enumeration thread should be stuck for various reasons. MFC after: 1 week

dev/usb: minor spelling fixes in comments.

2016-05-02T17:44:03Z

No functional change. Reviewed by: hselasky

Don't wait forever for USB data to be flushed.

2015-06-05T06:06:07Z

MFC after: 1 week

Resolve a special case deadlock: When two or more threads are

2015-01-13T16:37:43Z

simultaneously detaching kernel drivers on the same USB device we can get stuck in the "usb_wait_pending_ref_locked()" function because the conditions needed for allowing detach are not met. The "destroy_dev()" function waits for all system calls involving the given character device to return. Character device system calls may lock the USB enumeration lock, which is also held when "destroy_dev()" is called. This can sometimes lead to a deadlock not noticed by WITNESS. The current solution is to ensure the calling thread is the only one holding the USB enumeration lock and prevent other threads from getting refs while a USB device detach is ongoing. This turned out not to be sufficient. To solve this deadlock we could use "destroy_dev_sched()" to schedule the device destruction in the background, but then we don't know when it is safe to free() the private data of the character device. Instead a callback function is executed by the USB explore process to kill off any leftover USB character devices synchronously after the USB device explore code is finished and the USB enumeration lock is no longer locked. This makes porting easier and also ensures us that character devices must eventually go away after a USB device detach. While at it ensure that "flag_iserror" is only written when "priv_mtx" is locked, which is protecting it. MFC after: 5 days

When we fail to get a USB reference we should just return, because

2014-10-03T16:09:46Z

there are no more references held. MFC after: 3 days