linux-kernel - Re: [RFC PATCH 0/2] mm: introduce anon

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Z8h04F4b_YVMhXCM@casper.infradead.org>
Date: Wed, 5 Mar 2025 15:59:28 +0000
From: Matthew Wilcox <willy@...radead.org>
To: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
	Vlastimil Babka <vbabka@...e.cz>, Jann Horn <jannh@...gle.com>,
	"Liam R . Howlett" <Liam.Howlett@...cle.com>,
	Alexander Viro <viro@...iv.linux.org.uk>,
	Christian Brauner <brauner@...nel.org>, Jan Kara <jack@...e.cz>,
	Paul Moore <paul@...l-moore.com>,
	Stephen Smalley <stephen.smalley.work@...il.com>,
	Ondrej Mosnacek <omosnace@...hat.com>,
	Suren Baghdasaryan <surenb@...gle.com>,
	David Hildenbrand <david@...hat.com>, linux-mm@...ck.org,
	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
	selinux@...r.kernel.org
Subject: Re: [RFC PATCH 0/2] mm: introduce anon_vma flags, reduce kernel
 allocs

On Wed, Mar 05, 2025 at 02:55:06PM +0000, Lorenzo Stoakes wrote:
> So adding additional fields is generally unviable, and VMA flags are
> equally as contended, and prevent VMA merge, further impacting overhead.
> 
> We can however make use of the time-honoured kernel tradition of grabbing
> bits where we can.
> 
> Since we can rely upon anon_vma allocations being at least system
> word-aligned, we have a handful of bits in the vma->anon_vma available to
> use as flags.

I'm not a huge fan when there's a much better solution.  It's an
unsigned long, but we can only use the first 32 bits because of 32-bit
compatibility?  This is a noose we've made for our own neck.

(there are many more places to fix up; this is illustrative):

diff --git a/include/linux/hugetlb_inline.h b/include/linux/hugetlb_inline.h
index 0660a03d37d9..c6ea81ff4afe 100644
--- a/include/linux/hugetlb_inline.h
+++ b/include/linux/hugetlb_inline.h
@@ -8,7 +8,7 @@
 
 static inline bool is_vm_hugetlb_page(struct vm_area_struct *vma)
 {
-	return !!(vma->vm_flags & VM_HUGETLB);
+	return test_bit(VM_HUGETLB, vma->vm_flags);
 }
 
 #else
diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
index 0ca9feec67b8..763210ba70b6 100644
--- a/include/linux/mm_types.h
+++ b/include/linux/mm_types.h
@@ -571,7 +571,8 @@ static inline void *folio_get_private(struct folio *folio)
 	return folio->private;
 }
 
-typedef unsigned long vm_flags_t;
+#define VM_FLAGS_COUNT	(8 / sizeof(unsigned long))
+typedef unsigned long vm_flags_t[VM_FLAGS_COUNT];
 
 /*
  * A region containing a mapping of a non-memory backed file under NOMMU