From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 306021DC05D; Thu, 21 Nov 2024 22:01:27 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=90.155.50.34 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1732226491; cv=none; b=Z9nyh5umpJw+jAAutAF8YmjVV1in7TQ104eePfguQFGuxDxJ7mUKgWHORZ09z1OThzkyX9xZ3zKYcdjjOEWfoWK77RMXNbkNZTie8nrLwspWv4fkSxyj4vyWEb2zDIsgAhfw0ylWBckmS2DBb2r9v+aZQJfpoFx0b86Pb/3rcEo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1732226491; c=relaxed/simple; bh=pqEyDF5LLO1VwH1MXzcryDaT3vlXiFcbp4M1sDFbPsQ=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=N2bcK2xuiuOQF/mWrBro7h6Ukn4Vh/HNToW3UgkTyLOMFUjDYPdkZo3uqgr0kc6T0RZVr3Is+W+IZrGIeg8B17zZXgrWF+HmUz+CLpFOL1yggfeJM3PNayHTLPYw90S7kioA44C4XYRTrdCTUxc2iK7fn0CD/CgVuLq7kAei8ic= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=infradead.org; spf=none smtp.mailfrom=infradead.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b=kXfaX916; arc=none smtp.client-ip=90.155.50.34 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=infradead.org Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=infradead.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="kXfaX916" 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> Precedence: bulk X-Mailing-List: rust-for-linux@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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.