From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9F3831E9919; Sat, 4 Jul 2026 17:10:53 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=90.155.50.34 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783185057; cv=none; b=japdxBf9wYYLY46gDa+t4O3Xz74uOIi4k0G78Q18bi6yydknqn8Tg6Xu/fBKNi3EB8bjWz4870dk1qcWIb8i2mZpii6s4gpiDVA0471X9mPZF0dacB/lUJn17zSKOxysQBL0bTpeFew7Mqj6DJeqUlce9bkYxrswB0YVfr2tds4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783185057; c=relaxed/simple; bh=tPhd2RoYWzsxbWUX8bMlnPo4xKeWntQ2eLZJ2CoQjPQ=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=QLUVqX9y1cee5/mHDpnVK+tNThSfXI0c7EqROnMmqwPTdX/qCzT6NXi3yWmwTyYXJMDrHbqptfrI/Zt3knvib8rlGVrd6EKCFVDNzOBV3cn1QkB6cZFS9/hQgmEkPlXOq00Bv5kc+BSKFdo//vGx22zkuGwIV/tgRSGS1rNChuM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org; spf=pass smtp.mailfrom=infradead.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b=VwUU9qZ6; arc=none smtp.client-ip=90.155.50.34 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=infradead.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="VwUU9qZ6" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=9PJUeKUOu9VN+EoCJb6IzQu+NtmoeyB8SgqhsADXrKg=; b=VwUU9qZ6BwbgdDYkZp9g2f+PLt +GJ/FdOE9fBzvn4Z6dNVCmhGCEHqAoh3e5NEZTUIwpObn07nACX2AjUKkvvUoDO6KSrFPaIuI4ESH rmstq0A0CESd/WKgyTEneXV9MjP+BF2oOH0AduGCqMJRmw5XX062p3Y72FNrkriVScv/uImJ8uFph hEK5wf9MBX7kHUjLkV1ezy27AdO2jrmyKGQ73JO8dv3BogFdKpwaWe5GuHEHUmncwf17LpQB3Psl2 sySE2MNVN/ANK8yAHDoXm3sCopHIeK5Rkp99GKco3CSBxk04d32GjIdWPal42pPHq85mVgzpj5ccb rLqWdVsw==; Received: from 77-249-17-252.cable.dynamic.v4.ziggo.nl ([77.249.17.252] helo=noisy.programming.kicks-ass.net) by casper.infradead.org with esmtpsa (Exim 4.99.1 #2 (Red Hat Linux)) id 1wg3t5-0000000CFaU-3Iba; Sat, 04 Jul 2026 17:10:44 +0000 Received: by noisy.programming.kicks-ass.net (Postfix, from userid 1000) id B32AA300402; Sat, 04 Jul 2026 19:10:42 +0200 (CEST) Date: Sat, 4 Jul 2026 19:10:42 +0200 From: Peter Zijlstra To: Gary Guo Cc: Boqun Feng , Alice Ryhl , Lyude Paul , Daniel Almeida , Onur =?iso-8859-1?Q?=D6zkan?= , Miguel Ojeda , =?iso-8859-1?Q?Bj=F6rn?= Roy Baron , Benno Lossin , Andreas Hindborg , Trevor Gross , Danilo Krummrich , Tamir Duberstein , Alexandre Courbot , Ingo Molnar , Will Deacon , Waiman Long , linux-kernel@vger.kernel.org, rust-for-linux@vger.kernel.org Subject: Re: [PATCH RFC 0/2] rust: sync: create lock class using `#[track_caller]` Message-ID: <20260704171042.GT751831@noisy.programming.kicks-ass.net> References: <20260703-rust_lockdep-v1-0-1c21c62d0341@garyguo.net> <20260703140140.GE651302@noisy.programming.kicks-ass.net> <20260703223242.GS751831@noisy.programming.kicks-ass.net> Precedence: bulk X-Mailing-List: rust-for-linux@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Sat, Jul 04, 2026 at 05:52:35PM +0100, Gary Guo wrote: > On Fri Jul 3, 2026 at 11:32 PM BST, Peter Zijlstra wrote: > > On Fri, Jul 03, 2026 at 03:24:29PM +0100, Gary Guo wrote: > >> [snip] On the lockdep side, > >> essentially the name will be "(rust)", while the actual name can be retrieved > >> from the lock class key. > >> > >> So for > >> > >> let foo = KBox::pin_init(Mutex::new(42)); > >> > >> in, say, foo.c:123 > >> > >> it will eventually call > >> > >> struct rust_location *loc = /* static generated by the Rust compiler */; > >> mutex_init_lockdep(foo, "(rust)", (struct lock_class_key *)loc) > >> > >> And when "(rust)" is encountered as lock class name, instead of printing the > >> string as is, lockdep will call > >> > >> lockdep_print_rust_name(loc) > >> > >> which will be doing essentially > >> > >> pr_cont("foo.c:123"); > > > > That seems quite terrible. The C names are based on the expression used > > to initialize the class and are thus somewhat descriptive. But file:line > > combos are horrid identifiers for locks. > > > > Why would you want to do this? > > I do think this is not ideal, however the current code is already doing this. > This RFC series isn't changing the name at all, just represent this in a > different way. > > The reason that file:line is used for names is due to the fundamental difference > between initialization in C and Rust. In C you create something uninitialized > first, and then initialize it, and it'll be UB if the value is used before > initialization or (for some types) initialize a value twice. In Rust we use > pin_init to ensure that a value cannot be used uninitialized. > > The way the syntax is write out currently is something like > > pin_init!(MyStruct { > my_mutex <- new_mutex!(initial_data), > }) > > [ > which this series is turning it to > > pin_init!(MyStruct { > my_mutex <- Mutex::new(initial_data), > }) > ] > > as you can see the `new_mutex!` or `Mutx::new` does not know where it is going To be frank, no I don't see. I have absolutely no frigging clue what any of that means :-( > to be initialized to, because we prevent people from being able to name a > yet-to-be-initialized place. > > It is possible to use the C approach (which early days of Rust-for-Linux does > use), but doing so require a lot of unsafe keywords because you are relying on > the programmer to not mess things up, instead of having the compiler check. > > So the best alternative that we can use for the name under this constraint is > the file:line combo. It is less descriptive, but at least it does tell you where > the lock class is used, so you can still trace it back. Given lockdep is a > debugging feature, I think the less descriptive name, albeit inconvenient, is > not a dealbreaker. People already struggle to make sense of lockdep reports, this isn't going to make it better :/ > The trade off here is the convenience of creating a lock (safely) vs the > descriptiveness of the name, and I think the former is more important. It is > still possible to explicit give a name if it helps (Binder is actually doing > this already), but this currently cannot be implicitly created. Like I said, Rust is still line noise to me, and I really don't understand anything you've just tried to tell me. Now, I do speak (some) C++, and the new thing you mention got me thinking you're talking about a constructor. Are you trying to say that since the invocation of the constructor is somewhat implicit, there is no good way to stringize the structure member name and store it? That said, in C++ you can mandate a string be handed to the constructor; this would mean everybody would need to explicitly provide a descriptive name, surely Rust can do this same? Every !debug build could then instantly ignore that string, but at least it'd be there.