Received: by 2002:a05:6358:11c7:b0:104:8066:f915 with SMTP id i7csp792785rwl; Wed, 12 Apr 2023 04:19:38 -0700 (PDT) X-Google-Smtp-Source: AKy350bs4aAHHTVsBS/g34ssKDhr0dIPgFrUJ+w7b5llMX7Jpec0xkFYlNxCF/V6iUUj1ccu1Onh X-Received: by 2002:a17:906:a20b:b0:94e:3d6f:9c0f with SMTP id r11-20020a170906a20b00b0094e3d6f9c0fmr2043190ejy.55.1681298377944; Wed, 12 Apr 2023 04:19:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1681298377; cv=none; d=google.com; s=arc-20160816; b=S+9MdK4eVvyxdB3dTBBQkoYSGhKDxl5cjKTF/+K4jB/F0uuz+mqsTIRvvqG/hLiJ2H /tpS3jicLaYpg7cDNsr2t96uoMIwTU0VnrgA/0mCan8jdN1SKumf6bYy7wyhFInMc2/4 kxifJws6vmSAfqkkY5LQNW4ryiJS+ZMo/G8XMx9guqq3S8QJKUe7BxOfxttXMx6QU4f7 QQ8SzDq9p/7aP4Y2gw1vyQbe/ZRtsUiVe8cc4Ny9TS5QSTMP4cbZhLk2gzNL1zBnN/G+ oanAkrVZHC0bJ3d6oFLQhHEzZVcIBv9537OSx8jk4r8Ccyg0AWlHyYJXGGl60lAhOETM JLQQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=C9vgeMqqjwy92KIDibUs2lkkbVvQINAuG9wgc3eeu+E=; b=OyJrwAK6thXWuOKCCMR0Jo2An3Q7Ckz/WbVXdzFiZpmSHlsdXpatabbw8s1HAMW+T3 hUwKfPQyFnPLAq145qEuUtrhgzRSwNdA/izQ+eDl2Pqve1IF2X4yhcAOqMAuFl8Hvofo HeAT5F+UhLOrsMh7cnDpNhMK/P8+ija1NTElFy0c6nliFH4EbZ+bWXW4jOZbcKcZnD5G FDYlJeG0fA6h29TPI64321AtlfUOWKY+OArKArJkiS6Vfbc0Dsletz3MOPOGVxJhk3nV NLKXbpSUIdYLfBmymJ1hR8pDPqEYm0PTvZ875b1n05qvZIw+2dCEGsb+QibpWNw4twbR ZtIQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20221208 header.b=YugBswhP; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id t9-20020a1709061be900b00939ad2676ffsi12233420ejg.762.2023.04.12.04.19.12; Wed, 12 Apr 2023 04:19:37 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20221208 header.b=YugBswhP; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230250AbjDLLSG (ORCPT + 99 others); Wed, 12 Apr 2023 07:18:06 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41890 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230256AbjDLLR4 (ORCPT ); Wed, 12 Apr 2023 07:17:56 -0400 Received: from mail-yb1-xb29.google.com (mail-yb1-xb29.google.com [IPv6:2607:f8b0:4864:20::b29]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 877066EA5; Wed, 12 Apr 2023 04:17:35 -0700 (PDT) Received: by mail-yb1-xb29.google.com with SMTP id e127so11251716ybf.8; Wed, 12 Apr 2023 04:17:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1681298205; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=C9vgeMqqjwy92KIDibUs2lkkbVvQINAuG9wgc3eeu+E=; b=YugBswhPW+UhUWOJGhp/3WcZfP2rk1uY6rRxt7D9a45ZGQi7bmJwVshblR38ZWSTDH 23IewvaIooujWdTVmhuNFhegCozkDECYBPgvRVChB8msUVI2SNVgrjIH7lYnlOZYMohJ Pgv9jvUJ5kmmdfZf6nXgVV3aLtUk+TfVIDQtgThI6UyIuFbbtKleLyRh7+Nsf78yem0J pkUqD8mx7kBIRxzJHncZ1nqcswhDiiCjKqqOykPVV0PacTIAh7A2XPyC4YfLVvVbKaDS KsYEWmD7m0tclgJ8bDmrrrnm/ukRg7yjFngUYgI8HK5JBmsz1XWk1UBlY9imNPMgsaVG FLBA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1681298205; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=C9vgeMqqjwy92KIDibUs2lkkbVvQINAuG9wgc3eeu+E=; b=2X6RFWcfyPIu1yI7MFoPxifrEiJe+GXNs3E4kqs4TkW/k/zBMedCzzoW5w9/3X+08i BTHXyKwa+2f0CxIvZabwAZBlnBpkGvdQCkJHk8y8rSzF0aLbOMLFnWi3HDpX1HFr2bsJ UNdZkDxLU3gCdDD2BGQpgZVVuPZJDEn81roLljtB+te6BKz1o7wYLdHJ/o1CA8bElEmY OrFmi9mLt9+JKBjYowPjLKd7iNDck1cQc+sD15sCIb4510CI26cHiTi6uTt/7eR7qoYO 6ThXCxF1xPAzEaF3Urgn8xeQET5z0HYF8BHJtWQz2nBagyta+nV2GSRoVy3w13d878Le CYMg== X-Gm-Message-State: AAQBX9fmBDq1LbncWk46wn7p69pbdppwYi/FFBCu0e+nydt0TYqdR30J t8o0DvuXalN4lYy6VNkA+GFpspaVk1/me3duEnA= X-Received: by 2002:a25:7390:0:b0:b6e:d788:eba4 with SMTP id o138-20020a257390000000b00b6ed788eba4mr8849797ybc.6.1681298204957; Wed, 12 Apr 2023 04:16:44 -0700 (PDT) MIME-Version: 1.0 References: <20230411054543.21278-1-wedsonaf@gmail.com> <20230411054543.21278-11-wedsonaf@gmail.com> <20230411215413.7720246f.gary@garyguo.net> In-Reply-To: <20230411215413.7720246f.gary@garyguo.net> From: Wedson Almeida Filho Date: Wed, 12 Apr 2023 08:16:34 -0300 Message-ID: Subject: Re: [PATCH v4 11/13] rust: lock: add `Guard::do_unlocked` To: Gary Guo Cc: rust-for-linux@vger.kernel.org, Miguel Ojeda , Alex Gaynor , Boqun Feng , =?UTF-8?Q?Bj=C3=B6rn_Roy_Baron?= , linux-kernel@vger.kernel.org, Wedson Almeida Filho , Martin Rodriguez Reboredo Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 11 Apr 2023 at 17:54, Gary Guo wrote: > > On Tue, 11 Apr 2023 02:45:41 -0300 > Wedson Almeida Filho wrote: > > > From: Wedson Almeida Filho > > > > It releases the lock, executes some function provided by the caller, > > then reacquires the lock. This is preparation for the implementation of > > condvars, which will sleep after between unlocking and relocking. > > > > We need an explicit `relock` method for primitives like `SpinLock` that > > have an irqsave variant: we use the guard state to determine if the lock > > was originally acquired with the regular `lock` function or > > `lock_irqsave`. > > > > Reviewed-by: Martin Rodriguez Reboredo > > Signed-off-by: Wedson Almeida Filho > > --- > > v1 -> v2: No changes > > v2 -> v3: No changes > > v3 -> v4: No changes > > > > rust/kernel/sync/lock.rs | 25 +++++++++++++++++++++++++ > > rust/kernel/sync/lock/spinlock.rs | 17 +++++++++++++++-- > > 2 files changed, 40 insertions(+), 2 deletions(-) > > > > diff --git a/rust/kernel/sync/lock.rs b/rust/kernel/sync/lock.rs > > index 819b8ea5ba2b..cde57756795f 100644 > > --- a/rust/kernel/sync/lock.rs > > +++ b/rust/kernel/sync/lock.rs > > @@ -22,6 +22,9 @@ pub mod spinlock; > > /// > > /// - Implementers must ensure that only one thread/CPU may access the protected data once the lock > > /// is owned, that is, between calls to `lock` and `unlock`. > > +/// - Implementers must also ensure that `relock` uses the same locking method as the original > > +/// lock operation. For example, it should disable interrupts if [`IrqSaveBackend::lock_irqsave`] > > +/// is used. > > pub unsafe trait Backend { > > /// The state required by the lock. > > type State; > > @@ -55,6 +58,17 @@ pub unsafe trait Backend { > > /// > > /// It must only be called by the current owner of the lock. > > unsafe fn unlock(ptr: *mut Self::State, guard_state: &Self::GuardState); > > + > > + /// Reacquires the lock, making the caller its owner. > > + /// > > + /// # Safety > > + /// > > + /// Callers must ensure that `state` comes from a previous call to [`Backend::lock`] (or > > + /// variant) that has been unlocked with [`Backend::unlock`] and will be relocked now. > > + unsafe fn relock(ptr: *mut Self::State, guard_state: &mut Self::GuardState) { > > + // SAFETY: The safety requirements ensure that the lock is initialised. > > + *guard_state = unsafe { Self::lock(ptr) }; > > + } > > } > > > > /// The "backend" of a lock that supports the irq-save variant. > > @@ -164,6 +178,17 @@ pub struct Guard<'a, T: ?Sized, B: Backend> { > > // SAFETY: `Guard` is sync when the data protected by the lock is also sync. > > unsafe impl Sync for Guard<'_, T, B> {} > > > > +impl Guard<'_, T, B> { > > + #[allow(dead_code)] > > + pub(crate) fn do_unlocked(&mut self, cb: impl FnOnce()) { > > + // SAFETY: The caller owns the lock, so it is safe to unlock it. > > + unsafe { B::unlock(self.lock.state.get(), &self.state) }; > > + cb(); > > + // SAFETY: The lock was just unlocked above and is being relocked now. > > + unsafe { B::relock(self.lock.state.get(), &mut self.state) }; > > This should be > > let _guard = ScopeGuard::new(|| unsafe { > B::relock(self.lock.state.get(), &mut self.state) } > }); > cb(); > > Although we currently use `-Cpanic=abort`, I think as a general rule we > should still try to make code unwind-safe, so it can remain sound if > someone takes the code and use it for userspace (e.g. for testing > purpose, or maybe sharing codebase with tools). Good point. Although this has not been something we cared about in the last couple of years because we abort, I think we should carefully review code for this as we upstream. It is also important for async scenarios: we need to go back to a consistent state when we tear down `Future` instances. > > + } > > +} > > + > > impl core::ops::Deref for Guard<'_, T, B> { > > type Target = T; > > > > diff --git a/rust/kernel/sync/lock/spinlock.rs b/rust/kernel/sync/lock/spinlock.rs > > index 34dec09a97c0..e2a2f68e6d93 100644 > > --- a/rust/kernel/sync/lock/spinlock.rs > > +++ b/rust/kernel/sync/lock/spinlock.rs > > @@ -4,6 +4,7 @@ > > //! > > //! This module allows Rust code to use the kernel's `spinlock_t`. > > > > +use super::IrqSaveBackend; > > use crate::bindings; > > > > /// Creates a [`SpinLock`] initialiser with the given name and a newly-created lock class. > > @@ -95,7 +96,8 @@ pub type SpinLock = super::Lock; > > /// A kernel `spinlock_t` lock backend. > > pub struct SpinLockBackend; > > > > -// SAFETY: The underlying kernel `spinlock_t` object ensures mutual exclusion. > > +// SAFETY: The underlying kernel `spinlock_t` object ensures mutual exclusion. `relock` uses the > > +// same scheme as `unlock` to figure out which locking method was used originally. > > unsafe impl super::Backend for SpinLockBackend { > > type State = bindings::spinlock_t; > > type GuardState = Option; > > @@ -127,13 +129,24 @@ unsafe impl super::Backend for SpinLockBackend { > > None => unsafe { bindings::spin_unlock(ptr) }, > > } > > } > > + > > + unsafe fn relock(ptr: *mut Self::State, guard_state: &mut Self::GuardState) { > > + let _ = match guard_state { > > + // SAFETY: The safety requiments of this function ensure that `ptr` has been > > + // initialised. > > + None => unsafe { Self::lock(ptr) }, > > + // SAFETY: The safety requiments of this function ensure that `ptr` has been > > + // initialised. > > + Some(_) => unsafe { Self::lock_irqsave(ptr) }, > > + }; > > + } > > } > > > > // SAFETY: The underlying kernel `spinlock_t` object ensures mutual exclusion. We use the `irqsave` > > // variant of the C lock acquisition functions to disable interrupts and retrieve the original > > // interrupt state, and the `irqrestore` variant of the lock release functions to restore the state > > // in `unlock` -- we use the guard context to determine which method was used to acquire the lock. > > -unsafe impl super::IrqSaveBackend for SpinLockBackend { > > +unsafe impl IrqSaveBackend for SpinLockBackend { > > unsafe fn lock_irqsave(ptr: *mut Self::State) -> Self::GuardState { > > // SAFETY: The safety requirements of this function ensure that `ptr` points to valid > > // memory, and that it has been initialised before. >