On 12/01/16 19:21, tang.jun...@zte.com.cn wrote:
> Hello Bart,
>> * Even if queue_delayed_work() returns 0 the qdata work passed to
>> alua_rtpg_queue() is still added to the pg->rtpg_list and hence will be
>> executed once the delayed work is executed. So I think that the
>> condition you described (fn() not called) cannot happen.
> I find it by reading code.
> How did you think that it will be
> executed once the delayed work is executed?
> It is not re-queued to the pg->rtpg_work again.
> It is triggered by pgpath->activate_path.work in dm-mod,
> and maybe it would never run anymore.
Are you aware that if queue_delayed_work() returns 0 that that means
that a work item has already been queued (pg->rtpg_work in this case)?
* queue_delayed_work_on - queue work on specific CPU after delay
* @cpu: CPU number to execute work on
* @wq: workqueue to use
* @dwork: work to queue
* @delay: number of jiffies to wait before queueing
* Return: %false if @work was already on a queue, %true otherwise. If
* @delay is zero and @dwork is idle, it will be scheduled for immediate
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html