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 AA6F1C4345F for ; Thu, 18 Apr 2024 23:05:25 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 29EB96B0087; Thu, 18 Apr 2024 19:05:25 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 2285A6B0088; Thu, 18 Apr 2024 19:05:25 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 07BB66B0089; Thu, 18 Apr 2024 19:05:25 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id DA3D56B0087 for ; Thu, 18 Apr 2024 19:05:24 -0400 (EDT) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 5FC99A0179 for ; Thu, 18 Apr 2024 23:05:24 +0000 (UTC) X-FDA: 82024185768.29.9504136 Received: from mail-oo1-f44.google.com (mail-oo1-f44.google.com [209.85.161.44]) by imf01.hostedemail.com (Postfix) with ESMTP id 366F54000E for ; Thu, 18 Apr 2024 23:05:22 +0000 (UTC) Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=ZCOkCf1e; spf=pass (imf01.hostedemail.com: domain of boqun.feng@gmail.com designates 209.85.161.44 as permitted sender) smtp.mailfrom=boqun.feng@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1713481522; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=hvHGL8IFMHbrcf+pVPbylnOJOYY5+Yhex1+9u/nVOnc=; b=7mO7kiuoquFbjjI8ibpLz+d/pk+4B00XrnB4uPhIqKOmR+kLPzc8kTNHt3Cl54QfUEC98M lPuGXwSlOkU6h6Ev+QpID36UwmelNVFc9iB2EWuOD19B7gXAdus9lYzPBFwtJSPQgLuzWe 1uxF3BMomsMeuAaqpu2rdz3lIFw9fUE= ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=ZCOkCf1e; spf=pass (imf01.hostedemail.com: domain of boqun.feng@gmail.com designates 209.85.161.44 as permitted sender) smtp.mailfrom=boqun.feng@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1713481522; a=rsa-sha256; cv=none; b=Wc/PDDMFYDNQUE7XY6PcAiUHRDplInZSvCD3twavbO/IVXEgW3a8Jw9uSgKkeNHoXXVBb7 1k08InZxg9m+MRJ67OSexLyJMLxBo9FkevLIiwT+V3/UW7VaJgxDUi4CQruHtDH/W67xK2 uiZpju7yNAw0+38gqvG7txFjQroDh3k= Received: by mail-oo1-f44.google.com with SMTP id 006d021491bc7-5aa3f0fcd46so921876eaf.1 for ; Thu, 18 Apr 2024 16:05:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1713481521; x=1714086321; darn=kvack.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:feedback-id:from:to:cc:subject:date :message-id:reply-to; bh=hvHGL8IFMHbrcf+pVPbylnOJOYY5+Yhex1+9u/nVOnc=; b=ZCOkCf1ecnJma+tM9tHqZh3H+7DXd7h0EwvUM7WXIAxImiBT3cjTgX///7Wkg/o8n1 rdqx1skv7dhSIARaNEkkCRZMzaUMUo1PkKuBGFdIq5w6NblwukKgWSxRf7mO6m7LtDWH Z7Z0KENe+NuEFfKggodN39Y7PliIF1XrwwlnR9LdqYYToVy4utbFw2Q3d9sva5pwxT8+ WFlgG4mJD+7WhThTsi0/B274/hoqgnB0NimjOoVnBCWBoS9TdU184c6DTiN//st/A6nd fF/Awyq521wb2RU3phkA4YwWFZ+VpHhcCRJoMRNBFC9MmRgRyEaaMtHbsYx4XjGFBh0D no4Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1713481521; x=1714086321; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:feedback-id:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=hvHGL8IFMHbrcf+pVPbylnOJOYY5+Yhex1+9u/nVOnc=; b=F/tlyQ3QBX+qXNfJfvquh0l41WIa7OVvvZYLmYKiah7VHOcjF3WfgwiRqoW9SwwRsd L1ROk/HqqL5PqcEiQZntDLMH8L5Aa+rlu/xpguLS3a4qxegROfd33Q5naIZmyQmXWzd9 oLStrhS1fT0r85g6dm2o6w/172ZYrihmWLkI4kMFXdV/v1G9qyrcn5E07Mcqo9iWcjwD jWBR9k0zHkd2iJOAZtLlzLKwgb4c++RCm8topEgbJXCtH6aiJgZB5ARojfAhqHpC++rB ouSYOgpGw0+nIyjC9NxNG7IjC7t2FDSaSQ2rssDtxOit7l2QRP/Iw1uRPHyNSuGWjY3w 7OZA== X-Forwarded-Encrypted: i=1; AJvYcCUZ+oxu1njSP+YDW1pnDwrwWdIwNImHlw1jBvUjv9BJqEkzU34NlK6Vju1JlisX2R3tMLljVEU69UtXO9AaV+jIF74= X-Gm-Message-State: AOJu0YylxdIgohUcA9aitzeGRvMD03POeR9yVwErlGaDTuIE2O0W3X93 6+5bc/RD7Xgy956JxcEgFPG9/UQUbe4zGBTqipeFS0lD+3mrdHmt X-Google-Smtp-Source: AGHT+IGaGcAg7aUZYx8CG4VqIhha4Z9dYkC687PU2DC81EdXMDCwsAe7gdVQn3Y0qr2SHcuZQcwS8g== X-Received: by 2002:a05:6358:6a4f:b0:183:7f41:8c10 with SMTP id c15-20020a0563586a4f00b001837f418c10mr609589rwh.31.1713481521098; Thu, 18 Apr 2024 16:05:21 -0700 (PDT) Received: from fauth1-smtp.messagingengine.com (fauth1-smtp.messagingengine.com. [103.168.172.200]) by smtp.gmail.com with ESMTPSA id l4-20020a0cac04000000b00698fa74199fsm1068529qvb.1.2024.04.18.16.05.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 18 Apr 2024 16:05:19 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailfauth.nyi.internal (Postfix) with ESMTP id 587AF1200032; Thu, 18 Apr 2024 19:05:18 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Thu, 18 Apr 2024 19:05:18 -0400 X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledrudekuddgudelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne goufhprghmrfhhohhnvgdqohhuthculdehtddtmdenucfjughrpeffhffvvefukfhfgggt uggjsehttdertddttddvnecuhfhrohhmpeeuohhquhhnucfhvghnghcuoegsohhquhhnrd hfvghnghesghhmrghilhdrtghomheqnecuggftrfgrthhtvghrnhephedugfduffffteeu tddvheeuveelvdfhleelieevtdeguefhgeeuveeiudffiedvnecuufhprghmrfhhohhnvg epudektdegvdegvddthedvnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehm rghilhhfrhhomhepsghoqhhunhdomhgvshhmthhprghuthhhphgvrhhsohhnrghlihhthi dqieelvdeghedtieegqddujeejkeehheehvddqsghoqhhunhdrfhgvnhhgpeepghhmrghi lhdrtghomhesfhhigihmvgdrnhgrmhgv X-ME-Proxy: Feedback-ID: iad51458e:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 18 Apr 2024 19:05:17 -0400 (EDT) Date: Thu, 18 Apr 2024 16:04:52 -0700 From: Boqun Feng To: Benno Lossin Cc: Alice Ryhl , Miguel Ojeda , Matthew Wilcox , Al Viro , Andrew Morton , Kees Cook , Alex Gaynor , Wedson Almeida Filho , Gary Guo , =?iso-8859-1?Q?Bj=F6rn?= Roy Baron , Andreas Hindborg , Greg Kroah-Hartman , Arve =?iso-8859-1?B?SGr4bm5lduVn?= , Todd Kjos , Martijn Coenen , Joel Fernandes , Carlos Llamas , Suren Baghdasaryan , Arnd Bergmann , Trevor Gross , linux-mm@kvack.org, linux-kernel@vger.kernel.org, rust-for-linux@vger.kernel.org, Christian Brauner Subject: Re: [PATCH v6 4/4] rust: add abstraction for `struct page` Message-ID: References: <20240418-alice-mm-v6-0-cb8f3e5d688f@google.com> <20240418-alice-mm-v6-4-cb8f3e5d688f@google.com> <87dc4cdf-ccf6-4b08-8915-313aad313f93@proton.me> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Stat-Signature: 9t6h9tyfyhmp1xwmiac1zijst4d3ubjx X-Rspamd-Queue-Id: 366F54000E X-Rspamd-Server: rspam10 X-Rspam-User: X-HE-Tag: 1713481522-936795 X-HE-Meta: U2FsdGVkX1+n3HjnpXQ4rflwlShFLa4tlRq2sn1mznfAn8lqbIJG70hnmpOhg+Yvx/s1kYUh1zs9M0hm2isql5dstfO59bP9X+U+VAELeYqnjH7oCQ/xSGJ8hi4TPpVq/q0lPh4R2vdz5oVpRi9iZwClPfUI2j+N0KwA3c9w7DOytTyii8dvx2aWMl6PqoYbxn65dzPGXxF27cMGP3oiPVvN1Kp3rlhBY8leTM9MoxDMqMWYn4x9vBXtRk5FzAniAI6/2ZhZQAlWNE5VQSUrdHg4bNRoTGDuYQpj3xIfBoD5UZHH9WUiTdXDZuD/86c7iL467CYtDi6M+WV593B3sTwbHRRkXrmemma6dXmB39tnKXK7fGs0PsfehKicvFch9PFQvpqLvZZKs1631urjBSbsLMBisnh21HOTA/Kx+ttIBGF/cmNhaV8ZTuVUHvQHbs8HaM94ahBaafHAKFDV0SG7fYnL331Fr6pCLi0lq3FO9FaFjvBnVJY/SmS7kupJ7JVsdWU6JzNA+Kbd1JTQ5T4c1Lw5xmpPTDLvzj2DcOPHSmKWplH4XSUHOWNsce3cxlfkR08abivKl3ScZNQd3LlIOxZm8/gL3svCvMQWKeHolN07kzbGDqfR88oBbaiAFkWhgo6cU6HjuW/2MCDKLhpSMfAWXSUT14bdihSFu/mQA20VGKH7jU8HnDr0QKeG3RSIwKQrcfkgnInTa5vV3MziE3tcIO0TJXRYOVH8ayKsHnbOnilcChGmcOOvfc3HQQT+a6Q/vNSnGP/PizYmc6gB/EEq9eJzwMj6tKlHsbKS7OgXKb9MHGgIzkHasSHlarTMv5wQ2WyoEWdfyGLVSmvy7TywLFJ7elv2Ui00h7sWCyBqAtiqGYkBR7A+Fb8EdTBd/PoFn+A0Do4yIih/Io9W0fTdyj857oGM/K4s0cykYoOUOB7Ukf1OjtZbZH6RxKaNlRvXUi2G8mmS5nf fE4JqlQm Z/6V16C7O7ZGhfYWJ7V5g3K0gbPoGz97g6ZC9sSnJ+OI8bp8H6jPH8NMJv/hkmtJGzkA7eG9sVtmVyScvHsdpTRnRxnJ1rnCEAyg/iZQZMVAtb5qALUgssq+QKHsHlkr1a6/mamxkaL0nYI4r+xWGgqrDOKG7jHtlWgRV0ywwJd99P7CR8Z7V41dyjp6cI7BN8J06gyH075T3JSqvmePnjWY2qkICdlC9SUYdAjIU9Wk5pKYTyMQXR+e8oNc6dvmXuDHquJx1l3Hpx6ZKG37W71URTIBgQ8uKP996AeStC405K8b0jB67cgRqKcn0tNyFA7drGa1FT1cyRhKikMexlwhrFVEtYgP9FPp2CUz3yQuBGLQMAeHXVrsENIZOXTHu8DtvrMy5g5Qyj+kT/ZnvIfjPAS9sI/t3yOTvE7uYu09UXU8db0qVnGARlzzNg0b2a85dbUV9yGTAYWBLwxu0YRS1ScZIrMQ2Ioib0kXjKNoOqvNtYIo5Im3jXbPT3QafPLUO 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 Thu, Apr 18, 2024 at 03:56:11PM -0700, Boqun Feng wrote: > On Thu, Apr 18, 2024 at 10:08:40PM +0000, Benno Lossin wrote: > > On 18.04.24 20:52, Boqun Feng wrote: > > > On Thu, Apr 18, 2024 at 08:59:20AM +0000, Alice Ryhl wrote: > > >> + /// Runs a piece of code with a raw pointer to a slice of this page, with bounds checking. > > >> + /// > > >> + /// If `f` is called, then it will be called with a pointer that points at `off` bytes into the > > >> + /// page, and the pointer will be valid for at least `len` bytes. The pointer is only valid on > > >> + /// this task, as this method uses a local mapping. > > >> + /// > > >> + /// If `off` and `len` refers to a region outside of this page, then this method returns > > >> + /// `EINVAL` and does not call `f`. > > >> + /// > > >> + /// # Using the raw pointer > > >> + /// > > >> + /// It is up to the caller to use the provided raw pointer correctly. The pointer is valid for > > >> + /// `len` bytes and for the duration in which the closure is called. The pointer might only be > > >> + /// mapped on the current thread, and when that is the case, dereferencing it on other threads > > >> + /// is UB. Other than that, the usual rules for dereferencing a raw pointer apply: don't cause > > >> + /// data races, the memory may be uninitialized, and so on. > > >> + /// > > >> + /// If multiple threads map the same page at the same time, then they may reference with > > >> + /// different addresses. However, even if the addresses are different, the underlying memory is > > >> + /// still the same for these purposes (e.g., it's still a data race if they both write to the > > >> + /// same underlying byte at the same time). > > >> + fn with_pointer_into_page( > > >> + &self, > > >> + off: usize, > > >> + len: usize, > > >> + f: impl FnOnce(*mut u8) -> Result, > > > > > > I wonder whether the way to go here is making this function signature: > > > > > > fn with_slice_in_page ( > > > &self, > > > off: usize, > > > len: usize, > > > f: iml FnOnce(&UnsafeCell<[u8]>) -> Result > > > ) -> Result > > > > > > , because in this way, it makes a bit more clear that what memory that > > > `f` can access, in other words, the users are less likely to use the > > > pointer in a wrong way. > > > > > > But that depends on whether `&UnsafeCell<[u8]>` is the correct > > > abstraction and the ecosystem around it: for example, I feel like these > > > two functions: > > > > > > fn len(slice: &UnsafeCell<[u8]>) -> usize > > > fn as_ptr(slice: &UnsafeCell<[u8]>) -> *mut u8 > > > > > > should be trivially safe, but I might be wrong. Again this is just for > > > future discussion. > > > > I think the "better" type would be `&[UnsafeCell]`. Since there you > > can always access the length. > > > > Hmm.. here is the thing, having `&UnsafeCell<[u8]>` means having a `*mut > [u8]>`, and it should always be safe to get a "length" of `*mut [u8]`, > right? I haven't found any method doing that, but the length should be > just a part of fat pointer, so I think getting that is a defined > behavior. But maybe I'm missing something. > Hmm... but I guess one of the problems of this approach, is how to construct a `&UnsafeCell<[u8]>` from a pointer and length... Regards, Boqun > > Another question would be if page allows for uninitialized bits, in that > > case, we would need `&[Opaque]`. > > > > Yes, or `&Opaque<[u8>]`. > > Regards, > Boqun > > > But I don't remember how to get a valid raw pointer from > > `&[UnsafeCell]`. > > > > -- > > Cheers, > > Benno > >