From: Boqun Feng <boqun.feng@gmail.com>
To: Alice Ryhl <aliceryhl@google.com>
Cc: "Miguel Ojeda" <ojeda@kernel.org>,
"Alex Gaynor" <alex.gaynor@gmail.com>,
"Wedson Almeida Filho" <wedsonaf@gmail.com>,
"Gary Guo" <gary@garyguo.net>,
"Björn Roy Baron" <bjorn3_gh@protonmail.com>,
"Benno Lossin" <benno.lossin@proton.me>,
"Andreas Hindborg" <a.hindborg@samsung.com>,
"Peter Zijlstra" <peterz@infradead.org>,
"Ingo Molnar" <mingo@redhat.com>, "Will Deacon" <will@kernel.org>,
"Waiman Long" <longman@redhat.com>,
"Tiago Lam" <tiagolam@gmail.com>,
"Thomas Gleixner" <tglx@linutronix.de>,
"Martin Rodriguez Reboredo" <yakoyoku@gmail.com>,
rust-for-linux@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 3/4] rust: sync: add `CondVar::wait_timeout`
Date: Thu, 4 Jan 2024 14:18:42 -0800 [thread overview]
Message-ID: <ZZcuwkBsvSs6bzXF@boqun-archlinux> (raw)
In-Reply-To: <20240104-rb-new-condvar-methods-v3-3-70b514fcbe52@google.com>
On Thu, Jan 04, 2024 at 02:02:43PM +0000, 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.
>
> Reviewed-by: Martin Rodriguez Reboredo <yakoyoku@gmail.com>
> Reviewed-by: Tiago Lam <tiagolam@gmail.com>
> Signed-off-by: Alice Ryhl <aliceryhl@google.com>
Reviewed-by: Boqun Feng <boqun.feng@gmail.com>
That said, I want to hear from Thomas on the usage of jiffies, see
below:
> ---
[...]
> - fn wait_internal<T: ?Sized, B: Backend>(&self, wait_state: u32, guard: &mut Guard<'_, T, B>) {
> + fn wait_internal<T: ?Sized, B: Backend>(
> + &self,
> + wait_state: u32,
> + guard: &mut Guard<'_, T, B>,
> + timeout_in_jiffies: c_long,
This is an internal function, and it makes sense we use the same type
for durations as the C function we rely on.
> + ) -> c_long {
> let wait = Opaque::<bindings::wait_queue_entry>::uninit();
>
> // SAFETY: `wait` points to valid memory.
> @@ -113,11 +122,13 @@ fn wait_internal<T: ?Sized, B: Backend>(&self, wait_state: u32, guard: &mut Guar
> bindings::prepare_to_wait_exclusive(self.wait_list.get(), wait.get(), wait_state as _)
> };
>
> - // SAFETY: No arguments, switches to another thread.
> - guard.do_unlocked(|| unsafe { bindings::schedule() });
> + // SAFETY: Switches to another thread. The timeout can be any number.
> + let ret = guard.do_unlocked(|| unsafe { bindings::schedule_timeout(timeout_in_jiffies) });
>
> // SAFETY: Both `wait` and `wait_list` point to valid memory.
> unsafe { bindings::finish_wait(self.wait_list.get(), wait.get()) };
> +
> + ret
> }
>
[...]
> + /// 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.
> + #[must_use = "wait_interruptible_timeout returns if a signal is pending, so the caller must check the return value"]
> + pub fn wait_interruptible_timeout<T: ?Sized, B: Backend>(
> + &self,
> + guard: &mut Guard<'_, T, B>,
> + jiffies: Jiffies,
This is a public interface, so it may make sense use a HZ-independent
type for durations, e.g. core::time::Duration:
https://doc.rust-lang.org/core/time/struct.Duration.html
but we don't have enough users to see whether there would be a need for
HZ-dependent durations, so I think it's fine that we stick with a simple
solution in Alice's patchset to get the ball rolling, we can always
remove a public interface with HZ-dependent durations whenever we want.
Thoughts?
Regards,
Boqun
> + ) -> CondVarTimeoutResult {
> + let jiffies = jiffies.try_into().unwrap_or(MAX_SCHEDULE_TIMEOUT);
> + let res = self.wait_internal(bindings::TASK_INTERRUPTIBLE, guard, jiffies);
> +
> + match (res as Jiffies, crate::current!().signal_pending()) {
> + (jiffies, true) => CondVarTimeoutResult::Signal { jiffies },
> + (0, false) => CondVarTimeoutResult::Timeout,
> + (jiffies, false) => CondVarTimeoutResult::Woken { jiffies },
> + }
> + }
> +
[...]
> +
> +/// The return type of `wait_timeout`.
> +pub enum CondVarTimeoutResult {
> + /// The timeout was reached.
> + Timeout,
> + /// Somebody woke us up.
> + Woken {
> + /// Remaining sleep duration.
> + jiffies: Jiffies,
> + },
> + /// A signal occurred.
> + Signal {
> + /// Remaining sleep duration.
> + jiffies: Jiffies,
> + },
> +}
> 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()
> }
> }
>
> diff --git a/rust/kernel/task.rs b/rust/kernel/task.rs
> index 9451932d5d86..ffb4a51eb898 100644
> --- a/rust/kernel/task.rs
> +++ b/rust/kernel/task.rs
> @@ -7,6 +7,9 @@
> use crate::{bindings, types::Opaque};
> use core::{marker::PhantomData, ops::Deref, ptr};
>
> +/// A sentinal value used for infinite timeouts.
> +pub const MAX_SCHEDULE_TIMEOUT: c_long = c_long::MAX;
> +
> /// Returns the currently running task.
> #[macro_export]
> macro_rules! current {
>
> --
> 2.43.0.472.g3155946c3a-goog
>
next prev parent reply other threads:[~2024-01-04 22:19 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-04 14:02 [PATCH v3 0/4] Additional CondVar methods needed by Rust Binder Alice Ryhl
2024-01-04 14:02 ` [PATCH v3 1/4] rust: sync: add `CondVar::notify_sync` Alice Ryhl
2024-01-04 18:56 ` Boqun Feng
2024-01-04 14:02 ` [PATCH v3 2/4] rust: time: add msecs to jiffies conversion Alice Ryhl
2024-01-04 14:02 ` [PATCH v3 3/4] rust: sync: add `CondVar::wait_timeout` Alice Ryhl
2024-01-04 22:18 ` Boqun Feng [this message]
2024-01-05 10:30 ` Alice Ryhl
2024-01-04 22:44 ` Boqun Feng
2024-01-04 14:02 ` [PATCH v3 4/4] rust: sync: update integer types in CondVar Alice Ryhl
2024-01-04 14:19 ` Martin Rodriguez Reboredo
2024-01-04 22:47 ` Boqun Feng
2024-01-05 9:44 ` Alice Ryhl
2024-01-04 14:17 ` [PATCH v3 0/4] Additional CondVar methods needed by Rust Binder Alice Ryhl
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=ZZcuwkBsvSs6bzXF@boqun-archlinux \
--to=boqun.feng@gmail.com \
--cc=a.hindborg@samsung.com \
--cc=alex.gaynor@gmail.com \
--cc=aliceryhl@google.com \
--cc=benno.lossin@proton.me \
--cc=bjorn3_gh@protonmail.com \
--cc=gary@garyguo.net \
--cc=linux-kernel@vger.kernel.org \
--cc=longman@redhat.com \
--cc=mingo@redhat.com \
--cc=ojeda@kernel.org \
--cc=peterz@infradead.org \
--cc=rust-for-linux@vger.kernel.org \
--cc=tglx@linutronix.de \
--cc=tiagolam@gmail.com \
--cc=wedsonaf@gmail.com \
--cc=will@kernel.org \
--cc=yakoyoku@gmail.com \
/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 NNTP newsgroup(s).