From: Peter Zijlstra <peterz@infradead.org> To: Tejun Heo <tj@kernel.org> Cc: Petr Mladek <pmladek@suse.com>, Andrew Morton <akpm@linux-foundation.org>, Oleg Nesterov <oleg@redhat.com>, Ingo Molnar <mingo@redhat.com>, Steven Rostedt <rostedt@goodmis.org>, "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>, Josh Triplett <josh@joshtriplett.org>, Thomas Gleixner <tglx@linutronix.de>, Linus Torvalds <torvalds@linux-foundation.org>, Jiri Kosina <jkosina@suse.cz>, Borislav Petkov <bp@suse.de>, Michal Hocko <mhocko@suse.cz>, linux-mm@kvack.org, Vlastimil Babka <vbabka@suse.cz>, linux-api@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v9 06/12] kthread: Add kthread_drain_worker() Date: Fri, 24 Jun 2016 09:05:15 +0200 [thread overview] Message-ID: <20160624070515.GU30154@twins.programming.kicks-ass.net> (raw) In-Reply-To: <20160623213258.GO3262@mtj.duckdns.org> 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?
WARNING: multiple messages have this Message-ID (diff)
From: Peter Zijlstra <peterz@infradead.org> To: Tejun Heo <tj@kernel.org> Cc: Petr Mladek <pmladek@suse.com>, Andrew Morton <akpm@linux-foundation.org>, Oleg Nesterov <oleg@redhat.com>, Ingo Molnar <mingo@redhat.com>, Steven Rostedt <rostedt@goodmis.org>, "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>, Josh Triplett <josh@joshtriplett.org>, Thomas Gleixner <tglx@linutronix.de>, Linus Torvalds <torvalds@linux-foundation.org>, Jiri Kosina <jkosina@suse.cz>, Borislav Petkov <bp@suse.de>, Michal Hocko <mhocko@suse.cz>, linux-mm@kvack.org, Vlastimil Babka <vbabka@suse.cz>, linux-api@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v9 06/12] kthread: Add kthread_drain_worker() Date: Fri, 24 Jun 2016 09:05:15 +0200 [thread overview] Message-ID: <20160624070515.GU30154@twins.programming.kicks-ass.net> (raw) In-Reply-To: <20160623213258.GO3262@mtj.duckdns.org> 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@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>
next prev parent reply other threads:[~2016-06-24 7:05 UTC|newest] Thread overview: 71+ messages / expand[flat|nested] mbox.gz Atom feed top 2016-06-16 11:17 [PATCH v9 00/12] kthread: Kthread worker API improvements Petr Mladek 2016-06-16 11:17 ` Petr Mladek 2016-06-16 11:17 ` [PATCH v9 01/12] kthread: Rename probe_kthread_data() to kthread_probe_data() Petr Mladek 2016-06-16 11:17 ` Petr Mladek 2016-06-20 19:16 ` Tejun Heo 2016-06-20 19:16 ` Tejun Heo 2016-06-16 11:17 ` [PATCH v9 02/12] kthread: Kthread worker API cleanup Petr Mladek 2016-06-16 11:17 ` Petr Mladek 2016-06-20 19:27 ` Tejun Heo 2016-06-20 19:27 ` Tejun Heo 2016-06-16 11:17 ` [PATCH v9 03/12] kthread/smpboot: Do not park in kthread_create_on_cpu() Petr Mladek 2016-06-16 11:17 ` Petr Mladek 2016-06-16 11:17 ` [PATCH v9 04/12] kthread: Allow to call __kthread_create_on_node() with va_list args Petr Mladek 2016-06-16 11:17 ` Petr Mladek 2016-06-16 11:17 ` Petr Mladek 2016-06-20 19:51 ` Tejun Heo 2016-06-20 19:51 ` Tejun Heo 2016-06-16 11:17 ` [PATCH v9 05/12] kthread: Add kthread_create_worker*() Petr Mladek 2016-06-16 11:17 ` Petr Mladek 2016-06-16 11:17 ` Petr Mladek 2016-06-20 19:55 ` Tejun Heo 2016-06-20 19:55 ` Tejun Heo 2016-06-16 11:17 ` [PATCH v9 06/12] kthread: Add kthread_drain_worker() Petr Mladek 2016-06-16 11:17 ` Petr Mladek 2016-06-20 19:56 ` Tejun Heo 2016-06-20 19:56 ` Tejun Heo 2016-06-22 20:54 ` Peter Zijlstra 2016-06-22 20:54 ` Peter Zijlstra 2016-06-23 21:32 ` Tejun Heo 2016-06-23 21:32 ` Tejun Heo 2016-06-23 21:32 ` Tejun Heo 2016-06-24 7:05 ` Peter Zijlstra [this message] 2016-06-24 7:05 ` Peter Zijlstra 2016-06-24 9:08 ` Petr Mladek 2016-06-24 9:08 ` Petr Mladek 2016-06-24 15:54 ` Tejun Heo 2016-06-24 15:54 ` Tejun Heo 2016-06-27 14:33 ` Petr Mladek 2016-06-27 14:33 ` Petr Mladek 2016-06-27 14:33 ` Petr Mladek 2016-06-28 17:04 ` Tejun Heo 2016-06-28 17:04 ` Tejun Heo 2016-06-29 8:17 ` Petr Mladek 2016-06-29 8:17 ` Petr Mladek 2016-06-29 13:15 ` Tejun Heo 2016-06-29 13:15 ` Tejun Heo 2016-06-29 13:15 ` Tejun Heo 2016-06-16 11:17 ` [PATCH v9 07/12] kthread: Add kthread_destroy_worker() Petr Mladek 2016-06-16 11:17 ` Petr Mladek 2016-06-20 19:57 ` Tejun Heo 2016-06-20 19:57 ` Tejun Heo 2016-06-16 11:17 ` [PATCH v9 08/12] kthread: Detect when a kthread work is used by more workers Petr Mladek 2016-06-16 11:17 ` Petr Mladek 2016-06-20 20:10 ` Tejun Heo 2016-06-20 20:10 ` Tejun Heo 2016-06-16 11:17 ` [PATCH v9 09/12] kthread: Initial support for delayed kthread work Petr Mladek 2016-06-16 11:17 ` Petr Mladek 2016-06-20 20:20 ` Tejun Heo 2016-06-20 20:20 ` Tejun Heo 2016-06-16 11:17 ` [PATCH v9 10/12] kthread: Allow to cancel " Petr Mladek 2016-06-16 11:17 ` Petr Mladek 2016-06-20 20:27 ` Tejun Heo 2016-06-20 20:27 ` Tejun Heo 2016-06-16 11:17 ` [PATCH v9 11/12] kthread: Allow to modify delayed " Petr Mladek 2016-06-16 11:17 ` Petr Mladek 2016-06-20 20:29 ` Tejun Heo 2016-06-20 20:29 ` Tejun Heo 2016-06-16 11:17 ` [PATCH v9 12/12] kthread: Better support freezable kthread workers Petr Mladek 2016-06-16 11:17 ` Petr Mladek 2016-06-20 20:30 ` Tejun Heo 2016-06-20 20:30 ` Tejun Heo
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20160624070515.GU30154@twins.programming.kicks-ass.net \ --to=peterz@infradead.org \ --cc=akpm@linux-foundation.org \ --cc=bp@suse.de \ --cc=jkosina@suse.cz \ --cc=josh@joshtriplett.org \ --cc=linux-api@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=mhocko@suse.cz \ --cc=mingo@redhat.com \ --cc=oleg@redhat.com \ --cc=paulmck@linux.vnet.ibm.com \ --cc=pmladek@suse.com \ --cc=rostedt@goodmis.org \ --cc=tglx@linutronix.de \ --cc=tj@kernel.org \ --cc=torvalds@linux-foundation.org \ --cc=vbabka@suse.cz \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.