> > + if (!test_and_set_bit_lock(SLOW_WORK_PENDING, &work->flags)) {> > Can you explain the purpose of the SLOW_WORK_PENDING bit a bit more?> I don't understand why you need it, or what exactly you're doing here.

you'll notice that it disables interrupts and takes a spinlock. We'd like toavoid that if we can.

> Seems like if someone enqueues a work item twice in a row, behavior> is unpredicatble? If it's done fast enough, the second submission> will be ignored.

Yes, that's fine. The facility promises to invoke the work function at sometime in the future; it doesn't promise to run it once per enqueuement request.

Another way to look at it is that if you call slow_work_enqueue(), you can becertain that the work function will be run sometime in the future.

I could count the number of enquements and run the work function once perenqueuement, but that isn't really necessary. The work function can be madeto work that out for itself. It can even enqueue itself if it thinks itshould be run again.

> If slow enough, then the first will have started executing already, so> PENDING bit will have cleared, so this will set the DEFERRED bit. But I> suspect I'm completely misunderstanding?

The PENDING bit promises that the work function will be run in the future.

The ENQ_DEFERRED bit is an delayed form of queueing. If a work item iscurrently under execution, we cannot at this point queue it for furtherexecution as we promise that a work function will only be executing in onethread at any one time. If we did immediately stick it on the to-be-executedqueue, someone might come along and try executing it.

The ENQ_DEFERRED bit is handled at the end of execution, after the EXECUTINGbit has been cleared, but before the spinlock is dropped. If the ENQ_DEFERREDbit is set, the PENDING bit must also be set.

I guess I need to stick a comment in slow_work_enqueue() to detail this,though the comments in slow_work_execute() do talk about it.