Linux block layer
 help / color / mirror / Atom feed
From: NeilBrown <neilb@suse.de>
To: Ingo Molnar <mingo@redhat.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Jens Axboe <axboe@kernel.dk>
Cc: linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	linux-block@vger.kernel.org
Subject: [PATCH 6/7] sched: Add wait/wake interface for variable updated under a lock.
Date: Mon, 26 Aug 2024 16:31:03 +1000	[thread overview]
Message-ID: <20240826063659.15327-7-neilb@suse.de> (raw)
In-Reply-To: <20240826063659.15327-1-neilb@suse.de>

Sometimes we need to wait for a condition to be true which must be
testing while holding a lock.  Correspondingly the condition is made
true while holing the lock and the wake up is sent under the lock.

This patch provides wake and wait interfaces which can be used for this
situation when the lock is either a mutex or a spinlock.

Signed-off-by: NeilBrown <neilb@suse.de>
---
 include/linux/wait_bit.h | 69 ++++++++++++++++++++++++++++++++++++++++
 1 file changed, 69 insertions(+)

diff --git a/include/linux/wait_bit.h b/include/linux/wait_bit.h
index c1675457c077..6995a0d89ebd 100644
--- a/include/linux/wait_bit.h
+++ b/include/linux/wait_bit.h
@@ -401,6 +401,75 @@ do {									\
 	__ret;								\
 })
 
+/**
+ * wait_var_event_spinlock - wait for a variable to be updated under a spinlock
+ * @var: the address of the variable being waited on
+ * @condition: condition to wait for
+ * @lock: the spinlock which protects updates to the variable
+ *
+ * Wait for a condition which can only be reliably tested while holding
+ * a spinlock.  The variables assessed in the condition will normal be updated
+ * under the same spinlock, and the wake up should be signalled with
+ * wake_up_var_locked() under the same spinlock.
+ *
+ * This is similar to wait_var_event(), but assume a spinlock is held
+ * while calling this function and while updating the variable.
+ *
+ * This must be called while the given lock is held and the lock will be
+ * dropped when schedule() is called to wait for a wake up, and will be
+ * reclaimed before testing the condition again.
+ */
+#define wait_var_event_spinlock(var, condition, lock)			\
+do {									\
+	might_sleep();							\
+	if (condition)							\
+		break;							\
+	___wait_var_event(var, condition, TASK_UNINTERRUPTIBLE, 0, 0,	\
+			  spin_unlock(lock); schedule(); spin_lock(lock)); \
+} while (0)
+
+/**
+ * wait_var_event_mutex - wait for a variable to be updated under a mutex
+ * @var: the address of the variable being waited on
+ * @condition: condition to wait for
+ * @mutex: the mutex which protects updates to the variable
+ *
+ * Wait for a condition which can only be reliably tested while holding
+ * a mutex.  The variables assessed in the condition will normal be
+ * updated under the same mutex, and the wake up should be signalled
+ * with wake_up_var_locked() under the same mutex.
+ *
+ * This is similar to wait_var_event(), but assume a mutex is held
+ * while calling this function and while updating the variable.
+ *
+ * This must be called while the given mutex is held and the mutex will be
+ * dropped when schedule() is called to wait for a wake up, and will be
+ * reclaimed before testing the condition again.
+ */
+#define wait_var_event_mutex(var, condition, mutex)			\
+do {									\
+	might_sleep();							\
+	if (condition)							\
+		break;							\
+	___wait_var_event(var, condition, TASK_UNINTERRUPTIBLE, 0, 0,	\
+			  mutex_unlock(mutex); schedule(); mutex_lock(mutex)); \
+} while (0)
+
+/**
+ * wake_up_var_locked - wake up waits for a variable while holding a spinlock or mutex
+ * @var: the address of the variable being waited on
+ * @lock: The spinlock or mutex what protects the variable
+ *
+ * Send a wake up for the given variable which should be waited for with
+ * wait_var_event_spinlock() or wait_var_event_mutex().  Unlike wake_up_var(),
+ * no extra barriers are needed as the locking provides sufficient sequencing.
+ */
+#define wake_up_var_locked(var, lock)					\
+do {									\
+	lockdep_assert_held(lock);					\
+	wake_up_var(var);						\
+} while (0)
+
 /**
  * clear_and_wake_up_bit - clear a bit and wake up anyone waiting on that bit
  * @bit: the bit of the word being waited on
-- 
2.44.0


  parent reply	other threads:[~2024-08-26  6:37 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-08-26  6:30 [PATCH 0/7 v2 RFC] Make wake_up_{bit,var} less fragile NeilBrown
2024-08-26  6:30 ` [PATCH 1/7] block: change wait on bd_claiming to use a var_waitqueue, not a bit_waitqueue NeilBrown
2024-09-17  3:12   ` Jens Axboe
2024-09-17 21:54     ` NeilBrown
2024-09-17  3:13   ` (subset) " Jens Axboe
2024-08-26  6:30 ` [PATCH 2/7] sched: change wake_up_bit() and related function to expect unsigned long * NeilBrown
2024-09-16 11:28   ` Peter Zijlstra
2024-09-16 11:48     ` NeilBrown
2024-09-16 18:18       ` Peter Zijlstra
2024-09-16 20:37         ` NeilBrown
2024-08-26  6:31 ` [PATCH 3/7] sched: Improve documentation for wake_up_bit/wait_on_bit family of functions NeilBrown
2024-08-26  6:31 ` [PATCH 4/7] sched: Document wait_var_event() family of functions and wake_up_var() NeilBrown
2024-08-26  6:31 ` [PATCH 5/7] sched: Add test_and_clear_wake_up_bit() and atomic_dec_and_wake_up() NeilBrown
2024-08-26  6:31 ` NeilBrown [this message]
2024-08-26  6:31 ` [PATCH 7/7] Block: switch bd_prepare_to_claim to use wait_var_event_mutex() NeilBrown
2024-09-15 23:52 ` [PATCH 0/7 v2 RFC] Make wake_up_{bit,var} less fragile NeilBrown

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=20240826063659.15327-7-neilb@suse.de \
    --to=neilb@suse.de \
    --cc=axboe@kernel.dk \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=torvalds@linux-foundation.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