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 89CF2D6EC00 for ; Fri, 29 Nov 2024 11:44:27 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E583A6B0083; Fri, 29 Nov 2024 06:44:26 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id E08486B0085; Fri, 29 Nov 2024 06:44:26 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CCF7B6B0088; Fri, 29 Nov 2024 06:44:26 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id A9DED6B0083 for ; Fri, 29 Nov 2024 06:44:26 -0500 (EST) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 2FA361C74BD for ; Fri, 29 Nov 2024 11:44:26 +0000 (UTC) X-FDA: 82838949228.09.35479BB Received: from mail-wr1-f47.google.com (mail-wr1-f47.google.com [209.85.221.47]) by imf07.hostedemail.com (Postfix) with ESMTP id 036F440010 for ; Fri, 29 Nov 2024 11:44:15 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b="nG/RgilQ"; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf07.hostedemail.com: domain of aliceryhl@google.com designates 209.85.221.47 as permitted sender) smtp.mailfrom=aliceryhl@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1732880656; a=rsa-sha256; cv=none; b=EeMNwpkra05MNoNPbZDuD9R8jYrrm9Ze/TQedBqNVK86XQzf8SGNF0mMzvHw/yCNcSou0+ GQqTueyZFfPbj7keDwsP11rJtZpsXQv1C54aLrVj48HRXJaudrDu6OqnxWdoURCEZgwbc/ WAx1CzMrtthwDGYJ6afaaRjNTQCOw70= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b="nG/RgilQ"; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf07.hostedemail.com: domain of aliceryhl@google.com designates 209.85.221.47 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=1732880656; 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=OQ73yuMOKPHbjjTrctlmL2Ii8jjSbh3c7dyfWFA6sg0=; b=xOe4Z2YTEdIvVDv5kFT7vPRp3qbKYQfkprHB6sclLtQoz/Z04Zo8HMf7lu0nKtbGvusgEf QGLdzh0xyfIevqctpWALAYuRooWxdP6096oT1fFX8H490XVtQNnxCczs9/I0J2Z2CL3ZI1 jofD2w/sxjjVTLow2zT+VHBuNu623Uc= Received: by mail-wr1-f47.google.com with SMTP id ffacd0b85a97d-385de59c1a0so601977f8f.2 for ; Fri, 29 Nov 2024 03:44:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1732880663; x=1733485463; 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=OQ73yuMOKPHbjjTrctlmL2Ii8jjSbh3c7dyfWFA6sg0=; b=nG/RgilQfLpIE3WcuZ2ZUeiVE1z+NRweNjhk/L2fEtff2D8KnwbOBJQy+YJVVLCOWY Qv3FuExU1iC6b3T3M4YkBWL4ZUIJvE7i3c9/MbicEalQ7P7Rlma7hPJI/ZXQZvR4cIrL CR76g5azQdlQlJsGjEK5Hoq2sJ1Fkw3/vyJ2m1TB1mSsCxSdja9xNv9sOjRFG9XNXajV 4DZdPy1BQnmQufpvwyNEReTppZdnkQxXz3F/3Lf4cZp+IqPlnTkvvOOKSomqQbA7d9zo x3XMK45gZO2ETCzwRHbE8wHUDEgJGA2R1yiM83sw8mQCuq+fXSKItm9UKcoXYkiWC6jW lI1A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1732880663; x=1733485463; 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=OQ73yuMOKPHbjjTrctlmL2Ii8jjSbh3c7dyfWFA6sg0=; b=T7lz4uoBWc3lHFieKFPidyOEqBcPYY0EEEQbQkPg6WulrjkUVB796tXXkbZcKZfZ4z LD9Q4Dw/QZbYmSDjMQeBrp9rVS/V1BCs9DQj0RCm1Z37kWsTftgewdHT6eBLat4rMSH6 qOdkYlAzgilzA7FV5NwLJDjhd30j/QzmBYvndOOZRTQEL8cFYweVGUn82hyGKU1DPnyA R50YZxIW30bH/sAg/9E2PL3LVkAmOzlNpayxg1t+xRg+AK/wjwsvINzic+XTf/cO3OUt XtVgJkEE1jUwACj5lhEW2rmx9fKrMPqRWE5bzw4gd8XZevspJb0cS66+bqxPgrc422PD NeNg== X-Forwarded-Encrypted: i=1; AJvYcCWMR7hfJJpnY6vh0Nb4x7BEjI0BNoh5Zkf7aUpfdXV9PuD4mlFoJYZackMQs2NTvtLUWrQO7hhBuA==@kvack.org X-Gm-Message-State: AOJu0Yy2sAGlENaN5rthHJpG3AUnKe5brgE58Wp5khl4+V+qMmd+tDJ8 LhUn7HtKK3I5J6NqKLkg2EFw0SbXKcuNLdbpWsZbD7jW2WtHb2c3b0luzSmhemr6lIWl8+5VbE4 9NI7wwartj2axEFLQ9kbIRD0GQ+/ArUuBH4js X-Gm-Gg: ASbGncse9PELhgLbctsL3VYoNIsKsQAyM/6IfOe1DrYDAsoHc5ZeW2omgCVoobBu37p ti7xiS5h8t3rSUMso+1FF+1M7Tjs7uImsZj98Hy6AnfJRN8uj4O+p+lXpoplL9Q== X-Google-Smtp-Source: AGHT+IGVnUklndpXhdyscMxG8htYeF72cv7+U9W4dYUy8Ks1XP/gpsHYY0FVa0X3H1aDKz7Spt7IggS5LohLKWzjv4I= X-Received: by 2002:a05:6000:1547:b0:382:4a8e:b81c with SMTP id ffacd0b85a97d-385c6ec0fefmr10140400f8f.33.1732880662644; Fri, 29 Nov 2024 03:44:22 -0800 (PST) MIME-Version: 1.0 References: <20241122-vma-v9-0-7127bfcdd54e@google.com> <20241122-vma-v9-2-7127bfcdd54e@google.com> In-Reply-To: From: Alice Ryhl Date: Fri, 29 Nov 2024 12:44:10 +0100 Message-ID: Subject: Re: [PATCH v9 2/8] mm: rust: add vm_area_struct methods that require read access To: Jann Horn Cc: Miguel Ojeda , Matthew Wilcox , Lorenzo Stoakes , Vlastimil Babka , John Hubbard , "Liam R. Howlett" , Andrew Morton , Greg Kroah-Hartman , Arnd Bergmann , Christian Brauner , Suren Baghdasaryan , Alex Gaynor , Boqun Feng , Gary Guo , =?UTF-8?Q?Bj=C3=B6rn_Roy_Baron?= , Benno Lossin , linux-kernel@vger.kernel.org, linux-mm@kvack.org, rust-for-linux@vger.kernel.org, Andreas Hindborg Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 036F440010 X-Stat-Signature: 6yqgbun577nm85t4hgpmnosk9kaq7p3m X-Rspam-User: X-HE-Tag: 1732880655-50537 X-HE-Meta: U2FsdGVkX197/vHvud+dzvEJM6RGvX7J5l8yARbWM+CHePxm+Np7fHpkABn5hqvCZPaq/YTpX4s1xPzLtcWV07TFW2Iue+9tJpVFYNR5Bmspbb7CoFVNeLTW0TxYnVGu/sWE8wR0hQUE4pP9a7zvZz08vhxEGhVQigde590SzOtM0NUkmjlE9aRutumS+ehONV4x7jF6sOWi5vuXMlR3BXfEURZ5NQjsAxxW0+/7/r4SaRfQ5dme0yNj+TNJeA7yA5rjqRK6bmc8PzKKlX2Dq2XmyxW1w802VZWvgFLh0VK3UbQeMCJLiWBP+qJHbyYMIiZ7E9RADF+pUoaaj3sIBPtHLJy1vQARtUh2/X0bS/N8EOm3Mh14qkE7zVxsMQ2OHwQuJx2AIEOUOOPwf3JyZHmyMzCSA7EBhW1J8v2Uhwe+rWfqPldLE1Z4eWoxCBlfDBLdK5px+nHPGGq+Axvxx8p9KfTtHNn/Aea+Y7fO+oliiVMLonK0kEXY5MMPu8uPStKx+OLxkyA0OZ9Fp91PPra9usRBTkJnQJzZ6C5fa2Isqbfyr7AEprRnRhLW1ZCi0lVBBDAJYHeoxVmOMkHzP5BkEuDo4EyvOUXLZP9xfdci2STCoa/mPkeVAbefyOLj2y61ppkxQ+fOJ6kCI8kLZT2dau6ZNOAC7RS4rWwxv3Ryre5R6lAzrCCNwa111xv8nEYmjOssWqgLfty1gzNkny4KS3Vn8XSH3eHqfimFCoPFqSFqspmuB+ALlTMd5khNK9D3zWpkg6Ksj/WE0NxohAauALhbVcko2AKm/YohG6y1TpDeZOLiPxxK5YPLcMvd2AhVzqimulMwIl1cJZPg9uFp0azaWPonSHSAm1TVXAGkaKGjyLaLn0VtfOutJOrb6BZ1AwhwSherS6UC+Xvd7BMYYkCrMXDFOwZEd0AFbe3ixiQTN3xDNpDTjreswV34EHWTiDy84OEAZKzywRU uVQYad41 wmXwxWe+IQVh4WyhS+UQK2JGIth7r7Ty6PuITIVGRaFIGwAeSfmfMUsXmZFbhoiHDx2TmMMk5Oab/ub7Enkgh9Xw96AtDIPqHLpzMMm8yeeHeECSBaorUh3DUpQEGHSusumJn2DbIsK8zwQldOlK8dvZoHD+mzZQN0+Co0FroPXhdPIfOIXNvN8QzMaXdMjZGgAA9ekfp7Pt6iQPGF5nY6Kc9TgmpJwlpHgurYnIJoZJINcN9Jz7h8+OVk+hGAdaleLgifRlkYunLlln41+6xZBMKE5ZPU2yeEV4TkOfNHAM/W+zz/Ek29UodRVeTJhpyP9tzHzZzBoy56TuD2COGaxhhZkUSTgGfoxhQWUarfzV3Wp8= 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 Wed, Nov 27, 2024 at 4:41=E2=80=AFPM Jann Horn wrote: > > On Wed, Nov 27, 2024 at 1:01=E2=80=AFPM Alice Ryhl = wrote: > > On Tue, Nov 26, 2024 at 11:10=E2=80=AFPM Jann Horn w= rote: > > > > > > On Fri, Nov 22, 2024 at 4:41=E2=80=AFPM Alice Ryhl wrote: > > > > This adds a type called VmAreaRef which is used when referencing a = vma > > > > that you have read access to. Here, read access means that you hold > > > > either the mmap read lock or the vma read lock (or stronger). > > > > > > > > Additionally, a vma_lookup method is added to the mmap read guard, = which > > > > enables you to obtain a &VmAreaRef in safe Rust code. > > > > > > > > This patch only provides a way to lock the mmap read lock, but a > > > > follow-up patch also provides a way to just lock the vma read lock. > > > > > > > > Acked-by: Lorenzo Stoakes (for mm bits= ) > > > > Signed-off-by: Alice Ryhl > > > > > > Reviewed-by: Jann Horn > > > > Thanks! > > > > > with one comment: > > > > > > > + /// Zap pages in the given page range. > > > > + /// > > > > + /// This clears page table mappings for the range at the leaf = level, leaving all other page > > > > + /// tables intact, and freeing any memory referenced by the VM= A in this range. That is, > > > > + /// anonymous memory is completely freed, file-backed memory h= as its reference count on page > > > > + /// cache folio's dropped, any dirty data will still be writte= n back to disk as usual. > > > > + #[inline] > > > > + pub fn zap_page_range_single(&self, address: usize, size: usiz= e) { > > > > + // SAFETY: By the type invariants, the caller has read acc= ess to this VMA, which is > > > > + // sufficient for this method call. This method has no req= uirements on the vma flags. Any > > > > + // value of `address` and `size` is allowed. > > > > > > If we really want to allow any address and size, we might want to add > > > an early bailout in zap_page_range_single(). The comment on top of > > > zap_page_range_single() currently says "The range must fit into one > > > VMA", and it looks like by the point we reach a bailout, we could hav= e > > > gone through an interval tree walk via > > > mmu_notifier_invalidate_range_start()->__mmu_notifier_invalidate_rang= e_start()->mn_itree_invalidate() > > > for a range that ends before it starts; I don't know how safe that is= . > > > > I could change the comment on zap_page_range_single() to say: > > > > "The range should be contained within a single VMA. Otherwise an error > > is returned." > > > > And then I can add an overflow check at the top of > > zap_page_range_single(). Sounds ok? > > Yes, I think changing the comment like that and adding a check for > whether address+size wraps around there addresses this. Hmm. Looking at this again now ... For one, the function returns void so we can at best handle overflow by performing a no-op. Another question is, are we actually okay to call it with ranges outside the vma? Does that just no-op or what? Maybe the Rust side should just bail out early if the address range is not a subset of the vma? Alice