Re: [PATCH] workqueue: Document exceptions to work item non-reentrancy guarantee

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 02/17/2014 08:43 PM, Ben Hutchings wrote:
On Sat, 2014-02-15 at 14:38 -0500, Peter Hurley wrote:
Since commit a2c1c57be8d9fd5b716113c8991d3d702eeacf77,
   workqueue: consider work function when searching for busy work items
work items whose work functions are re-assigned are no longer guaranteed
non-reentrancy with the previously assigned work function. For example,

         PREPARE_WORK(&work, funcA)
         schedule_work(&work)
           .
         < funcA starts >
           .
         PREPARE_WORK(&work, funcB)
         schedule_work(&work)

funcA() may run concurrently with funcB().

The work item non-reentrancy guarantee is a crucial design guarantee
which, if violated, may not have obvious consequences. For example,
the entire firewire subsystem expects the as-documented per-work item
non-reentrancy guarantee, which was the behavior prior to the above
commit, not the per-work function + per-work item behavior since.

Document the known exceptions to this guarantee.
[...]

It never would have occurred to me that you could safely change the
function for a work item that is already scheduled or running.
Especially given that PREPARE_WORK() is just a simple assignment (i.e.
no serialisation).

process_one_work() has an established order that safely allows for
resetting the work function and scheduling the work, and further
guaranteeing that the new work function will run.

Further, existing memory barriers ensure that
1. The new work function is visible on all cpus before testing if
   the work is already pending.
2. The new work function is stored as the worker's current function
   before the work is marked as not pending.

If this wasn't possible, then single-threaded workqueues could
not be used for multiple functions without flushing work.

I wonder if the floppy driver is broken too.

Regards,
Peter Hurley


--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Kernel]     [Kernel Development Newbies]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Hiking]     [Linux Kernel]     [Linux SCSI]