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: Windows password security audit tool. GUI, reports in PDF.
[<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

Powered by Openwall GNU/*/Linux Powered by OpenVZ