Ryan Stone b58cf1cb35 Fix race condition in linuxkpi workqueue ... Consider the following scenario: 1. A delayed_work struct in the WORK_ST_TIMER state. 2. Thread A calls mod_delayed_work() 3. Thread B (a callout thread) simultaneously calls linux_delayed_work_timer_fn() The following sequence of events is possible: A: Call linux_cancel_delayed_work() A: Change state from TIMER TO CANCEL B: Change state from CANCEL to TASK B: taskqueue_enqueue() the task A: taskqueue_cancel() the task A: Call linux_queue_delayed_work_on(). This is a no-op because the state is WORK_ST_TASK. As a result, the delayed_work struct will never be invoked. This is causing address resolution in ib_addr.c to stop permanently, as it never tries to reschedule a task that it thinks is already scheduled. Fix this by introducing locking into the cancel path (which corresponds with the lock held while the callout runs). This will prevent the callout from changing the state of the task until the cancel is complete, preventing the race. Differential Revision: https://reviews.freebsd.org/D28420 Reviewed by: hselasky MFC after: 2 months		2021-02-04 13:54:53 -05:00
..
include	LinuxKPI: implement devres() framework parts and two examples	2021-01-28 16:32:43 +00:00
src	Fix race condition in linuxkpi workqueue	2021-02-04 13:54:53 -05:00