From: Yiwei Zhang <zzyiwei@android.com>
To: Andrew Morton <akpm@linux-foundation.org>,
Felix Kuehling <Felix.Kuehling@amd.com>,
Jens Axboe <axboe@kernel.dk>, Petr Mladek <pmladek@suse.com>,
"J. Bruce Fields" <bfields@redhat.com>,
Peter Zijlstra <peterz@infradead.org>,
Frederic Weisbecker <frederic@kernel.org>,
Marcelo Tosatti <mtosatti@redhat.com>,
Ilias Stamatis <stamatis.iliass@gmail.com>,
Rob Clark <robdclark@chromium.org>,
Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
Liang Chen <cl@rock-chips.com>
Cc: linux-kernel@vger.kernel.org, kernel-team@android.com,
Yiwei Zhang <zzyiwei@android.com>
Subject: [PATCH] kthread: add kthread_mod_pending_delayed_work api
Date: Sun, 14 Feb 2021 00:06:11 +0000 [thread overview]
Message-ID: <20210214000611.2169820-1-zzyiwei@android.com> (raw)
The existing kthread_mod_delayed_work api will queue a new work if
failing to cancel the current work due to no longer being pending.
However, there's a case that the same work can be enqueued from both
an async request and a delayed work, and a racing could happen if the
async request comes right after the timeout delayed work gets scheduled,
because the clean up work may not be safe to run twice.
Signed-off-by: Yiwei Zhang <zzyiwei@android.com>
---
include/linux/kthread.h | 3 +++
kernel/kthread.c | 48 +++++++++++++++++++++++++++++++++++++++++
2 files changed, 51 insertions(+)
diff --git a/include/linux/kthread.h b/include/linux/kthread.h
index 65b81e0c494d..250cdc5ff2a5 100644
--- a/include/linux/kthread.h
+++ b/include/linux/kthread.h
@@ -192,6 +192,9 @@ bool kthread_queue_delayed_work(struct kthread_worker *worker,
bool kthread_mod_delayed_work(struct kthread_worker *worker,
struct kthread_delayed_work *dwork,
unsigned long delay);
+bool kthread_mod_pending_delayed_work(struct kthread_worker *worker,
+ struct kthread_delayed_work *dwork,
+ unsigned long delay);
void kthread_flush_work(struct kthread_work *work);
void kthread_flush_worker(struct kthread_worker *worker);
diff --git a/kernel/kthread.c b/kernel/kthread.c
index a5eceecd4513..13881076afdd 100644
--- a/kernel/kthread.c
+++ b/kernel/kthread.c
@@ -1142,6 +1142,54 @@ bool kthread_mod_delayed_work(struct kthread_worker *worker,
}
EXPORT_SYMBOL_GPL(kthread_mod_delayed_work);
+/**
+ * kthread_mod_pending_delayed_work - modify delay of a pending delayed work
+ * @worker: kthread worker to use
+ * @dwork: kthread delayed work to queue
+ * @delay: number of jiffies to wait before queuing
+ *
+ * If @dwork is still pending modify @dwork's timer so that it expires after
+ * @delay. If @dwork is still pending and @delay is zero, @work is guaranteed to
+ * be queued immediately.
+ *
+ * Return: %true if @dwork was pending and its timer was modified,
+ * %false otherwise.
+ *
+ * A special case is when the work is being canceled in parallel.
+ * It might be caused either by the real kthread_cancel_delayed_work_sync()
+ * or yet another kthread_mod_delayed_work() call. We let the other command
+ * win and return %false here. The caller is supposed to synchronize these
+ * operations a reasonable way.
+ *
+ * This function is safe to call from any context including IRQ handler.
+ * See __kthread_cancel_work() and kthread_delayed_work_timer_fn()
+ * for details.
+ */
+bool kthread_mod_pending_delayed_work(struct kthread_worker *worker,
+ struct kthread_delayed_work *dwork,
+ unsigned long delay)
+{
+ struct kthread_work *work = &dwork->work;
+ unsigned long flags;
+ int ret = true;
+
+ raw_spin_lock_irqsave(&worker->lock, flags);
+ if (!work->worker || work->canceling ||
+ !__kthread_cancel_work(work, true, &flags)) {
+ ret = false;
+ goto out;
+ }
+
+ /* Work must not be used with >1 worker, see kthread_queue_work() */
+ WARN_ON_ONCE(work->worker != worker);
+
+ __kthread_queue_delayed_work(worker, dwork, delay);
+out:
+ raw_spin_unlock_irqrestore(&worker->lock, flags);
+ return ret;
+}
+EXPORT_SYMBOL_GPL(kthread_mod_pending_delayed_work);
+
static bool __kthread_cancel_work_sync(struct kthread_work *work, bool is_dwork)
{
struct kthread_worker *worker = work->worker;
--
2.30.0.478.g8a0d178c01-goog
next reply other threads:[~2021-02-14 0:07 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-14 0:06 Yiwei Zhang [this message]
2021-02-15 13:28 ` Petr Mladek
2021-02-16 9:11 ` Christoph Hellwig
2021-02-16 18:58 ` Yiwei Zhang
2021-02-17 11:14 ` Petr Mladek
2021-02-19 6:29 ` Yiwei Zhang
2021-02-19 10:27 ` Petr Mladek
2021-02-19 10:30 ` Christoph Hellwig
2021-02-19 10:56 ` Petr Mladek
2021-02-23 0:39 ` Yiwei Zhang
2021-02-23 0:58 ` Yiwei Zhang
2021-02-23 15:52 ` Petr Mladek
2021-02-23 22:29 ` Yiwei Zhang
2021-02-24 9:34 ` Petr Mladek
2021-02-25 22:17 ` Yiwei Zhang
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=20210214000611.2169820-1-zzyiwei@android.com \
--to=zzyiwei@android.com \
--cc=Felix.Kuehling@amd.com \
--cc=akpm@linux-foundation.org \
--cc=axboe@kernel.dk \
--cc=bfields@redhat.com \
--cc=cl@rock-chips.com \
--cc=frederic@kernel.org \
--cc=kernel-team@android.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mathieu.desnoyers@efficios.com \
--cc=mtosatti@redhat.com \
--cc=peterz@infradead.org \
--cc=pmladek@suse.com \
--cc=robdclark@chromium.org \
--cc=stamatis.iliass@gmail.com \
/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: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®