From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 50A621C07C2; Tue, 15 Oct 2024 12:57:31 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1728997051; cv=none; b=l7Z0WxUQDpuceFiWAzMqir6bWmYHmVYKLKxi8dq+aJOt5eF6zzz+fUp2/U0Hf6tBi6ujyvyoBCNFFcZfTXD6xlvOermIw62JgBfAwXF9ixkqLJ2oTHESOEZrfPO1w5bW3vlH58ClXFxo00GDobbMVn526ZGUsSdljDDMZGT0VrE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1728997051; c=relaxed/simple; bh=dJpNpg4JPPY/O0b3QgBOKSll0jihj67BoIw2p0+2iwQ=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=aO+4T3D8Mmv+3aXHudsLVVcaUG1QTqlwxa50XjvIYXUPYAEL4+6+xrh0DyYjjjjxj1J5GilEoLz3Y87wxqVi1Ehu9/q2AV8OjVSoPPAEPCMZt9aGAGRtrKzOkZNullzqJJZTP/N7AOrbhg9DnZFCEKVRkYxhSYaCUAfaVU+MYIE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=phBFZuoq; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="phBFZuoq" Received: by smtp.kernel.org (Postfix) with ESMTPSA id B5F30C4CEC6; Tue, 15 Oct 2024 12:57:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1728997051; bh=dJpNpg4JPPY/O0b3QgBOKSll0jihj67BoIw2p0+2iwQ=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=phBFZuoqq4PHSpip/KCjeH3DkV757wLi4CS4RL/n5rArdFNtAqDNKG9z+v0Fk+rAB BZnoB/60dkbf6FJaj1A1Ckhb4NcXVzc9wCvgLXRdbKISeQmTMh3f3GGr2LED9q4la5 DjzBND+2d+l3tgraqeVK6L0Oewt7sHPJVb49BFCVtfK20gyai9SHoDzXDAtTzAo70J CRaRGqQkX0jaXlLEOzoWyAhfomX10XoHM1YOEOpjhX/H/YUkuNbK9NzRoDRLyCcpDG oJREAJvRsP56VP78ejYGrfZ18rVyoJnH+U5kGbWk+XX7LscG1GEYvSiY8PHuMcZAaG TQlxE+wXIvy5Q== From: Andreas Hindborg To: Boqun Feng Cc: Lyude Paul , Thomas Gleixner , rust-for-linux@vger.kernel.org, Danilo Krummrich , airlied@redhat.com, Ingo Molnar , Will Deacon , Waiman Long , Peter Zijlstra , linux-kernel@vger.kernel.org, Benno Lossin , Daniel Almeida , Gary Guo , Miguel Ojeda , Alex Gaynor , Wedson Almeida Filho , =?utf-8?Q?Bj=C3=B6rn?= Roy Baron , Andreas Hindborg , Alice Ryhl , Trevor Gross , Martin Rodriguez Reboredo , Valentin Obst Subject: Re: [PATCH v6 3/3] rust: sync: Add SpinLockIrq In-Reply-To: (Boqun Feng's message of "Mon, 7 Oct 2024 05:42:50 -0700") References: <20240916213025.477225-1-lyude@redhat.com> <20240916213025.477225-4-lyude@redhat.com> <8734lew7jn.ffs@tglx> <0a802e5fc0623ac8ae4653a398d0dfd73c479b96.camel@redhat.com> <59803e6abd88dc29c402ff2b7ed020e45f4df1df.camel@redhat.com> Date: Tue, 15 Oct 2024 14:57:11 +0200 Message-ID: <87sesxa5i0.fsf@kernel.org> 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 Boqun Feng writes: > On Sat, Oct 05, 2024 at 02:19:38PM -0400, Lyude Paul wrote: >> On Fri, 2024-10-04 at 14:48 -0400, Lyude Paul wrote: >> > >> > FWIW: I agree we want things to map C closely wherever we can, but part of the >> > reason of having rust in the kernel at all is to take advantage of the >> > features it provides us that aren't in C - so there's always going to be >> > differences in some places. This being said though, I'm more then happy to >> > minimize those as much as possible and explore ways to figure out how to make >> > it so that correctly using these interfaces is as obvious and not-error prone >> > as possible. The last thing I want is to encourage bad patterns in drivers >> > that maintainers have to deal with the headaches of for ages to come, >> > especially when rust should be able to help with this as opposed to harm :). >> >> I was thinking about this a bit more today and I realized I might actually >> have a better solution that I think would actually map a lot closer to the C >> primitives and I feel a bit silly it didn't occur to me before. >> >> What if instead of with_interrupts_disabled, we extended Lock so that types >> like SpinLockIrq that require a context like IrqDisabled can require the use >> of two new methods: >> >> * first_lock(&self, cb: impl for<'a> FnOnce(Guard<'a, T, B>, B::Context<'a>) -> R) -> R > > I think you really want to use a `&mut T` instead of `Guard<'a, T, B>`, > otherwise people can do: > > let g = lock1.first_lock(|guard, _ctx| { guard }); > // here the lock is held, but the interrupts might be enabled. Is it impossible to limit the lifetime of the guard such that it cannot be returned from `first_lock`? BR Andreas