[2/2] rust: sync: add `CondVar::wait_timeout`

Message ID 20231206-rb-new-condvar-methods-v1-2-33a4cab7fdaa@google.com
State New
Headers
Series Additional CondVar methods needed by Rust Binder |

Commit Message

Alice Ryhl Dec. 6, 2023, 10:09 a.m. UTC
  Sleep on a condition variable with a timeout.

This is used by Rust Binder for process freezing. There, we want to
sleep until the freeze operation completes, but we want to be able to
abort the process freezing if it doesn't complete within some timeout.

Signed-off-by: Alice Ryhl <aliceryhl@google.com>
---
 rust/kernel/sync.rs         |  2 +-
 rust/kernel/sync/condvar.rs | 73 +++++++++++++++++++++++++++++++++++++++++++++
 rust/kernel/sync/lock.rs    |  4 +--
 3 files changed, 76 insertions(+), 3 deletions(-)
  

Comments

Martin Rodriguez Reboredo Dec. 6, 2023, 3:53 p.m. UTC | #1
On 12/6/23 07:09, Alice Ryhl wrote:
> Sleep on a condition variable with a timeout.
> 
> This is used by Rust Binder for process freezing. There, we want to
> sleep until the freeze operation completes, but we want to be able to
> abort the process freezing if it doesn't complete within some timeout.
> 
> Signed-off-by: Alice Ryhl <aliceryhl@google.com>
> ---
> [...]
>   
> +    /// Atomically releases the given lock (whose ownership is proven by the guard) and puts the
> +    /// thread to sleep. It wakes up when notified by [`CondVar::notify_one`] or
> +    /// [`CondVar::notify_all`], or when the thread receives a signal.
> +    ///
> +    /// Returns whether there is a signal pending.

Remaining jiffies or zero on timeout?

> +    fn wait_internal_timeout<T, B>(
> +        &self,
> +        wait_state: u32,
> +        guard: &mut Guard<'_, T, B>,
> +        timeout: u64,
> +    ) -> u64
> [...]
> +
> +    /// Releases the lock and waits for a notification in interruptible mode.
> +    ///
> +    /// Atomically releases the given lock (whose ownership is proven by the guard) and puts the
> +    /// thread to sleep. It wakes up when notified by [`CondVar::notify_one`] or
> +    /// [`CondVar::notify_all`], or when a timeout occurs, or when the thread receives a signal.
> +    ///
> +    /// Returns whether there is a signal pending.

This one is correct.

