Re: [PATCH] backing_dev: Fix hung task on sync

Hello,

On Sun, Mar 16, 2014 at 12:13:55PM -0700, dbasehore . wrote:

There's already behavior that is somewhat like that with the current
implementation. If there's an item on a workqueue, it could run at any
time. From the perspective of the driver/etc. that is using the
workqueue, there should be no difference between work being on the
workqueue and the kernel triggering a schedule right after the work is
removed from the workqueue, but before the work function has done
anything.

It is different.  mod_delayed_work() *guarantees* that the target work
item will become pending for execution at least after the specified
time has passed.  What you're suggesting removes any semantically
consistent meaning of the API.

So to reiterate, calling mod_delayed_work on something that is already
in the workqueue has two behaviors. One, the work is dispatched before
mod_delayed_work can remove it from the workqueue. Two,
mod_delayed_work removes it from the workqueue and sets the timer (or
not in the case of 0). The behavior of the proposed change should be
no different than the first behavior.

No, mod_delayed_work() does *one* thing - the work item is queued for
the specified delay no matter the current state of the work item.  It
is *guaranteed* that the work item will go pending after the specified
time.  That is the sole meaning of the API.

This should not introduce new behavior from the perspective of the
code using delayed_work. It is true that there is a larger window of
time between when you call mod_delayed_work and when an already queued
work item will run, but I don't believe that matters.

You're completely misunderstanding the API.  Plesae re-read it and
understand what it does first.

Thanks.

-- 
tejun

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>