On Thu, Jun 23, 2016 at 05:32:58PM -0400, Tejun Heo wrote:
Hello,
On Wed, Jun 22, 2016 at 10:54:45PM +0200, Peter Zijlstra wrote:
quoted
quoted
+ * The caller is responsible for blocking all users of this kthread
+ * worker from queuing new works. Also it is responsible for blocking
+ * the already queued works from an infinite re-queuing!
This, I really dislike that. And it makes the kthread_destroy_worker()
from the next patch unnecessarily fragile.
Why not add a kthread_worker::blocked flag somewhere and refuse/WARN
kthread_queue_work() when that is set.
It's the same logic from workqueue counterpart.
So ? Clearly it (the kthread workqueue) can be improved here.
For workqueue, nothing can make it less fragile as the workqueue
struct itself is freed on destruction. If its users fail to stop
issuing work items, it'll lead to use-after-free.
Right, but this kthread thingy does not, so why not add a failsafe?
IIRC, the draining of self-requeueing work items is a specific
requirement from some edge use case which used workqueue to implement
multi-step state machine.
Right, that might be an issue,
Given how rare that is
Could you then not remove/rework these few cases for workqueue as well
and make that 'better' too?
and the extra
complexity of identifying self-requeueing cases, let's forget about
draining and on destruction clear the worker pointer to block further
queueing and then flush whatever is in flight.
You're talking about regular workqueues here?
--
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>