From: "Edgecombe, Rick P" <rick.p.edgecombe@intel.com>
To: "keescook@chromium.org" <keescook@chromium.org>,
"christophe.leroy@csgroup.eu" <christophe.leroy@csgroup.eu>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"x86@kernel.org" <x86@kernel.org>,
"luto@kernel.org" <luto@kernel.org>,
"dave.hansen@linux.intel.com" <dave.hansen@linux.intel.com>,
"debug@rivosinc.com" <debug@rivosinc.com>,
"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
"linux-sh@vger.kernel.org" <linux-sh@vger.kernel.org>,
"linux-csky@vger.kernel.org" <linux-csky@vger.kernel.org>,
"mingo@redhat.com" <mingo@redhat.com>,
"kirill.shutemov@linux.intel.com"
<kirill.shutemov@linux.intel.com>,
"tglx@linutronix.de" <tglx@linutronix.de>,
"linux-parisc@vger.kernel.org" <linux-parisc@vger.kernel.org>,
"loongarch@lists.linux.dev" <loongarch@lists.linux.dev>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
"linux-snps-arc@lists.infradead.org"
<linux-snps-arc@lists.infradead.org>,
"Liam.Howlett@oracle.com" <Liam.Howlett@oracle.com>,
"hpa@zytor.com" <hpa@zytor.com>,
"peterz@infradead.org" <peterz@infradead.org>,
"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>,
"bp@alien8.de" <bp@alien8.de>,
"linux-s390@vger.kernel.org" <linux-s390@vger.kernel.org>,
"linux-alpha@vger.kernel.org" <linux-alpha@vger.kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"linux-mips@vger.kernel.org" <linux-mips@vger.kernel.org>,
"sparclinux@vger.kernel.org" <sparclinux@vger.kernel.org>,
"broonie@kernel.org" <broonie@kernel.org>
Subject: Re: [PATCH v2 5/9] mm: Initialize struct vm_unmapped_area_info
Date: Wed, 28 Feb 2024 17:01:35 +0000 [thread overview]
Message-ID: <8b12189f4379e9e321527ca2ece597a61c431c80.camel@intel.com> (raw)
In-Reply-To: <def71a27-2d5f-40da-867e-979648afc4cf@csgroup.eu>
On Wed, 2024-02-28 at 13:22 +0000, Christophe Leroy wrote:
> > Any preference? Or maybe am I missing your point and talking
> > nonsense?
> >
>
> So my preference would go to the addition of:
>
> info.new_field = 0;
>
> But that's very minor and if you think it is easier to manage and
> maintain by performing {} initialisation at declaration, lets go for
> that.
Appreciate the clarification and help getting this right. I'm thinking
Kees' and now Kirill's point about this patch resulting in unnecessary
manual zero initialization of the structs is probably something that
needs to be addressed.
If I created a bunch of patches to change each call site, I think the
the best is probably to do the designated field zero initialization
way.
But I can do something for powerpc special if you want. I'll first try
with powerpc matching the others, and if it seems objectionable, please
let me know.
Thanks,
Rick
next prev parent reply other threads:[~2024-02-28 17:02 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-26 19:09 [PATCH v2 0/9] Cover a guard gap corner case Rick Edgecombe
2024-02-26 19:09 ` [PATCH v2 1/9] mm: Switch mm->get_unmapped_area() to a flag Rick Edgecombe
2024-02-26 19:09 ` [PATCH v2 2/9] mm: Introduce arch_get_unmapped_area_vmflags() Rick Edgecombe
2024-02-26 19:09 ` [PATCH v2 3/9] mm: Use get_unmapped_area_vmflags() Rick Edgecombe
2024-02-26 19:09 ` [PATCH v2 4/9] thp: Add thp_get_unmapped_area_vmflags() Rick Edgecombe
2024-02-26 19:09 ` [PATCH v2 5/9] mm: Initialize struct vm_unmapped_area_info Rick Edgecombe
2024-02-27 7:02 ` Christophe Leroy
2024-02-27 15:00 ` Edgecombe, Rick P
2024-02-27 18:07 ` Kees Cook
2024-02-27 18:16 ` Christophe Leroy
2024-02-27 20:25 ` Edgecombe, Rick P
2024-02-28 13:22 ` Christophe Leroy
2024-02-28 17:01 ` Edgecombe, Rick P [this message]
2024-02-28 23:10 ` Christophe Leroy
2024-02-28 17:21 ` Kees Cook
2024-03-02 0:47 ` Edgecombe, Rick P
2024-03-02 1:51 ` Kees Cook
2024-03-04 18:00 ` Christophe Leroy
2024-03-04 18:03 ` Edgecombe, Rick P
2024-02-28 11:51 ` Kirill A. Shutemov
[not found] ` <20240302001714.674091-1-rick.p.edgecombe@intel.com>
2024-03-02 0:17 ` [RFC v2.1 12/12] hugetlbfs: Use initializer for " Rick Edgecombe
2024-02-26 19:09 ` [PATCH v2 6/9] mm: Take placement mappings gap into account Rick Edgecombe
2024-02-26 19:09 ` [PATCH v2 7/9] x86/mm: Implement HAVE_ARCH_UNMAPPED_AREA_VMFLAGS Rick Edgecombe
2024-02-26 19:09 ` [PATCH v2 8/9] x86/mm: Care about shadow stack guard gap during placement Rick Edgecombe
2024-02-26 19:09 ` [PATCH v2 9/9] selftests/x86: Add placement guard gap test for shstk Rick Edgecombe
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=8b12189f4379e9e321527ca2ece597a61c431c80.camel@intel.com \
--to=rick.p.edgecombe@intel.com \
--cc=Liam.Howlett@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=bp@alien8.de \
--cc=broonie@kernel.org \
--cc=christophe.leroy@csgroup.eu \
--cc=dave.hansen@linux.intel.com \
--cc=debug@rivosinc.com \
--cc=hpa@zytor.com \
--cc=keescook@chromium.org \
--cc=kirill.shutemov@linux.intel.com \
--cc=linux-alpha@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-csky@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mips@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-parisc@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=linux-sh@vger.kernel.org \
--cc=linux-snps-arc@lists.infradead.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=loongarch@lists.linux.dev \
--cc=luto@kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=sparclinux@vger.kernel.org \
--cc=tglx@linutronix.de \
--cc=x86@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).