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 7C445EE645D for ; Thu, 12 Sep 2024 08:03:10 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C3C986B007B; Thu, 12 Sep 2024 04:03:09 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B9DF76B0082; Thu, 12 Sep 2024 04:03:09 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A40376B0083; Thu, 12 Sep 2024 04:03:09 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 839F36B007B for ; Thu, 12 Sep 2024 04:03:09 -0400 (EDT) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id EEBEFC0F36 for ; Thu, 12 Sep 2024 08:03:08 +0000 (UTC) X-FDA: 82555345656.10.EA20A0A Received: from mail-4322.protonmail.ch (mail-4322.protonmail.ch [185.70.43.22]) by imf12.hostedemail.com (Postfix) with ESMTP id 10A2740018 for ; Thu, 12 Sep 2024 08:03:06 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=proton.me header.s=protonmail header.b=C4CwBt63; spf=pass (imf12.hostedemail.com: domain of benno.lossin@proton.me designates 185.70.43.22 as permitted sender) smtp.mailfrom=benno.lossin@proton.me; dmarc=pass (policy=quarantine) header.from=proton.me ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1726128082; 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=Xq9/zJGImDodUK6APv8rmLUXRYQWoOSD8nL+qHMbnYM=; b=D597/EshJALnY6K1q7464IdGKMb+F1W4zF4qgQXIS6UiKcq2+GBixIVxQ4s5bPcTnQE2vu K5x6BkR8f8bfW1ydAj7Yt04oD0AUxQ14RKxF4kg6J66cfg5jyAVpkPgvbclXIgrq20Zfqk ds0Db87DNpgE8w3OyMEI6xkaZ4aEioY= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1726128082; a=rsa-sha256; cv=none; b=ZcHfuwO7Mj1jwYuGtmq4w7Frxq0/oCi6v+Kr36f0vfmd2m301wGJeZhBFhelw0P4lCPqDg dDNqUBQbp9/BEQOgYQ/o/e8GYChFH/NMT9C/mNV/vndXVgpOak5Qb3SR93aa4T4r4sJuyD hdoJF0N567jSoQ7vdhsFLxGnZLKNDnE= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=pass header.d=proton.me header.s=protonmail header.b=C4CwBt63; spf=pass (imf12.hostedemail.com: domain of benno.lossin@proton.me designates 185.70.43.22 as permitted sender) smtp.mailfrom=benno.lossin@proton.me; dmarc=pass (policy=quarantine) header.from=proton.me DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me; s=protonmail; t=1726128184; x=1726387384; bh=Xq9/zJGImDodUK6APv8rmLUXRYQWoOSD8nL+qHMbnYM=; 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=C4CwBt63SnffFih3hoIpqHY1Ol+QUlLNiK1Q+9okWe+1BRA9KOKE8UeiPBL+XThbs FL478P4CStuTWW52UhdZh7oN5WZQc5VoAZCjeaPOGgvIQdCaSdUEQonz5w1KqxD7zi 8CEc5LDTJq71hMOGRm4QpK+5gh+zINCc6D0U3SujD/knbVjTWFDRnfE68D0sghCyww 2RSnyJQp/Mt31JdvquLUCF2xjdVGNfMkjdupd4AfI7Yk16bUeXWE0ErHA5tdqrXLma wyoY0PmWm2HcmMSPMZfSqrabiWWZCgjbzrZf+goJyruCVKuk0ouIiW+O3dcsX9KESC 4oq7ktDf9Z16w== Date: Thu, 12 Sep 2024 08:03:00 +0000 To: Danilo Krummrich , Alice Ryhl From: Benno Lossin Cc: 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: <58c81781-65b5-48ab-9c4c-b4f2dd014445@proton.me> In-Reply-To: References: <20240816001216.26575-1-dakr@kernel.org> <19d81a27-9600-4990-867c-624104e3ad83@proton.me> <77b91448-a21e-4e1b-9a8e-3d2052d79a78@proton.me> Feedback-ID: 71780778:user:proton X-Pm-Message-ID: e1b1c981f8d8dd5b13dddd8bb98baf557cdbfb28 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 10A2740018 X-Stat-Signature: dcafkmh3y3o6mc4gpp186us6i4d473j5 X-HE-Tag: 1726128186-562538 X-HE-Meta: U2FsdGVkX1+ILUBQiHPtqAdtXMclD8c3RzOHgxY79yOrjFv+PEhH/Ojc09fctjoZ2AVQrdn/8MtXwu94GQcAMaSpciOoc8ORXpXPeStTS+UIRcgbl3zngJD0xjabRAcNxpxaZDr1yl8WJ246aFZssmn9ftVWLsAnQ0TPoNmYWaDJDnwjy7NR42+YXbPl0NN4E7FZh0JKwz3KsyzxAGOm79/QfwwmHLtCs002QvuBDJAh+r83YBRn+++8759LSrf8tq7rtEWusmIMR22uaWT4ToVTJXwsGVzb2DUjVCaTiSPRWy5rXm4s+CpvxLddbrKd1RFnNBwMkgHQeBb9RaX/KLosCRD7pvCVhcPexR+kubLWNsxHXMTmJ8SvyuoPk6eIvsuUMrKdaCJIQtz9oGHRSR48zRvWZ+YFcnddfi1/r4I9WBTARA5sHxioXpdQCix2Hoyt4B6Ru9wfoCnuSIKN9qJ6K/oERFuDtN4uXIZaxcM2CMvEsV2zRcBbdZ7iYnhnjKA8vvS7P5hOBuO5KveR6/zqKOSQNtMpGoCIWY5c3yTs2OVeD1MNBpHxVToFRLp3LEMjJPyVOQURqFUuZTp6/oX2LQUGtJ+KwEeWkoJtPkjsBkd9Nwc1WWg6sURizbkN9eGnVfpg2ehK3D6mV7flYHeYlVHYrMWIjsV3d379m4TKk1KK85AWEbsuFhd2nDUI5KN0BKTNe9Hs7ZVYRgw49yIUSo7Lo+V6rixLTijdxtyXne7znCZFXpBa/KqXob8ibnifE0KxQ/jnyYGeA7qdwG8RAtWcGz5uEcLRfuFTROo/yZPpHds1wqIDJKuZ5ALoSybLWvdp+OUI8rfZ5vBKd1bXVlcij1Wzp4JmCrJwY9p/27Bp+Z2UxtCqp46HY7ubIuO9kL7jQgQ7HSj6rnUPsl4B3O7X5kzG8kX8s4KotD1AN5cM2a2tI3M3xQSrbuO/EN3Qr5FZZj6Njpw/Ccu bJEgiE3c 43nL/GORHazcCBhq6acJN+Kku2yT9mcUVAL2Eh/cXi+mbaiJHGRKwnH+fJg1FQh1gSLuoWLOqHrgfTx/7Ec6S9iyfknitOXoimeNItVF+jfnXazloqhDm5wiZe3fn6cmatHnJMGMkg5V7dQW1IDex/B3O/dhTtxiHXcgVS6c8n+PzbvVuhTEP912N7TUb8JGj67sNYuoqPE11rnm5PIbxp0Of6a1AqvvdrezxQv8YkidPFbZSaH+djpdkk9SkFD6Td3gCafKgu6T1lCYeO9wTYp2X79PHIqJMtzQsdm55PVVnMXhx9ZCZGt3Ic/CnwKyhthhqVyyU0HovW2W+zFsboJOV8aLpGczz3LX7Yg63WdHT8mwLZDtLPaUpuqDfngA2AE5tMGGU3fw8TEREffqRUPOVnEKCPIefZhgFduyc9eCsWux7b3mzyXDzyQcpumCQrElw3izcl2C/l1/w8Y7v04bsSw== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000001, 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 11.09.24 16:50, Danilo Krummrich wrote: > On Wed, Sep 11, 2024 at 03:27:57PM +0200, Alice Ryhl wrote: >> On Wed, Sep 11, 2024 at 3:26=E2=80=AFPM 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 =3D 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", is= n't it? >>>>>>> >>>>>>> ZSTs can have alignment and then unaligned pointers do exist for th= em >>>>>>> (and dereferencing them is UB!): >>>>>> >>>>>> Where is this documented? The documentation says: >>>>>> >>>>>> "For operations of size zero, *every* pointer is valid, including th= e 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-z= sts.html >>>>> The first iterator implementation has an alignment issue. (Neverthele= ss, >>>>> 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 proje= ct. >>>> >>>> Well, my point is how do we know? There's no language specification an= d 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/iss= ues/93 >>> Maybe I missed something. You could also try to ask at the rust zulip i= n >>> 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. >=20 > I agree -- I also wrote this in a previous mail. >=20 > I was just wondering why you are so sure about it, since the documentatio= n > doesn't seem to be clear about it. As Alice found below, the documentation is actually clear about this. (I think I read it at some point, but forgot exactly where it was) Maybe it could be better documented that dereferencing has the same requirements as `read` (or whatever they are). >> 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 =E2=80=9Cproper=E2=80=9D alignment is defined by the poin= tee 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. >=20 > Good point. >=20 > It still sounds like it's only required for functions that explicitly sta= te so. >=20 > 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. This sounds to me like an implementation detail note, not something that a caller should consider. But that's my interpretation. --- Cheers, Benno