linux-kernel - Re: [PATCH 00/10] mm: make mm->flags a bitmap and 64-bit on all arches

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: <af5492d4-f8dc-4270-a4c6-73d76f098942@lucifer.local>
Date: Wed, 13 Aug 2025 05:18:31 +0100
From: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
To: SeongJae Park <sj@...nel.org>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
        Gerald Schaefer <gerald.schaefer@...ux.ibm.com>,
        Heiko Carstens <hca@...ux.ibm.com>, Vasily Gorbik <gor@...ux.ibm.com>,
        Christian Borntraeger <borntraeger@...ux.ibm.com>,
        Sven Schnelle <svens@...ux.ibm.com>,
        "David S . Miller" <davem@...emloft.net>,
        Andreas Larsson <andreas@...sler.com>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        Andy Lutomirski <luto@...nel.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>,
        Borislav Petkov <bp@...en8.de>, "H . Peter Anvin" <hpa@...or.com>,
        Alexander Viro <viro@...iv.linux.org.uk>,
        Christian Brauner <brauner@...nel.org>, Jan Kara <jack@...e.cz>,
        Kees Cook <kees@...nel.org>, David Hildenbrand <david@...hat.com>,
        Zi Yan <ziy@...dia.com>, Baolin Wang <baolin.wang@...ux.alibaba.com>,
        "Liam R . Howlett" <Liam.Howlett@...cle.com>,
        Nico Pache <npache@...hat.com>, Ryan Roberts <ryan.roberts@....com>,
        Dev Jain <dev.jain@....com>, Barry Song <baohua@...nel.org>,
        Xu Xin <xu.xin16@....com.cn>,
        Chengming Zhou <chengming.zhou@...ux.dev>,
        Vlastimil Babka <vbabka@...e.cz>, Mike Rapoport <rppt@...nel.org>,
        Suren Baghdasaryan <surenb@...gle.com>, Michal Hocko <mhocko@...e.com>,
        David Rientjes <rientjes@...gle.com>,
        Shakeel Butt <shakeel.butt@...ux.dev>,
        Arnaldo Carvalho de Melo <acme@...nel.org>,
        Namhyung Kim <namhyung@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
        Jiri Olsa <jolsa@...nel.org>, Ian Rogers <irogers@...gle.com>,
        Adrian Hunter <adrian.hunter@...el.com>,
        Kan Liang <kan.liang@...ux.intel.com>,
        Masami Hiramatsu <mhiramat@...nel.org>,
        Oleg Nesterov <oleg@...hat.com>, 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>,
        Jason Gunthorpe <jgg@...pe.ca>, John Hubbard <jhubbard@...dia.com>,
        Peter Xu <peterx@...hat.com>, Jann Horn <jannh@...gle.com>,
        Pedro Falcato <pfalcato@...e.de>, Matthew Wilcox <willy@...radead.org>,
        Mateusz Guzik <mjguzik@...il.com>, linux-s390@...r.kernel.org,
        linux-kernel@...r.kernel.org, sparclinux@...r.kernel.org,
        linux-fsdevel@...r.kernel.org, linux-mm@...ck.org,
        linux-trace-kernel@...r.kernel.org, linux-perf-users@...r.kernel.org
Subject: Re: [PATCH 00/10] mm: make mm->flags a bitmap and 64-bit on all
 arches

On Tue, Aug 12, 2025 at 01:13:26PM -0700, SeongJae Park wrote:
> On Tue, 12 Aug 2025 16:44:09 +0100 Lorenzo Stoakes <lorenzo.stoakes@...cle.com> wrote:
>
> > We are currently in the bizarre situation where we are constrained on the
> > number of flags we can set in an mm_struct based on whether this is a
> > 32-bit or 64-bit kernel.
> >
> > This is because mm->flags is an unsigned long field, which is 32-bits on a
> > 32-bit system and 64-bits on a 64-bit system.
> >
> > In order to keep things functional across both architectures, we do not
> > permit mm flag bits to be set above flag 31 (i.e. the 32nd bit).
> >
> > This is a silly situation, especially given how profligate we are in
> > storing metadata in mm_struct, so let's convert mm->flags into a bitmap and
> > allow ourselves as many bits as we like.
>
> I like this conversion.

Thanks!

>
> [...]
> >
> > In order to execute this change, we introduce a new opaque type -
> > mm_flags_t - which wraps a bitmap.
>
> I have no strong opinion here, but I think coding-style.rst[1] has one?  To
> quote,
>
>     Please don't use things like ``vps_t``.
>     It's a **mistake** to use typedef for structures and pointers.

You stopped reading the relevant section in [1] :) Keep going and you see:

	Lots of people think that typedefs help readability. Not so. They
	are useful only for: totally opaque objects (where the typedef is
	actively used to hide what the object is).  Example: pte_t
	etc. opaque objects that you can only access using the proper
	accessor functions.

So this is what this is.

The point is that it's opaque, that is you aren't supposed to know about or
care about what's inside, you use the accessors.

This means we can extend the size of this thing as we like, and can enforce
atomicity through the accessors.

We further highlight the opaqueness through the use of the __private.

>
> checkpatch.pl also complains similarly.
>
> Again, I have no strong opinion, but I think adding a clarification about why
> we use typedef despite of the documented recommendation here might be nice?

I already gave one, I clearly indicate it's opaque.

>
> [...]
> > For mm->flags initialisation on fork, we adjust the logic to ensure all
> > bits are cleared correctly, and then adjust the existing intialisation
>
> Nit.  s/intialisation/initialisation/ ?

Ack thanks!

>
> [...]
>
> [1] https://docs.kernel.org/process/coding-style.html#typedefs
>
>
> Thanks,
> SJ