On 12/01/16 19:21, tang.junhui@xxxxxxxxxx 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. */ Bart. -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
