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 482FBD6ACEF for ; Wed, 27 Nov 2024 15:46:13 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A69556B0088; Wed, 27 Nov 2024 10:46:12 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id A18736B0089; Wed, 27 Nov 2024 10:46:12 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8E0766B008C; Wed, 27 Nov 2024 10:46:12 -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 728C36B0088 for ; Wed, 27 Nov 2024 10:46:12 -0500 (EST) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 1E57C12178D for ; Wed, 27 Nov 2024 15:46:12 +0000 (UTC) X-FDA: 82832301300.29.ACE407D Received: from mail-wr1-f43.google.com (mail-wr1-f43.google.com [209.85.221.43]) by imf12.hostedemail.com (Postfix) with ESMTP id A178040010 for ; Wed, 27 Nov 2024 15:46:07 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=ORJh6XXd; spf=pass (imf12.hostedemail.com: domain of aliceryhl@google.com designates 209.85.221.43 as permitted sender) smtp.mailfrom=aliceryhl@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1732722366; 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=PXMPfZWRhjLS8qOrb4f6pSt8s/tpQyEcD7eDM+Hjasg=; b=AdNp6/bTs6qnEaEyfuCTIyzri7u3CdKLdBWrw7unPebGoa5r3V7pUHv6wiMAQmVaMYkU1k l0Fkw6IUASCjuv/yM/vJ7HfISZMTgVrGw3TRl2rsHS4cQryajD9aC+nd+ZtQvtKMWm9+L4 HYZCuaPi4MuxTTFwfWU1wJJzt61P5Qg= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=ORJh6XXd; spf=pass (imf12.hostedemail.com: domain of aliceryhl@google.com designates 209.85.221.43 as permitted sender) smtp.mailfrom=aliceryhl@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1732722366; a=rsa-sha256; cv=none; b=vlyFcko8LHsvUq7SqnnabLsO/wqUx812iw2/54BginWxoGMBxvp5yyvB2b2Fz6c1t34jgC sohjUQWH+SwaG/nWobBXw0V6vQBpgIcCYWQX/LOWTwHHpOl22oCLAZCgik0nKCFKCFXosg FZ7uM14AyudYqVT2qNvw48fnaRsm4Ik= Received: by mail-wr1-f43.google.com with SMTP id ffacd0b85a97d-38232cebb0cso5231739f8f.1 for ; Wed, 27 Nov 2024 07:46:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1732722368; x=1733327168; 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=PXMPfZWRhjLS8qOrb4f6pSt8s/tpQyEcD7eDM+Hjasg=; b=ORJh6XXdD86buWWuIowrg6BcMVHtqepG1Zx/XkinLbIm0xEz18buR5j0KwtiNV86Qr DjSp+4klX/PBjaeNTS87l1QE8JSkGtlIPG9D3rmtHNYsIgCyrCONLYa4nqd88soFfsJm 3DzCsyp4ChvA+Axg2jq+fPVAdZNXxsciGeCE8JGoKJ/KKSfJCIdtMmRs8vZkwqS2AG1c 7xCsJkhatTB9KP1F9rtRRupueYnoDtuc3/D7KOujo9VIuePyPxF321JEYWQTxY7ptAs5 kCKQgeiz7+XTC+aCzJ0OI/oJVFvF6HukS4BwNsLAWLlmvvL7kEt32E4tzp7pSys3Ql8p j5AQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1732722368; x=1733327168; 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=PXMPfZWRhjLS8qOrb4f6pSt8s/tpQyEcD7eDM+Hjasg=; b=j849xvJYSSqd04FVVTp33QKz3orAgMqkzpZup4szoqkpgOjXQbQU68hC8xfQSymXp3 4Pf+EhJ9ccaMOEboJM77SMOLFzAd5vI+fJ5nNiuXTbZ/umaeJQUuQ1rDCZ4XUZisMIlh v3KXzef+jYGT81aTNICxFLJQE4VrYZ9LIbw3S/BLR8mIZIAyPvCbGlhlxFjHbV/9NjfO T5WraTIU4FC0S7+DHIhKATDyfXN7Ev0XOhO7rHOvsItzSjRfZ4kJQGxspXtHyCCnsZ+u XPyFPB4RUNUyTfJ9KPYeDu2DbQSuLgJn/6xdeL+bwYKaYWmGLMCG3npmaQdpiB4i0UjZ jD1w== X-Forwarded-Encrypted: i=1; AJvYcCX8onB/n1ev7j8duG/J5YwsBMIjooSSZeOzsUR2iBxCJfK3byqwXlR8NgehZQUq+VXjuVZHFYNJmw==@kvack.org X-Gm-Message-State: AOJu0YyS3vjIf7bwpWUe2naEiRcl4KNfvZxeVw836s8wCF8Q2THC+a+c 0cq1hxFYnAE0mHCElqa93D52gdOcfzpzuWkzqWT7llSB+MCSATnFSDdRExguONYRDUt4X5wI9hK ZNTDklDfy0doRnqikwIF0ZE98nc6/8oK7AJcp X-Gm-Gg: ASbGnctCCHhhyatfVrs+zFcqV5DukoZkbY62MWkDXvWTE7ctCax7C00RlJUfLFiffzF ILtRcRGjhwHGYRv+9KYfDZz1zSdtfgpcu9Ok4oC+6B33ZKF46hTJ5n/Y2yvLpwA== X-Google-Smtp-Source: AGHT+IGDwrFX1rI3+Zmj9OqMkY68rfDsh0lNdwaGAF+wFEhJ3s/r1DcCWW7uJv3M/3bmy6ZbAMIuWWJy0I9D4wbOcPg= X-Received: by 2002:a5d:5f85:0:b0:382:49b3:17b2 with SMTP id ffacd0b85a97d-385c6ebf0a4mr2729408f8f.33.1732722368392; Wed, 27 Nov 2024 07:46:08 -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: Wed, 27 Nov 2024 16:45:55 +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: rspam05 X-Stat-Signature: e53eursk1u1zsq5r13ipucdztafjsdpx X-Rspamd-Queue-Id: A178040010 X-Rspam-User: X-HE-Tag: 1732722367-544201 X-HE-Meta: U2FsdGVkX19dpPHvGSZ/SW2oAARrbumE9dJd7YZsh3uOcOSy1HInSH1+RaH6UD2GWDCA3y3Uhd/2dJh60zKHkUT7n7rCr+Ua3vRvG/Y2GiPVHOrBICF4nNQpyDffu8U5d01Zgx1AatzM9tNW8FOp+zV0me6MJAQc4nU57Lf29EZxV+9HxUmdrmSOMO67Z+MWKYbmKBwVc/RfLCelT5EuBxMN5KOAuVm/1yaWBN47cFXnnE/8LCRqN9P/24auID0li5UOzpenBdAdiii+S9NGZxj1JS1vRdQpp3v4SVCdDy5YZyhlorLTTui45a8DSz2NOuISWeqkYSR2YqYZBZDixvHKoAz+G/nn6cIGTs1Aj16cIjlgIDDcAdczRrAATEnfSdH1IHLhaMqXDwqZVR2Wq00WXWvPnu3fKXqibEXA7dgxOP7JL4eKPXE0T/NB3DNHYo1ImkDcy21fltTry2AX2nX/QzTIdPiRiLKj56y59vmTIKeLhEGpgoROmcK/B1bshqlAy1E6UaCaEJL6BWqfgRYZgQsHFX9o0T42fsP8hQIUTKFONE1rbu8XLl0s9PWQOKY8Xd970HxQjIW5XTaT3LSWDalIaaV5ypPGKsT1Y7iCWaW6tGCm+vMSW/sbjOiaoJO+c9k6/mGzCIBUJ521Hjuyyh5ZKTpCGdENTWUNSC7KkVaEKH/Qqce/amg1ykmEMC9w8DcPMHUt/SgxG938uKNq+W/69c0ZDNMCXP8i0NU6/bv0EVZdFPB3dLCZEIf6fM8YvJ8Y7rm1pdcjLnDQOJ0/vSIYFti/2KFob5AMcyHYOoc4gPzoZNI5C2kRUjbr8djiqYz2gSVBNH7KNLdof0JjTO+duVatEGpV1flCCCxH7JOK24OKjbw9SLEDp9Sm7curiH69fdDnHjyvpzCSREY9MyPTi+5nbsT3hklMrkS81EzdogECMFzjMf0v8tWx/GFSh12kUf3HrYpqlsD makN/wPR 9SI3RTz21ygxHK7UBAUpEr1YRbZVFrimK9rGoj3XRsXeQY3isTctWkUZacQ+5T7yKLakGXU0JuoxwNqY2vEIQCRo+iKvEKIHq61lrneogYtQvLKFYYnnbaniUDWVwiZzQnFLYLVo96wXIWhEPjQ8MNpBKN56/euWHdzVSQ1CT24KZmr4BWJvrCWwtThdWkCtwq4OzoppUXuaXtJUSCVsDDKHDh119VYCRfMhoSHCfdMnO96voCLpmGJ+Izply/h4uhbcbIlvvFqnL6zljdmr6H3oKaT/4P0LFPvljqraMGv8yEfW9FzWrSInOuY6AOFS9VR7GncjXcG2ueDHFfbzi6BLlX7YWDn2rPHQle8OiBvacThY= 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. Can there be a page at the top of the address space? If so, I have to be a bit careful in the wrap-around check, because it should only fail if the addition wraps around *and* the sum is non-zero. Alice