From: SeongJae Park <sj@kernel.org>
To: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
Cc: SeongJae Park <sj@kernel.org>,
Gerald Schaefer <gerald.schaefer@linux.ibm.com>,
Heiko Carstens <hca@linux.ibm.com>,
Vasily Gorbik <gor@linux.ibm.com>,
Christian Borntraeger <borntraeger@linux.ibm.com>,
Sven Schnelle <svens@linux.ibm.com>,
"David S . Miller" <davem@davemloft.net>,
Andreas Larsson <andreas@gaisler.com>,
Dave Hansen <dave.hansen@linux.intel.com>,
Andy Lutomirski <luto@kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
"H . Peter Anvin" <hpa@zytor.com>,
Alexander Viro <viro@zeniv.linux.org.uk>,
Christian Brauner <brauner@kernel.org>, Jan Kara <jack@suse.cz>,
Kees Cook <kees@kernel.org>, David Hildenbrand <david@redhat.com>,
Zi Yan <ziy@nvidia.com>,
Baolin Wang <baolin.wang@linux.alibaba.com>,
"Liam R . Howlett" <Liam.Howlett@oracle.com>,
Nico Pache <npache@redhat.com>,
Ryan Roberts <ryan.roberts@arm.com>, Dev Jain <dev.jain@arm.com>,
Barry Song <baohua@kernel.org>, Xu Xin <xu.xin16@zte.com.cn>,
Chengming Zhou <chengming.zhou@linux.dev>,
Vlastimil Babka <vbabka@suse.cz>, Mike Rapoport <rppt@kernel.org>,
Suren Baghdasaryan <surenb@google.com>,
Michal Hocko <mhocko@suse.com>,
David Rientjes <rientjes@google.com>,
Shakeel Butt <shakeel.butt@linux.dev>,
Arnaldo Carvalho de Melo <acme@kernel.org>,
Namhyung Kim <namhyung@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
Alexander Shishkin <alexander.shishkin@linux.intel.com>,
Jiri Olsa <jolsa@kernel.org>, Ian Rogers <irogers@google.com>,
Adrian Hunter <adrian.hunter@intel.com>,
Kan Liang <kan.liang@linux.intel.com>,
Masami Hiramatsu <mhiramat@kernel.org>,
Oleg Nesterov <oleg@redhat.com>,
Juri Lelli <juri.lelli@redhat.com>,
Vincent Guittot <vincent.guittot@linaro.org>,
Dietmar Eggemann <dietmar.eggemann@arm.com>,
Steven Rostedt <rostedt@goodmis.org>,
Ben Segall <bsegall@google.com>, Mel Gorman <mgorman@suse.de>,
Valentin Schneider <vschneid@redhat.com>,
Jason Gunthorpe <jgg@ziepe.ca>,
John Hubbard <jhubbard@nvidia.com>, Peter Xu <peterx@redhat.com>,
Jann Horn <jannh@google.com>, Pedro Falcato <pfalcato@suse.de>,
Matthew Wilcox <willy@infradead.org>,
Mateusz Guzik <mjguzik@gmail.com>,
linux-s390@vger.kernel.org, linux-kernel@vger.kernel.org,
sparclinux@vger.kernel.org, linux-fsdevel@vger.kernel.org,
linux-mm@kvack.org, linux-trace-kernel@vger.kernel.org,
linux-perf-users@vger.kernel.org
Subject: Re: [PATCH 00/10] mm: make mm->flags a bitmap and 64-bit on all arches
Date: Wed, 13 Aug 2025 09:24:45 -0700 [thread overview]
Message-ID: <20250813162445.5456-1-sj@kernel.org> (raw)
In-Reply-To: <af5492d4-f8dc-4270-a4c6-73d76f098942@lucifer.local>
On Wed, 13 Aug 2025 05:18:31 +0100 Lorenzo Stoakes <lorenzo.stoakes@oracle.com> wrote:
> 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@oracle.com> wrote:
[...]
> > > 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.
You're completely right and I agree all the points. Thank you for kindly
enlightening me :)
Thanks,
SJ
[...]
prev parent reply other threads:[~2025-08-13 16:24 UTC|newest]
Thread overview: 71+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-12 15:44 [PATCH 00/10] mm: make mm->flags a bitmap and 64-bit on all arches Lorenzo Stoakes
2025-08-12 15:44 ` [PATCH 01/10] mm: add bitmap mm->flags field Lorenzo Stoakes
2025-08-12 16:20 ` Liam R. Howlett
2025-08-13 19:53 ` Lorenzo Stoakes
2025-08-26 12:48 ` David Hildenbrand
2025-08-12 15:44 ` [PATCH 02/10] mm: convert core mm to mm_flags_*() accessors Lorenzo Stoakes
2025-08-12 16:32 ` Liam R. Howlett
2025-08-12 22:52 ` Andrew Morton
2025-08-13 4:11 ` Lorenzo Stoakes
2025-08-14 8:27 ` Mike Rapoport
2025-08-15 6:07 ` Baolin Wang
2025-08-26 12:50 ` David Hildenbrand
2025-08-26 12:58 ` Lorenzo Stoakes
2025-09-16 19:49 ` Chris Mason
2025-09-17 0:16 ` Mateusz Guzik
2025-09-17 5:20 ` Lorenzo Stoakes
2025-09-17 5:22 ` Mateusz Guzik
2025-09-17 5:13 ` Lorenzo Stoakes
2025-09-17 5:16 ` Lorenzo Stoakes
2025-09-17 23:40 ` Andrew Morton
2025-09-18 5:56 ` Lorenzo Stoakes
2025-08-12 15:44 ` [PATCH 03/10] mm: convert prctl " Lorenzo Stoakes
2025-08-12 16:34 ` Liam R. Howlett
2025-08-14 8:29 ` Mike Rapoport
2025-08-26 12:50 ` David Hildenbrand
2025-08-12 15:44 ` [PATCH 04/10] mm: convert arch-specific code " Lorenzo Stoakes
2025-08-12 17:19 ` Liam R. Howlett
2025-08-13 14:10 ` Lorenzo Stoakes
2025-08-14 8:30 ` Mike Rapoport
2025-08-26 12:51 ` David Hildenbrand
2025-08-12 15:44 ` [PATCH 05/10] mm: convert uprobes " Lorenzo Stoakes
2025-08-12 17:24 ` Liam R. Howlett
2025-08-14 8:33 ` Mike Rapoport
2025-08-26 12:51 ` David Hildenbrand
2025-08-12 15:44 ` [PATCH 06/10] mm: update coredump logic to correctly use bitmap mm flags Lorenzo Stoakes
2025-08-12 17:26 ` Liam R. Howlett
2025-08-14 8:37 ` Mike Rapoport
2025-08-15 13:52 ` Christian Brauner
2025-08-15 14:12 ` Lorenzo Stoakes
2025-08-26 11:33 ` Lorenzo Stoakes
2025-08-26 12:52 ` David Hildenbrand
2025-08-12 15:44 ` [PATCH 07/10] mm: correct sign-extension issue in MMF_* flag masks Lorenzo Stoakes
2025-08-12 17:30 ` Liam R. Howlett
2025-08-14 8:38 ` Mike Rapoport
2025-08-26 13:05 ` David Hildenbrand
2025-08-26 13:59 ` Lorenzo Stoakes
2025-08-26 14:08 ` Lorenzo Stoakes
2025-08-12 15:44 ` [PATCH 08/10] mm: update fork mm->flags initialisation to use bitmap Lorenzo Stoakes
2025-08-12 17:31 ` Liam R. Howlett
2025-08-14 8:39 ` Mike Rapoport
2025-08-26 13:12 ` David Hildenbrand
2025-08-26 14:21 ` Lorenzo Stoakes
2025-08-26 14:28 ` David Hildenbrand
2025-08-26 14:32 ` Lorenzo Stoakes
2025-08-26 15:24 ` David Hildenbrand
2025-08-26 15:39 ` Lorenzo Stoakes
2025-08-26 15:53 ` David Hildenbrand
2025-08-26 16:26 ` Lorenzo Stoakes
2025-08-12 15:44 ` [PATCH 09/10] mm: convert remaining users to mm_flags_*() accessors Lorenzo Stoakes
2025-08-12 17:32 ` Liam R. Howlett
2025-08-14 8:42 ` Mike Rapoport
2025-08-26 13:13 ` David Hildenbrand
2025-08-12 15:44 ` [PATCH 10/10] mm: replace mm->flags with bitmap entirely and set to 64 bits Lorenzo Stoakes
2025-08-12 17:35 ` Liam R. Howlett
2025-08-12 17:43 ` Lorenzo Stoakes
2025-08-14 8:43 ` Mike Rapoport
2025-08-26 13:14 ` David Hildenbrand
2025-08-26 13:22 ` Lorenzo Stoakes
2025-08-12 20:13 ` [PATCH 00/10] mm: make mm->flags a bitmap and 64-bit on all arches SeongJae Park
2025-08-13 4:18 ` Lorenzo Stoakes
2025-08-13 16:24 ` SeongJae Park [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20250813162445.5456-1-sj@kernel.org \
--to=sj@kernel.org \
--cc=Liam.Howlett@oracle.com \
--cc=acme@kernel.org \
--cc=adrian.hunter@intel.com \
--cc=alexander.shishkin@linux.intel.com \
--cc=andreas@gaisler.com \
--cc=baohua@kernel.org \
--cc=baolin.wang@linux.alibaba.com \
--cc=borntraeger@linux.ibm.com \
--cc=bp@alien8.de \
--cc=brauner@kernel.org \
--cc=bsegall@google.com \
--cc=chengming.zhou@linux.dev \
--cc=dave.hansen@linux.intel.com \
--cc=davem@davemloft.net \
--cc=david@redhat.com \
--cc=dev.jain@arm.com \
--cc=dietmar.eggemann@arm.com \
--cc=gerald.schaefer@linux.ibm.com \
--cc=gor@linux.ibm.com \
--cc=hca@linux.ibm.com \
--cc=hpa@zytor.com \
--cc=irogers@google.com \
--cc=jack@suse.cz \
--cc=jannh@google.com \
--cc=jgg@ziepe.ca \
--cc=jhubbard@nvidia.com \
--cc=jolsa@kernel.org \
--cc=juri.lelli@redhat.com \
--cc=kan.liang@linux.intel.com \
--cc=kees@kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=lorenzo.stoakes@oracle.com \
--cc=luto@kernel.org \
--cc=mark.rutland@arm.com \
--cc=mgorman@suse.de \
--cc=mhiramat@kernel.org \
--cc=mhocko@suse.com \
--cc=mingo@redhat.com \
--cc=mjguzik@gmail.com \
--cc=namhyung@kernel.org \
--cc=npache@redhat.com \
--cc=oleg@redhat.com \
--cc=peterx@redhat.com \
--cc=peterz@infradead.org \
--cc=pfalcato@suse.de \
--cc=rientjes@google.com \
--cc=rostedt@goodmis.org \
--cc=rppt@kernel.org \
--cc=ryan.roberts@arm.com \
--cc=shakeel.butt@linux.dev \
--cc=sparclinux@vger.kernel.org \
--cc=surenb@google.com \
--cc=svens@linux.ibm.com \
--cc=tglx@linutronix.de \
--cc=vbabka@suse.cz \
--cc=vincent.guittot@linaro.org \
--cc=viro@zeniv.linux.org.uk \
--cc=vschneid@redhat.com \
--cc=willy@infradead.org \
--cc=xu.xin16@zte.com.cn \
--cc=ziy@nvidia.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.