From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f53.google.com (mail-wm1-f53.google.com [209.85.128.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1D32519922F for ; Tue, 25 Feb 2025 17:36:20 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.53 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1740504983; cv=none; b=I87HFhbHTARkThDXoza4d5uYimrtMgWiJMSFMGKgSIxn1sp51MOaPKFLne14nS278i38FbdnqeWtCap+wDrVTQqWiia4/E4tu2LCwkHhIAfESKOR8ICOQv8RdreCjV9GdpFaDOSarZZ+uVSM76mVGmfBUpPHfCXQG7Hx7PizH/g= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1740504983; c=relaxed/simple; bh=gOl/36Ytrp1zDSvgkiGrHn22n77JQLii4H7PNe1Rj8k=; h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=GM+1L8W0qxatG4tj1t1Msr5Kb5i0798PEJyxj6fUAJkLLFkgQ+5OPBIEYX7Kx2/82xSevit42on9h+KQEdYx967rq0E/f6K2Hg5x26T0k1VruCxdtme2pyN8ihFSpW4M192XKs/6cwYWeaeF7vrYP3CLQVPQfQDwJ/SQMg3TpXs= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=AJSv+rNn; arc=none smtp.client-ip=209.85.128.53 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="AJSv+rNn" Received: by mail-wm1-f53.google.com with SMTP id 5b1f17b1804b1-4394a0c65fcso59984535e9.1 for ; Tue, 25 Feb 2025 09:36:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1740504979; x=1741109779; darn=vger.kernel.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=jb7TDT/aVvgdtxg6kdFOwwgVqkaL6U92QY48yAXPGLY=; b=AJSv+rNnAStmwd6xYcjFg/j9ptQuRMvrGj5oFP2Y67J5jQNKVjx1/X3hLWpZJ1aLlZ kCDc0UliYwjo6nsAMVz9JsYHqYM4gqy7sJZl5AYpMjOfvBHdfqmZICEY7+VmlBzK+TXy xeM4QRyl4yciqbaFTuqV4JLL2X1zQ+3XXlb4u35zBszbdyuCTZLJY4BmFyq9G4uMb3Sq /SVQfwqALAeZ+QI66MC5jXl4SyjO1hljM1XISQgIO/U1LBwT1Vcs1xqKwlmm9GG9cDao DeXX9Xdzd3uCzwxU4TzyflUIR26oAW0k1tYn94TVULrcGJah6q8sKhRbxb9VSjMzxgn9 srbQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1740504979; x=1741109779; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=jb7TDT/aVvgdtxg6kdFOwwgVqkaL6U92QY48yAXPGLY=; b=eLayF/Nqm/fS1g8vGV/AjCRREnSrCPTGeDG4TEIUvnWHLf9iaw5wEnSHWvGwqH7uD/ NI0DJIltBRnCuZ4uHaps3acwW+z0kU2T2nwPjEeXBjLCQrvtqXUC8LUJWRARLd+wLvKO KrDfPgVCGLUESerjgA649baZOASCd80t0mLQ5HmvJ9SvJmvtQWmy500mALb9qfo81g64 lGFJIoWMxrrd1gOW9/W2wqALNAdj8P0tBIOjmeyF/tjcJAfpxDD6ihHM0pCwRzoWSx/f iPhfN3vbcONz8l7zgH22vS3kcSYFGLhCFmrK6BzO3HEzcGuUSva1WrZqjh94Mjmwq3pz T37A== X-Forwarded-Encrypted: i=1; AJvYcCUJLVIRiwALK4i5Jy57vXg8JFCxYjVG9SharnAvAwDcQy3W4YSOW7pn0pe14GzR6N9Gh8vkR2gpG6LrkA6COw==@vger.kernel.org X-Gm-Message-State: AOJu0YyYcSs4X+lW20t47zw+nFuVsbj1UPLzt06HRxp6VFhEoN/Wp0Xe QtGcTSZOb/k+BEgfk62z1U+96gS3FSPYn2Xbi/SHDziv2xbWAULwjoSRlNgGrOozGuRMCBInsGN yK/SZ+7Oc/Z9VjT/W7hbcmcR89O4qfuyZWT7w X-Gm-Gg: ASbGncvqHWhAdQ3ahaZAYNxC+SJZyP1osnlMfnqa3Y6uAo5YIkzeqWYjBf9g+9Va7z5 tfC3phjwEM9p8OdKWRGmcNSGqCFfw6sdqfJmbjCtI+pDKYfI+56jQe8wYsgVIeswetLqX9uIdcE 3wmLSXfCOxX8cN59VVGKEXLQTy3Rae1+D0Q8y23w== X-Google-Smtp-Source: AGHT+IEKeLbYDcWbkUCjv9WAAKpj5i9urIXFAIil9bTEvJFu6/6yC9kyIte/8TvLmHWUW8IDBAxxehZuyfy5A6xga1I= X-Received: by 2002:a05:600c:1d8c:b0:439:98ca:e39b with SMTP id 5b1f17b1804b1-43ab44b58c3mr31936975e9.29.1740504979330; Tue, 25 Feb 2025 09:36:19 -0800 (PST) Precedence: bulk X-Mailing-List: rust-for-linux@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 References: <20250222141521.1fe24871@eugeo> <6pwjvkejyw2wjxobu6ffeyolkk2fppuuvyrzqpigchqzhclnhm@v5zhfpmirk2c> In-Reply-To: From: Alice Ryhl Date: Tue, 25 Feb 2025 18:36:07 +0100 X-Gm-Features: AQ5f1Jrk5Ircg0d1PeSghOYiJs5Q14TTxoym4eosxDvw1DHTRuGD27YpgvptUqQ Message-ID: Subject: Re: C aggregate passing (Rust kernel policy) To: Ventura Jack Cc: Linus Torvalds , Kent Overstreet , Gary Guo , airlied@gmail.com, boqun.feng@gmail.com, david.laight.linux@gmail.com, ej@inai.de, gregkh@linuxfoundation.org, hch@infradead.org, hpa@zytor.com, ksummit@lists.linux.dev, linux-kernel@vger.kernel.org, miguel.ojeda.sandonis@gmail.com, rust-for-linux@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Feb 25, 2025 at 6:21=E2=80=AFPM Ventura Jack wrote: > > On Tue, Feb 25, 2025 at 9:12=E2=80=AFAM Alice Ryhl = wrote: > > > > On Sun, Feb 23, 2025 at 4:30=E2=80=AFPM Ventura Jack wrote: > > > > > > Just to be clear and avoid confusion, I would > > > like to clarify some aspects of aliasing. > > > In case that you do not already know about this, > > > I suspect that you may find it very valuable. > > > > > > I am not an expert at Rust, so for any Rust experts > > > out there, please feel free to point out any errors > > > or mistakes that I make in the following. > > > > > > The Rustonomicon is (as I gather) the semi-official > > > documentation site for unsafe Rust. > > > > > > Aliasing in C and Rust: > > > > > > C "strict aliasing": > > > - Is not a keyword. > > > - Based on "type compatibility". > > > - Is turned off by default in the kernel by using > > > a compiler flag. > > > > > > C "restrict": > > > - Is a keyword, applied to pointers. > > > - Is opt-in to a kind of aliasing. > > > - Is seldom used in practice, since many find > > > it difficult to use correctly and avoid > > > undefined behavior. > > > > > > Rust aliasing: > > > - Is not a keyword. > > > - Applies to certain pointer kinds in Rust, namely > > > Rust "references". > > > Rust pointer kinds: > > > https://doc.rust-lang.org/reference/types/pointer.html > > > - Aliasing in Rust is not opt-in or opt-out, > > > it is always on. > > > https://doc.rust-lang.org/nomicon/aliasing.html > > > - Rust has not defined its aliasing model. > > > https://doc.rust-lang.org/nomicon/references.html > > > "Unfortunately, Rust hasn't actually > > > defined its aliasing model. > > > While we wait for the Rust devs to specify > > > the semantics of their language, let's use > > > the next section to discuss what aliasing is > > > in general, and why it matters." > > > There is active experimental research on > > > defining the aliasing model, including tree borrows > > > and stacked borrows. > > > - The aliasing model not being defined makes > > > it harder to reason about and work with > > > unsafe Rust, and therefore harder to avoid > > > undefined behavior/memory safety bugs. > > > > I think all of this worrying about Rust not having defined its > > aliasing model is way overblown. Ultimately, the status quo is that > > each unsafe operation that has to do with aliasing falls into one of > > three categories: > > > > * This is definitely allowed. > > * This is definitely UB. > > * We don't know whether we want to allow this yet. > > > > The full aliasing model that they want would eliminate the third > > category. But for practical purposes you just stay within the first > > subset and you will be happy. > > > > Alice > > Is there a specification for aliasing that defines your first bullet > point, that people can read and use, as a kind of partial > specification? Or maybe a subset of your first bullet point, as a > conservative partial specification? I am guessing that stacked > borrows or tree borrows might be useful for such a purpose. > But I do not know whether either of stacked borrows or tree > borrows have only false positives, only false negatives, or both. In general I would say read the standard library docs. But I don't know of a single resource with everything in one place. Stacked borrows and tree borrows are attempts at creating a full model that puts everything in the two first categories. They are not conservative partial specifications. > For Rust documentation, I have heard of the official > documentation websites at > > https://doc.rust-lang.org/book/ > https://doc.rust-lang.org/nomicon/ > > And various blogs, forums and research papers. > > If there is no such conservative partial specification for > aliasing yet, I wonder if such a conservative partial > specification could be made with relative ease, especially if > it is very conservative, at least in its first draft. Though there > is currently no specification of the Rust language and just > one major compiler. > > I know that Java defines an additional conservative reasoning > model for its memory model that is easier to reason about > than the full memory model, namely happens-before > relationship. That conservative reasoning model is taught in > official Java documentation and in books. On the topic of conservative partial specifications, I like the blog post "Tower of weakenings" from back when the strict provenance APIs were started, which I will share together with a quote from it: > Instead, we should have a tower of Memory Models, with the ones at the to= p being =E2=80=9Cwhat users should think about and try to write their code = against=E2=80=9D. As you descend the tower, the memory models become increa= singly complex or vague but critically always more permissive than the ones= above it. At the bottom of the tower is =E2=80=9Cwhatever the compiler act= ually does=E2=80=9D (and arguably =E2=80=9Cwhatever the hardware actually d= oes=E2=80=9D in the basement, if you care about that). > https://faultlore.com/blah/tower-of-weakenings/ You can also read the docs for the ptr module: https://doc.rust-lang.org/stable/std/ptr/index.html > On the topic of difficulty, even if there was a full specification, > it might still be difficult to work with aliasing in unsafe Rust. > For C "restrict", I assume that "restrict" is fully specified, and > C developers still typically avoid "restrict". And for unsafe > Rust, the Rust community helpfully encourages people to > avoid unsafe Rust when possible due to its difficulty. This I will not object to :) Alice