Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1339585 > unrolled thread

[PATCH v5 05/20] kthread: Add destroy_kthread_worker()

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  [PATCH v5 05/20] kthread: Add destroy_kthread_worker() Petr Mladek <pmladek@suse.com> - 2016-02-22 16:00 +0100
    Re: [PATCH v5 05/20] kthread: Add destroy_kthread_worker() Peter Zijlstra <peterz@infradead.org> - 2016-02-25 13:40 +0100
      Re: [PATCH v5 05/20] kthread: Add destroy_kthread_worker() Petr Mladek <pmladek@suse.com> - 2016-02-26 16:20 +0100

#1339585 — [PATCH v5 05/20] kthread: Add destroy_kthread_worker()

The current kthread worker users call flush() and stop() explicitly.
This function drains the worker, stops it, and frees the kthread_worker
struct in one call.

It is supposed to be used together with create_kthread_worker*() that
allocates struct kthread_worker.

Also note that drain() correctly handles self-queuing works in compare
with flush().

Signed-off-by: Petr Mladek <pmladek@suse.com>
---
 include/linux/kthread.h |  2 ++
 kernel/kthread.c        | 21 +++++++++++++++++++++
 2 files changed, 23 insertions(+)

diff --git a/include/linux/kthread.h b/include/linux/kthread.h
index 943900c7ce35..c4a95a3ba500 100644
--- a/include/linux/kthread.h
+++ b/include/linux/kthread.h
@@ -136,4 +136,6 @@ bool queue_kthread_work(struct kthread_worker *worker,
 void flush_kthread_work(struct kthread_work *work);
 void flush_kthread_worker(struct kthread_worker *worker);
 
+void destroy_kthread_worker(struct kthread_worker *worker);
+
 #endif /* _LINUX_KTHREAD_H */
diff --git a/kernel/kthread.c b/kernel/kthread.c
index ab72ca5c3003..f5fa777e6802 100644
--- a/kernel/kthread.c
+++ b/kernel/kthread.c
@@ -834,3 +834,24 @@ void drain_kthread_worker(struct kthread_worker *worker)
 	spin_unlock_irq(&worker->lock);
 }
 EXPORT_SYMBOL(drain_kthread_worker);
+
+/**
+ * destroy_kthread_worker - destroy a kthread worker
+ * @worker: worker to be destroyed
+ *
+ * Drain and destroy @worker.  It has the same conditions
+ * for use as drain_kthread_worker(), see above.
+ */
+void destroy_kthread_worker(struct kthread_worker *worker)
+{
+	struct task_struct *task;
+
+	task = worker->task;
+	if (WARN_ON(!task))
+		return;
+
+	drain_kthread_worker(worker);
+	kthread_stop(task);
+	kfree(worker);
+}
+EXPORT_SYMBOL(destroy_kthread_worker);
-- 
1.8.5.6

[toc] | [next] | [standalone]

#1343146

On Mon, Feb 22, 2016 at 03:56:55PM +0100, Petr Mladek wrote:
> Also note that drain() correctly handles self-queuing works in compare
> with flush().

Nothing seems to prevent adding more work after drain() observes
list_empty().

[toc] | [prev] | [next] | [standalone]

#1344332

On Thu 2016-02-25 13:36:41, Peter Zijlstra wrote:
> On Mon, Feb 22, 2016 at 03:56:55PM +0100, Petr Mladek wrote:
> > Also note that drain() correctly handles self-queuing works in compare
> > with flush().
> 
> Nothing seems to prevent adding more work after drain() observes
> list_empty().

You might want to drain() more times during the kthread worker life
time to make sure that the work is done.

The user is responsible for stopping any queuing when this function
is called. The user usually needs to handle this anyway because
producing a work that could not be queued would cause problems.

To be honest, I wanted to keep the main principles of the API
compatible with workqueues. It should reduce some potential confusion.
Also it will make it easier to convert between the two APIs.
IMHO, there are work loads when you are not sure if you will
need a dedicated kthread when designing a new functionality.

Best Regards,
Petr

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web