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 6DCA5EE49A5 for ; Wed, 11 Sep 2024 13:28:15 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 06CE2940039; Wed, 11 Sep 2024 09:28:15 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id F3890940021; Wed, 11 Sep 2024 09:28:14 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DDB14940039; Wed, 11 Sep 2024 09:28:14 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id BFCAA940021 for ; Wed, 11 Sep 2024 09:28:14 -0400 (EDT) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 65D171A180E for ; Wed, 11 Sep 2024 13:28:14 +0000 (UTC) X-FDA: 82552536108.26.F19AE08 Received: from mail-wr1-f44.google.com (mail-wr1-f44.google.com [209.85.221.44]) by imf04.hostedemail.com (Postfix) with ESMTP id 6F91440020 for ; Wed, 11 Sep 2024 13:28:12 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=qrrYLPRC; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf04.hostedemail.com: domain of aliceryhl@google.com designates 209.85.221.44 as permitted sender) smtp.mailfrom=aliceryhl@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1726061177; 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=px4cSD8HQGH2wO4T6TnkDTDsLBmuGTU3jnHSj51SJ2E=; b=IDaQeTAKFzWSuRSgWvDuMueSxZ+7JIyOs9fjgKlNUdzJ8l7Av92kL6mld5rEGmO2vR9orP AcIS6gngmWjLQniqmVongCgjoqPXWF9gTmaWZffgi25OhvL/+9+RHkrdmyaYPYE7YPsrEU g3PgpfLJL3U7cxm1yUURqK5QEzQnHmY= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1726061177; a=rsa-sha256; cv=none; b=z29gvmWZD1Fv9c642TBZoBNNfYPDDymQHa47k254KIN2I2MUi1eP03VtBK2KUGvCRqPuNK FJNM723xBiXiNG/21jkUiYBP+t3OTyLHHSVeegt+BZMVLGI27Lh4fQW1ERiAecpSRBX0sW KLf1YtyCv7REdoIPJNboSnW+tghtV+8= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=qrrYLPRC; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf04.hostedemail.com: domain of aliceryhl@google.com designates 209.85.221.44 as permitted sender) smtp.mailfrom=aliceryhl@google.com Received: by mail-wr1-f44.google.com with SMTP id ffacd0b85a97d-374c5bab490so584389f8f.1 for ; Wed, 11 Sep 2024 06:28:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1726061291; x=1726666091; darn=kvack.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=px4cSD8HQGH2wO4T6TnkDTDsLBmuGTU3jnHSj51SJ2E=; b=qrrYLPRCFwtFRUSZkruyGoIpJb6hYYld8/YWFoLmnNPT9xojosK82mCE/37u9kPJ43 UpE2R8TEOz8qgICd+THTjvy8nsOufuVDm2hU5LpEKwdJuyZbXiSs4rbUGqYEH0RAiGyw aiu/GvoMwhZaMPch3lqbiQNaWAfB0j8456aHkspi51O4C6umHgEMwf9hR+Mix7e66Wiw sDbZf7BI3e+cDqOzW/JwoweeEH8M8/76yEslBpHLdVGpOtUqNkc7H18CKZ3XrM2QeyNm NH8CmjyJ+L5W/l1yy9wP25pYNKnozrE6/HPyvg5lJBRRAuY4/oBcI3ZvWhKJcBOPl9XM CArQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1726061291; x=1726666091; 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=px4cSD8HQGH2wO4T6TnkDTDsLBmuGTU3jnHSj51SJ2E=; b=M0OjrVQPojyj+P2NlHm1YT4mLXBe4OYjUuaZc34yBvLTh1wSCuXvax35Rgqmb+xAR3 yqEeEHaO+Jz+M3RNlujQ8u9/N+xgzA/dQ3tzZvmTyJmRXUxe0zmaebUljLp5T/DhqJJf xEkaNF+5wOvOkkPjxCupzn1PvvGmCL9qLt1zeUKeGuqwH8d3PDi61xzVC/TgEYrDCpsK Oet7PxIcOBrgg6QXAbtdSPDLBs9OHc4I9AkyuYsiMp+ALBWHt6w4092J219BN9VjV62o SkSDOjyYnby6wYdJULU7VcAaVb82Sjprn3xMB9Uz0xkQfvuVf10UzXI8YbfdxrZ70vjD FLuw== X-Forwarded-Encrypted: i=1; AJvYcCVZsn0KQOxKXHky9WQ4cPJXG0B1zT0u7TbJDNy78OlWj0AfdPlnr5hguk4MDLLi38nCTMUsB1y/nQ==@kvack.org X-Gm-Message-State: AOJu0YxW9V3F8xrjiJGiUd4Eip24X8NhMsHlrpCaclqk3vtRzhU7GBbk UPeKeKb8CGOfQM5MsSPW8oslUu49oBqr2aujzHZZdLsERJWqSBioo0XaG4+S/7AUuKbjIev9iT6 tE/YseyvwOBSW9Xb96lWGmINfnMo7GLx4C/U3 X-Google-Smtp-Source: AGHT+IF7/qa6erGSnEBi7fIAOrWoIKy5LBtKxYx46O8lTaD8uJY5tg4G2Y2qvcaMrtOl7y3nlkrlm3fI+Ca7t7jxV0U= X-Received: by 2002:a05:6000:511:b0:374:cb8e:4b43 with SMTP id ffacd0b85a97d-378a8a8405amr3432838f8f.32.1726061290584; Wed, 11 Sep 2024 06:28:10 -0700 (PDT) MIME-Version: 1.0 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> In-Reply-To: From: Alice Ryhl Date: Wed, 11 Sep 2024 15:27:57 +0200 Message-ID: Subject: Re: [PATCH v6 09/26] rust: alloc: implement kernel `Box` To: Benno Lossin Cc: Danilo Krummrich , 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 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 6F91440020 X-Stat-Signature: u6qixuwyoxwg3ttu44x75cdka6pnfqxp X-Rspam-User: X-HE-Tag: 1726061292-720783 X-HE-Meta: U2FsdGVkX1/P3iPjw0KzROLgp7TkXzZs+7Db0zXZF7L1thFnhdbLnrENtIFPygkVmVTPRBViBAzwcaUu2/azAJXhJ9isiq65kjr3AVe0LsinmyF4vVsctc3SmA0o+1AcsQFYfYlOrbvZDbFdx5XW6a0JCBO8yoGU5l1tA81VaTM+Ej9dX7j0gdlclKchHREWFbpCobYqAMQikXHWGi7XYolV87um0ZyckybR8C2GcasgH17DICjGMDUk98d+0WsGQ88G8lXjI6mANaTKzpbGDVr3I+4+B01cqoi/+fK7nbDgHJV0nQo7QSAXanhlVmurpt6EeIrXxOkiy0T+a/fN6fsJ05OEIT2E13rlzCgPB5ZTPQjzAczZwbtXzz9e6kgevOf/PkOlmAj4q75oa6ErpYuSedmuDL9+AnIoKMUTBFA7UD+y3zDP1wszn6+bBUUuPaIy9CJq5MEYMizTqyPk/1yT5MiIO3W49kOsmgEwhn4LdlTdZrS+bul2iIyC9fKV/SHQKCL4h4k0TBo+pxoxl8o4saDsWXdlJ3B4uEO58W3RMDc6ByLB0QdIjwc4cprP9TcIHZ79EOT+VHZx9xpm2bU9Srzq6+KrkyOX+sCPtQK5P7SM/2eMeeY13z+ci49VsLgcH9JM2nFI7G52D5gndmK+er1IspDe6QWV85RroHaVWw7YI1j8eKBWfC4N/BZkEWMatDNhVJCPFT1+MqVIjUo0OXUU0OD1Axhszqq88WrB8ntYNpvptG3oqLsG9ffgbaP9AHmemO5Hc/1jufxaXaufr8LNp4U4q14fcWF8gS/ldY4Imo6jCf/nLpR4ztN4FDxo3/KRxGnsPNupo7t++FFoI0S0KkH01I1oDDzZAQGEq1Tvqc9okbnR37JpH+3fNr0E9E/zz0+iPwbb/CKzEflk5z4mqSF7Pf5q7+VXJWAJLUZr9b7j7Dbu2OKTK38HD1Nr6TrAmiOIHBsVU1m +PvNZ6wO VXxwVVeJWUvIB6Kpj8YEtRWXzhRO1qROn2Rho/fh+rkP+tDeV+NmrUFEP5bgfpnpTA6YK3EqRPZ8hETmzbGeC5v1FIoXLzmGwRyDDwyKuj7sFj7ez1bcee2xkOWHQDDeSKcx2aDVQH6j2SEjcliK3aiKRXOqMijCKgxlaNj9B2kY5/vuVMgv12Gb35uyc03oeTcaj9zgx7c5D7KbedSH6sxG0uY3+k+Nr3hvQr7Pvufi10vxo4nb0zc6XCTqEZhYBPWfAxySrf/nxqeJPsgP6f8ctSNaV6SOTUmycSArCKtrvzVcLzcKWLOdpwNPixeENh/XpeQbACeybg/VK4Ih+4eNpG60gsoncbUww/2WL6UHmdkpTxuJpdW/twA== X-Bogosity: Ham, tests=bogofilter, spamicity=0.022003, 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 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 p= oints 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 the= m > >>>> (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-zs= ts.html > >> The first iterator implementation has an alignment issue. (Nevertheles= s, > >> 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 projec= t. > > > > 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/issue= s/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. 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 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. Alice