Remove /^/[*/]\s*\$FreeBSD\$.*\n/
The SPDX folks have obsoleted the BSD-2-Clause-FreeBSD identifier. Catch up to that fact and revert to their recommended match of BSD-2-Clause. Discussed with: pfg MFC After: 3 days Sponsored by: Netflix
Submitted by: Horse Ma <Shichun.Ma@dell.com> MFC after: 1 week Sponsored by: Mellanox Technologies
Do not count these as errors. MFC after: 1 week Sponsored by: Mellanox Technologies
Bump the FreeBSD version due to structure change to force recompilation of external USB modules. MFC after: 1 week Sponsored by: Mellanox Technologies
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.
by reviving the SX control request lock and refining which lock protects the common scratch area in "struct usb_device". The SX control request lock was removed by r246759 because it caused a lock order reversal with the USB enumeration lock inside usbd_transfer_setup() as a function of r246616. It was thought that reducing the number of locks would resolve the LOR, but because some USB device drivers use usbd_do_request_flags() inside callback functions, like in taskqueues, a deadlock may occur when these are drained from device_detach(). By restoring the SX control request lock usbd_do_request_flags() is allowed to complete its execution when a USB device driver is detaching. By using the SX control request lock to protect the scratch area, the LOR introduced by r246616 is also resolved. Bump the FreeBSD version while at it to force recompilation of all USB kernel modules. Found by: avos@ MFC after: 1 week
userspace, so that USB applications can be killed if an enumeration thread should be stuck for various reasons. MFC after: 1 week
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
on USB HUBs by moving the code into the USB explore threads. The deadlock happens because child devices of the USB HUB don't have the expected reference count when called from outside the explore thread. Only the HUB device itself, which the IOCTL interface locks, gets the correct reference count. MFC after: 3 days