From: Baoquan He <bhe@redhat.com>
To: Kees Cook <keescook@chromium.org>,
"Kirill A. Shutemov" <kirill@shutemov.name>
Cc: LKML <linux-kernel@vger.kernel.org>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
"H. Peter Anvin" <hpa@zytor.com>,
Dave Hansen <dave.hansen@linux.intel.com>,
Andy Lutomirski <luto@kernel.org>,
Peter Zijlstra <peterz@infradead.org>, X86 ML <x86@kernel.org>,
Mike Travis <travis@sgi.com>,
Thomas Garnier <thgarnie@google.com>,
Andrew Morton <akpm@linux-foundation.org>,
Masahiro Yamada <yamada.masahiro@socionext.com>
Subject: Re: [PATCH v3 3/6] mm: Add build time sanity check for struct page size
Date: Mon, 18 Feb 2019 16:07:27 +0800 [thread overview]
Message-ID: <20190218080727.GH14858@MiWiFi-R3L-srv> (raw)
In-Reply-To: <CAGXu5jLVYC8QZ9xo_=JxODQAPVTJMvnWwUb+aZKO-X-Luz+S0w@mail.gmail.com>
On 02/17/19 at 08:50am, Kees Cook wrote:
> On Sat, Feb 16, 2019 at 6:02 AM Baoquan He <bhe@redhat.com> wrote:
> >
> > Size of struct page might be larger than 64 bytes if debug options
> > enabled, or fields added for debugging intentionally. Yet an upper
> > limit need be added at build time to trigger an alert in case the
> > size is too big to boot up system, warning people to check if it's
> > be done on purpose in advance.
> >
> > Here 1/4 of PAGE_SIZE is chosen since system must have been insane
> > with this value. For those systems with PAGE_SIZE larger than 4KB,
> > 1KB is simply taken.
> >
> > Signed-off-by: Baoquan He <bhe@redhat.com>
> > ---
> > mm/page_alloc.c | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> > index 35fdde041f5c..eb6c8e22333b 100644
> > --- a/mm/page_alloc.c
> > +++ b/mm/page_alloc.c
> > @@ -67,6 +67,7 @@
> > #include <linux/lockdep.h>
> > #include <linux/nmi.h>
> > #include <linux/psi.h>
> > +#include <linux/sizes.h>
> >
> > #include <asm/sections.h>
> > #include <asm/tlbflush.h>
> > @@ -7084,6 +7085,7 @@ void __init free_area_init_nodes(unsigned long *max_zone_pfn)
> > unsigned long start_pfn, end_pfn;
> > int i, nid;
> >
> > + BUILD_BUG_ON(sizeof(struct page) > min_t(size_t, SZ_1K, PAGE_SIZE));
>
> Are there systems with PAGE_SIZE < 1K? Maybe this should just be a
> direct SZ_1K check?
This check was suggested by Kirill, I forgot adding his "Suggested-by",
sorry abou that.
Originally he suggested to add code in generic place like this:
BUILD_BUG_ON(sizeof(struct page) < min(SZ_1K, PAGE_SIZE/4));
In later post, the kbuild test robot reported an build error on i386
ARCH,
http://lkml.kernel.org/r/20180911074733.GX1740@192.168.1.3
From the report hint, I thought 'PAGE_SIZE/4' also related to the macro
expansion, so change it as min_t(size_t, SZ_1K, PAGE_SIZE).
Just now I tried the build again, changing it back to 'PAGE_SIZE/4' also
works.
BUILD_BUG_ON(sizeof(struct page) > min_t(size_t, SZ_1K, PAGE_SIZE/4));
I guess Kirill wants to make it as self explanatory for this check by
suggesting it as min(SZ_1K, PAGE_SIZE/4), to stress the 'PAGE_SIZE/4'.
As he said in mail thread, "If struct page is more than 1/4 of PAGE_SIZE
something is horribly broken".
lkml.kernel.org/r/20180903102642.rmzawwqsqjvh2mkb@kshutemo-mobl1
Just try to give more details about this adding, not defend. I am
fine to take any of them.
> (Also, perhaps this should use the new static_assert where struct page
> is defined?)
I searched with 'git grep', didn't find static_assert macro or function.
And also no finding in include/linux/mm_types.h. Could you please be
more specific?
Thanks
Baoquan
>
> > /* Record where the zone boundaries are */
> > memset(arch_zone_lowest_possible_pfn, 0,
> > sizeof(arch_zone_lowest_possible_pfn));
> > --
> > 2.17.2
> >
>
>
> --
> Kees Cook
next prev parent reply other threads:[~2019-02-18 8:07 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-16 14:00 [PATCH v3 0/6] Several patches to fix code bugs, improve documents and clean up Baoquan He
2019-02-16 14:00 ` [PATCH v3 1/6] x86/mm/KASLR: Improve code comments about struct kaslr_memory_region Baoquan He
2019-02-17 17:07 ` Kees Cook
2019-02-18 3:17 ` Baoquan He
2019-03-12 3:45 ` Baoquan He
2019-03-12 0:55 ` Baoquan He
2019-02-16 14:00 ` [PATCH v3 2/6] x86/mm/KASLR: Open code unnecessary function get_padding Baoquan He
2019-02-17 17:14 ` Kees Cook
2019-02-16 14:00 ` [PATCH v3 3/6] mm: Add build time sanity check for struct page size Baoquan He
2019-02-17 16:50 ` Kees Cook
2019-02-18 8:07 ` Baoquan He [this message]
2019-02-16 14:00 ` [PATCH v3 4/6] x86/mm/KASLR: Fix the wrong calculation of memory region initial size Baoquan He
2019-02-17 16:53 ` Kees Cook
2019-02-18 8:30 ` Baoquan He
2019-02-16 14:00 ` [PATCH v3 5/6] x86/mm/KASLR: Calculate the actual size of vmemmap region Baoquan He
2019-02-17 17:25 ` Kees Cook
2019-02-18 9:50 ` Baoquan He
2019-02-18 10:09 ` Baoquan He
2019-02-18 10:11 ` Baoquan He
2019-02-16 14:00 ` [PATCH v3 6/6] x86/mm/KASLR: Do not adapt the size of the direct mapping section for SGI UV system Baoquan He
2019-02-17 2:09 ` Baoquan He
2019-02-18 19:24 ` Mike Travis
2019-02-19 0:04 ` Baoquan He
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=20190218080727.GH14858@MiWiFi-R3L-srv \
--to=bhe@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=hpa@zytor.com \
--cc=keescook@chromium.org \
--cc=kirill@shutemov.name \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
--cc=thgarnie@google.com \
--cc=travis@sgi.com \
--cc=x86@kernel.org \
--cc=yamada.masahiro@socionext.com \
/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.