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 759AAC02180 for ; Wed, 15 Jan 2025 11:05:13 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 17D14280002; Wed, 15 Jan 2025 06:05:13 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 12F0F280001; Wed, 15 Jan 2025 06:05:13 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id F3791280002; Wed, 15 Jan 2025 06:05:12 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id D47A0280001 for ; Wed, 15 Jan 2025 06:05:12 -0500 (EST) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 98F5AB062E for ; Wed, 15 Jan 2025 11:05:12 +0000 (UTC) X-FDA: 83009404464.24.22F2E96 Received: from mail-wr1-f45.google.com (mail-wr1-f45.google.com [209.85.221.45]) by imf14.hostedemail.com (Postfix) with ESMTP id A4A9010001A for ; Wed, 15 Jan 2025 11:05:10 +0000 (UTC) Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=eCGUngfa; spf=pass (imf14.hostedemail.com: domain of aliceryhl@google.com designates 209.85.221.45 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=1736939110; 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=fw2NuiSUZiESYrNqPbihqFsk7tcBYqw0a62Ou7xyGL8=; b=HNpjhtfTuHpY+JEMcgVTdLEcrwGuDJloejPRZwbtT32VxDlusp1dbWvQYyRdMH8NVfAHu+ YDrb9mJ0gXSNTiLK7V2ud8V1itDybiL4LaGtO26HaRxmSVKHSKMZ2tnp1m5IkBDFKSdxal e1RXGj0EAlBX19rizS5Vb9/sbEmm6bc= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1736939110; a=rsa-sha256; cv=none; b=0uen21A6njwZlQkpCdvKVmXSVgWuLV35F5cILMqB2dBWnm6KsN3ogprW4C3Z/cXI6QZzyz lduJZjUodrQEt7xpke8Ofl9erafQePoHREZ2IwKDjQJw1KmtoPlEGtbUdVsNEq0Jo7Il9M 9QyKbzU75CRoFVYPvAda+eefqkyc4gg= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=eCGUngfa; spf=pass (imf14.hostedemail.com: domain of aliceryhl@google.com designates 209.85.221.45 as permitted sender) smtp.mailfrom=aliceryhl@google.com; dmarc=pass (policy=reject) header.from=google.com Received: by mail-wr1-f45.google.com with SMTP id ffacd0b85a97d-386329da1d9so3355421f8f.1 for ; Wed, 15 Jan 2025 03:05:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1736939109; x=1737543909; 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=fw2NuiSUZiESYrNqPbihqFsk7tcBYqw0a62Ou7xyGL8=; b=eCGUngfaetXUPGxj1A9bJPYun7KCoRLaeC80QIutcHkwtPXhcqQvlhuxn5UryT84LC R5ut8xou4wmDdnMjQaYuw1oVw/T81Oz7hB+9e4kaLmrtlsabMLd0ZLnUemP843Uiw3zj 6VC+F9A4Blm4iJoWpGVkMTpRJn3aYj5hGATxdMade5U69VbPoLNR96OEUDFIxl+eEHaG fLom2wq2QV2/jQzubpNCDvZU51MX3ztoA1uu1IQmfdIHdX38bLaJ45KGZfFMCNNb9vbU Gvz8F+ib4ozAgg8nfOTEKZi534d80RaOjg/sM6lAM+YQeTEJXh4rCw14fZQWJkVcqZcM M6HQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736939109; x=1737543909; 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=fw2NuiSUZiESYrNqPbihqFsk7tcBYqw0a62Ou7xyGL8=; b=GXcP/zsnmYcbALmKTOrmm11y1boIUajIi3x81PS4RHqyZTR44mcuCzYTjMLtHsEKe0 T+kHguSxVbrS29Jhv5Cyu2wpsPbqZBVCRRnYz0cZb3E9XR7iSdbem9v4afPrfbj9gt+P 5N2sh1Vzg1PngmfTiPo3QcmDd+A849dbM2Mbu0JJCgmqK+1lp2STHR6GTM8WgOudQbq1 O53Dvdw3R3RcwRPH4VNWMbV9F6NI+mzjCJA11TkcZB99KElyz/Fj7cbgIspeD0SNN6xu 182IORezyfLV5cWYKiNB1oSn1V75KjRuZcm9i7RsyoqmS9+5/mFP/BG720e2lpffWC/+ wi/w== X-Forwarded-Encrypted: i=1; AJvYcCXEqLS9bzOBwGkmEbSV+1H4A5emAv5sadWTFIk9lAufVv3RJfmlFGhMD8lxCr0+rbbFuz3ihtuu7w==@kvack.org X-Gm-Message-State: AOJu0YwR6mHOPTuRYrI22Db+PbntOCq7T/CaPzHATj/CiVY2pwxUJgsc u/UPCErhmfV9gOagkbw7MikROqIux2gsIcv2I3OWHGchVKaoZUTKN+rwH0tI7AnJVeoAlswCLit 7+3JAtc9XPtVLr9eOiTgOUxwWDGHNw8ha89HO X-Gm-Gg: ASbGncsg91FoBEwdNO50fEMQbCbx13dqJqAiDXCEAiIPM096ljaHaCl+O1EZQtfVtAS 8KRb5rtqq0iiB+rOfGoy1l4tHkfaFWl6xX8+sl74= X-Google-Smtp-Source: AGHT+IHQlkpmJ4SoCrhT3u1y4CSjWAKIL28MBjTX2lVvYBBLzc5GMtrDu7feK4jaKpPa94ivV5baH+7BMYhxyxFr8iQ= X-Received: by 2002:a05:6000:4008:b0:38b:d8a5:df3f with SMTP id ffacd0b85a97d-38bd8a5e15emr11123415f8f.0.1736939109052; Wed, 15 Jan 2025 03:05:09 -0800 (PST) MIME-Version: 1.0 References: <87frlsbekc.fsf@kernel.org> <18bc911a-ede5-410b-9955-5382bcef975c@lucifer.local> <87msg09uzu.fsf@kernel.org> <8b803030-0ca3-4591-b2f3-bb9bcc2aca21@lucifer.local> <871pxcgg02.fsf@kernel.org> <195559a2-8c5e-40f7-b60a-8534dc177d9b@lucifer.local> <874j20e3wp.fsf@kernel.org> In-Reply-To: <874j20e3wp.fsf@kernel.org> From: Alice Ryhl Date: Wed, 15 Jan 2025 12:04:57 +0100 X-Gm-Features: AbW1kvYti3f1YoDCRgS07yTDhT0aKjFEX7txjVrvuXbkRveP56pBQq4uE9IijY0 Message-ID: Subject: Re: [PATCH v11 2/8] mm: rust: add vm_area_struct methods that require read access To: Andreas Hindborg Cc: Lorenzo Stoakes , Miguel Ojeda , Matthew Wilcox , Vlastimil Babka , John Hubbard , "Liam R. Howlett" , Andrew Morton , Greg Kroah-Hartman , Arnd Bergmann , Christian Brauner , Jann Horn , Suren Baghdasaryan , Alex Gaynor , Boqun Feng , Gary Guo , =?UTF-8?Q?Bj=C3=B6rn_Roy_Baron?= , Benno Lossin , Trevor Gross , linux-kernel@vger.kernel.org, linux-mm@kvack.org, rust-for-linux@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: A4A9010001A X-Stat-Signature: mpr781fgrbgzt4ssdudmxymtebnqgxfj X-Rspam-User: X-HE-Tag: 1736939110-325739 X-HE-Meta: U2FsdGVkX18F6TOwVGgpl+2YtuW1CSmNYDAdzxJO12KDDH0DtnsCISVZM+q7AwZmfZrEYAISAeVmBab3chwypanKzokPN6HNw0GfCdK5UMo36xdzdnBYX47qozOPOSkV0zXAORIEa0JoHuds/ZGuAbu6T7/vmyX4+5xNXB8cjsrAf3BKimxTDRtTnzr6Y90SwVU5NWUYNwhhDe1sa/QQUyKmqEdYAX39+Vk6paPo0y7Zz+PzJeEwO2oKn3PqVPsVhVSLOOaGivMn1g0FdmBvA3DHkWWkEcn8pwZVlr67pmkryQnqZOTGKMvy7BJuiAPq+xjPPHdrMQsVEVZwts71Kk8Yu8RIQhvkx6K99ovgh1UKFM6MIV+zPuaoAKfisvZlC7YMwMwGii0IfecM/B0Oc7ZANZeWEvL4k8A1/WZbaATquH274DMqzesJqk8XFv5m72YXmCKMOQr3NnMguSEq+nq4hH7gnaMxn7/M1g57OqIuITw8YY7a8bxxsBNG3sugOIPSqulPkY97CGSsAJAzDaU51Y01WsA+jwUpY1uBN2EY7P8UCe+NxhJf3a7qZSBLC/iZjXTjhDwsG99ESbw5H2B1BemhB45brrhc0kMjiTTen57i2HtYFsdrv82ZxoVxZUh43wN762vWKQH0KUlodCudo1VbOT/1JQ2PBjmu9x7COvpy9+T7Z2Pg+zdIwHvWyYgz6HJkzyY7ZCi87d2UYXUbbSW+rS9TSkuut0xc/fgl4dSyK6UrzjzqfdtpHfcOiUX+excvC5G4BW0YFGVD1FtDOZ0DSmcsPelg3FJokcrzqsT5D5ihVmTlMGe/DLJ5WBYNIJtoKTTLFsGPH3fA7LWR8QQWOGMGZyPgUuNRU5zuvo9IFiLXQFBGnEGYXOlNaaka7TjM4iwyHp+EtvPKt8Zfn241cIMwl22/6lPO20W/Bodyjkc7sEEtXlMswUakjjebwUBw4OxPUIoFy+g GYlQ2VB4 hAaaydTDq9PjJ6wEe84J3FVm+7te8dTHt9Xg2KyaGeWgI8DvyDxIKO+GcxPOLQeZEKup2+4g5CaMLY3L2S8BXFcZiehWPqCgXBAo/TWV3Pc3kvMbHIJqsttU9eJ7MtdjZZjmc95Xjw33CbSC71WNS/ZLw/8NFGNiXI78Dv61cPJLlToW4jR0h2JpV2inkSQVtg4P3B7Kd81Uz0dGiYBxJMX/2IXypN41qUKVVGWp0jG1lLyBz/wfqQLhhd6sl2p57zzmfCyxLFnzAOSSzU4hAB83iyrE8yn5cDJCqXfLx0dG1EVNbXohDtyFr0A59JvEh9QmEC/EvsD6CQhtSQF8/0RdnfY1PSrgwMgoNrascYRDRnPs= X-Bogosity: Unsure, tests=bogofilter, spamicity=0.473536, 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, Jan 15, 2025 at 12:03=E2=80=AFPM Andreas Hindborg wrote: > > "Lorenzo Stoakes" writes: > > > On Tue, Jan 14, 2025 at 10:50:01AM +0100, Alice Ryhl wrote: > >> On Mon, Jan 13, 2025 at 3:45=E2=80=AFPM Lorenzo Stoakes > >> wrote: > >> > > >> > For a series at v11 where there is broad agreement with maint= ainers within > >> > > >> > the subsystem which it wraps, perhaps the priority should be = to try to have > >> > > >> > the series merged unless there is significant technical objec= tion from the > >> > > >> > rust side? > >> > > >> > > >> > > >> >> > >> > > >> >> How about this: > >> > > >> >> > >> > > >> >> This clears the virtual memory map for the range given by `s= tart` and > >> > > >> >> `size`, dropping refcounts to memory held by the mappings 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 dat= a will still > >> > > >> >> be written back to disk as usual. > >> > > >> > > >> > > >> > Sorry I object to this, 'clears the virtual memory map' is re= ally > >> > > >> > vague. What is already there is better. > >> > > >> > >> > > >> Would you like the proposed paragraph if we replaced "virtual m= emory > >> > > >> map" with "page table mappings", or do you object to the entire= ty of the > >> > > >> new suggestion? > >> > > > > >> > > > I object to the suggestion in general. The description is fine a= s it is. > >> > > > >> > > Ok. I'm raising a flag because I had more questions after reading = the > >> > > docstring than before. > >> > > >> > Sure and so I think this is valuable information, and indicates it's > >> > probably worthwhile adding a little extra information on mentioning = page > >> > tables. > >> > >> Sorry, I'm a bit lost. What would you like me to add? Perhaps there's > >> an existing file in Documentation/ that I can link to? > > > > Sure no problem, I propose expanding: > > > > /// This clears page table mappings for the range at the leaf level, le= aving all other page > > /// tables intact, > > /// anonymous memory is completely freed, file-backed memory has its re= ference count on page > > /// cache folio's dropped, any dirty data will still be written back to= disk as usual. > > > > To include information on page tables. I suggest something like: > > > > /// It may seem odd that we clear at the leaf level, this is however a = product > > /// of the page table structure used to map physical memory into a virt= ual > > /// address space - each virtual address actually consists of a bitmap = of array > > /// indices into page tables, which form a hierarchical page table leve= l > > /// structure. > > /// > > /// As a result, each page table level maps a multiple of page table le= vels > > /// below, and thus span ever increasing ranges of pages. At the leaf o= r PTE > > /// level, we map the actual physical memory. > > /// > > /// It is here where a zap operates, as it the only place we can be cer= tain of > > /// clearing without impacting any other virtual mappings. It is an > > /// implementation detail as to whether the kernel goes further in free= ing > > /// unused page tables, but for the purposes of this operation we must = only > > /// assume that the leaf level is cleared. > > > > Alice, Andreas - please let me know if this makes sense/is clear or nee= ds > > further clarification. > > Sounds good to me - thanks. > > @Alice - can we add PTE, PTE entry, PMD, PUD to the vocabulary at the > top? Not sure if it should go here in virt.rs or in mm.rs. If you have > no cycles I can try to add it down the road. Sorry, I don't know these concepts well enough to write about them right now. If there's a documentation page I can link to that's great, but otherwise I think it will have to wait. Alice