Re: workqueue question.

[Ben Greear <greearb@candelatech.com>]

On 06/29/2011 01:43 AM, Tejun Heo wrote:
> Hello,
>
> On Tue, Jun 28, 2011 at 11:56:39AM -0700, Ben Greear wrote:
>> Is it OK to call INIT_WORK(&foo, bar)
>> if we are currently being called by the work-queue
>> using foo?
>
> Yes, but if flush_work*() races with it, flushing can finish before
> execution is complete.

It appears that the code just wants to (re)add itself to the
work queue with a different callback method:

static void rpc_final_put_task(struct rpc_task *task,
		struct workqueue_struct *q)
{
	if (q != NULL) {
		INIT_WORK(&task->u.tk_work, rpc_async_release);
		queue_work(q, &task->u.tk_work);
	} else
		rpc_free_task(task);
}

My debugging leads me to believe that the rpc_async_release
is (very rarely) called on a task object that has already been logically
freed.

Is there a better way to queue this up that might have less chance
of some strange race?

>
>> Also, is it valid to free the memory containing foo
>> in a workqueue callback?
>
> Yeap.

Is there a method that can be called from a workqueue callback
to verify that the item has not been re-added to the work-queue?

I tried doing a cancel, but that caused recursive locking issues.

I'd like to call this right before freeing the object and BUG_ON()
if the object is actually still on on a work-queue.

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com