mirror of
https://github.com/AuxXxilium/linux_dsm_epyc7002.git
synced 2024-12-17 01:16:42 +07:00
b2685bdacd
Running io_watchdog_func() while ohci_urb_enqueue() is running can cause a race condition where ohci->prev_frame_no is corrupted and the watchdog can mis-detect following error: ohci-platform 664a0800.usb: frame counter not updating; disabled ohci-platform 664a0800.usb: HC died; cleaning up Specifically, following scenario causes a race condition: 1. ohci_urb_enqueue() calls spin_lock_irqsave(&ohci->lock, flags) and enters the critical section 2. ohci_urb_enqueue() calls timer_pending(&ohci->io_watchdog) and it returns false 3. ohci_urb_enqueue() sets ohci->prev_frame_no to a frame number read by ohci_frame_no(ohci) 4. ohci_urb_enqueue() schedules io_watchdog_func() with mod_timer() 5. ohci_urb_enqueue() calls spin_unlock_irqrestore(&ohci->lock, flags) and exits the critical section 6. Later, ohci_urb_enqueue() is called 7. ohci_urb_enqueue() calls spin_lock_irqsave(&ohci->lock, flags) and enters the critical section 8. The timer scheduled on step 4 expires and io_watchdog_func() runs 9. io_watchdog_func() calls spin_lock_irqsave(&ohci->lock, flags) and waits on it because ohci_urb_enqueue() is already in the critical section on step 7 10. ohci_urb_enqueue() calls timer_pending(&ohci->io_watchdog) and it returns false 11. ohci_urb_enqueue() sets ohci->prev_frame_no to new frame number read by ohci_frame_no(ohci) because the frame number proceeded between step 3 and 6 12. ohci_urb_enqueue() schedules io_watchdog_func() with mod_timer() 13. ohci_urb_enqueue() calls spin_unlock_irqrestore(&ohci->lock, flags) and exits the critical section, then wake up io_watchdog_func() which is waiting on step 9 14. io_watchdog_func() enters the critical section 15. io_watchdog_func() calls ohci_frame_no(ohci) and set frame_no variable to the frame number 16. io_watchdog_func() compares frame_no and ohci->prev_frame_no On step 16, because this calling of io_watchdog_func() is scheduled on step 4, the frame number set in ohci->prev_frame_no is expected to the number set on step 3. However, ohci->prev_frame_no is overwritten on step 11. Because step 16 is executed soon after step 11, the frame number might not proceed, so ohci->prev_frame_no must equals to frame_no. To address above scenario, this patch introduces a special sentinel value IO_WATCHDOG_OFF and set this value to ohci->prev_frame_no when the watchdog is not pending or running. When ohci_urb_enqueue() schedules the watchdog (step 4 and 12 above), it compares ohci->prev_frame_no to IO_WATCHDOG_OFF so that ohci->prev_frame_no is not overwritten while io_watchdog_func() is running. Signed-off-by: Shigeru Yoshida <Shigeru.Yoshida@windriver.com> Signed-off-by: Haiqing Bai <Haiqing.Bai@windriver.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> |
||
---|---|---|
.. | ||
atm | ||
c67x00 | ||
chipidea | ||
class | ||
common | ||
core | ||
dwc2 | ||
dwc3 | ||
early | ||
gadget | ||
host | ||
image | ||
isp1760 | ||
misc | ||
mon | ||
mtu3 | ||
musb | ||
phy | ||
renesas_usbhs | ||
serial | ||
storage | ||
typec | ||
usbip | ||
wusbcore | ||
Kconfig | ||
Makefile | ||
README | ||
usb-skeleton.c |
To understand all the Linux-USB framework, you'll use these resources: * This source code. This is necessarily an evolving work, and includes kerneldoc that should help you get a current overview. ("make pdfdocs", and then look at "usb.pdf" for host side and "gadget.pdf" for peripheral side.) Also, Documentation/usb has more information. * The USB 2.0 specification (from www.usb.org), with supplements such as those for USB OTG and the various device classes. The USB specification has a good overview chapter, and USB peripherals conform to the widely known "Chapter 9". * Chip specifications for USB controllers. Examples include host controllers (on PCs, servers, and more); peripheral controllers (in devices with Linux firmware, like printers or cell phones); and hard-wired peripherals like Ethernet adapters. * Specifications for other protocols implemented by USB peripheral functions. Some are vendor-specific; others are vendor-neutral but just standardized outside of the www.usb.org team. Here is a list of what each subdirectory here is, and what is contained in them. core/ - This is for the core USB host code, including the usbfs files and the hub class driver ("hub_wq"). host/ - This is for USB host controller drivers. This includes UHCI, OHCI, EHCI, and others that might be used with more specialized "embedded" systems. gadget/ - This is for USB peripheral controller drivers and the various gadget drivers which talk to them. Individual USB driver directories. A new driver should be added to the first subdirectory in the list below that it fits into. image/ - This is for still image drivers, like scanners or digital cameras. ../input/ - This is for any driver that uses the input subsystem, like keyboard, mice, touchscreens, tablets, etc. ../media/ - This is for multimedia drivers, like video cameras, radios, and any other drivers that talk to the v4l subsystem. ../net/ - This is for network drivers. serial/ - This is for USB to serial drivers. storage/ - This is for USB mass-storage drivers. class/ - This is for all USB device drivers that do not fit into any of the above categories, and work for a range of USB Class specified devices. misc/ - This is for all USB device drivers that do not fit into any of the above categories.