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;
Date:   Mon, 3 Apr 2023 16:25:29 +0100
From:   Gary Guo <gary@garyguo.net>
To:     Wedson Almeida Filho <wedsonaf@gmail.com>
Cc:     Peter Zijlstra <peterz@infradead.org>,
        Boqun Feng <boqun.feng@gmail.com>,
        rust-for-linux@vger.kernel.org, Miguel Ojeda <ojeda@kernel.org>,
        Alex Gaynor <alex.gaynor@gmail.com>,
        =?UTF-8?B?Qmo=?= =?UTF-8?B?w7Zybg==?= Roy Baron 
        <bjorn3_gh@protonmail.com>, linux-kernel@vger.kernel.org,
        Wedson Almeida Filho <walmeida@microsoft.com>,
        Ingo Molnar <mingo@redhat.com>, Will Deacon <will@kernel.org>,
        Waiman Long <longman@redhat.com>
Subject: Re: [PATCH 03/13] rust: lock: introduce `Mutex`
Message-ID: <20230403162529.7bef76e6.gary@garyguo.net>
In-Reply-To: <ZCrZkUaoslXHpige@wedsonaf-dev>
References: <20230330043954.562237-1-wedsonaf@gmail.com>
        <20230330043954.562237-3-wedsonaf@gmail.com>
        <20230330130108.GE124812@hirez.programming.kicks-ass.net>
        <ZCXZMNj7aOKbC7Ev@boqun-archlinux>
        <20230403082052.GR4253@hirez.programming.kicks-ass.net>
        <ZCrZkUaoslXHpige@wedsonaf-dev>
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?nPdNvG++FbyRZ9q/ESRkbZ/682/NoyHeBlcWVxfZugxhwpOw1EHpdlTjJCan?=
 =?us-ascii?Q?zU4oHSvVz91DHYAB1hi75fACoxNs3HPBzEXGu18uqGUPb7HxXfBeuKHXNUei?=
 =?us-ascii?Q?/FviPxrMf7VZiynyk9PhGfiBh4MEQnB8y+xgJRE99aRdRgG24h633qbMBvwV?=
 =?us-ascii?Q?IlpQC6XhJe3/C34nNTl8+L2I14wDxCnA6zVHGK+5EcBFKycQeselL3VsvlTZ?=
 =?us-ascii?Q?VEGdI2TRPRIIgsaHOLAAN8ayeMroC0NS9k6zAACndJ01t9K1Dp772/hsvTdu?=
 =?us-ascii?Q?4EyWZS2AqgGYWSAvv986m1MKeVRsz74pGOWapUUPsiV51YdNOHP95dqXlL0M?=
 =?us-ascii?Q?wapEiMdp1axPH0dUr6q82i6x9pbSbChCHmQ9+FIUIJO8UUg8gFfgYMeLMhJH?=
 =?us-ascii?Q?KNUBzoqq5UYehz6rq+VluWQi5fc+fIFA63qWE+q5k+ZmZqUjB1DXKNmUsXI9?=
 =?us-ascii?Q?UK3eLSI1EFOXDMh4vBT2PDeN9WWABtZ/OyJGPq96bKpqTgm4vSUdwmhXHtp7?=
 =?us-ascii?Q?Qgvzhjsni0mUcsbgGnUKNBENjmoPHBprF1QBAOfIk4SoxYJxQi1QbeXSEfqw?=
 =?us-ascii?Q?iuvcqf1OLKiCl7EQ1B54fnpr3Al6NfgpOYrhPbDhcgUAG3ubRf7OsaO76nJy?=
 =?us-ascii?Q?q1u44ndKbOVQaxmEtnLft8VjCiRQ6ZzkiyWHj7Ti4Kymq7dj/GyeWHAtJRFG?=
 =?us-ascii?Q?X4ne/Y/7DaHt7+HzGB3dzhcrcKzdMyDZ7U/9RscFvlD89QNyRUdEQUPBjD75?=
 =?us-ascii?Q?khLviWar2uN/g6Oaq4qa8iz+blgVvXnHSdqd/oIEwHCsx3945UgXquLbBTU2?=
 =?us-ascii?Q?QJTir3cVEg/Uj29kcN+TnAFN0sAoPCGaj9oAg1rdQ9pqiS83YqsaHjyGuWC2?=
 =?us-ascii?Q?NzJR6kzZeAxVmP8xjspCLRBm/QznFY0K1h7MhHpn4YkyAA9DYkRWX9RSolon?=
 =?us-ascii?Q?ceEDMF9Mim/Kjd0KmQmR2r9/X5rltUk9w7A3LHewyIu6LYqxOziQmgiOc4rF?=
 =?us-ascii?Q?xj9w7HH38KSb+BOM5i8df9FlJH7awqHJr0KqpT/qfD+1A/5C1sulYdrjfWj/?=
 =?us-ascii?Q?+/X3WiPj2tntSl8DlB/T11jx4BoTmgUc4WEw3qXlJ2ITIOfsiKB2bbzALDmU?=
 =?us-ascii?Q?/V+gT/IP5ctVugd7dQg/dix+OMDChr7FgClsIdV5YNjBTXjFia07NVoiCh9Q?=
 =?us-ascii?Q?GtSbeT+o8narAboFAZocBLqYp5/satsmyGt+BMUQGsop+8TNax6hPgyKTgTz?=
 =?us-ascii?Q?wKXAwV12t/02U8YITLNd59YvI0m28Kmrb67qkStqHTknMRricVu9KmeLQk3W?=
 =?us-ascii?Q?icOF2hLz9AQlw/F71PMLpe2vzM9KdlOBCLQTn1W9GEuYnCrMfDaJzqNW5F1n?=
 =?us-ascii?Q?cbdYLUIUqxnHFytSHXwSsMAKjYk44rwg2sLizXSm26zs9Brez/0OYfSIvDpQ?=
 =?us-ascii?Q?SIEQyADNFymFCOysJGXbIkLqcjsfknAKHy3Db1c2+2AFh2MEoCOZhgl8Aqqd?=
 =?us-ascii?Q?q3QU7vhCVEUyWU/FbIVhXSM5y0cGDZqODXncAEa2Fh4FYtgCz0B8aNtsOY59?=
 =?us-ascii?Q?3Fq2QMRQgOXNkYpu6U8Yflhez+O461IPyiGuSl29?=
