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 C4536E64025 for ; Thu, 21 Nov 2024 22:01:37 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 14FE16B007B; Thu, 21 Nov 2024 17:01:37 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 0FFEA6B0082; Thu, 21 Nov 2024 17:01:37 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id F09046B0083; Thu, 21 Nov 2024 17:01:36 -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 D27866B007B for ; Thu, 21 Nov 2024 17:01:36 -0500 (EST) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 5B8CCC14A2 for ; Thu, 21 Nov 2024 22:01:36 +0000 (UTC) X-FDA: 82811472954.26.F2FB631 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf15.hostedemail.com (Postfix) with ESMTP id 804DFA0023 for ; Thu, 21 Nov 2024 22:00:38 +0000 (UTC) Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=kXfaX916; dmarc=none; spf=none (imf15.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1732226308; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=OElOW/ym0iS6wv612P7RpAETtR98Co4NnCdEquW2kPI=; b=0JtCmim9NKCyKnmQ0QeyiPznlUch5U6GLxMLejJDd0CYFEq5OERNNt6PYHGPWSek+UDyUP x5lskax0oEkd2DCf4hyYIToFLpPCi3aP0CF3ZrXzOUrZR+YeMFWrxq4f9gOMPKiJAbMHED TVvAq/ezR/1Let5yUVVR0xjsUr0rTMA= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=kXfaX916; dmarc=none; spf=none (imf15.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1732226308; a=rsa-sha256; cv=none; b=IibJJKNfhTgC6UmOIJSOWeIE2ix3sgaaL9ticJkV/d+JTpIkwUjWl8Y6EicVD0RGPKmoez yGHfz7ZY7wCnCcouOeTViVofm06sv69hs4yj3Vn+wWb0Psk4ncgrVeUdYvqWdlwa+ixwEy EetFeyrB4Du4sn9xRAM5X666GwN/vQU= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=OElOW/ym0iS6wv612P7RpAETtR98Co4NnCdEquW2kPI=; b=kXfaX916eTmUA8NIJkVhCtVOj9 6/ZNIImqz2m3g+qE4BcfIGRDfrlySGNVRElRXrnE+/ONgXWXilGEVrMOcFnIyBMd9ClOfVocOQmQL eS9U6riV8LMWsruPnyXth28UhQAl1tE25R3UghuB43etl8byhT3QIlQ4RfkGCe2aXcMcafDILpkk0 Ia4q5UTtAGCON/jH9YRRO6A+2sdgVymtGnT9V9z5rovnwMOkjqY/v2U2ao1gtrcKmwa7GVSot6qIB 3GdMIWds0oIqKblJ5iicpvC06OQmnwbuq1hSgOWUEyVJTuBh2MdTJoTZ1g65+s3NnCKBNY3MoQMqh Qewqq69A==; Received: from willy by casper.infradead.org with local (Exim 4.98 #2 (Red Hat Linux)) id 1tEFEp-00000006re3-21QZ; Thu, 21 Nov 2024 22:01:23 +0000 Date: Thu, 21 Nov 2024 22:01:23 +0000 From: Matthew Wilcox To: Boqun Feng Cc: Abdiel Janulgue , Alice Ryhl , rust-for-linux@vger.kernel.org, Miguel Ojeda , Alex Gaynor , Gary Guo , =?iso-8859-1?Q?Bj=F6rn?= Roy Baron , Benno Lossin , Andreas Hindborg , Trevor Gross , Danilo Krummrich , Wedson Almeida Filho , Valentin Obst , open list , Andrew Morton , "open list:MEMORY MANAGEMENT" , airlied@redhat.com, Kairui Song Subject: Re: [PATCH v3 0/2] rust: page: Add support for existing struct page mappings Message-ID: References: <98a46b27-c4bb-4540-8f75-f176c3f2fae1@gmail.com> <650846e4-b6a0-472d-a14e-4357d20faadb@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 804DFA0023 X-Stat-Signature: jjedbop1sngbiztxwrxuo36gbyb79ikf X-Rspam-User: X-HE-Tag: 1732226438-507526 X-HE-Meta: U2FsdGVkX19uCjNhmpIlRSI/yuSrBI7fZCLIaxIIUspEnqSxAOBTTkwhlpfJssJQFKZw01ojH/vSl09hWC4cXA04QXxRvP2wxVAz1ilYa9Fpp7rVfzTG7P1k41RSA+Kc0e9bbrZeAXIje90nPZFWh+9TfaYxjUIcbtsrVO3/QyR5J/Z1WDnKQQbddKr9yd9N1NWvQY2XFWJa6hR+/HQ9IAHEn5fNGxJ5vuSCGsLk3jxwoPm3kU19nzj1SfcMj10LltHsXr9EyCULcqMNP5bS6dARel1JALGOBRSPBN0/l6UY3MTNMqTGYlQN7j2K3uuW2BqUSsgSg1R4v1+MC3uVQrG+ibDcSWtkBwOVMJVO2dsEBA4pnQLH5x1GcdUi7DUAhwcqVj4EM/DOJ41eZf/CQHuHCe6cdPjxYlL3TIIa8ZPEzJP3g8wsZId3b0i/EJdC23z1IQUJnSr1gL1G6M/tO2N9tHWEJZJEwUKthFrDfDEvLPpnmzteNhTNGnVVCsMHccBRf4toHQLs/v4y87MHHUFdqSyyVN7vQxmk2mUyFKE5VLLUTaawkKCjC/X9QllVKm8z+r68VDsdJCqZb8Y2t6FDpWJiEIZ2UOjq8Ttr8qWcpZESrjfB8v+s7L9W2kld16wo21uvpyOK4+Kmjp3j7cBEKu6thNAFMYvdwq48OyCQ7cBvRW/4+CXeOKl1BoidP7u2k00ri4/Jk9cdWIxKIFuHEtvhol/tnZJXPDIwdfJtBCqjQJsznIMzBBlHsuCVze33ANvGkqqTZ6Eji+rP+L7e9GjwIVmD2f7Ep7Il8UQiQl6uJRH6Jy/tIguXU9RAJoPA0BEM+pRef+Etvp6EqqRkomd3sJFLplOUrvDB5ug4TJss/IunNQBdDhxHyWDHHZDRrDx1lLZD2wlr5cqY1V0RvK7Ob6vFmWiibwLjDcE/PltQqf1jfjhF1EKTqA8WV0eeYTsVOMFCU1d0DXR Albk2G4B pHVbG0tbl1CqmnUICt9Jvso+9gSks5HnYwQA1Rv7BrrYWkiu8vvQCAvI0z3SuDK3pZf2bu9tPDKZBTavnx+YlkJiC4CikmptLsJ9RuYt7dzLHNr+IWJOY24+JhPddxV+P+oc6393AgZTkrsEBr45DCT+Mwhf/3kNwGfwzAH0LPCfp9T5tffvMG2GiVjBQ8LD7vZP/0IU7afHEhw4Ep5ibDx9VS2vL0zLHCANqtCum6gspjRD4639HqtTzaEZlNZgpOFVuCSlmdY13U3TFSseOh5544KzF5+Dyx7GZB7O2AHVsTtummRAlW+v4Fw== 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 Thu, Nov 21, 2024 at 11:12:30AM -0800, Boqun Feng wrote: > On Thu, Nov 21, 2024 at 11:30:13AM +0200, Abdiel Janulgue wrote: > > Hi Boqun, Matthew: > > > > On 21/11/2024 02:24, Boqun Feng wrote: > > > > > So if I understand correctly, what Abdiel needs here is a way to convert > > > > > a virtual address to the corresponding page, would it make sense to just > > > > > use folio in this case? Abdiel, what's the operation you are going to > > > > > call on the page you get? > > > > > > > > Yes that's basically it. The goal here is represent those existing struct > > > > page within this rust Page abstraction but at the same time to avoid taking > > > > over its ownership. > > > > > > > > Boqun, Alice, should we reconsider Ownable and Owned trait again? :) > > > > > > > > > > Could you use folio in your case? If so, we can provide a simple binding > > > for folio which should be `AlwaysRefcounted`, and re-investigate how > > > page should be wrapped. > > > > > > > I'm not sure. Is there a way to get the struct folio from a vmalloc'd > > address, e.g vmalloc_to_folio()? > > > > I think you can use page_folio(vmalloc_to_page(..)) to get the folio, > but one thing to notice is that folio is guaranteed to be a non-tail > page, so if you want to do something later for the particular page (if > it's a tail page), you will need to know the offset of the that page in > folio. You can do something like below: This is one of those things which will work today, but will stop working in the future, and anyway will only appear to work for some users. For example, both vmalloc and slab allocations do not use the refcount on the struct page for anything. eg this will be a UAF (please excuse me writing in C): char *a = kmalloc(256, GFP_KERNEL); struct page *page = get_page(virt_to_page(a)); char *b = page_address(page) + offset_in_page(a); // a and b will now have the same bit pattern kfree(a); *b = 1; Once you've called kfree(), slab is entitled to hand that memory out to any other user of kmalloc(). This might actually work to protect vmalloc() memory from going away under you, but I intend to change vmalloc so that it won't work (nothing to do with this patch series, rather an approach to make vmalloc more efficient). One reason you're confused today is that we have a temporary ambiguity around what "folio" actually means. The original definition (ie mine) was simply that it was a non-tail page. We're moving towards the definition Johannes wanted, which is that it's only the memdesc for anonymous & file-backed memory [1]. So while vmalloc_to_folio() makes sense under the original definition, it's an absurdity under the new definition. So, Abdiel, why are you trying to add this? What are you actually trying to accomplish in terms of "I am writing a device driver for XXX and I need to ..."? You've been very evasive up to now. [1] Actually Johannes wants to split them apart even further so that anon & file memory have different types, and we may yet get there. One step at a time.