linux-kernel - Re: [PATCH 4/4] mm: introduce and use VMA flag test helpers

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20251030125234.GA1204670@ziepe.ca>
Date: Thu, 30 Oct 2025 09:52:34 -0300
From: Jason Gunthorpe <jgg@...pe.ca>
To: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
	Muchun Song <muchun.song@...ux.dev>,
	Oscar Salvador <osalvador@...e.de>,
	David Hildenbrand <david@...hat.com>,
	"Liam R . Howlett" <Liam.Howlett@...cle.com>,
	Vlastimil Babka <vbabka@...e.cz>, Mike Rapoport <rppt@...nel.org>,
	Suren Baghdasaryan <surenb@...gle.com>,
	Michal Hocko <mhocko@...e.com>,
	Axel Rasmussen <axelrasmussen@...gle.com>,
	Yuanchu Xie <yuanchu@...gle.com>, Wei Xu <weixugc@...gle.com>,
	Peter Xu <peterx@...hat.com>, Ingo Molnar <mingo@...hat.com>,
	Peter Zijlstra <peterz@...radead.org>,
	Juri Lelli <juri.lelli@...hat.com>,
	Vincent Guittot <vincent.guittot@...aro.org>,
	Dietmar Eggemann <dietmar.eggemann@....com>,
	Steven Rostedt <rostedt@...dmis.org>,
	Ben Segall <bsegall@...gle.com>, Mel Gorman <mgorman@...e.de>,
	Valentin Schneider <vschneid@...hat.com>,
	Kees Cook <kees@...nel.org>, Matthew Wilcox <willy@...radead.org>,
	John Hubbard <jhubbard@...dia.com>,
	Leon Romanovsky <leon@...nel.org>, Zi Yan <ziy@...dia.com>,
	Baolin Wang <baolin.wang@...ux.alibaba.com>,
	Nico Pache <npache@...hat.com>, Ryan Roberts <ryan.roberts@....com>,
	Dev Jain <dev.jain@....com>, Barry Song <baohua@...nel.org>,
	Lance Yang <lance.yang@...ux.dev>, Xu Xin <xu.xin16@....com.cn>,
	Chengming Zhou <chengming.zhou@...ux.dev>,
	Jann Horn <jannh@...gle.com>,
	Matthew Brost <matthew.brost@...el.com>,
	Joshua Hahn <joshua.hahnjy@...il.com>, Rakie Kim <rakie.kim@...com>,
	Byungchul Park <byungchul@...com>,
	Gregory Price <gourry@...rry.net>,
	Ying Huang <ying.huang@...ux.alibaba.com>,
	Alistair Popple <apopple@...dia.com>,
	Pedro Falcato <pfalcato@...e.de>,
	Shakeel Butt <shakeel.butt@...ux.dev>,
	David Rientjes <rientjes@...gle.com>,
	Rik van Riel <riel@...riel.com>, Harry Yoo <harry.yoo@...cle.com>,
	Kemeng Shi <shikemeng@...weicloud.com>,
	Kairui Song <kasong@...cent.com>, Nhat Pham <nphamcs@...il.com>,
	Baoquan He <bhe@...hat.com>, Chris Li <chrisl@...nel.org>,
	Johannes Weiner <hannes@...xchg.org>,
	Qi Zheng <zhengqi.arch@...edance.com>, linux-kernel@...r.kernel.org,
	linux-fsdevel@...r.kernel.org, linux-mm@...ck.org
Subject: Re: [PATCH 4/4] mm: introduce and use VMA flag test helpers

On Thu, Oct 30, 2025 at 10:04:31AM +0000, Lorenzo Stoakes wrote:
> It may also just be sensible to drop the vma_test() since I've named VMA flags
> vma->flags which is kinda neat and not so painful to do:
> 
> 	if (vma_flags_test(&vma->flags, VMA_READ_BIT)) {
> 	}
> 
> Another note - I do hope to drop the _BIT at some point. But it felt egregious
> to do so _now_ since VM_READ, VMA_READ are so close it'd be _super_ easy to
> mistake the two.

Yes, you should have the bit until the non-bit versions are removed
entirely.

> Buuut I'm guessing actually you're thinking more of getting rid of
> vm_flags_word_[and, any, all]() all of which take VM_xxx parameters.

Yes
 
> > few instructions.
> >
> 
> Well I'm not sure, hopefully. Maybe I need to test this and see exactly what the
> it comes up with.
> 
> I mean you could in theory have:
> 
> vma_flags_any(&vma->flags, OR_VMA_FLAGS(VMA_PFNMAP_BIT, VMA_SEALED_BIT))

'any' here means any of the given bits set, yes? So the operation is

(flags & to_test) != 0

Which is bitmap_and, not or. In this case the compiler goes word by
word:

  flags[0] & to_test[0] != 0
  flags[1] & to_test[1] != 0
 
And constant propagation turns it into
  flags[1] & 0 != 0 ----> 0

So the extra word just disappears.

Similarly if you want to do a set bit using or

  flags[0] = flags[0] | to_set[0]
  flags[1] = flags[1] | to_set[1]

And again constant propagation
  flags[1] = flags[1] | 0 ------>  NOP

> I feel like we're going to need the 'special first word' stuff permanently for
> performance reasons.

I think not, look above..

> > Then everything only works with _BIT and we don't have the special
> > first word situation.
> 
> In any case we still need to maintain the word stuff for legacy purposes at
> least to handle the existing vm_flags_*() interfaces until the work is complete.

I think it will be hard to sustain this idea that some operations do
not work on the bits in the second word, it is just not very natural
going forward..

So I'd try to structure things to remove the non-BIT users before
adding multi-word..

Jason