From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id AC88AEE49BC for ; Wed, 11 Sep 2024 14:50:23 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 43351940053; Wed, 11 Sep 2024 10:50:23 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3E3A694004F; Wed, 11 Sep 2024 10:50:23 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2AB42940053; Wed, 11 Sep 2024 10:50:23 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 0B37194004F for ; Wed, 11 Sep 2024 10:50:23 -0400 (EDT) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id B9AE414155F for ; Wed, 11 Sep 2024 14:50:22 +0000 (UTC) X-FDA: 82552743084.29.63C2F47 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf19.hostedemail.com (Postfix) with ESMTP id 0D5231A0004 for ; Wed, 11 Sep 2024 14:50:19 +0000 (UTC) Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b="bU/sVYc2"; dmarc=pass (policy=quarantine) header.from=kernel.org; spf=pass (imf19.hostedemail.com: domain of dakr@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=dakr@kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1726066215; a=rsa-sha256; cv=none; b=krU1pPuZ0J/2WJ119JkLszFzlyUzAVrNjqsbEXg27ZG1bwecfbAabWua2Q28uWbYmTz8yD iLrH8vZMLM2h/U0sae8O8ojEuppSJB987J/Q/pah0VG0YqBE1HI8dM2I3qu/r4SmOLo0rx GlkR5qnPNq63yB2gOqY7mZC0ObURWus= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b="bU/sVYc2"; dmarc=pass (policy=quarantine) header.from=kernel.org; spf=pass (imf19.hostedemail.com: domain of dakr@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=dakr@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1726066215; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=8hp/fUOxd8FVGUXT2jJ9hyv8OAlHQssl27vPrrX0ooA=; b=BRXRRqcvAWh+EHS7pSTww1matBVEKUQ1QAFH4RBFh6KSZEwuJv5Mmzl1B2BrYbAXLzh+0J nCqv0dJFKZkmGn21tb6T1aONx7es3SrIWjjYcX6JaB6w34ITqAxy8R+JEMTJS501sLQTZr 3gdDmTGeciysCbEswsd0L1A3ycj3jps= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 63A875C0745; Wed, 11 Sep 2024 14:50:15 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id C0742C4CEC5; Wed, 11 Sep 2024 14:50:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1726066218; bh=5NUgVGZKhPsPWqKpyoN/ipsM7yaoeIQ2D1gjHv5lqK4=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=bU/sVYc2192PKf7Us9pOQty5kCoCfdUqYEKsDiTbLmYUKjTJ2rD/tYa3G0wzGs/VV aYY8jR+6BYZzAHFbvkt2qSuTdEOWpaTYlj3NwlCyfPHbDQyFCtAOZAoos5TYyMZyzB 5jw4lZ6Ec5liT19SJkV5nuxoOclkhanzA/Fd8vqbyfLpy8gkFu0sLyQm7g0nlCQ3mj asxDJHXOKzUQI5p6iiq92sl0XNIi5X9f/8YSgfydEjNnCbTvHG/X+soTPUv7VE04c5 j3mQ6likvODvO3CTpnmo5xsZWsXIBTvdirO/BzPPW5Fs0pYXukOkdXcevKLa3yYvdr 8kCnjFMpAF47A== Date: Wed, 11 Sep 2024 16:50:11 +0200 From: Danilo Krummrich To: Alice Ryhl Cc: Benno Lossin , ojeda@kernel.org, alex.gaynor@gmail.com, wedsonaf@gmail.com, boqun.feng@gmail.com, gary@garyguo.net, bjorn3_gh@protonmail.com, a.hindborg@samsung.com, akpm@linux-foundation.org, daniel.almeida@collabora.com, faith.ekstrand@collabora.com, boris.brezillon@collabora.com, lina@asahilina.net, mcanal@igalia.com, zhiw@nvidia.com, cjia@nvidia.com, jhubbard@nvidia.com, airlied@redhat.com, ajanulgu@redhat.com, lyude@redhat.com, linux-kernel@vger.kernel.org, rust-for-linux@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH v6 09/26] rust: alloc: implement kernel `Box` Message-ID: References: <20240816001216.26575-1-dakr@kernel.org> <20240816001216.26575-10-dakr@kernel.org> <0146cb78-5a35-4d6b-bc75-fed1fc0c270c@proton.me> <19d81a27-9600-4990-867c-624104e3ad83@proton.me> <77b91448-a21e-4e1b-9a8e-3d2052d79a78@proton.me> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Rspam-User: X-Stat-Signature: sx6w5ghabuagdtehrry4g1ipra9gmocn X-Rspamd-Queue-Id: 0D5231A0004 X-Rspamd-Server: rspam02 X-HE-Tag: 1726066219-885492 X-HE-Meta: U2FsdGVkX19/p9C1TWj+eoStRCEstJ6cdaLgr0MGtqkj1HjJsF/xbEa4AumA8phpaPY50vhlHztAq2+bw+PWtegphGxC9DTmXtixEpRnWGwY2E0V/rnwTRUE76Crw6OSGgvGrl9h6zUxvbeF7NziSSKwJzTkibPBxL9i3xYGoPGc8xPrDJCfl/GFkXGuZolz6E20mZX+GIbhLlbnhBbhLZT0EXFTGKXlBTtytBBgvEk0C1TL0nyMiG73XNfOnlr/Mjamv5o6PMfBzxAtDT41Xp6ZpQaQ0bKMXPuGkT3+h/Vt1XwJlkHCuUtqqFch9CDKHo29MHA7JrYLEtcxBNZvUE1cyzNt2JLxSKlLxYn1KBTaGiLSM6vtK80im4DTAAPNsItlc+4zE5HiEI2eQdf8VIsMuzAErnC6djteSzsXMRmbpfcnnKo/31s/jhxxna4Nrk5/9ucSbKyLS05K0OSaDrjj7RYsDusEKUeweL+fAyE6s4MOIGsSvcanOWFb0fqf6e9rTd0kgFw1BxWUeHyuIiKHw2ZPUuvdF5MFLVy4+pU9ewT9FDlVHio2+F/f7JVLKSd6RBtDecZ97XAMBbYJbFQulIg6Yv/sn0ZAmn9N0ooNhf0vRYOkteiIgtlO86DEJ/idlhc3j+1BrDrZkxQL4YSytajkreHngZeKBM9fKgMZMGa4mcueBM7SXaJ2D+xwGdhl49lXsJJt66fXx5EWxpaZVM1o4XxlNxj+9i2RiATLrqkuOBspIOPaJBKh66WMMyaLx4h4hwFX/DNcFrZxZ8QkczhAWcYSgvqlU6yvdG+rXt+a+NvX1g2hVeeT8nmaAjtk3NxPnFMFJYl9VIPO0zmgurt+e8F59svzumQBbTvPCYOmWYSEd/o9BzpD8/qFLZKYOYm5MOzYFYSMJazZHJHfMs6v9FOn1PiOJKvlsofM3+oDoDNRZX9WwrISO/tda6tqP1I6c4rNhHv2Z5N 59WjH0fO 4lUtV0jrK31A6pEWkRac15CZGQQ7l3+/G4hV2YYqyWg4kNb6UHlPeArhlq/+la3YO4JW9CCG+oGJD+hd21aRmUZEpXQTpkMpIVY0j1F9gCcsT2oVfJdDDHIVnWm4MXbMG0sCHnZnRc93sg/TrZzJ9ln8TV+TWf9cY1LvMZR1uSXNjpq0alKB0W18W3BeqiDgMclYhLbPPmvSLQ4imGqHbuo1oy0KnoQGO1GjrG4TiKmSLlTQW/R+FVcjlLyLmfuZ79S3jJc19nPMrdf3ADTm5o5Cn8ifkSupARTxOEf1hg9Qhe9VXGbyY2VbwIpX57RE39lh8kDdQ4moSlfWohuHr0/MM7FtPf2m9xhKsukwN1mjiMTa0C8+OOnP3Ml15D0lwhLXg0bJLUip5mCjVmhdKNSR3WGoQIuNT0P+oiaEI1x1D4We2POZ6thc78Qjj2dFsEsODR5zrvYSFBpY= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Wed, Sep 11, 2024 at 03:27:57PM +0200, Alice Ryhl wrote: > On Wed, Sep 11, 2024 at 3:26 PM Benno Lossin wrote: > > > > On 11.09.24 13:02, Danilo Krummrich wrote: > > > On Wed, Sep 11, 2024 at 08:36:38AM +0000, Benno Lossin wrote: > > >> On 11.09.24 01:25, Danilo Krummrich wrote: > > >>> On Tue, Sep 10, 2024 at 07:49:42PM +0000, Benno Lossin wrote: > > >>>> On 10.09.24 19:40, Danilo Krummrich wrote: > > >>>>> On Sat, Aug 31, 2024 at 05:39:07AM +0000, Benno Lossin wrote: > > >>>>>> On 16.08.24 02:10, Danilo Krummrich wrote: > > >>>>>>> +/// > > >>>>>>> +/// ``` > > >>>>>>> +/// # use kernel::bindings; > > >>>>>>> +/// const SIZE: usize = bindings::KMALLOC_MAX_SIZE as usize + 1; > > >>>>>>> +/// struct Huge([u8; SIZE]); > > >>>>>>> +/// > > >>>>>>> +/// assert!(KVBox::::new_uninit(GFP_KERNEL).is_ok()); > > >>>>>>> +/// ``` > > >>>>>> > > >>>>>> Similarly, you could then say above this one "Instead use either `VBox` > > >>>>>> or `KVBox`:" > > >>>>>> > > >>>>>>> +/// > > >>>>>>> +/// # Invariants > > >>>>>>> +/// > > >>>>>>> +/// The [`Box`]' pointer is always properly aligned and either points to memory allocated with `A` > > >>>>>> > > >>>>>> Please use `self.0` instead of "[`Box`]'". > > >>>>>> > > >>>>>>> +/// or, for zero-sized types, is a dangling pointer. > > >>>>>> > > >>>>>> Probably "dangling, well aligned pointer.". > > >>>>> > > >>>>> Does this add any value? For ZSTs everything is "well aligned", isn't it? > > >>>> > > >>>> ZSTs can have alignment and then unaligned pointers do exist for them > > >>>> (and dereferencing them is UB!): > > >>> > > >>> Where is this documented? The documentation says: > > >>> > > >>> "For operations of size zero, *every* pointer is valid, including the null > > >>> pointer. The following points are only concerned with non-zero-sized accesses." > > >>> [1] > > >> > > >> That's a good point, the documentation looks a bit outdated. I found > > >> this page in the nomicon: https://doc.rust-lang.org/nomicon/vec/vec-zsts.html > > >> The first iterator implementation has an alignment issue. (Nevertheless, > > >> that chapter of the nomicon is probably useful to you, since it goes > > >> over implementing `Vec`, but maybe you already saw it) > > >> > > >>> [1] https://doc.rust-lang.org/std/ptr/index.html > > >> > > >> Might be a good idea to improve/complain about this at the rust project. > > > > > > Well, my point is how do we know? There's no language specification and the > > > documentation is (at least) ambiguous. > > > > So I went through the unsafe-coding-guidelines issues list and only > > found this one: https://github.com/rust-lang/unsafe-code-guidelines/issues/93 > > Maybe I missed something. You could also try to ask at the rust zulip in > > the t-opsem channel for further clarification. > > > > I think we should just be on the safe side and assume that ZSTs require > > alignment. But if you get a convincing answer and if they say that they > > will document it, then I don't mind removing the alignment requirement. I agree -- I also wrote this in a previous mail. I was just wondering why you are so sure about it, since the documentation doesn't seem to be clear about it. > > Please see the section on alignment in the same page. Just because a > pointer is valid does not mean that it is properly aligned. > > From the page: > > Valid raw pointers as defined above are not necessarily properly > aligned (where “proper” alignment is defined by the pointee type, > i.e., *const T must be aligned to mem::align_of::()). However, most > functions require their arguments to be properly aligned, and will > explicitly state this requirement in their documentation. Notable > exceptions to this are read_unaligned and write_unaligned. > > When a function requires proper alignment, it does so even if the > access has size 0, i.e., even if memory is not actually touched. > Consider using NonNull::dangling in such cases. Good point. It still sounds like it's only required for functions that explicitly state so. And as cited from nomicon "This is possibly needless pedantry because ptr::read is a noop for a ZST, [...]". But, no question, of course we have to honor it anyways. > > Alice >