Searched hist:277136 (Results 1 - 4 of 4) sorted by relevance
| /freebsd-11-stable/sys/dev/usb/ | ||
| H A D | usb_bus.h | diff 277136 Tue Jan 13 14:43:17 MST 2015 hselasky Resolve a special case deadlock: When two or more threads are 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 |
| H A D | usb_device.h | diff 277136 Tue Jan 13 14:43:17 MST 2015 hselasky Resolve a special case deadlock: When two or more threads are 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 |
| H A D | usb_dev.c | diff 277136 Tue Jan 13 14:43:17 MST 2015 hselasky Resolve a special case deadlock: When two or more threads are 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 |
| H A D | usb_device.c | diff 277136 Tue Jan 13 14:43:17 MST 2015 hselasky Resolve a special case deadlock: When two or more threads are 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 |
Completed in 204 milliseconds