> +    #[must_use = "wait_timeout returns if a signal is pending, so the caller must check the return value"]
> +    pub fn wait_timeout<T: ?Sized, B: Backend>(
> +        &self,
> +        guard: &mut Guard<'_, T, B>,
> +        jiffies: u64,
> +    ) -> CondVarTimeoutResult {
> [...]
  
Boqun Feng Dec. 6, 2023, 4:30 p.m. UTC | #2
On Wed, Dec 06, 2023 at 10:09:24AM +0000, Alice Ryhl wrote:
[...]
> +
> +/// The return type of `wait_timeout`.
> +pub enum CondVarTimeoutResult {
> +    /// The timeout was reached.
> +    Timeout,
> +    /// Somebody woke us up.
> +    Woken {
> +        /// Remaining sleep duration.
> +        jiffies: u64,

I have a Jiffies definition in the my upcoming timer patchset:

/// The time unit of Linux kernel. One jiffy equals (1/HZ) second.
pub type Jiffies = core::ffi::c_ulong;

Maybe you can add that (in a separate patch) in kernel::time?

Regards,
Boqun

> +    },
> +    /// A signal occurred.
> +    Signal {
> +        /// Remaining sleep duration.
> +        jiffies: u64,
> +    },
> +}
[...]
  
Alice Ryhl Dec. 6, 2023, 4:38 p.m. UTC | #3
On Wed, Dec 6, 2023 at 4:53 PM Martin Rodriguez Reboredo
<yakoyoku@gmail.com> wrote:
>
> On 12/6/23 07:09, Alice Ryhl wrote:
> > Sleep on a condition variable with a timeout.
> >
> > This is used by Rust Binder for process freezing. There, we want to
> > sleep until the freeze operation completes, but we want to be able to
> > abort the process freezing if it doesn't complete within some timeout.
> >
> > Signed-off-by: Alice Ryhl <aliceryhl@google.com>
> > ---
> > [...]
> >
> > +    /// Atomically releases the given lock (whose ownership is proven by the guard) and puts the
> > +    /// thread to sleep. It wakes up when notified by [`CondVar::notify_one`] or
> > +    /// [`CondVar::notify_all`], or when the thread receives a signal.
> > +    ///
> > +    /// Returns whether there is a signal pending.
>
> Remaining jiffies or zero on timeout?

Seems like I just copied this typo from the other `_internal` method.
I'll fix it on both.

Alice
  
Peter Zijlstra Dec. 6, 2023, 4:39 p.m. UTC | #4
On Wed, Dec 06, 2023 at 08:30:06AM -0800, Boqun Feng wrote:
> On Wed, Dec 06, 2023 at 10:09:24AM +0000, Alice Ryhl wrote:
> [...]
> > +
> > +/// The return type of `wait_timeout`.
> > +pub enum CondVarTimeoutResult {
> > +    /// The timeout was reached.
> > +    Timeout,
> > +    /// Somebody woke us up.
> > +    Woken {
> > +        /// Remaining sleep duration.
> > +        jiffies: u64,
> 
> I have a Jiffies definition in the my upcoming timer patchset:
> 
> /// The time unit of Linux kernel. One jiffy equals (1/HZ) second.
> pub type Jiffies = core::ffi::c_ulong;
> 
> Maybe you can add that (in a separate patch) in kernel::time?

Urgh, why are we using jiffies in 2023?
  
Alice Ryhl Dec. 6, 2023, 4:42 p.m. UTC | #5
On Wed, Dec 6, 2023 at 5:39 PM Peter Zijlstra <peterz@infradead.org> wrote:
>
> On Wed, Dec 06, 2023 at 08:30:06AM -0800, Boqun Feng wrote:
> > On Wed, Dec 06, 2023 at 10:09:24AM +0000, Alice Ryhl wrote:
> > [...]
> > > +
> > > +/// The return type of `wait_timeout`.
> > > +pub enum CondVarTimeoutResult {
> > > +    /// The timeout was reached.
> > > +    Timeout,
> > > +    /// Somebody woke us up.
> > > +    Woken {
> > > +        /// Remaining sleep duration.
> > > +        jiffies: u64,
> >
> > I have a Jiffies definition in the my upcoming timer patchset:
> >
> > /// The time unit of Linux kernel. One jiffy equals (1/HZ) second.
> > pub type Jiffies = core::ffi::c_ulong;
> >
> > Maybe you can add that (in a separate patch) in kernel::time?
>
> Urgh, why are we using jiffies in 2023?

I assumed that the correct thing here would be to accept the same unit
as what schedule_timeout takes. Should I be doing something else?

Alice
  
Peter Zijlstra Dec. 6, 2023, 4:53 p.m. UTC | #6
On Wed, Dec 06, 2023 at 05:42:29PM +0100, Alice Ryhl wrote:
> On Wed, Dec 6, 2023 at 5:39 PM Peter Zijlstra <peterz@infradead.org> wrote:
> >
> > On Wed, Dec 06, 2023 at 08:30:06AM -0800, Boqun Feng wrote:
> > > On Wed, Dec 06, 2023 at 10:09:24AM +0000, Alice Ryhl wrote:
> > > [...]
> > > > +
> > > > +/// The return type of `wait_timeout`.
> > > > +pub enum CondVarTimeoutResult {
> > > > +    /// The timeout was reached.
> > > > +    Timeout,
> > > > +    /// Somebody woke us up.
> > > > +    Woken {
> > > > +        /// Remaining sleep duration.
> > > > +        jiffies: u64,
> > >
> > > I have a Jiffies definition in the my upcoming timer patchset:
> > >
> > > /// The time unit of Linux kernel. One jiffy equals (1/HZ) second.
> > > pub type Jiffies = core::ffi::c_ulong;
> > >
> > > Maybe you can add that (in a separate patch) in kernel::time?
> >
> > Urgh, why are we using jiffies in 2023?
> 
> I assumed that the correct thing here would be to accept the same unit
> as what schedule_timeout takes. Should I be doing something else?

Bah, so we have schedule_hrtimeout() that takes ktime/u64 nsec. But the
'problem' is that hrtimers are written with the expectation to fire,
while the old timers are written with the expectation to not fire.

Timeouts are typically best done with the latter, so in that regard
using schedule_timeout() is right. But it is sad to inflict the
brain-damage that is jiffies onto new code.

Perhaps add schedule_timeout_*msec() wrappers around schedule_timeout*()
and use a consistent sane time unit?

Thomas?
  
Alice Ryhl Dec. 6, 2023, 5 p.m. UTC | #7
On Wed, Dec 6, 2023 at 5:53 PM Peter Zijlstra <peterz@infradead.org> wrote:
>
> On Wed, Dec 06, 2023 at 05:42:29PM +0100, Alice Ryhl wrote:
> > On Wed, Dec 6, 2023 at 5:39 PM Peter Zijlstra <peterz@infradead.org> wrote:
> > >
> > > On Wed, Dec 06, 2023 at 08:30:06AM -0800, Boqun Feng wrote:
> > > > On Wed, Dec 06, 2023 at 10:09:24AM +0000, Alice Ryhl wrote:
> > > > [...]
> > > > > +
> > > > > +/// The return type of `wait_timeout`.
> > > > > +pub enum CondVarTimeoutResult {
> > > > > +    /// The timeout was reached.
> > > > > +    Timeout,
> > > > > +    /// Somebody woke us up.
> > > > > +    Woken {
> > > > > +        /// Remaining sleep duration.
> > > > > +        jiffies: u64,
> > > >
> > > > I have a Jiffies definition in the my upcoming timer patchset:
> > > >
> > > > /// The time unit of Linux kernel. One jiffy equals (1/HZ) second.
> > > > pub type Jiffies = core::ffi::c_ulong;
> > > >
> > > > Maybe you can add that (in a separate patch) in kernel::time?
> > >
> > > Urgh, why are we using jiffies in 2023?
> >
> > I assumed that the correct thing here would be to accept the same unit
> > as what schedule_timeout takes. Should I be doing something else?
>
> Bah, so we have schedule_hrtimeout() that takes ktime/u64 nsec. But the
> 'problem' is that hrtimers are written with the expectation to fire,
> while the old timers are written with the expectation to not fire.
>
> Timeouts are typically best done with the latter, so in that regard
> using schedule_timeout() is right. But it is sad to inflict the
> brain-damage that is jiffies onto new code.
>
> Perhaps add schedule_timeout_*msec() wrappers around schedule_timeout*()
> and use a consistent sane time unit?
>
> Thomas?

Hmm, looking over my usage in Rust Binder again ... the unit I need
*is* msec, but when we are woken up, we sometimes just go to sleep
again, which means that we need to be able to pass the remaining
duration back to `wait_timeout` to continue sleeping. I'm guessing
that I would lose precision if I converted back/forth to msecs here?

Alice
  
Tiago Lam Dec. 6, 2023, 5:05 p.m. UTC | #8
On 06/12/2023 10:09, Alice Ryhl wrote:
[...]
> diff --git a/rust/kernel/sync/condvar.rs b/rust/kernel/sync/condvar.rs
> index 9861c6749ad0..a6a6b6ab0c39 100644
> --- a/rust/kernel/sync/condvar.rs
> +++ b/rust/kernel/sync/condvar.rs
> @@ -120,6 +120,63 @@ fn wait_internal<T: ?Sized, B: Backend>(&self, wait_state: u32, guard: &mut Guar
>           unsafe { bindings::finish_wait(self.wait_list.get(), wait.get()) };
>       }
>   
> +    /// Atomically releases the given lock (whose ownership is proven by the guard) and puts the
> +    /// thread to sleep. It wakes up when notified by [`CondVar::notify_one`] or
> +    /// [`CondVar::notify_all`], or when the thread receives a signal.
> +    ///
> +    /// Returns whether there is a signal pending.
> +    fn wait_internal_timeout<T, B>(
> +        &self,
> +        wait_state: u32,
> +        guard: &mut Guard<'_, T, B>,
> +        timeout: u64,
> +    ) -> u64
> +    where
> +        T: ?Sized,
> +        B: Backend,
> +    {
> +        let wait = Opaque::<bindings::wait_queue_entry>::uninit();
> +
> +        // SAFETY: `wait` points to valid memory.
> +        unsafe { bindings::init_wait(wait.get()) };
> +
> +        // SAFETY: Both `wait` and `wait_list` point to valid memory.
> +        unsafe {
> +            bindings::prepare_to_wait_exclusive(self.wait_list.get(), wait.get(), wait_state as _)
> +        };
> +
> +        // SAFETY: Switches to another thread.
> +        let timeout =
> +            guard.do_unlocked(|| unsafe { bindings::schedule_timeout(timeout as _) as _ });

It looks like `schedule_timeout()` simply calls `schedule()` when the 
timeout passed is `MAX_SCHEDULE_TIMEOUT`, so `wait_internal_timeout()` 
could be merged together with the already existing `wait_internal()`, 
where `wait_internal()` would always call `schedule_timeout()`? I may be 
missing something, so just wondering why you decided to introduce 
another method.

> +
> +        // SAFETY: Both `wait` and `wait_list` point to valid memory.
> +        unsafe { bindings::finish_wait(self.wait_list.get(), wait.get()) };
> +
> +        timeout
> +    }
> +
> +    /// Releases the lock and waits for a notification in interruptible mode.
> +    ///
> +    /// Atomically releases the given lock (whose ownership is proven by the guard) and puts the
> +    /// thread to sleep. It wakes up when notified by [`CondVar::notify_one`] or
> +    /// [`CondVar::notify_all`], or when a timeout occurs, or when the thread receives a signal.
> +    ///
> +    /// Returns whether there is a signal pending.
> +    #[must_use = "wait_timeout returns if a signal is pending, so the caller must check the return value"]
> +    pub fn wait_timeout<T: ?Sized, B: Backend>(
> +        &self,
> +        guard: &mut Guard<'_, T, B>,
> +        jiffies: u64,
> +    ) -> CondVarTimeoutResult {

Should this be called `wait_timeout_interruptable` instead, so that if 
we need to add one using the `TASK_INTERRUPTIBLE` state later we don't 
need to modfy it again? It also matches the 
`schedule_timeout_interruptible` one in the kernel (although that's not 
a reason to change it just in itself).

> +        let res = self.wait_internal_timeout(bindings::TASK_INTERRUPTIBLE, guard, jiffies);
> +
> +        match (res as _, crate::current!().signal_pending()) {
> +            (jiffies, true) => CondVarTimeoutResult::Signal { jiffies },
> +            (0, false) => CondVarTimeoutResult::Timeout,
> +            (jiffies, false) => CondVarTimeoutResult::Woken { jiffies },
> +        }
> +    }
> +
>       /// Releases the lock and waits for a notification in interruptible mode.
>       ///
>       /// Atomically releases the given lock (whose ownership is proven by the guard) and puts the
> @@ -177,3 +234,19 @@ pub fn notify_all(&self) {
>           self.notify(0, 0);
>       }
>   }
> +
> +/// The return type of `wait_timeout`.
> +pub enum CondVarTimeoutResult {
> +    /// The timeout was reached.
> +    Timeout,
> +    /// Somebody woke us up.
> +    Woken {
> +        /// Remaining sleep duration.
> +        jiffies: u64,
> +    },
> +    /// A signal occurred.
> +    Signal {
> +        /// Remaining sleep duration.
> +        jiffies: u64,
> +    },
> +}


Is `Signal` and `Woken` only going to hold a single value? Would it be 
best represented as a tuple struct instead, like so?

     pub enum CondVarTimeoutResult {
         /// The timeout was reached.
         Timeout,
         /// Somebody woke us up.
         Woken (u64),
         /// A signal occurred.
         Signal (u64),
     }

Regard,
Tiago.
  
Alice Ryhl Dec. 8, 2023, 7:37 a.m. UTC | #9
On Wed, Dec 6, 2023 at 6:05 PM Tiago Lam <tiagolam@gmail.com> wrote:
>
>
> On 06/12/2023 10:09, Alice Ryhl wrote:
> [...]
> > diff --git a/rust/kernel/sync/condvar.rs b/rust/kernel/sync/condvar.rs
> > index 9861c6749ad0..a6a6b6ab0c39 100644
> > --- a/rust/kernel/sync/condvar.rs
> > +++ b/rust/kernel/sync/condvar.rs
> > @@ -120,6 +120,63 @@ fn wait_internal<T: ?Sized, B: Backend>(&self, wait_state: u32, guard: &mut Guar
> >           unsafe { bindings::finish_wait(self.wait_list.get(), wait.get()) };
> >       }
> >
> > +    /// Atomically releases the given lock (whose ownership is proven by the guard) and puts the
> > +    /// thread to sleep. It wakes up when notified by [`CondVar::notify_one`] or
> > +    /// [`CondVar::notify_all`], or when the thread receives a signal.
> > +    ///
> > +    /// Returns whether there is a signal pending.
> > +    fn wait_internal_timeout<T, B>(
> > +        &self,
> > +        wait_state: u32,
> > +        guard: &mut Guard<'_, T, B>,
> > +        timeout: u64,
> > +    ) -> u64
> > +    where
> > +        T: ?Sized,
> > +        B: Backend,
> > +    {
> > +        let wait = Opaque::<bindings::wait_queue_entry>::uninit();
> > +
> > +        // SAFETY: `wait` points to valid memory.
> > +        unsafe { bindings::init_wait(wait.get()) };
> > +
> > +        // SAFETY: Both `wait` and `wait_list` point to valid memory.
> > +        unsafe {
> > +            bindings::prepare_to_wait_exclusive(self.wait_list.get(), wait.get(), wait_state as _)
> > +        };
> > +
> > +        // SAFETY: Switches to another thread.
> > +        let timeout =
> > +            guard.do_unlocked(|| unsafe { bindings::schedule_timeout(timeout as _) as _ });
>
> It looks like `schedule_timeout()` simply calls `schedule()` when the
> timeout passed is `MAX_SCHEDULE_TIMEOUT`, so `wait_internal_timeout()`
> could be merged together with the already existing `wait_internal()`,
> where `wait_internal()` would always call `schedule_timeout()`? I may be
> missing something, so just wondering why you decided to introduce
> another method.

Ah, nice! I didn't notice that I could combine them.

> > +    /// Releases the lock and waits for a notification in interruptible mode.
> > +    ///
> > +    /// Atomically releases the given lock (whose ownership is proven by the guard) and puts the
> > +    /// thread to sleep. It wakes up when notified by [`CondVar::notify_one`] or
> > +    /// [`CondVar::notify_all`], or when a timeout occurs, or when the thread receives a signal.
> > +    ///
> > +    /// Returns whether there is a signal pending.
> > +    #[must_use = "wait_timeout returns if a signal is pending, so the caller must check the return value"]
> > +    pub fn wait_timeout<T: ?Sized, B: Backend>(
> > +        &self,
> > +        guard: &mut Guard<'_, T, B>,
> > +        jiffies: u64,
> > +    ) -> CondVarTimeoutResult {
>
> Should this be called `wait_timeout_interruptable` instead, so that if
> we need to add one using the `TASK_INTERRUPTIBLE` state later we don't
> need to modfy it again? It also matches the
> `schedule_timeout_interruptible` one in the kernel (although that's not
> a reason to change it just in itself).

I don't mind changing the names, but in this patch I was just
consistent with what was already there.

> > +/// The return type of `wait_timeout`.
> > +pub enum CondVarTimeoutResult {
> > +    /// The timeout was reached.
> > +    Timeout,
> > +    /// Somebody woke us up.
> > +    Woken {
> > +        /// Remaining sleep duration.
> > +        jiffies: u64,
> > +    },
> > +    /// A signal occurred.
> > +    Signal {
> > +        /// Remaining sleep duration.
> > +        jiffies: u64,
> > +    },
> > +}
>
>
> Is `Signal` and `Woken` only going to hold a single value? Would it be
> best represented as a tuple struct instead, like so?
>
>      pub enum CondVarTimeoutResult {
>          /// The timeout was reached.
>          Timeout,
>          /// Somebody woke us up.
>          Woken (u64),
>          /// A signal occurred.
>          Signal (u64),
>      }

I could do that, but I like the explicitly named version as it makes
it clear that the unit is jiffies.

Alice
  
Benno Lossin Dec. 8, 2023, 9:27 a.m. UTC | #10
On 12/8/23 08:37, Alice Ryhl wrote:
> On Wed, Dec 6, 2023 at 6:05 PM Tiago Lam <tiagolam@gmail.com> wrote:
>> On 06/12/2023 10:09, Alice Ryhl wrote:
>>> +/// The return type of `wait_timeout`.
>>> +pub enum CondVarTimeoutResult {
>>> +    /// The timeout was reached.
>>> +    Timeout,
>>> +    /// Somebody woke us up.
>>> +    Woken {
>>> +        /// Remaining sleep duration.
>>> +        jiffies: u64,
>>> +    },
>>> +    /// A signal occurred.
>>> +    Signal {
>>> +        /// Remaining sleep duration.
>>> +        jiffies: u64,
>>> +    },
>>> +}
>>
>> Is `Signal` and `Woken` only going to hold a single value? Would it be
>> best represented as a tuple struct instead, like so?
>>
>>      pub enum CondVarTimeoutResult {
>>          /// The timeout was reached.
>>          Timeout,
>>          /// Somebody woke us up.
>>          Woken (u64),
>>          /// A signal occurred.
>>          Signal (u64),
>>      }
> 
> I could do that, but I like the explicitly named version as it makes
> it clear that the unit is jiffies.

Why not use `type Jiffies = u64;` until we have proper bindings for
them? That way we can have both.
  
Benno Lossin Dec. 8, 2023, 7:04 p.m. UTC | #11
On 12/6/23 11:09, Alice Ryhl wrote:
> +    /// Atomically releases the given lock (whose ownership is proven by the guard) and puts the
> +    /// thread to sleep. It wakes up when notified by [`CondVar::notify_one`] or
> +    /// [`CondVar::notify_all`], or when the thread receives a signal.
> +    ///
> +    /// Returns whether there is a signal pending.
> +    fn wait_internal_timeout<T, B>(
> +        &self,
> +        wait_state: u32,
> +        guard: &mut Guard<'_, T, B>,
> +        timeout: u64,
> +    ) -> u64
> +    where
> +        T: ?Sized,
> +        B: Backend,
> +    {
> +        let wait = Opaque::<bindings::wait_queue_entry>::uninit();
> +
> +        // SAFETY: `wait` points to valid memory.
> +        unsafe { bindings::init_wait(wait.get()) };
> +
> +        // SAFETY: Both `wait` and `wait_list` point to valid memory.
> +        unsafe {
> +            bindings::prepare_to_wait_exclusive(self.wait_list.get(), wait.get(), wait_state as _)

Does `.into()` work here? If for some reason the type here changes, we
probably want to know about it.

> +        };
> +
> +        // SAFETY: Switches to another thread.
> +        let timeout =
> +            guard.do_unlocked(|| unsafe { bindings::schedule_timeout(timeout as _) as _ });

Ditto.
  
Alice Ryhl Dec. 12, 2023, 9:45 a.m. UTC | #12
On Fri, Dec 8, 2023 at 10:27 AM Benno Lossin <benno.lossin@proton.me> wrote:
>
> On 12/8/23 08:37, Alice Ryhl wrote:
> > On Wed, Dec 6, 2023 at 6:05 PM Tiago Lam <tiagolam@gmail.com> wrote:
> >> On 06/12/2023 10:09, Alice Ryhl wrote:
> >>> +/// The return type of `wait_timeout`.
> >>> +pub enum CondVarTimeoutResult {
> >>> +    /// The timeout was reached.
> >>> +    Timeout,
> >>> +    /// Somebody woke us up.
> >>> +    Woken {
> >>> +        /// Remaining sleep duration.
> >>> +        jiffies: u64,
> >>> +    },
> >>> +    /// A signal occurred.
> >>> +    Signal {
> >>> +        /// Remaining sleep duration.
> >>> +        jiffies: u64,
> >>> +    },
> >>> +}
> >>
> >> Is `Signal` and `Woken` only going to hold a single value? Would it be
> >> best represented as a tuple struct instead, like so?
> >>
> >>      pub enum CondVarTimeoutResult {
> >>          /// The timeout was reached.
> >>          Timeout,
> >>          /// Somebody woke us up.
> >>          Woken (u64),
> >>          /// A signal occurred.
> >>          Signal (u64),
> >>      }
> >
> > I could do that, but I like the explicitly named version as it makes
> > it clear that the unit is jiffies.
>
> Why not use `type Jiffies = u64;` until we have proper bindings for
> them? That way we can have both.

I do not mind adding and using a type alias, but I still think the
named fields are better.

Alice
  
Alice Ryhl Dec. 12, 2023, 9:51 a.m. UTC | #13
On Fri, Dec 8, 2023 at 8:04 PM Benno Lossin <benno.lossin@proton.me> wrote:
>
> On 12/6/23 11:09, Alice Ryhl wrote:
> > +    /// Atomically releases the given lock (whose ownership is proven by the guard) and puts the
> > +    /// thread to sleep. It wakes up when notified by [`CondVar::notify_one`] or
> > +    /// [`CondVar::notify_all`], or when the thread receives a signal.
> > +    ///
> > +    /// Returns whether there is a signal pending.
> > +    fn wait_internal_timeout<T, B>(
> > +        &self,
> > +        wait_state: u32,
> > +        guard: &mut Guard<'_, T, B>,
> > +        timeout: u64,
> > +    ) -> u64
> > +    where
> > +        T: ?Sized,
> > +        B: Backend,
> > +    {
> > +        let wait = Opaque::<bindings::wait_queue_entry>::uninit();
> > +
> > +        // SAFETY: `wait` points to valid memory.
> > +        unsafe { bindings::init_wait(wait.get()) };
> > +
> > +        // SAFETY: Both `wait` and `wait_list` point to valid memory.
> > +        unsafe {
> > +            bindings::prepare_to_wait_exclusive(self.wait_list.get(), wait.get(), wait_state as _)
>
> Does `.into()` work here? If for some reason the type here changes, we
> probably want to know about it.

I think we may be able to eliminate this cast by using c_int for the
integer type.

> > +        };
> > +
> > +        // SAFETY: Switches to another thread.
> > +        let timeout =
> > +            guard.do_unlocked(|| unsafe { bindings::schedule_timeout(timeout as _) as _ });
>
> Ditto.

Here, we're casting u64->long and then long->u64. How about this?

u64->long - Use timeout.try_into().unwrap_or(MAX_SCHEDULE_TIMEOUT),
since MAX_SCHEDULE_TIMEOUT is LONG_MAX.

long->u64 - This value is guaranteed to be less than the argument
passed to schedule_timeout. Use .into() for infallible cast.

Alice
  
Benno Lossin Dec. 12, 2023, 5:05 p.m. UTC | #14
On 12/12/23 10:51, Alice Ryhl wrote:
> On Fri, Dec 8, 2023 at 8:04 PM Benno Lossin <benno.lossin@proton.me> wrote:
>>
>> On 12/6/23 11:09, Alice Ryhl wrote:
>>> +    /// Atomically releases the given lock (whose ownership is proven by the guard) and puts the
>>> +    /// thread to sleep. It wakes up when notified by [`CondVar::notify_one`] or
>>> +    /// [`CondVar::notify_all`], or when the thread receives a signal.
>>> +    ///
>>> +    /// Returns whether there is a signal pending.
>>> +    fn wait_internal_timeout<T, B>(
>>> +        &self,
>>> +        wait_state: u32,
>>> +        guard: &mut Guard<'_, T, B>,
>>> +        timeout: u64,
>>> +    ) -> u64
>>> +    where
>>> +        T: ?Sized,
>>> +        B: Backend,
>>> +    {
>>> +        let wait = Opaque::<bindings::wait_queue_entry>::uninit();
>>> +
>>> +        // SAFETY: `wait` points to valid memory.
>>> +        unsafe { bindings::init_wait(wait.get()) };
>>> +
>>> +        // SAFETY: Both `wait` and `wait_list` point to valid memory.
>>> +        unsafe {
>>> +            bindings::prepare_to_wait_exclusive(self.wait_list.get(), wait.get(), wait_state as _)
>>
>> Does `.into()` work here? If for some reason the type here changes, we
>> probably want to know about it.
> 
> I think we may be able to eliminate this cast by using c_int for the
> integer type.

Sounds good.

>>> +        };
>>> +
>>> +        // SAFETY: Switches to another thread.
>>> +        let timeout =
>>> +            guard.do_unlocked(|| unsafe { bindings::schedule_timeout(timeout as _) as _ });
>>
>> Ditto.
> 
> Here, we're casting u64->long and then long->u64. How about this?
> 
> u64->long - Use timeout.try_into().unwrap_or(MAX_SCHEDULE_TIMEOUT),
> since MAX_SCHEDULE_TIMEOUT is LONG_MAX.
> 
> long->u64 - This value is guaranteed to be less than the argument
> passed to schedule_timeout. Use .into() for infallible cast.

Also sounds good :)
  
Boqun Feng Dec. 14, 2023, 7:58 p.m. UTC | #15
On Fri, Dec 08, 2023 at 08:37:27AM +0100, Alice Ryhl wrote:
[...]
> > > +    /// Releases the lock and waits for a notification in interruptible mode.
> > > +    ///
> > > +    /// Atomically releases the given lock (whose ownership is proven by the guard) and puts the
> > > +    /// thread to sleep. It wakes up when notified by [`CondVar::notify_one`] or
> > > +    /// [`CondVar::notify_all`], or when a timeout occurs, or when the thread receives a signal.
> > > +    ///
> > > +    /// Returns whether there is a signal pending.
> > > +    #[must_use = "wait_timeout returns if a signal is pending, so the caller must check the return value"]
> > > +    pub fn wait_timeout<T: ?Sized, B: Backend>(
> > > +        &self,
> > > +        guard: &mut Guard<'_, T, B>,
> > > +        jiffies: u64,
> > > +    ) -> CondVarTimeoutResult {
> >
> > Should this be called `wait_timeout_interruptable` instead, so that if
> > we need to add one using the `TASK_INTERRUPTIBLE` state later we don't
> > need to modfy it again? It also matches the
> > `schedule_timeout_interruptible` one in the kernel (although that's not
> > a reason to change it just in itself).
> 
> I don't mind changing the names, but in this patch I was just
> consistent with what was already there.
> 

Hmm.. so Rust's wait() is actually interruptible wait and we have
wait_uninterruptible(), while C API is wait_event() is uninterruptible,
and we have a wait_event_interruptible(), I think it makes sense we
follow what C API has. Will send a patch soon.

Regards,
Boqun

[...]
  

Patch

diff --git a/rust/kernel/sync.rs b/rust/kernel/sync.rs
index d219ee518eff..c1fb10fc64f4 100644
--- a/rust/kernel/sync.rs
+++ b/rust/kernel/sync.rs
@@ -13,7 +13,7 @@ 
 mod locked_by;
 
 pub use arc::{Arc, ArcBorrow, UniqueArc};
-pub use condvar::CondVar;
+pub use condvar::{CondVar, CondVarTimeoutResult};
 pub use lock::{mutex::Mutex, spinlock::SpinLock};
 pub use locked_by::LockedBy;
 
diff --git a/rust/kernel/sync/condvar.rs b/rust/kernel/sync/condvar.rs
index 9861c6749ad0..a6a6b6ab0c39 100644
--- a/rust/kernel/sync/condvar.rs
+++ b/rust/kernel/sync/condvar.rs
@@ -120,6 +120,63 @@  fn wait_internal<T: ?Sized, B: Backend>(&self, wait_state: u32, guard: &mut Guar
         unsafe { bindings::finish_wait(self.wait_list.get(), wait.get()) };
     }
 
+    /// Atomically releases the given lock (whose ownership is proven by the guard) and puts the
+    /// thread to sleep. It wakes up when notified by [`CondVar::notify_one`] or
+    /// [`CondVar::notify_all`], or when the thread receives a signal.
+    ///
+    /// Returns whether there is a signal pending.
+    fn wait_internal_timeout<T, B>(
+        &self,
+        wait_state: u32,
+        guard: &mut Guard<'_, T, B>,
+        timeout: u64,
+    ) -> u64
+    where
+        T: ?Sized,
+        B: Backend,
+    {
+        let wait = Opaque::<bindings::wait_queue_entry>::uninit();
+
+        // SAFETY: `wait` points to valid memory.
+        unsafe { bindings::init_wait(wait.get()) };
+
+        // SAFETY: Both `wait` and `wait_list` point to valid memory.
+        unsafe {
+            bindings::prepare_to_wait_exclusive(self.wait_list.get(), wait.get(), wait_state as _)
+        };
+
+        // SAFETY: Switches to another thread.
+        let timeout =
+            guard.do_unlocked(|| unsafe { bindings::schedule_timeout(timeout as _) as _ });
+
+        // SAFETY: Both `wait` and `wait_list` point to valid memory.
+        unsafe { bindings::finish_wait(self.wait_list.get(), wait.get()) };
+
+        timeout
+    }
+
+    /// Releases the lock and waits for a notification in interruptible mode.
+    ///
+    /// Atomically releases the given lock (whose ownership is proven by the guard) and puts the
+    /// thread to sleep. It wakes up when notified by [`CondVar::notify_one`] or
+    /// [`CondVar::notify_all`], or when a timeout occurs, or when the thread receives a signal.
+    ///
+    /// Returns whether there is a signal pending.
+    #[must_use = "wait_timeout returns if a signal is pending, so the caller must check the return value"]
+    pub fn wait_timeout<T: ?Sized, B: Backend>(
+        &self,
+        guard: &mut Guard<'_, T, B>,
+        jiffies: u64,
+    ) -> CondVarTimeoutResult {
+        let res = self.wait_internal_timeout(bindings::TASK_INTERRUPTIBLE, guard, jiffies);
+
+        match (res as _, crate::current!().signal_pending()) {
+            (jiffies, true) => CondVarTimeoutResult::Signal { jiffies },
+            (0, false) => CondVarTimeoutResult::Timeout,
+            (jiffies, false) => CondVarTimeoutResult::Woken { jiffies },
+        }
+    }
+
     /// Releases the lock and waits for a notification in interruptible mode.
     ///
     /// Atomically releases the given lock (whose ownership is proven by the guard) and puts the
@@ -177,3 +234,19 @@  pub fn notify_all(&self) {
         self.notify(0, 0);
     }
 }
+
+/// The return type of `wait_timeout`.
+pub enum CondVarTimeoutResult {
+    /// The timeout was reached.
+    Timeout,
+    /// Somebody woke us up.
+    Woken {
+        /// Remaining sleep duration.
+        jiffies: u64,
+    },
+    /// A signal occurred.
+    Signal {
+        /// Remaining sleep duration.
+        jiffies: u64,
+    },
+}
diff --git a/rust/kernel/sync/lock.rs b/rust/kernel/sync/lock.rs
index f12a684bc957..149a5259d431 100644
--- a/rust/kernel/sync/lock.rs
+++ b/rust/kernel/sync/lock.rs
@@ -139,7 +139,7 @@  pub struct Guard<'a, T: ?Sized, B: Backend> {
 unsafe impl<T: Sync + ?Sized, B: Backend> Sync for Guard<'_, T, B> {}
 
 impl<T: ?Sized, B: Backend> Guard<'_, T, B> {
-    pub(crate) fn do_unlocked(&mut self, cb: impl FnOnce()) {
+    pub(crate) fn do_unlocked<U>(&mut self, cb: impl FnOnce() -> U) -> U {
         // SAFETY: The caller owns the lock, so it is safe to unlock it.
         unsafe { B::unlock(self.lock.state.get(), &self.state) };
 
@@ -147,7 +147,7 @@  pub(crate) fn do_unlocked(&mut self, cb: impl FnOnce()) {
         let _relock =
             ScopeGuard::new(|| unsafe { B::relock(self.lock.state.get(), &mut self.state) });
 
-        cb();
+        cb()
     }
 }