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: > > > + * 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@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>