From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f73.google.com (mail-wr1-f73.google.com [209.85.221.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 387C5CA4E for ; Tue, 25 Nov 2025 10:13:12 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.73 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764065594; cv=none; b=LxmIs2EjcrC9PKjRYSYdfFbzanzNWEvBzd62W/Zh/0d8Bhw3TUQf3E8H6jT1ZOlHedEt9keZuxlB0pKajldOmWOzZNU7DO7TCldooRgly3yPglPQbEOza7+Bs9dMftCe78Ei4aRj1T5sUeZyHDY1/c5j8GdjW70N43f1Bra7tUo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764065594; c=relaxed/simple; bh=gsMSARXH32SKLC9OxBjpDrzvpj6wltDkXJ6u0vg9Su8=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=B+7wpK8Jo9fWnPMDqapU2egWMHAaB4uoB0M/EwuuDiXrXap1uVGnsQk8iVf/d7qGvjxFPXp+aalgWZG160m39IS/XGfwWMDWHvVJ03a4wUROSyg7kh4y5T7INXGqw59C0ef4swrXTJcixyK2eLJSiLBXSJ6Z66Q9s4ffY5x1bG0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--aliceryhl.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=MDCYvSWY; arc=none smtp.client-ip=209.85.221.73 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--aliceryhl.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="MDCYvSWY" Received: by mail-wr1-f73.google.com with SMTP id ffacd0b85a97d-429cbed2b8fso2957052f8f.1 for ; Tue, 25 Nov 2025 02:13:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1764065590; x=1764670390; darn=vger.kernel.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=b/erQEEZyPzxAtDWVJKBMClg46msX9PfsRuYGXr+zPI=; b=MDCYvSWYa/wtKq521faSxcIA7Qkau3XRMeBqoxxgycyRi8jDx19UcB5mhBzbtZQXb9 qxpi6Ji90MBdeor5dtgoBnb8JUOd62q+L0BFPG/gHU/Qtb/FzlakvvXxWEqoDAlnHMe5 jbDGkaekjG5C+N3HUw0XSxH1H0mKo4l66V+9eWWOITeZc8JHiS5wuxTpxrHPhQH8ZFXY s6CKkLnFceh/ZiNyBbskaDvjKg03l0ONiYXxPSU/klz6+16RjqUcgDB4rcP8fvZc0bgK UUuB/od52BOf+0IMjCq9BD8PHoMo/DnGbIW9q0H7nKZxSiIHFznP4jSbLiIZCSq/Aa9X SksQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1764065590; x=1764670390; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=b/erQEEZyPzxAtDWVJKBMClg46msX9PfsRuYGXr+zPI=; b=FnHjHYsSVTh1Nk/2sBndPSvkQgruTtrtmm7wgl6aSsQghT71kGVCFBo1ZxL39oIRj4 UCG2tyxm+MJ3Zp3ITYHl5f0yAaOQRVkCedRo/DYPfDK040DmTk/F1Fm4NO63CjSY79Wb Cw+HBfIB7Ujcp3/vR/DNSQ7uXcQQUwDrcu3N5yh0WcfUXP3WAaoNd+AIJjAvvQIFfgZC pB6g1+bK7GgVLP5DObm3ywQB/0irZE5f8Z8DE53CBGh4XymID3TuVsMsUgA795dGcOA6 g4YI2KnBoipsYqKZ4duDD7SywufnozhTyoGokTC8Ti36Kdz0fKbeK/6KxQACh+b0s8x0 0g1A== X-Forwarded-Encrypted: i=1; AJvYcCUpeTI9uz/NE6DUBvgX4EHwO7kyWVYgBJwCj7E3j5UX0CfvD7FjV9L3chvyZI4TZfeg7qjNV4PZqSNpOoo=@vger.kernel.org X-Gm-Message-State: AOJu0YwyeeeNMgMuMX1/HFNU/JqJTD96QLp/FjiaF89B5U4NmzJQl+/n LItr2NUmhNH0474G0JZ69fEb6yyYM69QDaQ6TkGTB4dvpkHmHx0ttxSimYmohW9jnW3YJy+NK3J mm/eTbqZXy8hPhSXEIg== X-Google-Smtp-Source: AGHT+IHsGtiL+iNDNVV1EqqG8i9Q6opGUyl7TTE27f4MhISajHThGLKjh7t7VU/7sKSZKE4kViLCm6zohC53wBY= X-Received: from wrno15.prod.google.com ([2002:adf:eacf:0:b0:42b:31d0:1334]) (user=aliceryhl job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6000:26c4:b0:42b:2f79:755e with SMTP id ffacd0b85a97d-42cc1ab8874mr14661798f8f.3.1764065590345; Tue, 25 Nov 2025 02:13:10 -0800 (PST) Date: Tue, 25 Nov 2025 10:13:09 +0000 In-Reply-To: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: Message-ID: Subject: Re: [PATCH v3 0/4] initial work on making VMA flags a bitmap From: Alice Ryhl To: Lorenzo Stoakes Cc: Andrew Morton , Muchun Song , Oscar Salvador , David Hildenbrand , "Liam R . Howlett" , Vlastimil Babka , Mike Rapoport , Suren Baghdasaryan , Michal Hocko , Axel Rasmussen , Yuanchu Xie , Wei Xu , Peter Xu , Ingo Molnar , Peter Zijlstra , Juri Lelli , Vincent Guittot , Dietmar Eggemann , Steven Rostedt , Ben Segall , Mel Gorman , Valentin Schneider , Kees Cook , Matthew Wilcox , Jason Gunthorpe , John Hubbard , Leon Romanovsky , Zi Yan , Baolin Wang , Nico Pache , Ryan Roberts , Dev Jain , Barry Song , Lance Yang , Xu Xin , Chengming Zhou , Jann Horn , Matthew Brost , Joshua Hahn , Rakie Kim , Byungchul Park , Gregory Price , Ying Huang , Alistair Popple , Pedro Falcato , Shakeel Butt , David Rientjes , Rik van Riel , Harry Yoo , Kemeng Shi , Kairui Song , Nhat Pham , Baoquan He , Chris Li , Johannes Weiner , Qi Zheng , linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, Miguel Ojeda , Alex Gaynor , Boqun Feng , Gary Guo , Bjorn Roy Baron , Benno Lossin , Andreas Hindborg , Trevor Gross , Danilo Krummrich , rust-for-linux@vger.kernel.org Content-Type: text/plain; charset="utf-8" On Tue, Nov 25, 2025 at 10:00:58AM +0000, Lorenzo Stoakes wrote: > We are in the rather silly situation that we are running out of VMA flags > as they are currently limited to a system word in size. > > This leads to absurd situations where we limit features to 64-bit > architectures only because we simply do not have the ability to add a flag > for 32-bit ones. > > This is very constraining and leads to hacks or, in the worst case, simply > an inability to implement features we want for entirely arbitrary reasons. > > This also of course gives us something of a Y2K type situation in mm where > we might eventually exhaust all of the VMA flags even on 64-bit systems. > > This series lays the groundwork for getting away from this limitation by > establishing VMA flags as a bitmap whose size we can increase in future > beyond 64 bits if required. > > This is necessarily a highly iterative process given the extensive use of > VMA flags throughout the kernel, so we start by performing basic steps. > > Firstly, we declare VMA flags by bit number rather than by value, retaining > the VM_xxx fields but in terms of these newly introduced VMA_xxx_BIT > fields. > > While we are here, we use sparse annotations to ensure that, when dealing > with VMA bit number parameters, we cannot be passed values which are not > declared as such - providing some useful type safety. > > We then introduce an opaque VMA flag type, much like the opaque mm_struct > flag type introduced in commit bb6525f2f8c4 ("mm: add bitmap mm->flags > field"), which we establish in union with vma->vm_flags (but still set at > system word size meaning there is no functional or data type size change). > > We update the vm_flags_xxx() helpers to use this new bitmap, introducing > sensible helpers to do so. > > This series lays the foundation for further work to expand the use of > bitmap VMA flags and eventually eliminate these arbitrary restrictions. LGTM from Rust perspective. Acked-by: Alice Ryhl