1. Patchew
  2. linux
  3. View series

[PATCH] rust: sync: Makes `CondVar::wait()` an uninterruptible wait

Boqun Feng posted 1 patch 2 years, 1 month ago 
rust/kernel/sync/condvar.rs | 28 ++++++++++++++--------------
1 file changed, 14 insertions(+), 14 deletions(-)
[PATCH] rust: sync: Makes `CondVar::wait()` an uninterruptible wait
Posted by Boqun Feng 2 years, 1 month ago 
Currently, `CondVar::wait()` is an interruptible wait, and this is
different than `wait_event()` in include/linux/wait.h (which is an
uninterruptible wait). To avoid confusion between different APIs on the
interruptible/uninterruptible, make `CondVar::wait()` an uninterruptible
wait same as `wait_event()`, also rename the old `wait()` to
`CondVar::wait_interruptible()`.

Spotted-by: Tiago Lam <tiagolam@gmail.com>
Signed-off-by: Boqun Feng <boqun.feng@gmail.com>
---
 rust/kernel/sync/condvar.rs | 28 ++++++++++++++--------------
 1 file changed, 14 insertions(+), 14 deletions(-)

diff --git a/rust/kernel/sync/condvar.rs b/rust/kernel/sync/condvar.rs
index b679b6f6dbeb..8630faa29b78 100644
--- a/rust/kernel/sync/condvar.rs
+++ b/rust/kernel/sync/condvar.rs
@@ -50,7 +50,7 @@ macro_rules! new_condvar {
 /// fn wait_for_value(e: &Example, v: u32) {
 ///     let mut guard = e.value.lock();
 ///     while *guard != v {
-///         e.value_changed.wait_uninterruptible(&mut guard);
+///         e.value_changed.wait(&mut guard);
 ///     }
 /// }
 ///
@@ -120,28 +120,28 @@ fn wait_internal<T: ?Sized, B: Backend>(&self, wait_state: u32, guard: &mut Guar
         unsafe { bindings::finish_wait(self.wait_list.get(), wait.get()) };
     }
 
-    /// Releases the lock and waits for a notification in interruptible mode.
+    /// Releases the lock and waits for a notification in uninterruptible mode.
     ///
     /// Atomically releases the given lock (whose ownership is proven by the guard) and puts the
     /// thread to sleep, reacquiring the lock on wake up. It wakes up when notified by
-    /// [`CondVar::notify_one`] or [`CondVar::notify_all`], or when the thread receives a signal.
-    /// It may also wake up spuriously.
+    /// [`CondVar::notify_one`] or [`CondVar::notify_all`]. Note that it may also wake up
+    /// spuriously.
+    pub fn wait<T: ?Sized, B: Backend>(&self, guard: &mut Guard<'_, T, B>) {
+        self.wait_internal(bindings::TASK_UNINTERRUPTIBLE, guard);
+    }
+
+    /// Releases the lock and waits for a notification in interruptible mode.
+    ///
+    /// Similar to [`CondVar::wait`], except that the wait is interruptible. That is, the thread may
+    /// wake up due to signals. It may also wake up spuriously.
     ///
     /// Returns whether there is a signal pending.
-    #[must_use = "wait returns if a signal is pending, so the caller must check the return value"]
-    pub fn wait<T: ?Sized, B: Backend>(&self, guard: &mut Guard<'_, T, B>) -> bool {
+    #[must_use = "wait_interruptible returns if a signal is pending, so the caller must check the return value"]
+    pub fn wait_interruptible<T: ?Sized, B: Backend>(&self, guard: &mut Guard<'_, T, B>) -> bool {
         self.wait_internal(bindings::TASK_INTERRUPTIBLE, guard);
         crate::current!().signal_pending()
     }
 
-    /// Releases the lock and waits for a notification in uninterruptible mode.
-    ///
-    /// Similar to [`CondVar::wait`], except that the wait is not interruptible. That is, the
-    /// thread won't wake up due to signals. It may, however, wake up supirously.
-    pub fn wait_uninterruptible<T: ?Sized, B: Backend>(&self, guard: &mut Guard<'_, T, B>) {
-        self.wait_internal(bindings::TASK_UNINTERRUPTIBLE, guard)
-    }
-
     /// Calls the kernel function to notify the appropriate number of threads with the given flags.
     fn notify(&self, count: i32, flags: u32) {
         // SAFETY: `wait_list` points to valid memory.
-- 
2.43.0
Re: [PATCH] rust: sync: Makes `CondVar::wait()` an uninterruptible wait
Posted by Miguel Ojeda 2 years, 1 month ago 
On Thu, Dec 14, 2023 at 9:04 PM Boqun Feng <boqun.feng@gmail.com> wrote:
>
> Currently, `CondVar::wait()` is an interruptible wait, and this is
> different than `wait_event()` in include/linux/wait.h (which is an
> uninterruptible wait). To avoid confusion between different APIs on the
> interruptible/uninterruptible, make `CondVar::wait()` an uninterruptible
> wait same as `wait_event()`, also rename the old `wait()` to
> `CondVar::wait_interruptible()`.
>
> Spotted-by: Tiago Lam <tiagolam@gmail.com>
> Signed-off-by: Boqun Feng <boqun.feng@gmail.com>

Applied to `rust-next` -- thanks everyone!

Cheers,
Miguel
Re: [PATCH] rust: sync: Makes `CondVar::wait()` an uninterruptible wait
Posted by Benno Lossin 2 years, 1 month ago 
On 12/14/23 21:04, Boqun Feng wrote:
> Currently, `CondVar::wait()` is an interruptible wait, and this is
> different than `wait_event()` in include/linux/wait.h (which is an
> uninterruptible wait). To avoid confusion between different APIs on the
> interruptible/uninterruptible, make `CondVar::wait()` an uninterruptible
> wait same as `wait_event()`, also rename the old `wait()` to
> `CondVar::wait_interruptible()`.
> 
> Spotted-by: Tiago Lam <tiagolam@gmail.com>
> Signed-off-by: Boqun Feng <boqun.feng@gmail.com>
> ---

Reviewed-by: Benno Lossin <benno.lossin@proton.me>

-- 
Cheers,
Benno
Re: [PATCH] rust: sync: Makes `CondVar::wait()` an uninterruptible wait
Posted by Tiago Lam 2 years, 1 month ago 
On 14/12/2023 20:04, Boqun Feng wrote:
> Currently, `CondVar::wait()` is an interruptible wait, and this is
> different than `wait_event()` in include/linux/wait.h (which is an
> uninterruptible wait). To avoid confusion between different APIs on the
> interruptible/uninterruptible, make `CondVar::wait()` an uninterruptible
> wait same as `wait_event()`, also rename the old `wait()` to
> `CondVar::wait_interruptible()`.
> 
> Spotted-by: Tiago Lam <tiagolam@gmail.com>
> Signed-off-by: Boqun Feng <boqun.feng@gmail.com>

Thanks, that's clearer.

Reviewed-by: Tiago Lam <tiagolam@gmail.com>
Re: [PATCH] rust: sync: Makes `CondVar::wait()` an uninterruptible wait
Posted by Alice Ryhl 2 years, 1 month ago 
On Thu, Dec 14, 2023 at 9:04 PM Boqun Feng <boqun.feng@gmail.com> wrote:
>
> Currently, `CondVar::wait()` is an interruptible wait, and this is
> different than `wait_event()` in include/linux/wait.h (which is an
> uninterruptible wait). To avoid confusion between different APIs on the
> interruptible/uninterruptible, make `CondVar::wait()` an uninterruptible
> wait same as `wait_event()`, also rename the old `wait()` to
> `CondVar::wait_interruptible()`.
>
> Spotted-by: Tiago Lam <tiagolam@gmail.com>
> Signed-off-by: Boqun Feng <boqun.feng@gmail.com>

The diff is a bit hard to read because you swapped the order of the
functions, but LGTM.

Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Re: [PATCH] rust: sync: Makes `CondVar::wait()` an uninterruptible wait
Posted by Boqun Feng 2 years, 1 month ago 
On Fri, Dec 15, 2023 at 11:27:56AM +0100, Alice Ryhl wrote:
> On Thu, Dec 14, 2023 at 9:04 PM Boqun Feng <boqun.feng@gmail.com> wrote:
> >
> > Currently, `CondVar::wait()` is an interruptible wait, and this is
> > different than `wait_event()` in include/linux/wait.h (which is an
> > uninterruptible wait). To avoid confusion between different APIs on the
> > interruptible/uninterruptible, make `CondVar::wait()` an uninterruptible
> > wait same as `wait_event()`, also rename the old `wait()` to
> > `CondVar::wait_interruptible()`.
> >
> > Spotted-by: Tiago Lam <tiagolam@gmail.com>
> > Signed-off-by: Boqun Feng <boqun.feng@gmail.com>
> 
> The diff is a bit hard to read because you swapped the order of the
> functions, but LGTM.
> 

Yeah, I did that because `wait_interruptible` metioned `wait`, so I had
to make `wait` still before `wait_interruptible`.

> Reviewed-by: Alice Ryhl <aliceryhl@google.com>

Thanks!

Regards,
Boqun
Re: [PATCH] rust: sync: Makes `CondVar::wait()` an uninterruptible wait
Posted by Benno Lossin 2 years, 1 month ago 
On 12/16/23 00:45, Boqun Feng wrote:
> On Fri, Dec 15, 2023 at 11:27:56AM +0100, Alice Ryhl wrote:
>> On Thu, Dec 14, 2023 at 9:04 PM Boqun Feng <boqun.feng@gmail.com> wrote:
>>>
>>> Currently, `CondVar::wait()` is an interruptible wait, and this is
>>> different than `wait_event()` in include/linux/wait.h (which is an
>>> uninterruptible wait). To avoid confusion between different APIs on the
>>> interruptible/uninterruptible, make `CondVar::wait()` an uninterruptible
>>> wait same as `wait_event()`, also rename the old `wait()` to
>>> `CondVar::wait_interruptible()`.
>>>
>>> Spotted-by: Tiago Lam <tiagolam@gmail.com>
>>> Signed-off-by: Boqun Feng <boqun.feng@gmail.com>
>>
>> The diff is a bit hard to read because you swapped the order of the
>> functions, but LGTM.
>>
> 
> Yeah, I did that because `wait_interruptible` metioned `wait`, so I had
> to make `wait` still before `wait_interruptible`.

What do you mean? If you are talking about the doclink, then
that should not matter.

-- 
Cheers,
Benno
Re: [PATCH] rust: sync: Makes `CondVar::wait()` an uninterruptible wait
Posted by Boqun Feng 2 years, 1 month ago 
On Mon, Dec 18, 2023 at 05:39:14PM +0000, Benno Lossin wrote:
> On 12/16/23 00:45, Boqun Feng wrote:
> > On Fri, Dec 15, 2023 at 11:27:56AM +0100, Alice Ryhl wrote:
> >> On Thu, Dec 14, 2023 at 9:04 PM Boqun Feng <boqun.feng@gmail.com> wrote:
> >>>
> >>> Currently, `CondVar::wait()` is an interruptible wait, and this is
> >>> different than `wait_event()` in include/linux/wait.h (which is an
> >>> uninterruptible wait). To avoid confusion between different APIs on the
> >>> interruptible/uninterruptible, make `CondVar::wait()` an uninterruptible
> >>> wait same as `wait_event()`, also rename the old `wait()` to
> >>> `CondVar::wait_interruptible()`.
> >>>
> >>> Spotted-by: Tiago Lam <tiagolam@gmail.com>
> >>> Signed-off-by: Boqun Feng <boqun.feng@gmail.com>
> >>
> >> The diff is a bit hard to read because you swapped the order of the
> >> functions, but LGTM.
> >>
> > 
> > Yeah, I did that because `wait_interruptible` metioned `wait`, so I had
> > to make `wait` still before `wait_interruptible`.
> 
> What do you mean? If you are talking about the doclink, then

I meant I prefer to keeping `wait` text-order-before
`wait_interruptible`, so that readers will first read it.

> that should not matter.

Yeah, I know the ordering doesn't matter for generating doc. However,
the ordering still matters for readers, I'd like them to learn about
`wait` first since according to the existing API in kernel, they are the
major usage.

Thanks for pointing it out anyway! ;-)

Regards,
Boqun

> 
> -- 
> Cheers,
> Benno
> 
>

Patchew 2.1-devel-b67e4c2

© 2016 - 2026 Red Hat, Inc.