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.

Hello Tang,

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)? 
 From kernel/workqueue.c:

  * 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
  * execution.


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

Reply via email to