From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-40134.protonmail.ch (mail-40134.protonmail.ch [185.70.40.134]) (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 50DC815FCED for ; Thu, 1 Aug 2024 13:46:38 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=185.70.40.134 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1722520000; cv=none; b=rUcSBheM+Jdolusycb3Blxl+qA0v3hVZnDvyeQEx+fVA7D/MRly87ZPLTufTaP+0QA9IGTObZfVUQq95OCiEYO4x/WVJfiHb0RBeF+m4QdWMau9gqS+5ae76odqlv1CmgtRel6jofFO3nxWQpBHFGsNVwYxwIjYALOHr+M/03Lk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1722520000; c=relaxed/simple; bh=sITK3pKr6Zobvg/kjShjIFRKWEFJyVWbo5cBMGKXrLM=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=ZPz9o0j/dCH4TQAvAL5lE2G4BJ5w2hVfcz95QOUD5vnC84bER8rZjB9O0CjmiQn78zoPRJHoLvxohz+xZHvCIirJ3vjiuTi+sfr2rOXVVJ18MyyvDVPltVt95lva44KNLsL3CS/yLklBrkLqVOsrB37o0GsSWZZSsYAa4KNG/m8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=proton.me; spf=pass smtp.mailfrom=proton.me; dkim=pass (2048-bit key) header.d=proton.me header.i=@proton.me header.b=k68WrCLN; arc=none smtp.client-ip=185.70.40.134 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=proton.me Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=proton.me Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=proton.me header.i=@proton.me header.b="k68WrCLN" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me; s=protonmail; t=1722519996; x=1722779196; bh=Q3cRDO4QKzRb10Iyi1TAhCZG+F7xgQQpPMz+/EOxj5k=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=k68WrCLN5fAj4Ej5MS6qd/AC+izxLBWeC7xPuC1Ej7V3QWBOSEKTFDb3Eu8jxkHf7 lXjkQjr+RzGktEoNK2A+6N/VPcQM9dQvkWS3cFC8N6Gblr6kE4142ihc4YmMb7hWhf mLF6XX5YMcNN4k91+lt8KZmooLP4JzfPfzLYTeSDBCetNyCjF+JnEg3N0/bqiRXEPC fo/Y1IOP8YmBRYUsRviuPHwQ8UnHRVNPDZmV9WeUu1auzYKSMftidj/I5/O0McIdJx 0AMZzbpxq9McTC1z6fjrUUSLYYr/MNAy+LfKX6FTzvclEzV9h/5k3UkWyOc+6IdUUr O9LQr1hHxxlww== Date: Thu, 01 Aug 2024 13:46:29 +0000 To: Alice Ryhl From: Benno Lossin Cc: Miguel Ojeda , Andrew Morton , Alex Gaynor , Wedson Almeida Filho , Boqun Feng , Gary Guo , =?utf-8?Q?Bj=C3=B6rn_Roy_Baron?= , Andreas Hindborg , Marco Elver , Coly Li , Paolo Abeni , Pierre Gondois , Ingo Molnar , Jakub Kicinski , Wei Yang , Matthew Wilcox , linux-kernel@vger.kernel.org, rust-for-linux@vger.kernel.org, Kees Cook Subject: Re: [PATCH v3 04/10] rust: list: add struct with prev/next pointers Message-ID: In-Reply-To: References: <20240723-linked-list-v3-0-89db92c7dbf4@google.com> <20240723-linked-list-v3-4-89db92c7dbf4@google.com> <1b2078d8-d93b-4626-a73f-edc5616a2357@proton.me> <5b13793c-3ec8-40c2-b0c6-e7b10883d0cb@proton.me> Feedback-ID: 71780778:user:proton X-Pm-Message-ID: 80ec9d7d263f3eca5edc93ab9fb0fa7d2fbcf829 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 On 01.08.24 14:51, Alice Ryhl wrote: > On Thu, Aug 1, 2024 at 12:45=E2=80=AFPM Benno Lossin wrote: >> >> On 01.08.24 11:42, Alice Ryhl wrote: >>> On Wed, Jul 31, 2024 at 8:41=E2=80=AFPM Benno Lossin wrote: >>>> >>>> On 23.07.24 10:22, Alice Ryhl wrote: >>>>> +/// The prev/next pointers for an item in a linked list. >>>>> +/// >>>>> +/// # Invariants >>>>> +/// >>>>> +/// The fields are null if and only if this item is not in a list. >>>>> +#[repr(transparent)] >>>>> +pub struct ListLinks { >>>>> + #[allow(dead_code)] >>>>> + inner: Opaque, >>>> >>>> Do you really need `Opaque`? Or would `UnsafeCell` be enough? (If it i= s >>>> enough and you change this, be aware that `Opaque` is `!Unpin`, so if >>>> you intend for `ListLinks` to also be `!Unpin`, then you need a >>>> `PhantomPinned`) >>> >>> I need the `!Unpin` part for aliasing. >> >> Oh good point, do you mind adding a comment for that? >> >>>>> +} >>>>> + >>>>> +// SAFETY: The next/prev fields of a ListLinks can be moved across t= hread boundaries. >>>> >>>> Why? This is not a justification. >>> >>> What would you say? >> >> While trying to come up with a safety comment I thought about the >> following: this impl does not depend on the type that is behind the >> pointer (ie the type containing the `ListLinks`). Thus this `ListLinks` >> will always implement `Send` even if the pointed-to value does not. >> What we could do (and what definitely would be correct) is this: >> `List` can only be used with `Send` types, then we could implement >> `Send` for `ListLinks`. But I haven't actually come up with a problem, >> so there might a more permissive solution. >> Do you have a use-case where you need `!Send` types in a list? >> >> Here is a part of my reasoning: If the pointed-to value is `!Send`, then >> the `List` item type must also be `!Send`. Thus all list operations take >> place on the same thread (since the `List` will be `!Send`). Therefore >> nobody can access the `prev`/`next` pointers from another thread. >> >> But this does not justify that `ListLinks` can be made `Send`. (although >> there isn't actually a problem) I think I confused myself. The paragraph above actually explains why we are allowed to make `ListLinks: Send`. What do you think of the following comment: // SAFETY: The only way to access/modify the pointers inside of `ListLinks<= ID>` is via holding the // associated `ListArc`. Since that type correctly implements `Send`= , it is impossible to // move this an instance of this type to a different thread if the pointees= are `!Send`. > I don't think there's any reason to forbid lists with !Send types. The > List just becomes !Send too. Yes, but that doesn't explain why `ListLinks` is allowed to be `Send`. --- Cheers, Benno