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 888FA1FFC5A; Sat, 22 Feb 2025 11:40:37 +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=1740224437; cv=none; b=lzHm+3k1lycweiO6hvnORpZDuvnFCv641o08hpQ03+kfEaGVQyq9uk4xcQCh+KjgxeJVRyHGI0fdyBVnC0r+3fIb9cSQWEVE/oTR3ThFy0rfFZKoix4m4rrCcD0UizgN03iW0yPveNMODm2VaiyDIdTZzA9cnOfzbFImE/j5V+c= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1740224437; c=relaxed/simple; bh=3DZ40JdNPlh8KNMjFXeN2zlk13Yu3H5tsfDipn0TRFc=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=hCen7tK4GHtVmkfDdTLWittqPEtdhhJ2XFwTnSbP/40x23AV16/Lid3qtsJ1KHv8BP2Rc+tLeZLJJ9ssibRoNUZwDy8iZ5G2dxL8Nz00QJoTMrdWYjjWBhlvu9v1LnoAPk5m9h/R3B/K6ftB/MOqRvZZUFSl8dyo3cCTUP0kZsU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=YWZhGPhu; 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="YWZhGPhu" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 48338C4CED1; Sat, 22 Feb 2025 11:40:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1740224437; bh=3DZ40JdNPlh8KNMjFXeN2zlk13Yu3H5tsfDipn0TRFc=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=YWZhGPhuwtmrz3CqQoL1DgGt3ZVNdTe1oLWIa0A8aGr4cDOhkA/JGOzrj0joK7mDl yOcVmtAk/7o7Jiqn0Ss2g9t2Fx43sh3U3WFhYmipR1E6qd9TGDydipXLnTLlwCrqmS aB3FL4Sd3gP6dcFH8s6A5E0CQQppkAS8tSgyvSVqnf5oWknJbYf2MswSN1H0GMF7to KGGaOPZ9h3YNh7ZJpNaweRGE8RNO5bBiYtgjGXBz3H8nWqw9VfSm8PlipaKsiV0vtl N7XNyplokwqYlzKsUXwZ0PRiv+iQgC/0iBQjyQTi65XVX4bnJgVV2KCesraHkTOQS/ fSNfu2C1CJ+VQ== From: Andreas Hindborg To: "Boqun Feng" Cc: "Tamir Duberstein" , "Miguel Ojeda" , "Anna-Maria Behnsen" , "Frederic Weisbecker" , "Thomas Gleixner" , "Danilo Krummrich" , "Alex Gaynor" , "Gary Guo" , =?utf-8?Q?Bj=C3=B6rn?= Roy Baron , "Benno Lossin" , "Alice Ryhl" , "Trevor Gross" , "Lyude Paul" , "Guangbo Cui" <2407018371@qq.com>, "Dirk Behme" , "Daniel Almeida" , , Subject: Re: [PATCH v8 02/14] rust: hrtimer: introduce hrtimer support In-Reply-To: <87y0xycowa.fsf@kernel.org> (Andreas Hindborg's message of "Sat, 22 Feb 2025 10:25:09 +0100") References: <20250218-hrtimer-v3-v6-12-rc2-v8-2-48dedb015eb3@kernel.org> <87wmdkgvr0.fsf@kernel.org> <87ldtzhexi.fsf@kernel.org> <87cyfbe89x.fsf@kernel.org> <87y0xycowa.fsf@kernel.org> User-Agent: mu4e 1.12.7; emacs 29.4 Date: Sat, 22 Feb 2025 12:40:23 +0100 Message-ID: <87h64mcimw.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; charset=utf-8 Content-Transfer-Encoding: quoted-printable Andreas Hindborg writes: > "Boqun Feng" writes: > >> On Fri, Feb 21, 2025 at 09:46:08AM -0500, Tamir Duberstein wrote: >>> On Fri, Feb 21, 2025 at 9:40=E2=80=AFAM Boqun Feng wrote: >>> > >>> > Hmm... if you mean: >>> > >>> > trait HasHrTimer { >>> > unsafe fn start(&self, expires: Ktime) { >>> > ... >>> > } >>> > } >>> > >>> > Then it'll be problematic because the pointer derived from `&self` >>> > doesn't have write provenance, therefore in a timer callback, the >>> > pointer cannot be used for write, which means for example you cannot >>> > convert the pointer back into a `Pin>`. >>> > >>> > To answer Tamir's question, pointers are heavily used here because we >>> > need to preserve the provenance. >>> >>> Wouldn't the natural implication be that &mut self is needed? Maybe >> >> For an `Arc`, you cannot get `&mut self`. >> >>> you can help me understand why pointers can express a contract that >>> references can't? >> >> I assume you already know what a pointer provenance is? >> >> http://doc.rust-lang.org/std/ptr/index.html#provenance >> >> Passing a pointer (including offset operation on it) preserves the >> provenance (determined as derive time), however, deriving a pointer from >> a reference gives the pointer a provenance based on the reference type. >> For example, let's say we have an `Arc` and a clone: >> >> let arc =3D Arc::new(42); >> let clone =3D arc.clone(); >> >> you can obviously do a into_raw() + from_raw() pair: >> >> let ptr =3D Arc::into_raw(arc); >> let arc =3D unsafe { Arc::from_raw(arc) }; >> >> however, if you create a reference based on `Arc::into_raw()`, and then >> derive a pointer from that, you change the provenance, > > In this case, the pointer will have the pointer of `Arc::into_raw()` > will have the provenance of the original reference. When you turn that > pointer back into a reference, won't the reference inherit the > provenance of the pointer, which is the same as the original reference? > > As I read the docs, getting a reference to a `Timer` from a reference to > a `` by converting `&MyType` to a `*const MyType`, > doing a `ptr.cast::().add(offset).cast::>()` and > converting that pointer to a reference should be fine? The final pointer > before converting back to a reference will still have provenance of the > original reference. Converting to a reference at the end will shrink the > provenance, but it is still fine. > > Going from a `&HrTimer` to a `&T` is a problem, because that would > require offset outside spatial permission of pointer provenance, and it > would require increasing the size of the spatial permission. > > Is this correctly understood? How does provenance work across language boundaries? Should we actually use `with_addr` [1] when we get pointers from C round trips? Best regards, Andreas Hindborg [1] https://doc.rust-lang.org/stable/std/primitive.pointer.html#method.with= _addr