Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1316843 > unrolled thread
| Started by | Petr Mladek <pmladek@suse.com> |
|---|---|
| First post | 2016-01-25 16:50 +0100 |
| Last post | 2016-01-25 20:20 +0100 |
| Articles | 2 — 2 participants |
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.
[PATCH v4 10/22] kthread: Allow to modify delayed kthread work Petr Mladek <pmladek@suse.com> - 2016-01-25 16:50 +0100
Re: [PATCH v4 10/22] kthread: Allow to modify delayed kthread work Tejun Heo <tj@kernel.org> - 2016-01-25 20:20 +0100
| From | Petr Mladek <pmladek@suse.com> |
|---|---|
| Date | 2016-01-25 16:50 +0100 |
| Subject | [PATCH v4 10/22] kthread: Allow to modify delayed kthread work |
| Message-ID | <qURyW-64A-17@gated-at.bofh.it> |
There are situations when we need to modify the delay of a delayed kthread
work. For example, when the work depends on an event and the initial delay
means a timeout. Then we want to queue the work immediately when the event
happens.
This patch implements mod_delayed_kthread_work() as inspired workqueues.
It tries to cancel the pending work and queue it again with the
given timeout.
A very special case is when the work is being canceled at the same time.
cancel_*kthread_work_sync() operation blocks queuing until the running
work finishes. Therefore we do nothing and let cancel() win. This should
not normally happen as the caller is supposed to synchronize these
operations a reasonable way.
Signed-off-by: Petr Mladek <pmladek@suse.com>
---
include/linux/kthread.h | 4 ++++
kernel/kthread.c | 50 +++++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 54 insertions(+)
diff --git a/include/linux/kthread.h b/include/linux/kthread.h
index dd2a587a2bd7..f501dfeaa0e3 100644
--- a/include/linux/kthread.h
+++ b/include/linux/kthread.h
@@ -168,6 +168,10 @@ bool queue_delayed_kthread_work(struct kthread_worker *worker,
struct delayed_kthread_work *dwork,
unsigned long delay);
+bool mod_delayed_kthread_work(struct kthread_worker *worker,
+ struct delayed_kthread_work *dwork,
+ unsigned long delay);
+
void flush_kthread_work(struct kthread_work *work);
void flush_kthread_worker(struct kthread_worker *worker);
diff --git a/kernel/kthread.c b/kernel/kthread.c
index 6e2eeca08d5f..ebb91848685f 100644
--- a/kernel/kthread.c
+++ b/kernel/kthread.c
@@ -1013,6 +1013,56 @@ out:
return ret;
}
+/**
+ * mod_delayed_kthread_work - modify delay of or queue a delayed kthread work
+ * @worker: kthread worker to use
+ * @dwork: delayed kthread work to queue
+ * @delay: number of jiffies to wait before queuing
+ *
+ * If @dwork is idle, equivalent to queue_delayed_kthread work(). Otherwise,
+ * modify @dwork's timer so that it expires after @delay. If @delay is zero,
+ * @work is guaranteed to be queued immediately.
+ *
+ * Return: %false if @dwork was idle and queued. Return %true if @dwork was
+ * pending and its timer was modified.
+ *
+ * A special case is when cancel_work_sync() is running in parallel.
+ * It blocks further queuing. We let the cancel() win and return %false.
+ * The caller is supposed to synchronize these operations a reasonable way.
+ *
+ * This function is safe to call from any context including IRQ handler.
+ * See try_to_grab_pending_kthread_work() for details.
+ */
+bool mod_delayed_kthread_work(struct kthread_worker *worker,
+ struct delayed_kthread_work *dwork,
+ unsigned long delay)
+{
+ struct kthread_work *work = &dwork->work;
+ unsigned long flags;
+ int ret = 0;
+
+try_again:
+ spin_lock_irqsave(&worker->lock, flags);
+ WARN_ON_ONCE(work->worker && work->worker != worker);
+
+ if (work->canceling)
+ goto out;
+
+ ret = try_to_cancel_kthread_work(work, &worker->lock, &flags);
+ if (ret == -EAGAIN)
+ goto try_again;
+
+ if (work->canceling)
+ ret = 0;
+ else
+ __queue_delayed_kthread_work(worker, dwork, delay);
+
+out:
+ spin_unlock_irqrestore(&worker->lock, flags);
+ return ret;
+}
+EXPORT_SYMBOL_GPL(mod_delayed_kthread_work);
+
static bool __cancel_kthread_work_sync(struct kthread_work *work)
{
struct kthread_worker *worker;
--
1.8.5.6
[toc] | [next] | [standalone]
| From | Tejun Heo <tj@kernel.org> |
|---|---|
| Date | 2016-01-25 20:20 +0100 |
| Message-ID | <qUUQa-cl-21@gated-at.bofh.it> |
| In reply to | #1316843 |
On Mon, Jan 25, 2016 at 04:44:59PM +0100, Petr Mladek wrote:
> +bool mod_delayed_kthread_work(struct kthread_worker *worker,
> + struct delayed_kthread_work *dwork,
> + unsigned long delay)
> +{
> + struct kthread_work *work = &dwork->work;
> + unsigned long flags;
> + int ret = 0;
> +
> +try_again:
> + spin_lock_irqsave(&worker->lock, flags);
> + WARN_ON_ONCE(work->worker && work->worker != worker);
> +
> + if (work->canceling)
> + goto out;
> +
> + ret = try_to_cancel_kthread_work(work, &worker->lock, &flags);
> + if (ret == -EAGAIN)
> + goto try_again;
> +
> + if (work->canceling)
Does this test need to be repeated? How would ->canceling change
while worker->lock is held?
Thanks.
--
tejun
[toc] | [prev] | [standalone]
Back to top | Article view | linux.kernel
csiph-web