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 91665D6ACEF for ; Wed, 27 Nov 2024 16:17:40 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E589C6B0083; Wed, 27 Nov 2024 11:17:39 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id E08E76B0085; Wed, 27 Nov 2024 11:17:39 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CD0436B0088; Wed, 27 Nov 2024 11:17:39 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id A934F6B0083 for ; Wed, 27 Nov 2024 11:17:39 -0500 (EST) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 5D95BAD26B for ; Wed, 27 Nov 2024 16:17:39 +0000 (UTC) X-FDA: 82832380344.03.AE8A32C Received: from mail-ed1-f54.google.com (mail-ed1-f54.google.com [209.85.208.54]) by imf12.hostedemail.com (Postfix) with ESMTP id C0D4440010 for ; Wed, 27 Nov 2024 16:17:34 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b="39/1hMn0"; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf12.hostedemail.com: domain of jannh@google.com designates 209.85.208.54 as permitted sender) smtp.mailfrom=jannh@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1732724254; a=rsa-sha256; cv=none; b=mtuTOSdNo8pDhXOg00tNnDMOZknKZ0DtA2oB3zSSq2z2Bf+F1+fZn7ir67GK2RNu4vqLVg ViGsYVMWL+KVLMEaRmRk8rg4dSOjU1luRlisxDM8Z2/t0HAcccaozPJ5jeuqUhHPfWxBfQ jmnoN7FBbp8eubVz/8WXoVbo+ht0w2I= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b="39/1hMn0"; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf12.hostedemail.com: domain of jannh@google.com designates 209.85.208.54 as permitted sender) smtp.mailfrom=jannh@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1732724254; 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=QZfqcNlPKbC2bnXSpyLfxx/nYb9jLK1fIKJvCta3m5I=; b=5hAplKCaa9S2kXzEY++v/acuEkAxUEccmsyxZCDc9woPGKdHOHdG9FVPwbPxBRvD/rOg5C HCN6uJlI7bUeVkRQvB0qW7bdYOX+tG83ZQUVD90qKCkzzG5IQk14WjI9X2EhVsLcUEJWVC iy8yF2tQBxGzatWCVFiYvNn3nhsfXiQ= Received: by mail-ed1-f54.google.com with SMTP id 4fb4d7f45d1cf-5d027dc53ccso10286a12.1 for ; Wed, 27 Nov 2024 08:17:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1732724256; x=1733329056; 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=QZfqcNlPKbC2bnXSpyLfxx/nYb9jLK1fIKJvCta3m5I=; b=39/1hMn0klIj8007xCuzXSt6JFdbqyOjuA2+RoXJ/kEsNpiwknwm9TSHdxSmGHiDbo YTYBcJA9VgAQnr41OKHx6dg5AY8dBxXtWeRBPZzvSNQmj/cA4ahKFIeXYBbXDX9SOtvd kH12fZAq3tzJQE9r/mbdHZVNsythxZO7Ua4/BePed05ewyhiynDFGL/s3bYezf2G8ID8 ITq2o7+5Hkm7R2HdlxSRNJih6VuaYy7QMK48qt3hLcn0K8P2OsjlHTN+4Ws/OU5h/RpG itOWJDLPVeoMhUidM5FCbPZ11f14u50blWHqUtqdVs+wbRxdf+o2yC2IAIekLUnO2jC0 r8AA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1732724256; x=1733329056; 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=QZfqcNlPKbC2bnXSpyLfxx/nYb9jLK1fIKJvCta3m5I=; b=TSfSPsWxWJKW5FMHOmoJZEyFLO80MgPavKnPaS3oFBT7xmovY5K4PAh7fti/U2m9ix yYFa4xrEoi/MTnH/i9bhXULO3ocxR7XhdsFuTkOvgsIMauQUzwiaAWR0k8OUw5QIVtC2 1rf/w1mEs+swXdtQPB6Ey3ce6t0sB91d0nXgNORzw4NvZE9o8LjHmMv4dsynK07htG2n t89fEyEWr+TvSUxCBP32AbAr/x8NMqOlrdlCZ3TVmMaXtbIPkvSJUCEt3caN7fjYFCQ1 52Z3VZiZ86DrfaBTjh103O5f6bV8pkXSNr00TYYJRdkcohnNqwYMGE57KIRR8gCbTAJ1 wbSQ== X-Forwarded-Encrypted: i=1; AJvYcCU2LGJqv9tZUTd8ffYr3OOBv7KAvTpBtt0T/elXIyQPFogY3XWpUoUyhX0QIwE6EUTz9BON9DQagA==@kvack.org X-Gm-Message-State: AOJu0YwBR6SG3bIWYhix0qQzzT9TS39vgLLkJUwapxKLf+oTT3QyIJZA vwGjVNQ2yok1cD9jpLbGEkHXYvPlQD9UNWg3Tgb4BkVgdzXEerClu/vVZNqYcgFn/cb1amntUsl THko0d00k6OJWscyBttb6hHCQUUxi3tcxKU/1 X-Gm-Gg: ASbGncvG/BrqH8Pc9Hu5OyFIymSux1h4NVrw0E97UUqRIQmsAhFgU0StAD+S9vST/j6 uUY8KV8lKsZZQCSX9cHsM8OjNTASNYluvoY+1hjY6sxhZ8bZkDYNWIxuwTk8= X-Google-Smtp-Source: AGHT+IFi4sjpJs/jiGm3WsRPclEJPb0VqSZyAZ6190zFqKsFlA1P7nnjtHWJJrmYhsCdQtveOqxd0wwWr/r4zunc7EQ= X-Received: by 2002:aa7:cacf:0:b0:5cf:c93f:36f3 with SMTP id 4fb4d7f45d1cf-5d08356e19bmr84170a12.7.1732724255341; Wed, 27 Nov 2024 08:17:35 -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: Jann Horn Date: Wed, 27 Nov 2024 17:16:59 +0100 Message-ID: Subject: Re: [PATCH v9 2/8] mm: rust: add vm_area_struct methods that require read access To: Alice Ryhl 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-Rspam-User: X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: C0D4440010 X-Stat-Signature: cm4nts6j8ziu1xkkqcr518sy1zx8bpmu X-HE-Tag: 1732724254-706582 X-HE-Meta: U2FsdGVkX19IEw1/UjYUb3SuVwjVSn03nHy1pUBlItPZdJOSXg3B/AZvJj8EoyM/Q1y7tSizZDesDV02qE1UcC2ZC2sZ+jvvPf5fg3gH/ZOsmWmtx1NbdPSoPayxV3tM84gsDkFUjjYwK0mYrapNmOC3fXOmOyRrcqdhPQQRVoVVxAnSFm7aQfgIcSQb23+ClZU6pzOeFWKwvTO2vnGOVmjtqCmWBxS4HMiLwbHmXQwU6Qm2bacyO4leAtDENACu4gWnhGHZd3DSrjj3gGmVXbDxiFkEQJfYyPryIp0PjELWqhwRScthxoZ7tHfYIqpGkjC56vhSWakhnEcMcbD/bN92Tg6iwAcNSdogVEibbQAHfrO2pmjJ9mhKAu5Tzpqr+EncyJFqEycAAo3M/8VWuOLiFwAYqWyRcDNN7YqVWf5dkiNVsy2QJiquadbSEU60oFCDTX2GxMsOj7YXaH2bn0GLhFvEG9FKO+UbrDMhGgoX3839rBxuzvIemjocxKzOiywvr4fpoEsrhrT9VgAD1ceq+BF20BL4I7s7YsFxZH53zdo6SzK+cD6B8muJbC/33ZItiOc1HprOmeSSDcfJeeVyeLIoC0jG1VPNTE1TPkB55DrOWj2sao85zDLXgQy6R4oSL4c/wGSW++wqKmtnmTruhO7KTCs+BHwZjqEPgWI0Smg1tuotI7Y1TIwS2jhipQGUxlVoNoaCdTVWsohM9u/SBW3fHs1hmjrmqtNTn0wWIq25Gec7QJAu8yNiSo/JATzDEsH/m59xf6NjoRT6adiBx7xJZl3WBIibIwUJzEAA6COSuMD4EtWkwRSurRphnYX+rzxBf0N5BmTiXdzZiq2N8PacxPcaLxnUQ3r1hGu1+C77XeI6EIcMY3R1g0oSaSzM9uqawhhQ25Q2e+UO2E6qrbyRSGBgUkGEKyZcdc532cllg5t0leMSJ0rTTcszGhdW927i0j0b9h7OYQq uMb6VGI0 GJY/GwtZLHvNlV2AnqsFFp0i7r+9Rhbl/h1liM9KqMw9LEnvbwqSOdBiKu7lJgxmc8CvuMDh+8IZq6aRMEyJQLAD2ULEDXJEEpKJ2PiWska3OCiTHB8j29aOe33YJb4Vm7EXLhchkrWtfs8nziSK4oxRL+xjCtfZ50dxKSQ2u/LFfeaqtPnkn6B7ozN9q9mtwwDWc/Aunx5K4y/fwhyrrJStD4p3uc4z5bcyQb/F5GSyagudpZtWnov/sqgu5LrAi4HOLHHLa3zE/iwMTpLXGxGYcODcmk40yCQHZNOLSmxfiBY/40FWsXR4D9dAXch9wf7+FYD3BI4X+AzhBRGeJpoEIgQ+7uEgRdc6R2W575TK2RwlflbduvGnAjjercM95ZMX1 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:46=E2=80=AFPM Alice Ryhl w= rote: > > On Wed, Nov 27, 2024 at 4:41=E2=80=AFPM Jann Horn wrot= e: > > > > 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 = wrote: > > > > > > > > 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 ho= ld > > > > > 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 loc= k. > > > > > > > > > > Acked-by: Lorenzo Stoakes (for mm bi= ts) > > > > > 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 lea= f level, leaving all other page > > > > > + /// tables intact, and freeing any memory referenced by the = VMA in this range. That is, > > > > > + /// anonymous memory is completely freed, file-backed memory= has its reference count on page > > > > > + /// cache folio's dropped, any dirty data will still be writ= ten back to disk as usual. > > > > > + #[inline] > > > > > + pub fn zap_page_range_single(&self, address: usize, size: us= ize) { > > > > > + // SAFETY: By the type invariants, the caller has read a= ccess to this VMA, which is > > > > > + // sufficient for this method call. This method has no r= equirements 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 a= dd > > > > 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 h= ave > > > > gone through an interval tree walk via > > > > mmu_notifier_invalidate_range_start()->__mmu_notifier_invalidate_ra= nge_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 erro= r > > > 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. Uh, good question... I can't think of any architectures that have userspace mappings right at the top of the address space, and having objects allocated right at the end of the address space would violate the C standard (because C guarantees that pointers pointing directly behind an array behave reasonably, and this would not work if a pointer pointing directly behind an array could wrap around to NULL). And unless the userspace allocator takes responsibility for enforcing this edge case, the kernel has to do it by preventing the last page of the virtual address space from being mapped. (This is the reason why a 32-bit process on an arm64 kernel is normally only allowed to map addresses up to 0xfffff000, see .) Allowing userspace to map the top of the address space would also be a bad idea because then ERR_PTR() could return valid userspace pointers. Looking at the current implementation of zap_page_range_single(), in the case you're describing, unmap_single_vma() would get called with end_addr=3D=3D0, and then we'd bail out on the "if (end <=3D vma->vm_start)= " check. So calling zap_page_range_single() on such a range would already fail.