public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Lyude Paul <lyude@redhat.com>
To: dri-devel@lists.freedesktop.org
Cc: Daniel Vetter <daniel@ffwll.ch>, Tejun Heo <tj@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Petr Mladek <pmladek@suse.com>,
	Suren Baghdasaryan <surenb@google.com>,
	"Steven Rostedt (VMware)" <rostedt@goodmis.org>,
	Ben Dooks <ben.dooks@codethink.co.uk>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Liang Chen <cl@rock-chips.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	linux-kernel@vger.kernel.org
Subject: [RFC v3 02/11] kthread: Introduce __kthread_queue_work()
Date: Fri, 17 Apr 2020 15:40:49 -0400	[thread overview]
Message-ID: <20200417194145.36350-3-lyude@redhat.com> (raw)
In-Reply-To: <20200417194145.36350-1-lyude@redhat.com>

While kthread_queue_work() is fine for basic kthread_worker usecases,
it's a little limiting if you want to create your own delayed work
implementations that delay off things other than a clock. Looking at
kthread_delayed_works for instance, all of the code shares the lock in
kthread_work so that that both the timer_list and actual kthread_worker
can be inspected and modified together atomically.

Currently, we want to be able to implement a type of delayed
kthread_work in DRM that delays until a specific vblank sequence has
passed, which we refer to as a drm_vblank_work, as opposed to using a
simple time-based delay. Some of the requirements we have for this are
the ability to allow for rescheduling and flushing on drm_vblank_works,
which become a lot harder to do properly if we can't re-queue work under
lock. Additionally, being able to specify a custom position in the
kthread_worker's work_list (which requires being under lock) is
important to be able to do since it's needed for implementing a custom
work flushing mechanism that waits for both the vblank sequence and
kthread_worker to complete once.

So - let's expose an unlocked version of kthread_queue_work() called
__kthread_queue_work(), which also allows for specifying a custom list
position in which to insert the work before.

Cc: Tejun Heo <tj@kernel.org>
Signed-off-by: Lyude Paul <lyude@redhat.com>
---
 include/linux/kthread.h |  3 +++
 kernel/kthread.c        | 34 ++++++++++++++++++++++++++++++----
 2 files changed, 33 insertions(+), 4 deletions(-)

diff --git a/include/linux/kthread.h b/include/linux/kthread.h
index 8bbcaad7ef0f..02e0c1c157bf 100644
--- a/include/linux/kthread.h
+++ b/include/linux/kthread.h
@@ -179,6 +179,9 @@ __printf(3, 4) struct kthread_worker *
 kthread_create_worker_on_cpu(int cpu, unsigned int flags,
 			     const char namefmt[], ...);
 
+bool __kthread_queue_work(struct kthread_worker *worker,
+			  struct kthread_work *work,
+			  struct list_head *pos);
 bool kthread_queue_work(struct kthread_worker *worker,
 			struct kthread_work *work);
 
diff --git a/kernel/kthread.c b/kernel/kthread.c
index bfbfa481be3a..46de56142593 100644
--- a/kernel/kthread.c
+++ b/kernel/kthread.c
@@ -816,6 +816,35 @@ static void kthread_insert_work(struct kthread_worker *worker,
 		wake_up_process(worker->task);
 }
 
+/**
+ * __kthread_queue_work - queue a kthread_work while under lock
+ * @worker: target kthread_worker
+ * @work: kthread_work to queue
+ * @pos: The position in @worker.work_list to insert @work before
+ *
+ * This is the same as kthread_queue_work(), except that it already expects
+ * the caller to be holding &kthread_worker.lock and allows for specifying a
+ * custom position in @worker.work_list to insert @work before.
+ *
+ * This function is mostly useful for users which might need to create their
+ * own delayed kthread_worker implementations.
+ *
+ * Returns: %true if @work was successfully queued, %false if it was already
+ * pending.
+ */
+bool __kthread_queue_work(struct kthread_worker *worker,
+			  struct kthread_work *work,
+			  struct list_head *pos)
+{
+	if (!queuing_blocked(worker, work)) {
+		kthread_insert_work(worker, work, pos);
+		return true;
+	}
+
+	return false;
+}
+EXPORT_SYMBOL_GPL(__kthread_queue_work);
+
 /**
  * kthread_queue_work - queue a kthread_work
  * @worker: target kthread_worker
@@ -835,10 +864,7 @@ bool kthread_queue_work(struct kthread_worker *worker,
 	unsigned long flags;
 
 	raw_spin_lock_irqsave(&worker->lock, flags);
-	if (!queuing_blocked(worker, work)) {
-		kthread_insert_work(worker, work, &worker->work_list);
-		ret = true;
-	}
+	ret = __kthread_queue_work(worker, work, &worker->work_list);
 	raw_spin_unlock_irqrestore(&worker->lock, flags);
 	return ret;
 }
-- 
2.25.1


  parent reply	other threads:[~2020-04-17 19:42 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-17 19:40 [RFC v3 00/11] drm/nouveau: Introduce CRC support for gf119+ Lyude Paul
2020-04-17 19:40 ` [RFC v3 01/11] drm/vblank: Register drmm cleanup action once per drm_vblank_crtc Lyude Paul
2020-04-21 12:29   ` Daniel Vetter
2020-04-17 19:40 ` Lyude Paul [this message]
2020-04-17 19:40 ` [RFC v3 03/11] drm/vblank: Add vblank works Lyude Paul
2020-04-17 20:16   ` [Poke: Tejun] " Lyude Paul
2020-04-17 21:03     ` Tejun Heo
2020-04-17 21:24       ` Lyude Paul
2020-04-21 12:34       ` Daniel Vetter
2020-04-22 16:22         ` Tejun Heo
2020-04-17 19:40 ` [RFC v3 04/11] drm/nouveau/kms/nv50-: Unroll error cleanup in nv50_head_create() Lyude Paul
2020-04-17 19:40 ` [RFC v3 05/11] drm/nouveau/kms/nv140-: Don't modify depth in state during atomic commit Lyude Paul
2020-04-17 19:40 ` [RFC v3 06/11] drm/nouveau/kms/nv50-: Fix disabling dithering Lyude Paul
2020-04-17 19:40 ` [RFC v3 07/11] drm/nouveau/kms/nv50-: s/harm/armh/g Lyude Paul
2020-04-17 19:40 ` [RFC v3 08/11] drm/nouveau/kms/nv140-: Track wndw mappings in nv50_head_atom Lyude Paul
2020-04-17 19:40 ` [RFC v3 09/11] drm/nouveau/kms/nv50-: Expose nv50_outp_atom in disp.h Lyude Paul
2020-04-17 19:40 ` [RFC v3 10/11] drm/nouveau/kms/nv50-: Move hard-coded object handles into header Lyude Paul
2020-04-17 19:40 ` [RFC v3 11/11] drm/nouveau/kms/nvd9-: Add CRC support Lyude Paul
2020-04-20 23:19 ` [RFC v3 00/11] drm/nouveau: Introduce CRC support for gf119+ Ben Skeggs

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=20200417194145.36350-3-lyude@redhat.com \
    --to=lyude@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=ben.dooks@codethink.co.uk \
    --cc=cl@rock-chips.com \
    --cc=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pmladek@suse.com \
    --cc=rostedt@goodmis.org \
    --cc=surenb@google.com \
    --cc=tglx@linutronix.de \
    --cc=tj@kernel.org \
    /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