X-OriginatorOrg: garyguo.net
X-MS-Exchange-CrossTenant-Network-Message-Id: 9f2814d3-2647-43a7-c073-08db3457a912
X-MS-Exchange-CrossTenant-AuthSource: LO2P265MB5183.GBRP265.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Apr 2023 15:25:30.8146
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: bbc898ad-b10f-4e10-8552-d9377b823d45
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: 8EsOGrnybq0+aCmEGZzYpiF1CDkyi6pgYsZqNS99LCCrSN91TYAlv5X0CrqERWrbPc+S7QOLkd3dpg8z4hK43Q==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CWXP265MB5783
X-Spam-Status: No, score=-0.2 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
        DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,
        SPF_HELO_PASS,SPF_PASS autolearn=unavailable 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: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Mon, 3 Apr 2023 10:50:09 -0300
Wedson Almeida Filho <wedsonaf@gmail.com> wrote:

> On Mon, Apr 03, 2023 at 10:20:52AM +0200, Peter Zijlstra wrote:
> > On Thu, Mar 30, 2023 at 11:47:12AM -0700, Boqun Feng wrote:  
> > > On Thu, Mar 30, 2023 at 03:01:08PM +0200, Peter Zijlstra wrote:  
> > > > On Thu, Mar 30, 2023 at 01:39:44AM -0300, Wedson Almeida Filho wrote:  
> > > > > From: Wedson Almeida Filho <walmeida@microsoft.com>
> > > > > 
> > > > > This is the `struct mutex` lock backend and allows Rust code to use the
> > > > > kernel mutex idiomatically.  
> > > > 
> > > > What, if anything, are the plans to support the various lockdep
> > > > annotations? Idem for the spinlock thing in the other patch I suppose.  
> > > 
> > > FWIW:
> > > 
> > > *	At the init stage, SpinLock and Mutex in Rust use initializers
> > > 	that are aware of the lockdep, so everything (lockdep_map and
> > > 	lock_class) is all set up.
> > > 
> > > *	At acquire or release time, Rust locks just use ffi to call C
> > > 	functions that have lockdep annotations in them, so lockdep
> > > 	should just work.
> > >   
> > 
> > ffi is what the C++ world calls RAII ?  
> 
> No, ffi is 'foreign function interface', it just means that the caller will use
> the same ABI as the callee.
> 
> > But yes, I got that far, but I wondered about things like
> > spin_lock_nested(&foo, SINGLE_DEPTH_NESTING) and other such 'advanced'
> > annotations.
> > 
> > Surely we're going to be needing them at some point. I suppose you can
> > do the single depth nesting one with a special guard type (or whatever
> > you call that in the rust world) ?  
> 
> I haven't looked at all the advanced annotations, but something like
> spin_lock_nested/mutex_lock_nested can be exposed as a lock_nested() associated
> function of the `Lock` type, so one would do:
> 
>   let guard = my_mutex.lock_nested(SINGLE_DEPTH_NESTING);
>   // Do something with data protected by my_mutex.

I don't think an additional function would work. It's not okay to
perform both nested locking and non-nested locking on the same lock
because non-nested locking will give you a mutable reference, and
getting another reference from nested lock guard would violate aliasing
rules.

A new lock type would be needed for nested locking, and guard of it can
only hand out immutable reference.

Best,
Gary