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 from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
