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 5E0E9C47DDF for ; Thu, 1 Feb 2024 06:51:08 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id CC82B6B0074; Thu, 1 Feb 2024 01:51:07 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id C78756B007B; Thu, 1 Feb 2024 01:51:07 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B67C26B007E; Thu, 1 Feb 2024 01:51:07 -0500 (EST) 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 A76B46B0074 for ; Thu, 1 Feb 2024 01:51:07 -0500 (EST) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 471E340578 for ; Thu, 1 Feb 2024 06:51:07 +0000 (UTC) X-FDA: 81742312974.09.82FB6D0 Received: from mail-yw1-f170.google.com (mail-yw1-f170.google.com [209.85.128.170]) by imf08.hostedemail.com (Postfix) with ESMTP id 542C7160002 for ; Thu, 1 Feb 2024 06:51:05 +0000 (UTC) Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=umich.edu header.s=google-2016-06-03 header.b=SI7Y7FYa; dmarc=pass (policy=none) header.from=umich.edu; spf=pass (imf08.hostedemail.com: domain of tmgross@umich.edu designates 209.85.128.170 as permitted sender) smtp.mailfrom=tmgross@umich.edu ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1706770265; 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=r0VzwVbSa/n1qDmz4589AdSmL/ygOZFpk7QXNbXjzSU=; b=Z2bwNKzCPPZVsbJr2TpSrCtSg3Xvwh6JKRDnkxAQUwNieMJjaUtMpT8kGqcc3XwLrgKHuU t1ENCe+quZxD85rCwL4TWP2Zp1nac5NmggRHX5iHROZtSMzVHg8iLLBDBsS5T4vvSrhgqH yXL5b1gWaIi1Q72dT1VIuHbRiKVcZQ4= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=pass header.d=umich.edu header.s=google-2016-06-03 header.b=SI7Y7FYa; dmarc=pass (policy=none) header.from=umich.edu; spf=pass (imf08.hostedemail.com: domain of tmgross@umich.edu designates 209.85.128.170 as permitted sender) smtp.mailfrom=tmgross@umich.edu ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1706770265; a=rsa-sha256; cv=none; b=VvVgTsd4HYsxHM7b335YSILF9daXWZfn7TFXqXZb+n10kwnbRmPBmHoM/e+d/JGGE1wGSs cGTVapHUJNxmBQp9p/aRyLd3Zlu7lqgYoZN03Y5Md+2YIdXEuSQzMXENy3PBcCZncLtHs7 fEdiIWxJegWKHZqre7x+8k6hIwXK7Dc= Received: by mail-yw1-f170.google.com with SMTP id 00721157ae682-60413de7474so6375367b3.0 for ; Wed, 31 Jan 2024 22:51:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umich.edu; s=google-2016-06-03; t=1706770264; x=1707375064; 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=r0VzwVbSa/n1qDmz4589AdSmL/ygOZFpk7QXNbXjzSU=; b=SI7Y7FYaUP2nuYSjTC1YzpZZUoK7Z10yHWlrabmi1AawCZ65B6lMHWhK7qIYwnQQnZ GEVBbLWFcpVSQb2PygTSLqHNvf885dJZ5a+o1f6z8pA75DufxtLWU+sQJTyf0XjkdoWj S7CnvkOjpdY0dciQn8+Ia9RGXZQozuqieCeYjS6l/hj4JbUu3y6lhRu1YADAsncbY98l F34X2jdW/A6qNsZOREZTKsJ4UvT6Ij1BriwNA0BWowM8W66cscx2rFi35J3gT+H108wC XnQoELIVoi5yYOpwwba4G7enziXBzr8ru5BWFjuyZQTKOYET71ELZnb5hADpghHUAkYX 1QUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706770264; x=1707375064; 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=r0VzwVbSa/n1qDmz4589AdSmL/ygOZFpk7QXNbXjzSU=; b=fPfNA0Y3e7eA+W4fKIn1Sr/tIOjMTM0cqMqhkmf/wirGjgZTBFMgEyDtBnwWISTWo7 uLC4hldjYhSS69/letMFSYNuFB1CK/uyoRJYigGpnpBr1lPncWYPOj42nyP7f+I++IyO M2elXHbvRoUPGPUU8rU/Mh6MBA1/6iZqGal+JIlNITEJSFtzuVX+Ja8o27wKYei6NwGW 6PRRP++mRRytx8QIUl67FWGflygQhs83LF4b4NGQ8Tyhj8Vvi1aimxSFapSD2SsRFqHS C5Z9Q8BsM7SRtO5+ZRk742JCWG6vz8wR5UTH69IzrWtPbz713XKlNnzpxCs840O/RyJu KEVg== X-Gm-Message-State: AOJu0YxCa4fphkO1mfelnZbTWm/ewDMuYcPZQVudamGs7nL5VHsTGibV jUSbAUGmXryObCvscUXL6ieFw1wlDF6Fgpzxe3D7+FUW6TBiasYcPMwkk5IrY1y1LxMythSXXcr NsfXQDClXL9Iv2JRc8KHWAWCfhRqRLb6RioB6gA== X-Google-Smtp-Source: AGHT+IEPGqm/Y0xYSHVANnXssBTUMPz3ZdBa3qhfP7xrY7cv7t5U8clp2+mPjqdB+Tw0QipEexd9/XI7bvCHxxl84/Q= X-Received: by 2002:a0d:e857:0:b0:5f6:4f5a:8bd2 with SMTP id r84-20020a0de857000000b005f64f5a8bd2mr3187081ywe.0.1706770264344; Wed, 31 Jan 2024 22:51:04 -0800 (PST) MIME-Version: 1.0 References: <20240124-alice-mm-v1-0-d1abcec83c44@google.com> <20240124-alice-mm-v1-3-d1abcec83c44@google.com> In-Reply-To: From: Trevor Gross Date: Thu, 1 Feb 2024 01:50:53 -0500 Message-ID: Subject: Re: [PATCH 3/3] rust: add abstraction for `struct page` To: Boqun Feng , Alice Ryhl , Andreas Hindborg Cc: Miguel Ojeda , Alex Gaynor , Wedson Almeida Filho , Gary Guo , =?UTF-8?Q?Bj=C3=B6rn_Roy_Baron?= , Benno Lossin , Kees Cook , Al Viro , Andrew Morton , Greg Kroah-Hartman , =?UTF-8?B?QXJ2ZSBIasO4bm5ldsOlZw==?= , Todd Kjos , Martijn Coenen , Joel Fernandes , Carlos Llamas , Suren Baghdasaryan , Arnd Bergmann , linux-mm@kvack.org, linux-kernel@vger.kernel.org, rust-for-linux@vger.kernel.org, Christian Brauner Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 542C7160002 X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: m5tsxukh65o6txu8tjksgrboeibtpigb X-HE-Tag: 1706770265-328726 X-HE-Meta: U2FsdGVkX1+Dv+OwFMCcp1Im1GD7ee1dcAfRj+ac7idQc91KJSalQm1T2Z0Lczvp6WePc5BcWJSo62f7Kc+t1Fk9BrMcW58ZX8i1479gsywn1FuaZkLKi1haks0dQkmAVLq07As1Zi2YBAX+pI8jqL2kkVLldTyNAQ9X2VWegdG96GLJoFY4LiFa38DWb60i14H7EYKY1fi1vPhcxzts+RXp4JjwX2S5gHSceEgMGvy021JA5XYDHDS+ELdHflB1aX32LbCnhAnOzC/Edm9JuBlKgN7YgfEUN522iObA6/eALo+ju0SkFGYtTteeFdIHB+SiGjPjkxi6CsPA1PWSg5wqjHOWqd4/RWQM2h2et7szHgEkbhSGCfk7fnMo/w4DnrUNAk993pnYfP0mRZh0Sa3z7CrcYwOX/S7Jv3BfT6tOquCrjAyCae1Aj64QbGrizHsdeut+67wEQJUJ8ZiBsKkJgt5ALFqAwtG56r0UKQVNYwaLJegwkMtEed3ieXP59i0+xl+pbiLXv3TWKx1MQD+tqv0+xeoEDW4J+7Zs19gxBJAeu69zD2uvNqdEGjYgznDxNIHq9o9JPrhM+fcJRzs16YbGpFTjt0b6EqhWpi2oobN0x+6MEElHHSm/lbxuMKuMq1ekrASI0sDFyEI66Nw1RsT/nZV271LrRRae4VoaARHDNIgXUL9AdTsO771EG8ZC4N11BeuidFOqQg7ZTxhdehM00k0U6nu6BeEkYJoGh64jxrLqWIx+nIQ8JfDeVdHi+3EXClJRf1Wn4Rr2azq8fRNei5y1BOlVtlShXB3jZoKUTYJxzEDr4AQSfthj/JCtVgJLqkgvDPGcIOUxghd4I/AQYFLVfMrJUghLB7GDtlEJ+rpl1Cf2e4rQxGuzNmdGvSy6Sgepd5A3ibwZHpswdfuGSnOWONZes1evb/b78DoQkeZ+wB4IXZDHtCXw6Ay+SJexn0GiRkIPGZo zG9rEShq U6D6dfQ0iwgDDe8WpPSpAukvugGoH3AxXpAwHYjgy7JrswgkU1SE1YD2lx1dbyrrMHeGvL1zrq0hDKjySOOD5hy+hpaOIM0e9iz1MwH6v68Cq3ykQ1desXCJ3nGZBfE2OUabPlUMwBkI/uYu3xup0eWYUWy2tGRHo0kyjjZs4yQX71J2duCooXmF/p5c1PjRXSv+nl0iRJ5Q8YJTsT90YnfYaajEdbAaWIAIBzc43A1KbbyxhfY+3olD9wb9XZDFsnWB2uullF0r/231SoQgjfVQRumiplSn5W52X5N3F1yWoV4UT+txBWRkT0vU7gI0/PetQljotu8fYlh4nfQjj1CRI6Fk1ZRJHwVlr 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, Jan 26, 2024 at 1:28=E2=80=AFPM Boqun Feng w= rote: > > On Fri, Jan 26, 2024 at 01:33:46PM +0100, Alice Ryhl wrote: > > On Fri, Jan 26, 2024 at 1:47=E2=80=AFAM Boqun Feng wrote: > > > > > > On Wed, Jan 24, 2024 at 11:20:23AM +0000, Alice Ryhl wrote: > > > > [...] > > > > + /// Maps the page and writes into it from the given buffer. > > > > + /// > > > > + /// # Safety > > > > + /// > > > > + /// Callers must ensure that `src` is valid for reading `len` = bytes. > > > > + pub unsafe fn write(&self, src: *const u8, offset: usize, len:= usize) -> Result { > > > > > > Use a slice like type as `src` maybe? Then the function can be safe: > > > > > > pub fn write>(&self, src: S, offset: usize) ->= Result > > > > > > Besides, since `Page` impl `Sync`, shouldn't this `write` and the > > > `fill_zero` be a `&mut self` function? Or make them both `unsafe` > > > because of potential race and add some safety requirement? > > > > Ideally, we don't want data races with these methods to be UB. They > > I understand that, but in the current code, you can write: > > CPU 0 CPU 1 > =3D=3D=3D=3D=3D =3D=3D=3D=3D=3D > > page.write(src1, 0, 8); > page.write(src2, 0, 8); > > and it's a data race at kernel end. So my question is more how we can > prevent the UB ;-) Hm. Would the following work? // Change existing functions to work with references, meaning they need= an // exclusive &mut self pub fn with_page_mapped( &mut self, f: impl FnOnce(&mut [u8; PAGE_SIZE]) -> T ) -> T pub fn with_pointer_into_page( &mut self, off: usize, len: usize, f: impl FnOnce(&mut [u8]) -> Result, ) -> Result // writing methods now take &mut self pub fn write(&mut self ...) pub fn fill_zero(&mut self ...) pub fn copy_into_page(&mut self ...) // Add two new functions that take &self, but return shared access pub fn with_page_mapped_raw( &self, f: impl FnOnce(&UnsafeCell<[u8; PAGE_SIZE]>) -> T ) -> T pub fn with_pointer_into_page_raw( &self, off: usize, len: usize, f: impl FnOnce(&[UnsafeCell]) -> Result, ) -> Result This would mean that anyone who can obey rust's mutability rules can use a page without any safety or race conditions to worry about, much better for usability. But if you do need to allow the data to be shared and racy, such as the userspace example, the `_raw` methods allow for that and you can `.get()` a `*mut u8` from the UnsafeCell. This moves the interior mutability only to the mapped data rather than the Page itself, which I think is more accurate anyway. Leveraging UnsafeCell would also make some things with UserSlicePtr more clear too. - Trevor > Regards, > Boqun > > > could be mapped into the address space of a userspace process. > > > > Alice >