From: Kees Cook <keescook@chromium.org>
To: Christophe Leroy <christophe.leroy@csgroup.eu>
Cc: Rick Edgecombe <rick.p.edgecombe@intel.com>,
"Liam.Howlett@oracle.com" <Liam.Howlett@oracle.com>,
"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
"debug@rivosinc.com" <debug@rivosinc.com>,
"broonie@kernel.org" <broonie@kernel.org>,
"kirill.shutemov@linux.intel.com"
<kirill.shutemov@linux.intel.com>,
"tglx@linutronix.de" <tglx@linutronix.de>,
"mingo@redhat.com" <mingo@redhat.com>,
"bp@alien8.de" <bp@alien8.de>,
"dave.hansen@linux.intel.com" <dave.hansen@linux.intel.com>,
"x86@kernel.org" <x86@kernel.org>,
"luto@kernel.org" <luto@kernel.org>,
"peterz@infradead.org" <peterz@infradead.org>,
"hpa@zytor.com" <hpa@zytor.com>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-alpha@vger.kernel.org" <linux-alpha@vger.kernel.org>,
"linux-snps-arc@lists.infradead.org"
<linux-snps-arc@lists.infradead.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"linux-csky@vger.kernel.org" <linux-csky@vger.kernel.org>,
"loongarch@lists.linux.dev" <loongarch@lists.linux.dev>,
"linux-mips@vger.kernel.org" <linux-mips@vger.kernel.org>,
"linux-parisc@vger.kernel.org" <linux-parisc@vger.kernel.org>,
"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>,
"linux-s390@vger.kernel.org" <linux-s390@vger.kernel.org>,
"linux-sh@vger.kernel.org" <linux-sh@vger.kernel.org>,
"sparclinux@vger.kernel.org" <sparclinux@vger.kernel.org>
Subject: Re: [PATCH v2 5/9] mm: Initialize struct vm_unmapped_area_info
Date: Tue, 27 Feb 2024 10:07:26 -0800 [thread overview]
Message-ID: <202402271004.7145FDB53F@keescook> (raw)
In-Reply-To: <94a2b919-e03b-4ade-b13e-7774849dc02b@csgroup.eu>
On Tue, Feb 27, 2024 at 07:02:59AM +0000, Christophe Leroy wrote:
>
>
> Le 26/02/2024 à 20:09, Rick Edgecombe a écrit :
> > Future changes will need to add a field to struct vm_unmapped_area_info.
> > This would cause trouble for any archs that don't initialize the
> > struct. Currently every user sets each field, so if new fields are
> > added, the core code parsing the struct will see garbage in the new
> > field.
> >
> > It could be possible to initialize the new field for each arch to 0, but
> > instead simply inialize the field with a C99 struct inializing syntax.
>
> Why doing a full init of the struct when all fields are re-written a few
> lines after ?
It's a nice change for robustness and makes future changes easier. It's
not actually wasteful since the compiler will throw away all redundant
stores.
> If I take the exemple of powerpc function slice_find_area_bottomup():
>
> struct vm_unmapped_area_info info;
>
> info.flags = 0;
> info.length = len;
> info.align_mask = PAGE_MASK & ((1ul << pshift) - 1);
> info.align_offset = 0;
But one cleanup that is possible from explicitly zero-initializing the
whole structure would be dropping all the individual "= 0" assignments.
:)
--
Kees Cook
WARNING: multiple messages have this Message-ID (diff)
From: Kees Cook <keescook@chromium.org>
To: Christophe Leroy <christophe.leroy@csgroup.eu>
Cc: Rick Edgecombe <rick.p.edgecombe@intel.com>,
"Liam.Howlett@oracle.com" <Liam.Howlett@oracle.com>,
"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
"debug@rivosinc.com" <debug@rivosinc.com>,
"broonie@kernel.org" <broonie@kernel.org>,
"kirill.shutemov@linux.intel.com"
<kirill.shutemov@linux.intel.com>,
"tglx@linutronix.de" <tglx@linutronix.de>,
"mingo@redhat.com" <mingo@redhat.com>,
"bp@alien8.de" <bp@alien8.de>,
"dave.hansen@linux.intel.com" <dave.hansen@linux.intel.com>,
"x86@kernel.org" <x86@kernel.org>,
"luto@kernel.org" <luto@kernel.org>,
"peterz@infradead.org" <peterz@infradead.org>,
"hpa@zytor.com" <hpa@zytor.com>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-alpha@vger.kernel.org" <linux-alpha@vger.kernel.org>,
"linux-snps-arc@lists.infradead.org"
<linux-snps-arc@lists.infradead.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"linux-csky@vger.kernel.org" <linux-csky@vger.kernel.org>,
"loongarch@lists.linux.dev" <loongarch@lists.linux.dev>,
"linux-mips@vger.kernel.org" <linux-mips@vger.kernel.org>,
"linux-parisc@vger.kernel.org" <linux-parisc@vger.kernel.org>,
"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>,
"linux-s390@vger.kernel.org" <linux-s390@vger.kernel.org>,
"linux-sh@vger.kernel.org" <linux-sh@vger.kernel.org>,
"sparclinux@vger.kernel.org" <sparclinux@vger.kernel.org>
Subject: Re: [PATCH v2 5/9] mm: Initialize struct vm_unmapped_area_info
Date: Tue, 27 Feb 2024 10:07:26 -0800 [thread overview]
Message-ID: <202402271004.7145FDB53F@keescook> (raw)
In-Reply-To: <94a2b919-e03b-4ade-b13e-7774849dc02b@csgroup.eu>
On Tue, Feb 27, 2024 at 07:02:59AM +0000, Christophe Leroy wrote:
>
>
> Le 26/02/2024 à 20:09, Rick Edgecombe a écrit :
> > Future changes will need to add a field to struct vm_unmapped_area_info.
> > This would cause trouble for any archs that don't initialize the
> > struct. Currently every user sets each field, so if new fields are
> > added, the core code parsing the struct will see garbage in the new
> > field.
> >
> > It could be possible to initialize the new field for each arch to 0, but
> > instead simply inialize the field with a C99 struct inializing syntax.
>
> Why doing a full init of the struct when all fields are re-written a few
> lines after ?
It's a nice change for robustness and makes future changes easier. It's
not actually wasteful since the compiler will throw away all redundant
stores.
> If I take the exemple of powerpc function slice_find_area_bottomup():
>
> struct vm_unmapped_area_info info;
>
> info.flags = 0;
> info.length = len;
> info.align_mask = PAGE_MASK & ((1ul << pshift) - 1);
> info.align_offset = 0;
But one cleanup that is possible from explicitly zero-initializing the
whole structure would be dropping all the individual "= 0" assignments.
:)
--
Kees Cook
_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
WARNING: multiple messages have this Message-ID (diff)
From: Kees Cook <keescook@chromium.org>
To: Christophe Leroy <christophe.leroy@csgroup.eu>
Cc: Rick Edgecombe <rick.p.edgecombe@intel.com>,
"Liam.Howlett@oracle.com" <Liam.Howlett@oracle.com>,
"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
"debug@rivosinc.com" <debug@rivosinc.com>,
"broonie@kernel.org" <broonie@kernel.org>,
"kirill.shutemov@linux.intel.com"
<kirill.shutemov@linux.intel.com>,
"tglx@linutronix.de" <tglx@linutronix.de>,
"mingo@redhat.com" <mingo@redhat.com>,
"bp@alien8.de" <bp@alien8.de>,
"dave.hansen@linux.intel.com" <dave.hansen@linux.intel.com>,
"x86@kernel.org" <x86@kernel.org>,
"luto@kernel.org" <luto@kernel.org>,
"peterz@infradead.org" <peterz@infradead.org>,
"hpa@zytor.com" <hpa@zytor.com>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-alpha@vger.kernel.org" <linux-alpha@vger.kernel.org>,
"linux-snps-arc@lists.infradead.org"
<linux-snps-arc@lists.infradead.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"linux-csky@vger.kernel.org" <linux-csky@vger.kernel.org>,
"loongarch@lists.linux.dev" <loongarch@lists.linux.dev>,
"linux-mips@vger.kernel.org" <linux-mips@vger.kernel.org>,
"linux-parisc@vger.kernel.org" <linux-parisc@vger.kernel.org>,
"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>,
"linux-s390@vger.kernel.org" <linux-s390@vger.kernel.org>,
"linux-sh@vger.kernel.org" <linux-sh@vger.kernel.org>,
"sparclinux@vger.kernel.org" <sparclinux@vger.kernel.org>
Subject: Re: [PATCH v2 5/9] mm: Initialize struct vm_unmapped_area_info
Date: Tue, 27 Feb 2024 10:07:26 -0800 [thread overview]
Message-ID: <202402271004.7145FDB53F@keescook> (raw)
In-Reply-To: <94a2b919-e03b-4ade-b13e-7774849dc02b@csgroup.eu>
On Tue, Feb 27, 2024 at 07:02:59AM +0000, Christophe Leroy wrote:
>
>
> Le 26/02/2024 à 20:09, Rick Edgecombe a écrit :
> > Future changes will need to add a field to struct vm_unmapped_area_info.
> > This would cause trouble for any archs that don't initialize the
> > struct. Currently every user sets each field, so if new fields are
> > added, the core code parsing the struct will see garbage in the new
> > field.
> >
> > It could be possible to initialize the new field for each arch to 0, but
> > instead simply inialize the field with a C99 struct inializing syntax.
>
> Why doing a full init of the struct when all fields are re-written a few
> lines after ?
It's a nice change for robustness and makes future changes easier. It's
not actually wasteful since the compiler will throw away all redundant
stores.
> If I take the exemple of powerpc function slice_find_area_bottomup():
>
> struct vm_unmapped_area_info info;
>
> info.flags = 0;
> info.length = len;
> info.align_mask = PAGE_MASK & ((1ul << pshift) - 1);
> info.align_offset = 0;
But one cleanup that is possible from explicitly zero-initializing the
whole structure would be dropping all the individual "= 0" assignments.
:)
--
Kees Cook
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
WARNING: multiple messages have this Message-ID (diff)
From: Kees Cook <keescook@chromium.org>
To: Christophe Leroy <christophe.leroy@csgroup.eu>
Cc: "luto@kernel.org" <luto@kernel.org>,
"linux-sh@vger.kernel.org" <linux-sh@vger.kernel.org>,
"peterz@infradead.org" <peterz@infradead.org>,
"dave.hansen@linux.intel.com" <dave.hansen@linux.intel.com>,
"linux-mips@vger.kernel.org" <linux-mips@vger.kernel.org>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
"hpa@zytor.com" <hpa@zytor.com>,
"sparclinux@vger.kernel.org" <sparclinux@vger.kernel.org>,
"linux-s390@vger.kernel.org" <linux-s390@vger.kernel.org>,
"x86@kernel.org" <x86@kernel.org>,
"linux-csky@vger.kernel.org" <linux-csky@vger.kernel.org>,
"mingo@redhat.com" <mingo@redhat.com>,
"linux-snps-arc@lists.infradead.org"
<linux-snps-arc@lists.infradead.org>,
"Liam.Howlett@oracle.com" <Liam.Howlett@oracle.com>,
"broonie@kernel.org" <broonie@kernel.org>,
"bp@alien8.de" <bp@alien8.de>,
"loongarch@lists.linux.dev" <loongarch@lists.linux.dev>,
"tglx@linutronix.de" <tglx@linutronix.de>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"debug@rivosinc.com" <debug @rivosinc.com>,
"linux-parisc@vger.kernel.org" <linux-parisc@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-alpha@vger.kernel.org" <linux-alpha@vger.kernel.org>,
"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
Rick Edgecombe <rick.p.edgecombe@intel.com>,
"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>,
"kirill.shutemov@linux.intel.com"
<kirill.shutemov@linux.intel.com>
Subject: Re: [PATCH v2 5/9] mm: Initialize struct vm_unmapped_area_info
Date: Tue, 27 Feb 2024 10:07:26 -0800 [thread overview]
Message-ID: <202402271004.7145FDB53F@keescook> (raw)
In-Reply-To: <94a2b919-e03b-4ade-b13e-7774849dc02b@csgroup.eu>
On Tue, Feb 27, 2024 at 07:02:59AM +0000, Christophe Leroy wrote:
>
>
> Le 26/02/2024 à 20:09, Rick Edgecombe a écrit :
> > Future changes will need to add a field to struct vm_unmapped_area_info.
> > This would cause trouble for any archs that don't initialize the
> > struct. Currently every user sets each field, so if new fields are
> > added, the core code parsing the struct will see garbage in the new
> > field.
> >
> > It could be possible to initialize the new field for each arch to 0, but
> > instead simply inialize the field with a C99 struct inializing syntax.
>
> Why doing a full init of the struct when all fields are re-written a few
> lines after ?
It's a nice change for robustness and makes future changes easier. It's
not actually wasteful since the compiler will throw away all redundant
stores.
> If I take the exemple of powerpc function slice_find_area_bottomup():
>
> struct vm_unmapped_area_info info;
>
> info.flags = 0;
> info.length = len;
> info.align_mask = PAGE_MASK & ((1ul << pshift) - 1);
> info.align_offset = 0;
But one cleanup that is possible from explicitly zero-initializing the
whole structure would be dropping all the individual "= 0" assignments.
:)
--
Kees Cook
next prev parent reply other threads:[~2024-02-27 18:07 UTC|newest]
Thread overview: 94+ 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-26 19:09 ` Rick Edgecombe
2024-02-26 19:09 ` Rick Edgecombe
2024-02-26 19:09 ` Rick Edgecombe
2024-02-27 7:02 ` Christophe Leroy
2024-02-27 7:02 ` Christophe Leroy
2024-02-27 7:02 ` Christophe Leroy
2024-02-27 7:02 ` Christophe Leroy
2024-02-27 15:00 ` Edgecombe, Rick P
2024-02-27 15:00 ` Edgecombe, Rick P
2024-02-27 15:00 ` Edgecombe, Rick P
2024-02-27 15:00 ` Edgecombe, Rick P
2024-02-27 18:07 ` Kees Cook [this message]
2024-02-27 18:07 ` Kees Cook
2024-02-27 18:07 ` Kees Cook
2024-02-27 18:07 ` Kees Cook
2024-02-27 18:16 ` Christophe Leroy
2024-02-27 18:16 ` Christophe Leroy
2024-02-27 18:16 ` Christophe Leroy
2024-02-27 18:16 ` Christophe Leroy
2024-02-27 20:25 ` Edgecombe, Rick P
2024-02-27 20:25 ` Edgecombe, Rick P
2024-02-27 20:25 ` Edgecombe, Rick P
2024-02-27 20:25 ` Edgecombe, Rick P
2024-02-28 13:22 ` Christophe Leroy
2024-02-28 13:22 ` Christophe Leroy
2024-02-28 13:22 ` Christophe Leroy
2024-02-28 13:22 ` Christophe Leroy
2024-02-28 17:01 ` Edgecombe, Rick P
2024-02-28 17:01 ` Edgecombe, Rick P
2024-02-28 17:01 ` Edgecombe, Rick P
2024-02-28 17:01 ` Edgecombe, Rick P
2024-02-28 23:10 ` Christophe Leroy
2024-02-28 23:10 ` Christophe Leroy
2024-02-28 23:10 ` Christophe Leroy
2024-02-28 23:10 ` Christophe Leroy
2024-02-28 17:21 ` Kees Cook
2024-02-28 17:21 ` Kees Cook
2024-02-28 17:21 ` Kees Cook
2024-02-28 17:21 ` Kees Cook
2024-03-02 0:47 ` Edgecombe, Rick P
2024-03-02 0:47 ` Edgecombe, Rick P
2024-03-02 0:47 ` Edgecombe, Rick P
2024-03-02 0:47 ` Edgecombe, Rick P
2024-03-02 1:51 ` Kees Cook
2024-03-02 1:51 ` Kees Cook
2024-03-02 1:51 ` Kees Cook
2024-03-02 1:51 ` Kees Cook
2024-03-04 18:00 ` Christophe Leroy
2024-03-04 18:00 ` Christophe Leroy
2024-03-04 18:00 ` Christophe Leroy
2024-03-04 18:00 ` Christophe Leroy
2024-03-04 18:03 ` Edgecombe, Rick P
2024-03-04 18:03 ` Edgecombe, Rick P
2024-03-04 18:03 ` Edgecombe, Rick P
2024-03-04 18:03 ` Edgecombe, Rick P
2024-02-28 11:51 ` Kirill A. Shutemov
2024-02-28 11:51 ` Kirill A. Shutemov
2024-02-28 11:51 ` Kirill A. Shutemov
2024-02-28 11:51 ` Kirill A. Shutemov
2024-03-02 0:17 ` [RFC v2.1 01/12] ARC: Use initializer for " Rick Edgecombe
2024-03-02 0:17 ` Rick Edgecombe
2024-03-02 0:17 ` [RFC v2.1 02/12] ARM: " Rick Edgecombe
2024-03-02 0:17 ` Rick Edgecombe
2024-03-02 0:17 ` [RFC v2.1 03/12] csky: " Rick Edgecombe
2024-03-03 3:09 ` Guo Ren
2024-03-05 14:51 ` Edgecombe, Rick P
2024-03-02 0:17 ` [RFC v2.1 04/12] LoongArch: " Rick Edgecombe
2024-03-02 0:17 ` [RFC v2.1 05/12] MIPS: " Rick Edgecombe
2024-03-02 0:17 ` [RFC v2.1 06/12] parisc: " Rick Edgecombe
2024-03-02 6:35 ` Helge Deller
2024-03-05 14:51 ` Edgecombe, Rick P
2024-03-02 0:17 ` [RFC v2.1 07/12] powerpc: " Rick Edgecombe
2024-03-02 0:17 ` Rick Edgecombe
2024-03-05 0:51 ` Michael Ellerman
2024-03-05 0:51 ` Michael Ellerman
2024-03-05 14:50 ` Edgecombe, Rick P
2024-03-05 14:50 ` Edgecombe, Rick P
2024-03-02 0:17 ` [RFC v2.1 08/12] s390: " Rick Edgecombe
2024-03-02 0:17 ` [RFC v2.1 09/12] sh: " Rick Edgecombe
2024-03-02 0:17 ` [RFC v2.1 10/12] sparc: " Rick Edgecombe
2024-03-02 0:17 ` [RFC v2.1 11/12] x86/mm: " Rick Edgecombe
2024-03-02 0:17 ` [RFC v2.1 12/12] hugetlbfs: " Rick Edgecombe
2024-03-02 4:42 ` [RFC v2.1 01/12] ARC: " Vineet Gupta
2024-03-02 4:42 ` Vineet Gupta
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=202402271004.7145FDB53F@keescook \
--to=keescook@chromium.org \
--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=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=rick.p.edgecombe@intel.com \
--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 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.