[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAG_fn=Xv74c80swzFjKyybQpRj7Qj9K1NVH-D6gcxcYEoUJ1xA@mail.gmail.com>
Date: Tue, 08 May 2018 14:50:02 +0000
From: Alexander Potapenko <glider@...gle.com>
To: dave.hansen@...ux.intel.com
Cc: Ingo Molnar <mingo@...nel.org>,
"Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
Linux Memory Management List <linux-mm@...ck.org>,
LKML <linux-kernel@...r.kernel.org>,
Matthias Kaehlcke <mka@...omium.org>,
Dmitriy Vyukov <dvyukov@...gle.com>,
Michael Davidson <md@...gle.com>
Subject: Re: [PATCH] x86/boot/64/clang: Use fixup_pointer() to access '__supported_pte_mask'
On Tue, May 8, 2018 at 4:30 PM Dave Hansen <dave.hansen@...ux.intel.com>
wrote:
> On 05/08/2018 05:16 AM, Alexander Potapenko wrote:
> > Similarly to commit 187e91fe5e91
> > ("x86/boot/64/clang: Use fixup_pointer() to access 'next_early_pgt'"),
> > '__supported_pte_mask' must be also accessed using fixup_pointer() to
> > avoid position-dependent relocations.
> >
> > Signed-off-by: Alexander Potapenko <glider@...gle.com>
> > Fixes: fb43d6cb91ef ("x86/mm: Do not auto-massage page protections")
> In the interests of standalone changelogs, I'd really appreciate an
> actual explanation of what's going on here. Your patch makes the code
> uglier and doesn't fix anything functional from what I can see.
You're right, sure. I'll send a patch with an updated description.
> The other commit has some explanation, so it seems like the rules for
> accessing globals in head64.c are different than other files because...
> something.
The problem as far as I understand it is that the code in __startup_64()
can be relocated during execution, but the compiler doesn't have to
generate PC-relative relocations when accessing globals from that function.
> The functional problem here is that it causes insta-reboots?
True.
> Do we have anything we can do to keep us from recreating these kinds of
> regressions all the time?
I'm not really aware of the possible options in the kernel land. Looks like
a task for some objtool-like utility?
As long as these regressions are caught with Clang, setting up a 0day Clang
builder might help.
At least I should've added a comment regarding this to __startup_64() last
time.
--
Alexander Potapenko
Software Engineer
Google Germany GmbH
Erika-Mann-Straße, 33
80636 München
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
Powered by blists - more mailing lists