From: Nick Desaulniers <ndesaulniers@google.com>
To: Will Deacon <will@kernel.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
Luc Van Oostenryck <luc.vanoostenryck@gmail.com>,
LKML <linux-kernel@vger.kernel.org>,
Linux Memory Management List <linux-mm@kvack.org>,
Linux ARM <linux-arm-kernel@lists.infradead.org>,
Catalin Marinas <catalin.marinas@arm.com>,
Jan Kara <jack@suse.cz>, Minchan Kim <minchan@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
"Kirill A . Shutemov" <kirill.shutemov@linux.intel.com>,
Vinayak Menon <vinmenon@codeaurora.org>,
Hugh Dickins <hughd@google.com>,
kernel-team <kernel-team@android.com>
Subject: Re: [PATCH v4 8/8] mm: Mark anonymous struct field of 'struct vm_fault' as 'const'
Date: Fri, 22 Jan 2021 11:10:50 -0800 [thread overview]
Message-ID: <CAKwvOdkYwZHdPj=UGmc2da_3iM7_EN22Vhj7vO2rJ_CAkLEPTg@mail.gmail.com> (raw)
In-Reply-To: <20210121212832.GA23234@willie-the-truck>
On Thu, Jan 21, 2021 at 1:28 PM Will Deacon <will@kernel.org> wrote:
>
> On Thu, Jan 21, 2021 at 11:24:36AM -0800, Nick Desaulniers wrote:
> > On Thu, Jan 21, 2021 at 5:11 AM Will Deacon <will@kernel.org> wrote:
> > >
> > > On Wed, Jan 20, 2021 at 11:02:06AM -0800, Linus Torvalds wrote:
> > > > On Wed, Jan 20, 2021 at 10:27 AM Nick Desaulniers
> > > > <ndesaulniers@google.com> wrote:
> > > > >
> > > > > Is there a difference between: [ const unnamed struct and individual const members ]
> > > >
> > > > Semantically? No.
> > > >
> > > > Syntactically the "group the const members together" is a lot cleaner,
> > > > imho. Not just from a "just a single const" standpoint, but from a
> > > > "code as documentation" standpoint.
> > > >
> > > > But I guess to avoid the clang issue, we could do the "mark individual
> > > > fields" thing.
> > >
> > > I'd prefer to wait until the bug against LLVM has been resolved before we
> > > try to work around anything. Although I couldn't find any other examples
> > > like this in the kernel, requiring all of the member fields to be marked as
> > > 'const' still feels pretty fragile to me; it's only a matter of time before
> > > new non-const fields get added, at which point the temptation for developers
> > > to remove 'const' from other fields when it gets in the way is pretty high.
> >
> > What's to stop a new non-const field from getting added outside the
> > const qualified anonymous struct?
> > What's to stop someone from removing const from the anonymous struct?
> > What's to stop a number of callers from manipulating the structure
> > temporarily before restoring it when returning by casting away the
> > const?
> >
> > Code review.
>
> Sure, but here we are cleaning up this stuff, so I think review only gets
> you so far. To me:
>
> const struct {
> int foo;
> long bar;
> };
>
> clearly says "don't modify fields of this struct", whereas:
>
> struct {
> const int foo;
> const long bar;
> };
>
> says "don't modify foo or bar, but add whatever you like on the end" and
> that's the slippery slope.
"but you could add additional non-const members on the end" for sure.
Though going back to
>> What's to stop a new non-const field from getting added outside the
> > const qualified anonymous struct?
my point with that is that the const anonymous struct is within a
non-const anonymous struct.
struct vm_fault {
const {
struct vm_area_struct *vma;
gfp_t gfp_mask;
pgoff_t pgoff;
unsigned long address;
// Your point is about new member additions here, IIUC
};
// My point: what's to stop someone from adding a new non-const member here?
unsigned int flags;
pmd_t *pmd;
pud_t *pud;
...
// or here?
};
The const anonymous struct will help prevent additions of non-const
members to the anonymous struct, sure; but if someone really wanted a
new non-const member in a `struct vm_fault` instance they're just
going to go around the const anonymous struct. Or is there something
more I'm missing about the order of the members of struct vm_fault?
> So then we end up with the eye-sore of:
>
> const struct {
> const int foo;
> const long bar;
> };
>
> and maybe that's the right answer, but I'm just saying we should wait for
> clang to make up its mind first. It's not like this is a functional problem,
> and there are enough GCC users around that we're not exactly in a hurry.
Yeah, I mean I'm happy to whip something up for Clang, even though I
suspect it will get shot down in code review until there's more
guidance from standards bodies. It doesn't hurt to try, and at least
have a patch "waiting in the wings" should we hear back from WG14 that
favors GCC's behavior. Who knows, maybe the guidance will be that
WG21 should revisit this behavior for C++ to avoid divergence with C
(as g++ and gcc currently do).
--
Thanks,
~Nick Desaulniers
next prev parent reply other threads:[~2021-01-22 19:11 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-20 17:36 [PATCH v4 0/8] Create 'old' ptes for faultaround mappings on arm64 with hardware access flag Will Deacon
2021-01-20 17:36 ` [PATCH v4 1/8] mm: Cleanup faultaround and finish_fault() codepaths Will Deacon
2021-01-20 17:36 ` [PATCH v4 2/8] mm: Allow architectures to request 'old' entries when prefaulting Will Deacon
2021-01-20 17:36 ` [PATCH v4 3/8] arm64: mm: Implement arch_wants_old_prefaulted_pte() Will Deacon
2021-01-20 17:36 ` [PATCH v4 4/8] mm: Move immutable fields of 'struct vm_fault' into anonymous struct Will Deacon
2021-01-20 18:13 ` Nick Desaulniers
2021-01-21 12:48 ` Will Deacon
2021-01-20 17:36 ` [PATCH v4 5/8] mm: Pass 'address' to map to do_set_pte() and drop FAULT_FLAG_PREFAULT Will Deacon
2021-01-20 17:36 ` [PATCH v4 6/8] mm: Avoid modifying vmf.address in __collapse_huge_page_swapin() Will Deacon
2021-01-20 17:36 ` [PATCH v4 7/8] mm: Use static initialisers for immutable fields of 'struct vm_fault' Will Deacon
2021-01-20 18:21 ` Nick Desaulniers
2021-01-21 12:50 ` Will Deacon
2021-01-20 17:36 ` [PATCH v4 8/8] mm: Mark anonymous struct field of 'struct vm_fault' as 'const' Will Deacon
2021-01-20 18:27 ` Nick Desaulniers
2021-01-20 19:02 ` Linus Torvalds
2021-01-21 13:11 ` Will Deacon
2021-01-21 19:24 ` Nick Desaulniers
2021-01-21 21:28 ` Will Deacon
2021-01-22 19:10 ` Nick Desaulniers [this message]
2021-01-22 19:27 ` Will Deacon
2021-01-22 17:47 ` Linus Torvalds
2021-01-26 23:08 ` [PATCH v4 0/8] Create 'old' ptes for faultaround mappings on arm64 with hardware access flag Will Deacon
2021-01-26 23:28 ` Hugh Dickins
2021-01-27 17:16 ` Will Deacon
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='CAKwvOdkYwZHdPj=UGmc2da_3iM7_EN22Vhj7vO2rJ_CAkLEPTg@mail.gmail.com' \
--to=ndesaulniers@google.com \
--cc=akpm@linux-foundation.org \
--cc=catalin.marinas@arm.com \
--cc=hughd@google.com \
--cc=jack@suse.cz \
--cc=kernel-team@android.com \
--cc=kirill.shutemov@linux.intel.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=luc.vanoostenryck@gmail.com \
--cc=minchan@kernel.org \
--cc=torvalds@linux-foundation.org \
--cc=vinmenon@codeaurora.org \
--cc=will@kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).