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 6DF45C4345F for ; Fri, 19 Apr 2024 17:24:18 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C6DFC6B0088; Fri, 19 Apr 2024 13:24:17 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C44976B0089; Fri, 19 Apr 2024 13:24:17 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id ABE886B0092; Fri, 19 Apr 2024 13:24:17 -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 8EDE06B0088 for ; Fri, 19 Apr 2024 13:24:17 -0400 (EDT) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 0E1254157C for ; Fri, 19 Apr 2024 17:24:17 +0000 (UTC) X-FDA: 82026954954.28.E01EC9F Received: from mail-oi1-f171.google.com (mail-oi1-f171.google.com [209.85.167.171]) by imf10.hostedemail.com (Postfix) with ESMTP id BCADBC0010 for ; Fri, 19 Apr 2024 17:24:14 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=QeG+LnEO; spf=pass (imf10.hostedemail.com: domain of boqun.feng@gmail.com designates 209.85.167.171 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=1713547454; a=rsa-sha256; cv=none; b=iP18eNUc4Et+P57VmP5X42A+IQ84Sj/8807my9syUO7qp6ciQWz40AZh4KiXeS+llkEdT5 CF0B718xe1JSd5OXCbUITJqLDj3VGZrdn1RSRdgunxgNe8LB8Pg1k5wN7QrQ4/fpl3TVHW H80l+TyG96y1q1eayBErdCAqh/LRBPE= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=QeG+LnEO; spf=pass (imf10.hostedemail.com: domain of boqun.feng@gmail.com designates 209.85.167.171 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=1713547454; 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=Wl1RUdIK+yEUkdLv0005F+A+5B6IMLIV9UGoxVMvVCU=; b=3VHZ9xuSVxwTPnfDBz/u2rbbyg5luxtmlmtVcoyyY+jVBwvtr2Zj7hpVyouwe1bR0x9z3e 3Tnr/OPvsDIVxf8LrjP0pYIpnkfDKydaO2zFXrucy4OYdQ6yW5puPZwNBcXYv0KlC3FRLu hD+u7ZFS1Kn2ujao5gXfWsLHcbEclbU= Received: by mail-oi1-f171.google.com with SMTP id 5614622812f47-3c709e5e4f9so1494128b6e.3 for ; Fri, 19 Apr 2024 10:24:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1713547454; x=1714152254; 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=Wl1RUdIK+yEUkdLv0005F+A+5B6IMLIV9UGoxVMvVCU=; b=QeG+LnEOwmh0lbf0QZ33WR6ZXoI5Go76fvxf3urQPo6qVtqe3b50rw7hcKw/o8ftU5 s30ME3LF2XayMCiC+jOkSZbEP1QWoYsjJ7blxksWgo3+lGPNj2yqftbXDfiEnp1BiyFC jKJ9mQaUxUYfeq2cpc05klbOP4vOH/vs1L2t05N1Iz2MOj04DJiyeST/Pb2NXcNt2Ttf GGB5mQmmAH+y2H0GrF1Fd6IKQ0QNzCNOFP6BBH7Eucpwb0HgO91SYOqW50NgfUaajauN H7CDAFuiuz78UIVB6YKnorUbocnvh/JforzBVDpHNMXuHPZ9Wb8UJLHsyFnuMr4iq1yk 2oDQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1713547454; x=1714152254; 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=Wl1RUdIK+yEUkdLv0005F+A+5B6IMLIV9UGoxVMvVCU=; b=bTU2IPtjWvduLcuBd5XphsbTHaRi7Sthm0LvOPtNkz0NzO+79ww4uzEvE0lUd8I1CH 7DO4x7POeegYZoQAMTCdasI1FFxV6WQKIxnXP/jSGd1CCMk+1SuifPXKgl+ZjsUXxNZF Ae9KMbi9QDpSc/PD4YRs8bfluo/oWfAozPrYppU8tGDh7jOTnmqC0EyJJ2ePOxmdcFAD cacHU93UGwjyw38gzidp3/vBEGLC+rYbNMeqwS3r7c2xzlkxrohGhRCWYaWixqt0a3rI NXtPNr70WsUvrs6YYJjwfueLAoSSP8QGGrNoJIg+f0/Nvy5mlnlPNN8slOWABuXcbN7a 2wyQ== X-Forwarded-Encrypted: i=1; AJvYcCXL2a6qRkkTpNC+/gtD9TcX4keKFnocYi+RXWtC4O0WZOfyo/kBLL9tDzcDJuS+nlRyI4thE2ztddsmCW4HZ0xTK3s= X-Gm-Message-State: AOJu0YzHtR4Dq/3QxT7rNbVUbrz9ieUJB2jvn+gRbxZ4rfQavYibF9sr LEBrhCITLL8ucyfHMjGajtcvCU281vcgBykGBuIB+zByZrZj/i4t X-Google-Smtp-Source: AGHT+IEkTetvSYPIdmojYakGwp8F2J3lrbHRow5batA+rBhiFfPZCEjfol7f2JHkMK9xqf/GOmAn8w== X-Received: by 2002:a05:6808:10d2:b0:3c7:47e5:d10c with SMTP id s18-20020a05680810d200b003c747e5d10cmr3534845ois.8.1713547453693; Fri, 19 Apr 2024 10:24:13 -0700 (PDT) Received: from fauth1-smtp.messagingengine.com (fauth1-smtp.messagingengine.com. [103.168.172.200]) by smtp.gmail.com with ESMTPSA id x16-20020ac87a90000000b0043686104e87sm1761576qtr.9.2024.04.19.10.24.12 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 19 Apr 2024 10:24:13 -0700 (PDT) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailfauth.nyi.internal (Postfix) with ESMTP id 46F631200043; Fri, 19 Apr 2024 13:24:12 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Fri, 19 Apr 2024 13:24:12 -0400 X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledrudekvddgudduhecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpeffhffvvefukfhfgggtuggjsehttdertddttddvnecuhfhrohhmpeeuohhq uhhnucfhvghnghcuoegsohhquhhnrdhfvghnghesghhmrghilhdrtghomheqnecuggftrf grthhtvghrnhepjeeihfdtuedvgedvtddufffggeefhefgtdeivdevveelvefhkeehffdt keeihedvnecuffhomhgrihhnpehruhhsthdqlhgrnhhgrdhorhhgnecuvehluhhsthgvrh fuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepsghoqhhunhdomhgvshhmthhp rghuthhhphgvrhhsohhnrghlihhthidqieelvdeghedtieegqddujeejkeehheehvddqsg hoqhhunhdrfhgvnhhgpeepghhmrghilhdrtghomhesfhhigihmvgdrnhgrmhgv X-ME-Proxy: Feedback-ID: iad51458e:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 19 Apr 2024 13:24:11 -0400 (EDT) Date: Fri, 19 Apr 2024 10:23:44 -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> <079c88af-2e6d-45fe-bf58-afebbf7583b4@proton.me> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <079c88af-2e6d-45fe-bf58-afebbf7583b4@proton.me> X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: BCADBC0010 X-Stat-Signature: mfwpkzpr1sh8unzajaoqq6mcb15gsdcy X-Rspam-User: X-HE-Tag: 1713547454-18902 X-HE-Meta: U2FsdGVkX18Os5i8HJ+HDgzBs7mtFc3txUeDbhIQXfFP0lbuuLb2gjOUy8D14MrNl+IGrv3lZq/huq0tjbMjCNmCSlGZ3oAPbhWeD7tgAeeASBNMkkO7bRQ+9cULO7MHa05RIkLb1s59gqQ5DZJhSSWNvBaYuBp26HhzhDolOSPoMRGbCGrzhfvVxa2Y8LW31XdYkn/BlZNEFnk+s7vfKhZ+CY1k5qXX2clySFqjNEerJ3GX6fobOlevIHD8cJrvyIZmw5cZP0bXqRyDVWbA0/yCJQUYXCW9HPkG/KSitQ6qCgoJcAAfcIBgOMSXK3TcgIa5HK1kCKOms335deN0+I6paCAQfngXxcIjQEEYigFS1PBPJaykqiP/WAZqA/mXd4lV/D42iuOU/SLH7V/gywuP5IG/MMW4HJLvpEHAlfHcYFSqNyd4n+ByktXcspLMTCGR4ro497estT7mt43QWCiwm9qP28VAw4AWtZQUEotKYzkP0sho5++YtUG5k2rzbHG6Ka2HURfqL1ivJKfshAc9a2VNTr+TBTJaTQbnqaDoo2Jw5e7jqX6/lwa/60r6H0OPPwxEJlFLZygVdNxACq6eawtRx68E28qPC4wDbQNl6yMshiMW2sTvJ4JL3QstaigPAUfRQZfNi0mF/xLAxN9+ArgCex9lSoBqv84oFw5eo/pT2QsCe81OJeKE3eJTxJHXTi1p7dByXlE/XrfpKrj7TkumBjJ7WbjEd2d7g1Kd4WhS4mr+IfOoBz7ECpiX/8yhU2tfxnqUC6o+yhPpAjZOd4w5jpQWXQtmPsfosbENICcEhdAfqFsedC80VOajf8Lj2QAC1NTbkVo45Q+m2bPx/vjtYuocXb5s//OHD1GfNjKUH4TwkuVDmmWpTdXEUO+0s6UkaomGy3Jj3fnsuBNJ56R48kx/Ku+BLMdP1ED0OkExEZB7l7Um+saI7mat1H30ZyCtAh2RxEd7dUr wyXHs/sA SLdio+IRSAy6cr+eeR5EkV+W/GpwkvQVxtU1Lgk36VcrLKl14GznMY8clXC9ElGDHzCr4CIl2+11uUZRLuqCBnJumhDfXWyuotLysnFUgiFBWPJLWnTCjG5rFY0pCNbF8rbvZ3//fjolxbhe++G7Giz+oH2mkc8FsDskcTB36qQQU9g0KRhPzNeMDYsdXhHJs+B7DTA/whn6dATL3ZWQza5u5ggCdJm8nNsND+ZS+AgVaotQ4CioOgxzBcG3vLyQd6jZpTf96lwjfCqgNZCzsr4Xdtm4Eift0PHyadiABIOOnJk6dwqkZ/NgdKVUyfU+J/v37+2BBgFjZJNc87HUleAshg35HjrKB9qElrs6q2b8dFop1VPZK0Jukmu72Wh7OCohhv6biJ5zF/sUCX9M8DGgq00/3eeSWum0MEvqCWIiWaqqI7XLZQOmQf9x4mqnMKM7iwQFeLwEYazmnWAHcwm2TFwExIdlgyo6RASqh0GKjNe8B2sYfLd6UN80hcOr40b7JEbAVIWmyarPunme4+7QWhymQIyhPFYuxmXpRoUKpRlWnYKds5A9kYM3sAeHcI7YHqh2OUg/6dfHEl3qyKjBf4plIYUBoWgo2GFrpjAOpDLRfepHJm3An7wQ9PDZeQ7PqfKqNR4XdtQYl7yw76TFVJjDEOoVeupL6MVvO9bhkwsw= 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 Fri, Apr 19, 2024 at 08:36:11AM +0000, Benno Lossin wrote: > On 19.04.24 01:04, Boqun Feng wrote: > > 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. > > There is `to_raw_parts` [1], but that is unstable. (Note that > `<[T] as Pointee>::Metadata = usize`, see [2]) > Oh, that's good to know, thank you! ;-) > >> > > > > Hmm... but I guess one of the problems of this approach, is how to > > construct a `&UnsafeCell<[u8]>` from a pointer and length... > > We could use `from_raw_parts` [3]. But when making the slice the outer > type, we can use a stable function to convert a pointer and a length to > a slice [4]. > Yes, but there appears no way to get a pointer with larger provenance from a `&[UnsafeCell]`, right? > > > > Regards, > > Boqun > > > >>> Another question would be if page allows for uninitialized bits, in that > >>> case, we would need `&[Opaque]`. > >>> > >> > >> Yes, or `&Opaque<[u8>]`. > > I don't think that putting the slice on the inside is what we want. Also Hmm.. why? So in `&UnsafeCell<[u8]>` vs `&[UnsafeCell]` case, I think the former represent "a slice of u8 that can be modified in the same time" very well, and this is what a pointer-and-length pair usually represents in kernel, I think. But yes, the latter is OK to me as well, just hard to play the provenance game I guess? > note that `Opaque` requires that `T: Sized` and that is not the case > for `[u8]`. Oh, you're right. In case of MaybeUninit, it requires `T: Sized`, so `Opaque<[u8]>` doesn't quite work. Moving forward, maybe the first step is to see whether `&[Opaque]` and `&[UnsafeCell]` can have a good way to generate a pointer with proper provenance? Time to ping t-opsem maybe? Regards, Boqun > > [1]: https://doc.rust-lang.org/nightly/core/primitive.pointer.html#method.to_raw_parts > [2]: https://doc.rust-lang.org/nightly/core/ptr/trait.Pointee.html#pointer-metadata > [3]: https://doc.rust-lang.org/nightly/core/ptr/fn.from_raw_parts.html > [4]: https://doc.rust-lang.org/nightly/core/slice/fn.from_raw_parts.html > > -- > Cheers, > Benno >