[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <8b12189f4379e9e321527ca2ece597a61c431c80.camel@intel.com>
Date: Wed, 28 Feb 2024 17:01:35 +0000
From: "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>
To: "keescook@...omium.org" <keescook@...omium.org>,
"christophe.leroy@...roup.eu" <christophe.leroy@...roup.eu>
CC: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"x86@...nel.org" <x86@...nel.org>, "luto@...nel.org" <luto@...nel.org>,
"dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>,
"debug@...osinc.com" <debug@...osinc.com>, "akpm@...ux-foundation.org"
<akpm@...ux-foundation.org>, "linux-sh@...r.kernel.org"
<linux-sh@...r.kernel.org>, "linux-csky@...r.kernel.org"
<linux-csky@...r.kernel.org>, "mingo@...hat.com" <mingo@...hat.com>,
"kirill.shutemov@...ux.intel.com" <kirill.shutemov@...ux.intel.com>,
"tglx@...utronix.de" <tglx@...utronix.de>, "linux-parisc@...r.kernel.org"
<linux-parisc@...r.kernel.org>, "loongarch@...ts.linux.dev"
<loongarch@...ts.linux.dev>, "linux-mm@...ck.org" <linux-mm@...ck.org>,
"linux-snps-arc@...ts.infradead.org" <linux-snps-arc@...ts.infradead.org>,
"Liam.Howlett@...cle.com" <Liam.Howlett@...cle.com>, "hpa@...or.com"
<hpa@...or.com>, "peterz@...radead.org" <peterz@...radead.org>,
"linuxppc-dev@...ts.ozlabs.org" <linuxppc-dev@...ts.ozlabs.org>,
"bp@...en8.de" <bp@...en8.de>, "linux-s390@...r.kernel.org"
<linux-s390@...r.kernel.org>, "linux-alpha@...r.kernel.org"
<linux-alpha@...r.kernel.org>, "linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>, "linux-mips@...r.kernel.org"
<linux-mips@...r.kernel.org>, "sparclinux@...r.kernel.org"
<sparclinux@...r.kernel.org>, "broonie@...nel.org" <broonie@...nel.org>
Subject: Re: [PATCH v2 5/9] mm: Initialize struct vm_unmapped_area_info
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
Powered by blists - more mailing lists