From: "Edgecombe, Rick P" <rick.p.edgecombe@intel.com>
To: "keescook@chromium.org" <keescook@chromium.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>,
"Liam.Howlett@oracle.com" <Liam.Howlett@oracle.com>,
"mingo@redhat.com" <mingo@redhat.com>,
"kirill.shutemov@linux.intel.com"
<kirill.shutemov@linux.intel.com>,
"christophe.leroy@csgroup.eu" <christophe.leroy@csgroup.eu>,
"tglx@linutronix.de" <tglx@linutronix.de>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
"hpa@zytor.com" <hpa@zytor.com>,
"peterz@infradead.org" <peterz@infradead.org>,
"bp@alien8.de" <bp@alien8.de>, "x86@kernel.org" <x86@kernel.org>,
"broonie@kernel.org" <broonie@kernel.org>
Cc: "linux-sh@vger.kernel.org" <linux-sh@vger.kernel.org>,
"loongarch@lists.linux.dev" <loongarch@lists.linux.dev>,
"linux-csky@vger.kernel.org" <linux-csky@vger.kernel.org>,
"linux-s390@vger.kernel.org" <linux-s390@vger.kernel.org>,
"linux-snps-arc@lists.infradead.org"
<linux-snps-arc@lists.infradead.org>,
"linux-alpha@vger.kernel.org" <linux-alpha@vger.kernel.org>,
"sparclinux@vger.kernel.org" <sparclinux@vger.kernel.org>,
"linux-parisc@vger.kernel.org" <linux-parisc@vger.kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>,
"linux-mips@vger.kernel.org" <linux-mips@vger.kernel.org>
Subject: Re: [PATCH v2 5/9] mm: Initialize struct vm_unmapped_area_info
Date: Tue, 27 Feb 2024 15:00:46 +0000 [thread overview]
Message-ID: <ad24469275325b86ed316df36153fcdb2863454f.camel@intel.com> (raw)
In-Reply-To: <94a2b919-e03b-4ade-b13e-7774849dc02b@csgroup.eu>
On Tue, 2024-02-27 at 07:02 +0000, Christophe Leroy wrote:
> > 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 ?
>
> 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;
>
> For me it looks better to just add:
>
> info.new_field = 0; /* or whatever value it needs to have */
Hi,
Thanks for taking a look. Yes, I guess that should have some
justification. I was thinking of two reasons:
1. No future additions of optional parameters would need to make tree
wide changes like this.
2. The change is easier to review and get correct because the necessary
context is within a single line. For example, in that function some of
members are set within a while loop. The place you pointed seems to be
the correct one, but a diff that had the new field set after:
info.high_limit = addr;
...would look correct too, but not be.
What is the concern with C99 initialization? FWIW, the full series also
removes an indirect branch, and probably is a net win for performance
in this path.
WARNING: multiple messages have this Message-ID (diff)
From: "Edgecombe, Rick P" <rick.p.edgecombe@intel.com>
To: "keescook@chromium.org" <keescook@chromium.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>,
"Liam.Howlett@oracle.com" <Liam.Howlett@oracle.com>,
"mingo@redhat.com" <mingo@redhat.com>,
"kirill.shutemov@linux.intel.com"
<kirill.shutemov@linux.intel.com>,
"christophe.leroy@csgroup.eu" <christophe.leroy@csgroup.eu>,
"tglx@linutronix.de" <tglx@linutronix.de>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
"hpa@zytor.com" <hpa@zytor.com>,
"peterz@infradead.org" <peterz@infradead.org>,
"bp@alien8.de" <bp@alien8.de>, "x86@kernel.org" <x86@kernel.org>,
"broonie@kernel.org" <broonie@kernel.org>
Cc: "linux-sh@vger.kernel.org" <linux-sh@vger.kernel.org>,
"loongarch@lists.linux.dev" <loongarch@lists.linux.dev>,
"linux-csky@vger.kernel.org" <linux-csky@vger.kernel.org>,
"linux-s390@vger.kernel.org" <linux-s390@vger.kernel.org>,
"linux-snps-arc@lists.infradead.org"
<linux-snps-arc@lists.infradead.org>,
"linux-alpha@vger.kernel.org" <linux-alpha@vger.kernel.org>,
"sparclinux@vger.kernel.org" <sparclinux@vger.kernel.org>,
"linux-parisc@vger.kernel.org" <linux-parisc@vger.kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>,
"linux-mips@vger.kernel.org" <linux-mips@vger.kernel.org>
Subject: Re: [PATCH v2 5/9] mm: Initialize struct vm_unmapped_area_info
Date: Tue, 27 Feb 2024 15:00:46 +0000 [thread overview]
Message-ID: <ad24469275325b86ed316df36153fcdb2863454f.camel@intel.com> (raw)
In-Reply-To: <94a2b919-e03b-4ade-b13e-7774849dc02b@csgroup.eu>
On Tue, 2024-02-27 at 07:02 +0000, Christophe Leroy wrote:
> > 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 ?
>
> 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;
>
> For me it looks better to just add:
>
> info.new_field = 0; /* or whatever value it needs to have */
Hi,
Thanks for taking a look. Yes, I guess that should have some
justification. I was thinking of two reasons:
1. No future additions of optional parameters would need to make tree
wide changes like this.
2. The change is easier to review and get correct because the necessary
context is within a single line. For example, in that function some of
members are set within a while loop. The place you pointed seems to be
the correct one, but a diff that had the new field set after:
info.high_limit = addr;
...would look correct too, but not be.
What is the concern with C99 initialization? FWIW, the full series also
removes an indirect branch, and probably is a net win for performance
in this path.
_______________________________________________
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: "Edgecombe, Rick P" <rick.p.edgecombe@intel.com>
To: "keescook@chromium.org" <keescook@chromium.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>,
"Liam.Howlett@oracle.com" <Liam.Howlett@oracle.com>,
"mingo@redhat.com" <mingo@redhat.com>,
"kirill.shutemov@linux.intel.com"
<kirill.shutemov@linux.intel.com>,
"christophe.leroy@csgroup.eu" <christophe.leroy@csgroup.eu>,
"tglx@linutronix.de" <tglx@linutronix.de>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
"hpa@zytor.com" <hpa@zytor.com>,
"peterz@infradead.org" <peterz@infradead.org>,
"bp@alien8.de" <bp@alien8.de>, "x86@kernel.org" <x86@kernel.org>,
"broonie@kernel.org" <broonie@kernel.org>
Cc: "linux-sh@vger.kernel.org" <linux-sh@vger.kernel.org>,
"loongarch@lists.linux.dev" <loongarch@lists.linux.dev>,
"linux-csky@vger.kernel.org" <linux-csky@vger.kernel.org>,
"linux-s390@vger.kernel.org" <linux-s390@vger.kernel.org>,
"linux-snps-arc@lists.infradead.org"
<linux-snps-arc@lists.infradead.org>,
"linux-alpha@vger.kernel.org" <linux-alpha@vger.kernel.org>,
"sparclinux@vger.kernel.org" <sparclinux@vger.kernel.org>,
"linux-parisc@vger.kernel.org" <linux-parisc@vger.kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>,
"linux-mips@vger.kernel.org" <linux-mips@vger.kernel.org>
Subject: Re: [PATCH v2 5/9] mm: Initialize struct vm_unmapped_area_info
Date: Tue, 27 Feb 2024 15:00:46 +0000 [thread overview]
Message-ID: <ad24469275325b86ed316df36153fcdb2863454f.camel@intel.com> (raw)
In-Reply-To: <94a2b919-e03b-4ade-b13e-7774849dc02b@csgroup.eu>
On Tue, 2024-02-27 at 07:02 +0000, Christophe Leroy wrote:
> > 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 ?
>
> 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;
>
> For me it looks better to just add:
>
> info.new_field = 0; /* or whatever value it needs to have */
Hi,
Thanks for taking a look. Yes, I guess that should have some
justification. I was thinking of two reasons:
1. No future additions of optional parameters would need to make tree
wide changes like this.
2. The change is easier to review and get correct because the necessary
context is within a single line. For example, in that function some of
members are set within a while loop. The place you pointed seems to be
the correct one, but a diff that had the new field set after:
info.high_limit = addr;
...would look correct too, but not be.
What is the concern with C99 initialization? FWIW, the full series also
removes an indirect branch, and probably is a net win for performance
in this path.
_______________________________________________
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: "Edgecombe, Rick P" <rick.p.edgecombe@intel.com>
To: "keescook@chromium.org" <keescook@chromium.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>,
"Liam.Howlett@oracle.com" <Liam.Howlett@oracle.com>,
"mingo@redhat.com" <mingo@redhat.com>,
"kirill.shutemov@linux.intel.com"
<kirill.shutemov@linux.intel.com>,
"christophe.leroy@csgroup.eu" <christophe.leroy@csgroup.eu>,
"tglx@linutronix.de" <tglx@linutronix.de>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
"hpa@zytor.com" <hpa@zytor.com>,
"peterz@infradead.org" <peterz@infradead.org>,
"bp@alien8.de" <bp@alien8.de>, "x86@kernel.org" <x86@kernel.org>,
"broonie@kernel.org" <broonie@kernel.org>
Cc: "linux-s390@vger.kernel.org" <linux-s390@vger.kernel.org>,
"linux-parisc@vger.kernel.org" <linux-parisc@vger.kernel.org>,
"linux-sh@vger.kernel.org" <linux-sh@vger.kernel.org>,
"linux-mips@vger.kernel.org" <linux-mips@vger.kernel.org>,
"linux-csky@vger.kernel.org" <linux-csky@vger.kernel.org>,
"loongarch@lists.linux.dev" <loongarch@lists.linux.dev>,
"linux-alpha@vger.kernel.org" <linux-alpha@vger.kernel.org>,
"sparclinux@vger.kernel.org" <sparclinux@vger.kernel.org>,
"linux-snps-arc@lists.infradead.org"
<linux-snps-arc@lists.infradead.org>,
"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH v2 5/9] mm: Initialize struct vm_unmapped_area_info
Date: Tue, 27 Feb 2024 15:00:46 +0000 [thread overview]
Message-ID: <ad24469275325b86ed316df36153fcdb2863454f.camel@intel.com> (raw)
In-Reply-To: <94a2b919-e03b-4ade-b13e-7774849dc02b@csgroup.eu>
On Tue, 2024-02-27 at 07:02 +0000, Christophe Leroy wrote:
> > 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 ?
>
> 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;
>
> For me it looks better to just add:
>
> info.new_field = 0; /* or whatever value it needs to have */
Hi,
Thanks for taking a look. Yes, I guess that should have some
justification. I was thinking of two reasons:
1. No future additions of optional parameters would need to make tree
wide changes like this.
2. The change is easier to review and get correct because the necessary
context is within a single line. For example, in that function some of
members are set within a while loop. The place you pointed seems to be
the correct one, but a diff that had the new field set after:
info.high_limit = addr;
...would look correct too, but not be.
What is the concern with C99 initialization? FWIW, the full series also
removes an indirect branch, and probably is a net win for performance
in this path.
next prev parent reply other threads:[~2024-02-27 15:00 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 [this message]
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
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=ad24469275325b86ed316df36153fcdb2863454f.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 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.