| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <Z6mX_29mUYcX0CFS@Mac.home>
Date: Sun, 9 Feb 2025 22:09:03 -0800
From: Boqun Feng <boqun.feng@...il.com>
To: Alice Ryhl <aliceryhl@...gle.com>
Cc: Miguel Ojeda <ojeda@...nel.org>, Gary Guo <gary@...yguo.net>,
Björn Roy Baron <bjorn3_gh@...tonmail.com>,
Benno Lossin <benno.lossin@...ton.me>,
Andreas Hindborg <a.hindborg@...nel.org>,
Trevor Gross <tmgross@...ch.edu>,
Peter Zijlstra <peterz@...radead.org>,
Ingo Molnar <mingo@...hat.com>, Will Deacon <will@...nel.org>,
Waiman Long <longman@...hat.com>, rust-for-linux@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] rust: sync: add wait_interruptible_freezable
Hi,
On Tue, Feb 04, 2025 at 01:43:25PM +0000, Alice Ryhl wrote:
> Binder allows you to freeze a process where some of its threads are
> blocked on the Binder driver. To make this work, we need to pass
> TASK_FREEZABLE when going to sleep in the appropriate places. Thus, add
> a new method wait_interruptible_freezable for the condition variable so
> that sleeps where this is supported can be marked as such.
>
> Signed-off-by: Alice Ryhl <aliceryhl@...gle.com>
> ---
> Changes in v2:
> - Document that you must not hold locks when you call the method.
> - Link to v1: https://lore.kernel.org/r/20250130-condvar-freeze-v1-1-a91d5661d505@google.com
> ---
> rust/kernel/sync/condvar.rs | 23 ++++++++++++++++++++++-
> rust/kernel/task.rs | 2 ++
> 2 files changed, 24 insertions(+), 1 deletion(-)
>
> diff --git a/rust/kernel/sync/condvar.rs b/rust/kernel/sync/condvar.rs
> index 7df565038d7d..1859e011e322 100644
> --- a/rust/kernel/sync/condvar.rs
> +++ b/rust/kernel/sync/condvar.rs
> @@ -11,7 +11,9 @@
> init::PinInit,
> pin_init,
> str::CStr,
> - task::{MAX_SCHEDULE_TIMEOUT, TASK_INTERRUPTIBLE, TASK_NORMAL, TASK_UNINTERRUPTIBLE},
> + task::{
> + MAX_SCHEDULE_TIMEOUT, TASK_FREEZABLE, TASK_INTERRUPTIBLE, TASK_NORMAL, TASK_UNINTERRUPTIBLE,
> + },
> time::Jiffies,
> types::Opaque,
> };
> @@ -159,6 +161,25 @@ pub fn wait_interruptible<T: ?Sized, B: Backend>(&self, guard: &mut Guard<'_, T,
> crate::current!().signal_pending()
> }
>
> + /// Releases the lock and waits for a notification in interruptible and freezable mode.
> + ///
> + /// The process is allowed to be frozen during this sleep. You must not hold any locks while
> + /// this operation is ongoing, and there is a lockdep assertion for this. Freezing a task that
> + /// holds a lock can trivially deadlock vs another task that needs that lock to complete before
> + /// it too can hit freezable.
> + #[must_use = "wait returns if a signal is pending, so the caller must check the return value"]
> + pub fn wait_interruptible_freezable<T: ?Sized, B: Backend>(
> + &self,
> + guard: &mut Guard<'_, T, B>,
> + ) -> bool {
> + self.wait_internal(
> + TASK_INTERRUPTIBLE | TASK_FREEZABLE,
> + guard,
> + MAX_SCHEDULE_TIMEOUT,
> + );
> + crate::current!().signal_pending()
> + }
> +
> /// 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
> diff --git a/rust/kernel/task.rs b/rust/kernel/task.rs
> index 07bc22a7645c..ea43a3b8d9c5 100644
> --- a/rust/kernel/task.rs
> +++ b/rust/kernel/task.rs
> @@ -23,6 +23,8 @@
> pub const TASK_INTERRUPTIBLE: c_int = bindings::TASK_INTERRUPTIBLE as c_int;
> /// Bitmask for tasks that are sleeping in an uninterruptible state.
> pub const TASK_UNINTERRUPTIBLE: c_int = bindings::TASK_UNINTERRUPTIBLE as c_int;
> +/// Bitmask for tasks that are sleeping in a freezable state.
> +pub const TASK_FREEZABLE: c_int = bindings::TASK_FREEZABLE as c_int;
> /// Convenience constant for waking up tasks regardless of whether they are in interruptible or
> /// uninterruptible sleep.
> pub const TASK_NORMAL: c_uint = bindings::TASK_NORMAL as c_uint;
>
> ---
> base-commit: 2014c95afecee3e76ca4a56956a936e23283f05b
> change-id: 20250130-condvar-freeze-f2ea5b308405
>
> Best regards,
> --
> Alice Ryhl <aliceryhl@...gle.com>
>
I queued this in my locking branch for upcoming PR to tip tree, since
it's relatively small and it belongs to the scope of tip, if all goes
well, it'll be in 6.15. I did some commit log changes while I'm at it,
please see below. Thanks.
Regards,
Boqun
------------->8
Subject: [PATCH] rust: sync: condvar: Add wait_interruptible_freezable()
To support waiting for a `CondVar` as a freezable process, add a
wait_interruptible_freezable() function.
Binder needs this function in the appropriate places to freeze a process
where some of its threads are blocked on the Binder driver.
[Boqun: Capitalize the title and reword the commit log]
Signed-off-by: Alice Ryhl <aliceryhl@...gle.com>
Signed-off-by: Boqun Feng <boqun.feng@...il.com>
Link: https://lore.kernel.org/r/20250204-condvar-freeze-v2-1-804483096260@google.com
---
rust/kernel/sync/condvar.rs | 23 ++++++++++++++++++++++-
rust/kernel/task.rs | 2 ++
2 files changed, 24 insertions(+), 1 deletion(-)
diff --git a/rust/kernel/sync/condvar.rs b/rust/kernel/sync/condvar.rs
index 7df565038d7d..1859e011e322 100644
--- a/rust/kernel/sync/condvar.rs
+++ b/rust/kernel/sync/condvar.rs
@@ -11,7 +11,9 @@
init::PinInit,
pin_init,
str::CStr,
- task::{MAX_SCHEDULE_TIMEOUT, TASK_INTERRUPTIBLE, TASK_NORMAL, TASK_UNINTERRUPTIBLE},
+ task::{
+ MAX_SCHEDULE_TIMEOUT, TASK_FREEZABLE, TASK_INTERRUPTIBLE, TASK_NORMAL, TASK_UNINTERRUPTIBLE,
+ },
time::Jiffies,
types::Opaque,
};
@@ -159,6 +161,25 @@ pub fn wait_interruptible<T: ?Sized, B: Backend>(&self, guard: &mut Guard<'_, T,
crate::current!().signal_pending()
}
+ /// Releases the lock and waits for a notification in interruptible and freezable mode.
+ ///
+ /// The process is allowed to be frozen during this sleep. You must not hold any locks while
+ /// this operation is ongoing, and there is a lockdep assertion for this. Freezing a task that
+ /// holds a lock can trivially deadlock vs another task that needs that lock to complete before
+ /// it too can hit freezable.
+ #[must_use = "wait returns if a signal is pending, so the caller must check the return value"]
+ pub fn wait_interruptible_freezable<T: ?Sized, B: Backend>(
+ &self,
+ guard: &mut Guard<'_, T, B>,
+ ) -> bool {
+ self.wait_internal(
+ TASK_INTERRUPTIBLE | TASK_FREEZABLE,
+ guard,
+ MAX_SCHEDULE_TIMEOUT,
+ );
+ crate::current!().signal_pending()
+ }
+
/// 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
diff --git a/rust/kernel/task.rs b/rust/kernel/task.rs
index 07bc22a7645c..ea43a3b8d9c5 100644
--- a/rust/kernel/task.rs
+++ b/rust/kernel/task.rs
@@ -23,6 +23,8 @@
pub const TASK_INTERRUPTIBLE: c_int = bindings::TASK_INTERRUPTIBLE as c_int;
/// Bitmask for tasks that are sleeping in an uninterruptible state.
pub const TASK_UNINTERRUPTIBLE: c_int = bindings::TASK_UNINTERRUPTIBLE as c_int;
+/// Bitmask for tasks that are sleeping in a freezable state.
+pub const TASK_FREEZABLE: c_int = bindings::TASK_FREEZABLE as c_int;
/// Convenience constant for waking up tasks regardless of whether they are in interruptible or
/// uninterruptible sleep.
pub const TASK_NORMAL: c_uint = bindings::TASK_NORMAL as c_uint;
--
Powered by blists - more mailing lists