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 gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 217C3C88E56 for ; Sun, 13 Sep 2026 09:37:14 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 4099510E0AA; Sun, 13 Sep 2026 09:37:13 +0000 (UTC) Authentication-Results: gabe.freedesktop.org; dkim=pass (2048-bit key; unprotected) header.d=kernel.org header.i=@kernel.org header.b="ZXq3ebKy"; dkim-atps=neutral Received: from tor.source.kernel.org (tor.source.kernel.org [172.105.4.254]) by gabe.freedesktop.org (Postfix) with ESMTPS id 317EF10E0AA for ; Sun, 13 Sep 2026 09:37:11 +0000 (UTC) Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by tor.source.kernel.org (Postfix) with ESMTP id 370D360AAB; Sun, 13 Sep 2026 09:37:10 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 46B941F000FF; Sun, 13 Sep 2026 09:36:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1789292229; bh=TeKLAo2lyBFX9D/j+t1NddJvYANiKwcO6O8pNn5tCYg=; h=From:To:Cc:Subject:In-Reply-To:References:Date; b=ZXq3ebKyzE91YMdk8KbwizzTYuRfKiJOjlC7hKcGtHQQZJ5nCJUfiu07FF3uqPR7f o6PqZ16b+Hzz787iWq7uAC2vR9/5i/IcYkPHKcuLhWMNuP85R6uSJM7F8FyrlWBS1Q KGIHV9T/yk+v10sUF/WNyxF8c8Po1Eo24e9YNLKt1UalWmzbnS3U12EvMGLOio9tEM ODMte60um3jwtWBD0ubXBYEB7KUwVDXh6qnHC7TqbJBMW531TTW44iAHQTQrd9L9Ll YCzgkk7cH0cJu67QwfwU4dQxrTMaBkv9vzAy6OxG6D2amnqezq/M6SGoPo0FCl+y/h jcgRapmP3RlUQ== From: Andreas Hindborg To: Matthew Wilcox Cc: Danilo Krummrich , Lorenzo Stoakes , Vlastimil Babka , "Liam R. Howlett" , Uladzislau Rezki , Miguel Ojeda , Boqun Feng , Gary Guo , =?utf-8?Q?Bj=C3=B6rn?= Roy Baron , Benno Lossin , Alice Ryhl , Trevor Gross , Daniel Almeida , Tamir Duberstein , Alexandre Courbot , Onur =?utf-8?Q?=C3=96zkan?= , Lyude Paul , Greg Kroah-Hartman , Arve =?utf-8?B?SGrDuG5uZXbDpWc=?= , Todd Kjos , Christian Brauner , Carlos Llamas , "Rafael J. Wysocki" , Dave Ertman , Leon Romanovsky , Paul Moore , Serge Hallyn , David Airlie , Simona Vetter , Alexander Viro , Jan Kara , Igor Korotin , Viresh Kumar , Nishanth Menon , Stephen Boyd , Bjorn Helgaas , Krzysztof =?utf-8?Q?Wilczy=C5=84ski?= , Pavel Tikhomirov , Michal Wilczynski , Ira Weiny , Matthew Brost , Thomas =?utf-8?Q?Hellstr=C3=B6m?= , Philipp Stanner , rust-for-linux@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, driver-core@lists.linux.dev, linux-block@vger.kernel.org, linux-security-module@vger.kernel.org, dri-devel@lists.freedesktop.org, linux-fsdevel@vger.kernel.org, linux-pm@vger.kernel.org, linux-pci@vger.kernel.org, linux-pwm@vger.kernel.org, linux-usb@vger.kernel.org Subject: Re: [PATCH v21 9/9] rust: page: add `ExclusivePage` for race-free page access In-Reply-To: References: <20260910-unique-ref-v21-0-e83257373062@kernel.org> <20260910-unique-ref-v21-9-e83257373062@kernel.org> Date: Sun, 13 Sep 2026 11:36:53 +0200 Message-ID: <878q55v6fe.fsf@kernel.org> MIME-Version: 1.0 Content-Type: text/plain X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" Matthew Wilcox writes: > On Thu, Sep 10, 2026 at 11:00:13AM +0200, Andreas Hindborg wrote: >> `ExclusivePage` wraps a regular page but adds an invariant that the >> page data area does not incur data races. This means `ExclusivePage` >> cannot be mapped to user space or shared with devices, and it >> becomes simpler to directly reference the contents of the page. >> >> Since `Page` implements `AlwaysRefCounted`, handing out a `&Page` >> from an `ExclusivePage` would allow safe code to obtain an >> `ARef` to the page and break the aliasing invariant of >> `ExclusivePage`. Thus, do not implement `Deref` for >> `ExclusivePage`. > > Given this description, I wonder if this shouldn't be implemented by > alloc_frozen_pages() / free_frozen_pages(). We'ree certainly trying > to move the C parts of the kernel away from thinking that pages have a > refcount (folios have a refcount; otheer memdescs may or may not have > a refcount). Do your intended users of this actually have a need for a > refcount? I'm not familiar with that API, but I will take a look. The `ExclusivePage` would not need a refcount. The reference is intended to be exclusive, giving mutable access to the page contents. I could imagine a situation where someone might want to transition a page reference from exclusive to shared, but I do not have a user for that at the moment. > >> +++ b/rust/kernel/page.rs >> @@ -17,7 +17,11 @@ >> AlwaysRefCounted, >> RefCounted, // >> }, >> - types::Opaque, >> + types::{ >> + Opaque, >> + Ownable, >> + Owned, // >> + }, > > While I'm asking stupid questions, what's the significance of the // > after Owned? I see it after RefCounted too. It is a hack to get rustfmt to format the import statements in a Linus compatible manner [1]. As far as I know, it will go away once rustfmt learns to do this by itself. Best regards, Andreas Hindborg [1] https://docs.kernel.org/rust/coding-guidelines.html#imports