From: Matthew Sakai <msakai@redhat.com>
To: dm-devel@lists.linux.dev
Cc: Mike Snitzer <snitzer@kernel.org>, Matthew Sakai <msakai@redhat.com>
Subject: [PATCH 01/13] dm vdo: make uds_*_semaphore interface private to uds-threads.c
Date: Thu, 29 Feb 2024 22:52:53 -0500 [thread overview]
Message-ID: <dbdb8036783597e27b85a33852c3b7acea40fb6e.1709264538.git.msakai@redhat.com> (raw)
In-Reply-To: <cover.1709264538.git.msakai@redhat.com>
From: Mike Snitzer <snitzer@kernel.org>
Signed-off-by: Mike Snitzer <snitzer@kernel.org>
Signed-off-by: Matthew Sakai <msakai@redhat.com>
---
drivers/md/dm-vdo/uds-threads.c | 39 +++++++++++++++++++++++++++++++++
drivers/md/dm-vdo/uds-threads.h | 37 -------------------------------
2 files changed, 39 insertions(+), 37 deletions(-)
diff --git a/drivers/md/dm-vdo/uds-threads.c b/drivers/md/dm-vdo/uds-threads.c
index 769c783e342a..33117f68cf36 100644
--- a/drivers/md/dm-vdo/uds-threads.c
+++ b/drivers/md/dm-vdo/uds-threads.c
@@ -136,10 +136,49 @@ int uds_join_threads(struct thread *thread)
return UDS_SUCCESS;
}
+static inline int __must_check uds_initialize_semaphore(struct semaphore *semaphore,
+ unsigned int value)
+{
+ sema_init(semaphore, value);
+ return UDS_SUCCESS;
+}
+
+static inline int uds_destroy_semaphore(struct semaphore *semaphore)
+{
+ return UDS_SUCCESS;
+}
+
+static inline void uds_acquire_semaphore(struct semaphore *semaphore)
+{
+ /*
+ * Do not use down(semaphore). Instead use down_interruptible so that
+ * we do not get 120 second stall messages in kern.log.
+ */
+ while (down_interruptible(semaphore) != 0) {
+ /*
+ * If we're called from a user-mode process (e.g., "dmsetup
+ * remove") while waiting for an operation that may take a
+ * while (e.g., UDS index save), and a signal is sent (SIGINT,
+ * SIGUSR2), then down_interruptible will not block. If that
+ * happens, sleep briefly to avoid keeping the CPU locked up in
+ * this loop. We could just call cond_resched, but then we'd
+ * still keep consuming CPU time slices and swamp other threads
+ * trying to do computational work. [VDO-4980]
+ */
+ fsleep(1000);
+ }
+}
+
+static inline void uds_release_semaphore(struct semaphore *semaphore)
+{
+ up(semaphore);
+}
+
int uds_initialize_barrier(struct barrier *barrier, unsigned int thread_count)
{
int result;
+ /* FIXME: must cleanup, uds_initialize_semaphore never fails! */
result = uds_initialize_semaphore(&barrier->mutex, 1);
if (result != UDS_SUCCESS)
return result;
diff --git a/drivers/md/dm-vdo/uds-threads.h b/drivers/md/dm-vdo/uds-threads.h
index 9f3bf7991383..b77a2d46da80 100644
--- a/drivers/md/dm-vdo/uds-threads.h
+++ b/drivers/md/dm-vdo/uds-threads.h
@@ -74,42 +74,5 @@ static inline void uds_unlock_mutex(struct mutex *mutex)
mutex_unlock(mutex);
}
-static inline int __must_check uds_initialize_semaphore(struct semaphore *semaphore,
- unsigned int value)
-{
- sema_init(semaphore, value);
- return UDS_SUCCESS;
-}
-
-static inline int uds_destroy_semaphore(struct semaphore *semaphore)
-{
- return UDS_SUCCESS;
-}
-
-static inline void uds_acquire_semaphore(struct semaphore *semaphore)
-{
- /*
- * Do not use down(semaphore). Instead use down_interruptible so that
- * we do not get 120 second stall messages in kern.log.
- */
- while (down_interruptible(semaphore) != 0) {
- /*
- * If we're called from a user-mode process (e.g., "dmsetup
- * remove") while waiting for an operation that may take a
- * while (e.g., UDS index save), and a signal is sent (SIGINT,
- * SIGUSR2), then down_interruptible will not block. If that
- * happens, sleep briefly to avoid keeping the CPU locked up in
- * this loop. We could just call cond_resched, but then we'd
- * still keep consuming CPU time slices and swamp other threads
- * trying to do computational work. [VDO-4980]
- */
- fsleep(1000);
- }
-}
-
-static inline void uds_release_semaphore(struct semaphore *semaphore)
-{
- up(semaphore);
-}
#endif /* UDS_THREADS_H */
--
2.42.0
next prev parent reply other threads:[~2024-03-01 3:53 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-01 3:52 [PATCH 00/13] dm vdo: clean up and simplify thread utilities Matthew Sakai
2024-03-01 3:52 ` Matthew Sakai [this message]
2024-03-01 3:52 ` [PATCH 02/13] dm vdo uds-threads: eliminate uds_*_semaphore interfaces Matthew Sakai
2024-03-01 3:52 ` [PATCH 03/13] dm vdo uds-threads: push 'barrier' down to sparse-cache Matthew Sakai
2024-03-01 3:52 ` [PATCH 04/13] dm vdo indexer sparse-cache: cleanup threads_barrier code Matthew Sakai
2024-03-01 3:52 ` [PATCH 05/13] dm vdo: rename uds-threads.[ch] to thread-utils.[ch] Matthew Sakai
2024-03-01 3:52 ` [PATCH 06/13] dm vdo indexer: rename uds.h to indexer.h Matthew Sakai
2024-03-01 3:52 ` [PATCH 07/13] dm vdo: fold thread-cond-var.c into thread-utils Matthew Sakai
2024-03-01 3:53 ` [PATCH 08/13] dm vdo thread-utils: push uds_*_cond interface down to indexer Matthew Sakai
2024-03-01 3:53 ` [PATCH 09/13] dm vdo thread-utils: remove all uds_*_mutex wrappers Matthew Sakai
2024-03-01 3:53 ` [PATCH 10/13] dm vdo thread-utils: further cleanup of thread functions Matthew Sakai
2024-03-01 3:53 ` [PATCH 11/13] dm vdo thread-utils: cleanup included headers Matthew Sakai
2024-03-01 3:53 ` [PATCH 12/13] dm vdo thread-registry: rename all methods to reflect vdo-only use Matthew Sakai
2024-03-01 3:53 ` [PATCH 13/13] dm vdo thread-device: " Matthew Sakai
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=dbdb8036783597e27b85a33852c3b7acea40fb6e.1709264538.git.msakai@redhat.com \
--to=msakai@redhat.com \
--cc=dm-devel@lists.linux.dev \
--cc=snitzer@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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).