From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from SN4PR0501CU005.outbound.protection.outlook.com (mail-southcentralusazon11011062.outbound.protection.outlook.com [40.93.194.62]) (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 92D203AD536; Thu, 19 Mar 2026 12:49:57 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=fail smtp.client-ip=40.93.194.62 ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773924599; cv=fail; b=aFKyMI6aHHcrJaWWJiss7q/MOFhB/bYGE11HzSpKVWZu/9jiyN/QMdNqby9RuX8eHBCXA8H6m9oh60i6neA9fCVj7bQaMBT4CHf66xFkm8DVDDEmYcu5GKVHQqiZwWJdZvCQGpyCado5AqKgTNzyxlygv7WVzsHkfDIUkbiPJxM= ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773924599; c=relaxed/simple; bh=doQzTlIbRfXeC6GYWD0scB3n/ZQevoCj01abc5xyKyM=; h=Content-Type:Date:Message-Id:To:Cc:Subject:From:References: In-Reply-To:MIME-Version; b=J6Px8vNlgr0oNFDSBnBnFCp0JGlV4+NmeU0ZrNruB9te62RAiuGR0XKoP+Zlld9B0t2E7Fh0/0pulpNnuVTQqUhn1L1jdVhL/V3RNTknrWvswZDylS3FDOora09B8bZ4rjd374DkMaSyO5t0+6OYU9Nxqwg/S4Z1Rs9OfIW/BtI= ARC-Authentication-Results:i=2; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=nvidia.com; spf=fail smtp.mailfrom=nvidia.com; dkim=pass (2048-bit key) header.d=Nvidia.com header.i=@Nvidia.com header.b=Mhpnmw0c; arc=fail smtp.client-ip=40.93.194.62 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=nvidia.com Authentication-Results: smtp.subspace.kernel.org; spf=fail smtp.mailfrom=nvidia.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=Nvidia.com header.i=@Nvidia.com header.b="Mhpnmw0c" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=PD5u+rV9aa+kY2aCgarqFGzg+5qLmy1GzDiJIOqMJ3RO154kiVgrXzfosG3g8YzC90ohPb3YYFrWSS/uwotH77OvePGXA4UZqq+NWzTX0OW9xriY+tGUQpeCROOC5/8s7lNSPachhlgMkND/E/oSlJwi1q7h8KqnFpdD8sjzj8drc0EBq88iWm/Jn4X0znstC5oxvOHdRDj5Lxz5Rkn/z+kFknV4z6hGVjslBfAiP1l6fpKoRzPS36sC9o2XdCQCD04Yc23oZK2flqruOXb91rMMW/UXnSdiUsb+l8T/mtpQaI7mdt68FzqvGUctJZlBQ2WihCJ7LwewVf6Edc8HKA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=SLePyHHiQgVIaYryaege9h02PvJgaxeouI8vMyT2voo=; b=ZHvZaelCzDFFBP4WXUdlqD270GVtSKRFmLjpHV4K7CGonBUHiaPUob1Xd7ZSJlgVubbnlakTDEao8+hl194kmqlACEP2GvR1poWAKeADTwGtHUkx15OnQIQ7mwQ3MXVkjgg6z/P/wbMy9pmFbo0dGxSRcQZBhmxJyfZRNtwt6gRXEXNXJUpLz9GiwmrVLH8kehQ7wPOvaX3hPf2wUvsx3us8gS4PvfMnWtXHw/xjwvujlTfZGT7IRFaeeo25ZlV3x00zgjTbxnOcG3eauv1K6d2Fl2LNMMW+tSc26wn0Kb8OzsfJ6WzXXo9JZ6zLfqxhMdQKxXxAeUrMoTWJ+pfN/w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nvidia.com; dmarc=pass action=none header.from=nvidia.com; dkim=pass header.d=nvidia.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Nvidia.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=SLePyHHiQgVIaYryaege9h02PvJgaxeouI8vMyT2voo=; b=Mhpnmw0cxMNA9ykoefNfi1tyXWLNM2DLP5o5JdZ7yPOODASG4oLjV6ttt5uXRAibShjH8X9m9WEh9SxDRgAhChsj8CXT5KM2x5/AwM2gCuE0eVza0ho79DucHZl3L2R3aK7vFGEIkF5Dmb3MpoiMnKhmD8jTX9ThRyLx1T/Knbv7RhsymbfpnMm8HjQmzICDNgaJiDTtCp4QfN3YvSYrWa8Dg20CRgJkOHQBIR+9K8p/FH6wA0PLN1dKZxPHO6yFIlI3BVEenAlbQnOE7v63YPy13GwtpTO/ekSp3by373x6AqFqvqYDzJWmXuVfg50QLEj+yryhnU/wzJg5hx3gaw== Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nvidia.com; Received: from CH2PR12MB3990.namprd12.prod.outlook.com (2603:10b6:610:28::18) by DM6PR12MB4388.namprd12.prod.outlook.com (2603:10b6:5:2a9::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9723.14; Thu, 19 Mar 2026 12:49:45 +0000 Received: from CH2PR12MB3990.namprd12.prod.outlook.com ([fe80::7de1:4fe5:8ead:5989]) by CH2PR12MB3990.namprd12.prod.outlook.com ([fe80::7de1:4fe5:8ead:5989%6]) with mapi id 15.20.9745.007; Thu, 19 Mar 2026 12:49:44 +0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Thu, 19 Mar 2026 21:49:40 +0900 Message-Id: To: "Joel Fernandes" Cc: , "Miguel Ojeda" , "Boqun Feng" , "Gary Guo" , =?utf-8?q?Bj=C3=B6rn_Roy_Baron?= , "Benno Lossin" , "Andreas Hindborg" , "Alice Ryhl" , "Trevor Gross" , "Danilo Krummrich" , "Dave Airlie" , "Daniel Almeida" , "Koen Koning" , , , "Nikola Djukic" , "Maarten Lankhorst" , "Maxime Ripard" , "Thomas Zimmermann" , "David Airlie" , "Simona Vetter" , "Jonathan Corbet" , "Alex Deucher" , =?utf-8?q?Christian_K=C3=B6nig?= , "Jani Nikula" , "Joonas Lahtinen" , "Rodrigo Vivi" , "Tvrtko Ursulin" , "Huang Rui" , "Matthew Auld" , "Matthew Brost" , "Lucas De Marchi" , =?utf-8?q?Thomas_Hellstr=C3=B6m?= , "Helge Deller" , "Alex Gaynor" , "Boqun Feng" , "John Hubbard" , "Alistair Popple" , "Timur Tabi" , "Edwin Peer" , "Andrea Righi" , "Andy Ritger" , "Zhi Wang" , "Balbir Singh" , "Philipp Stanner" , "Elle Rhumsaa" , , "Eliot Courtney" , , , , , , Subject: Re: [PATCH v13 1/2] rust: gpu: Add GPU buddy allocator bindings From: "Alexandre Courbot" References: <20260308180407.3988286-1-joelagnelf@nvidia.com> <20260317220323.1909618-1-joelagnelf@nvidia.com> <20260317220323.1909618-2-joelagnelf@nvidia.com> In-Reply-To: <20260317220323.1909618-2-joelagnelf@nvidia.com> X-ClientProxiedBy: OS7PR01CA0014.jpnprd01.prod.outlook.com (2603:1096:604:251::18) To CH2PR12MB3990.namprd12.prod.outlook.com (2603:10b6:610:28::18) Precedence: bulk X-Mailing-List: linux-fbdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH2PR12MB3990:EE_|DM6PR12MB4388:EE_ X-MS-Office365-Filtering-Correlation-Id: 9a4fd159-7f26-46e7-6dd5-08de85b5fec0 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|7416014|1800799024|376014|10070799003|366016|56012099003|22082099003|18002099003; X-Microsoft-Antispam-Message-Info: VkoOUjuVNxEGIDnrrS2GsP1zrN01IRx3ZyVc3undaj4vwqVKEq3XXG+z2chYI53vv/CVuilOzOiDOuGKbFWKl9XRko9rOIz3JlMYh08fl7wHO2QcKi/oYLPN4SQu0r0FwPu27ptrs72ddkoCSScxEb83c1DOs/0qZyvNrkckreA66mXsSOQl6H1uutlKpel6YbjJwoie4L4DG77ndm9V7z4/jTXj37GBzkPiQmiFCVUhczLRro8yw1HUDChZQ7KnVjkfY3NnBvIxAYvNsRsJ/kJ7PjgKQjA//njR3Xs96Y6qGLhphwJNfTiUtbWcO0UrTBiyYaR6xXqQ7Cnsfy2YQ8v3sHRsJy/jG2p+24SS0ziNLUg+SW5bcUthSRN7r8SAjuZ1Gu1bxwNcJsK8unOC9YyDGAuP1xXGtj2zRb3j9pGTnuCaWe74afhUhipDeyGIkYxQouagXEXwTypvyjC4Q4OwQ6n9L9ulPzRScBCQ3kl3i3mYX+/GbfujSES9ISTQIsNuCeNG7Vi0+KL2ju2s7hgxdKeymZLnklWeI+jgK+HrE7o9EjP2U5CNx9Hoiep6LqdkiyUKpI9NuC9vM9Vc9HEUyjpeXdKMe6LTtP93f2dRha4LZuq+CT2yKxh6+dIkI9ZIEmkG2fblH7qvSN7ulULuWXQ0Kqa9pEgA4VVwxaiH0I1WcFgp+KAiK9poqjO9c3ZJEqR/HYiaPADntUJsenK9/xlHre2jytvqlR1hixmRE+l9QM2qIColoKiUbTU9 X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH2PR12MB3990.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(7416014)(1800799024)(376014)(10070799003)(366016)(56012099003)(22082099003)(18002099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 2 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?Vmd6NnYyT2c1K09Qb0VXZGEwNHY1K1N3Q1oyVXVDN29xT3VFeTlBQ050L2ZJ?= =?utf-8?B?dEUvRmNld0hCN1F6cXJEUFFTc0NyQzdpSzNTWFY2bHZwbkN5cHZ0VWxzYWF1?= =?utf-8?B?ZitBeUtMMXBQWjkxUkx3M0pUamYvZldzZHh2OUtKaFRhTyt6bi92b3FtblZv?= =?utf-8?B?dmJtSUs1WjN4SzFQZ1poVlFHbVZWMHZmSUNDa0NDZlZBc3lLbHlSdk9ud1pC?= =?utf-8?B?bXBRZC9mV0doeHRyVkVxN25aRG1Rb1dOMUx5c0xPZUNiL0FIeUNCSnZQRytj?= =?utf-8?B?ekYvQ2U2cW53MWFxUTFSY240NjB4U3dlNzdwOHZGVDNEWDVTb1FxUDJOL05v?= =?utf-8?B?TVZ3LzFNRUdKUyswbENaNHZjeVFSMlpJN1Q1SlFzZHJPeDNsdmgxY0dQSGRX?= =?utf-8?B?ZXVFVlhpTU5xaDk4dndxc1AvaVYzNU9DNCt0ZnorWDU0eHdPcWM1UWYvc21w?= =?utf-8?B?QXJZTHZMeHJ0SjJqZGJmdFZIdUY1dEoxYnhvN2ZvTFRSZ0FqaElEdlJuUWo4?= =?utf-8?B?c3VkZUZnQ3dueGJNTVYzYmdpc200aVZ6S08zaGI0bit3MFNVeEgweE5PTksr?= =?utf-8?B?VUJyL2V0R1NkK3JTa0J0UmdUeUZYSU5RVGpBSHk1aFN5ZGNldXVWUnl4WmJ2?= =?utf-8?B?a2FzVW1NalV5L2FOcVZ5NHFsUGE1WHBzaDgwZjRkcEVWQi93ZjNIWDlqcHVp?= =?utf-8?B?dWpZbGhwWHRZYXRMRmZHbTMwWU1kRlFXTGJBWFd5YjVRQjN3WEVsTDJETita?= =?utf-8?B?dEhPRnhXdTUxK3EzYytnaSttWkQ1OStSVmxBeFBDUE9ERjdHeFhDamhZOWg4?= =?utf-8?B?ZGFFUGRCYWFaNnhEczFZQ1htQ0s1dXpEN1JrbHM3c3BkYlpDQXB4b1gvWVpj?= =?utf-8?B?M0FmK2hNVDNZQS9RYmRvZkRyQk5KQksrcHVrYWV0cXdCLzh0YXZNWTNWdDds?= =?utf-8?B?Wk9Ub2J2WExWd3ArZzZaRlF1VGorWUdUME5BTUdIMXJZWnZsbnpJQnU2R241?= =?utf-8?B?Qk1xNlY4VWN2TFdhZFFCcVZQY0JGekFVcG1aeTV3aUlFM3ZoaFB6TVhkODNu?= =?utf-8?B?a0JzMXBTM1FWclFaNGxONkJyVW10eFlhSzM3RlgvdldqZEVGYnhDb1pBNEJS?= =?utf-8?B?Nnc5QnVZV2gycGxJRFdLV2JDM0NkaEFzVHI5S3BYWkkvQUZzWit0aVhHZDkv?= =?utf-8?B?MXN3MGxzZnlvRHFwZURSZ3YxRlRyUXpiTXV4MndxZ3B3TmJDZGl0cnlwd240?= =?utf-8?B?QUROU0ZGRGxwU0VRckFSaG1QVDZqN0cva0xZQVR1ajZrdXk2YVZRMDdpSlNG?= =?utf-8?B?L25sM0dyOUxWdW9wSnZ0NGhxaDdJRURkZGdtalpRVU5yUzZDUDlWcVN5Zkky?= =?utf-8?B?SnJiYVBhS21MYXFRd09PRm9odTd1R3YrNDdKZjc3VjJXYzg1VzRLTWswOS9h?= =?utf-8?B?M3ZCVjIrMVVvWG4yMmQrQlRoY1JCTmVTenZXeDJxMDdmSUVKSlV4MVArYWVN?= =?utf-8?B?L2pYMW9WYXNVY20wMFNmVVJZcXJVNkVLbHRtNXRza24vbXhvYVpJNTdYdmF6?= =?utf-8?B?MEFURmxhcXdGd1h2ZGpQQ0I1QU5nbEpxV1JkZTVVUHhKemwrSXhmWXRWTjNN?= =?utf-8?B?RTc1SXhwSXBManFZcWtwZlVlbmMxeTgxbi9ZcWVrTk9EU1piSUVST3FrN21Z?= =?utf-8?B?R2RzN1VnVWpXTGFVUVBOYWMwTWE1SmlxZENrZzJVYzYrek5xWlduNmYyeDhE?= =?utf-8?B?RHBuSHU0bHpENkllSUtXWDE1OFJHcEFWN1hvOThFcEdvd2NYMDlyQ0RadWRn?= =?utf-8?B?R3IwNUhxUnp5TWVCMkhIUHF2TGVJaWwxZUxZOXZSVGYzdVlHL0JmV0M5Zllx?= =?utf-8?B?bmwvd2wyeEVISW1PLzhlbDFRZmRJY28vUllJUUxCR1FPbDVUdEJlOEM5VVFp?= =?utf-8?B?ZlZwU09Nb2lxKzlMNHRxaGVORjc1UU9FN2todEMvdDhaRnNJdGpEU2RxeHho?= =?utf-8?B?VnA0c2ZrQ1ZBWkkwQTYwZkhFVSsvUTZSSWdhODE3UWszelg4aXNiRmVtOGN2?= =?utf-8?B?bWJGZFp5alFOSjB2NytaV2oxZWVHek1RQ1dvOFpQNjU2SUJLSGtZdThlQ2tp?= =?utf-8?B?L0dwSjExNXhCTFExMFkwekFsQkQ3c3N5alEzZDZKSEp1ZXBsVzNRUWxHRUZR?= =?utf-8?B?RGdEY2pTNmpnUWs1VXJtemcyVEp5K1B4bkNvZXFvSlNaY0ttTkZNQ3JmTjZs?= =?utf-8?B?cFhON3Y2K2d0WjliWGJqaVBqVHIxSVlURHFMM1lIUDE4WjVhV0RDOFJJTFp2?= =?utf-8?B?dWI5ZDdoZHhIOURzd3MvMWR6VTNlUkU2c3hvcElMQ0RraXEyZjdrb2tLVkNO?= =?utf-8?Q?Yc9IhDeDjPe0yaLHcygF4nb774pwoimuODHhz3/lxw48g?= X-MS-Exchange-AntiSpam-MessageData-1: sfdGAXaEw9LUcQ== X-OriginatorOrg: Nvidia.com X-MS-Exchange-CrossTenant-Network-Message-Id: 9a4fd159-7f26-46e7-6dd5-08de85b5fec0 X-MS-Exchange-CrossTenant-AuthSource: CH2PR12MB3990.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Mar 2026 12:49:44.6858 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 43083d15-7273-40c1-b7db-39efd9ccc17a X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: MvSnS6cIPithcuPSgrgQcj+eWTbZyQO4R4rwqh38g3+9dzizOB8GoFvL3b2BKXNJVYULdzh2dvnF8T9j9BVeNA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR12MB4388 Hi Joel, On Wed Mar 18, 2026 at 7:03 AM JST, Joel Fernandes wrote: > Add safe Rust abstractions over the Linux kernel's GPU buddy > allocator for physical memory management. The GPU buddy allocator > implements a binary buddy system useful for GPU physical memory > allocation. nova-core will use it for physical memory allocation. > > Cc: Nikola Djukic > Signed-off-by: Joel Fernandes A few things came to mind when re-reading this again. I believe these will be my final comments on this patch though (famous last words). > +//! # Examples > +//! > +//! Create a buddy allocator and perform a basic range allocation: > +//! > +//! ``` > +//! use kernel::{ > +//! gpu::buddy::{ > +//! GpuBuddy, > +//! GpuBuddyAllocFlags, > +//! GpuBuddyAllocMode, > +//! GpuBuddyParams, // > +//! }, > +//! prelude::*, > +//! ptr::Alignment, > +//! sizes::*, // > +//! }; > +//! > +//! // Create a 1GB buddy allocator with 4KB minimum chunk size. > +//! let buddy =3D GpuBuddy::new(GpuBuddyParams { > +//! base_offset: 0, > +//! physical_memory_size: SZ_1G as u64, > +//! chunk_size: Alignment::new::(), > +//! })?; > +//! > +//! assert_eq!(buddy.size(), SZ_1G as u64); > +//! assert_eq!(buddy.chunk_size(), Alignment::new::()); Note that you can also use assert_eq!(buddy.chunk_size().as_usize(), SZ_4K); To avoid the `Alignment` constructor. > +impl GpuBuddyAllocMode { > + // Returns the C flags corresponding to the allocation mode. > + fn into_flags(self) -> usize { > + match self { > + Self::Simple =3D> 0, > + Self::Range { .. } =3D> bindings::GPU_BUDDY_RANGE_ALLOCATION= , > + Self::TopDown =3D> bindings::GPU_BUDDY_TOPDOWN_ALLOCATION, > + } > + } > + > + // Extracts the range start/end, defaulting to (0, 0) for non-range = modes. Let's use `(0, 0)` so they are properly formatted (I know it's not a doccomment, but the convention also applies to regular comments). > + fn range(self) -> (u64, u64) { > + match self { > + Self::Range { start, end } =3D> (start, end), > + _ =3D> (0, 0), > + } > + } > +} > + > +crate::impl_flags!( > + /// Modifier flags for GPU buddy allocation. > + /// > + /// These flags can be combined with any [`GpuBuddyAllocMode`] to co= ntrol > + /// additional allocation behavior. > + #[derive(Clone, Copy, Default, PartialEq, Eq)] > + pub struct GpuBuddyAllocFlags(u32); I've realized a bit late that this should actually be `GpuBuddyAllocFlags(usize)`. The values are defined in the bindings as `usize`, and we convert them to `u32`, only to convert them back into `usize` in `alloc_blocks`. I know it goes against the idea that flags should not have a size dependent on the architecture, but in this case it's just a consequence of the C API not doing it - and in the end we have to conform, so there is no point in resisting. Actually, `GpuBuddyAllocMode::into_flags` already return a `usize`, so we're already halfway there. Just going with the flow and using `usize` removes quite a few `as` in the code. Ideally we would fix the C API and switch back to `u32` in the near future but for now that's the best course of action imho. I've checked whether it worked, and it does - here is a diff for reference: https://github.com/Gnurou/linux/commit/2e1bfc2d8e1f93a76343c7c563b1f4b85a69= ab8b > + /// Get the base offset for allocations. > + pub fn base_offset(&self) -> u64 { > + self.0.params.base_offset > + } > + > + /// Get the chunk size (minimum allocation unit). > + pub fn chunk_size(&self) -> Alignment { > + self.0.params.chunk_size > + } > + > + /// Get the total managed size. > + pub fn size(&self) -> u64 { > + self.0.params.physical_memory_size > + } > + > + /// Get the available (free) memory in bytes. > + pub fn free_memory(&self) -> u64 { This name is a bit confusing as it can be interpreted as this method frees memory, whereas it doesn't free anything, and doesn't even deal with memory (but an address space that may or may not represent memory). In the C `struct gpu_buddy`, the member representing the chunk size is named `chunk_size`, and the total size `size`, making the two methods above this one adopt the same name (by a happy coincidence maybe :)). Let's do the same here - since we are querying `avail`, this method can just be called `avail` to align with the C API. In the same spirit, we should rename `GpuBuddyParams::physical_memory_size` into just `size` because that's the name of the corresponding field in `struct gpu_buddy` and again, we are not limited to managing physical memory with this allocator. > + let guard =3D self.0.lock(); > + > + // SAFETY: Per the type invariant, `inner` contains an initializ= ed allocator. > + // `guard` provides exclusive access. > + unsafe { (*guard.as_raw()).avail } > + } > + > + /// Allocate blocks from the buddy allocator. > + /// > + /// Returns a pin-initializer for [`AllocatedBlocks`]. > + pub fn alloc_blocks( > + &self, > + mode: GpuBuddyAllocMode, > + size: u64, > + min_block_size: Alignment, > + flags: impl Into, > + ) -> impl PinInit { > + let buddy_arc =3D Arc::clone(&self.0); > + let (start, end) =3D mode.range(); > + let mode_flags =3D mode.into_flags(); > + let modifier_flags =3D u32::from(flags.into()) as usize; > + > + // Create pin-initializer that initializes list and allocates bl= ocks. > + try_pin_init!(AllocatedBlocks { > + buddy: buddy_arc, > + list <- CListHead::new(), > + _: { > + // Reject zero-sized or inverted ranges. > + if let GpuBuddyAllocMode::Range { start, end } =3D mode = { > + if end <=3D start { > + Err::<(), Error>(EINVAL)?; > + } > + } Ah, indeed we want to disallow decreasing ranges. Actually, why not prevent them from even being expressed by using an actual Rust `Range`? This lets you turn this test into an `is_empty()` and removes 10 LoCs overall. You lose the ability to copy `GpuBuddyAllocMode`, but we don't need it in the first place. Here is a diff showing what it looks like, feel free to pick it: https://github.com/Gnurou/linux/commit/7f9348f6a64d0fbec7ddf99b78ca727a1ac1= cd06