LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@linutronix.de>
To: "Prakhya, Sai Praneeth" <sai.praneeth.prakhya@intel.com>
Cc: "linux-efi@vger.kernel.org" <linux-efi@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"x86@kernel.org" <x86@kernel.org>, Borislav Petkov <bp@alien8.de>,
Ingo Molnar <mingo@kernel.org>, Andy Lutomirski <luto@kernel.org>,
"Hansen, Dave" <dave.hansen@intel.com>,
Bhupesh Sharma <bhsharma@redhat.com>,
Peter Zijlstra <peterz@infradead.org>,
Ard Biesheuvel <ard.biesheuvel@linaro.org>
Subject: RE: [PATCH V2 1/2] x86/efi: Unmap EFI boot services code/data regions from efi_pgd
Date: Mon, 29 Oct 2018 19:18:50 +0100 (CET) [thread overview]
Message-ID: <alpine.DEB.2.21.1810291911570.5984@nanos.tec.linutronix.de> (raw)
In-Reply-To: <alpine.DEB.2.21.1810291907320.5984@nanos.tec.linutronix.de>
Sai,
On Mon, 29 Oct 2018, Thomas Gleixner wrote:
> On Mon, 29 Oct 2018, Prakhya, Sai Praneeth wrote:
>
> > Hi Thomas and Peter,
> >
> > [off the mailing list because I wasn't sure if it's a good idea to spam others with my questions]
>
> In general it's good to do on list because others can learn from the
> answers as well.
So you somehow managed to keep everyone and the lists in CC
nevertheless. Did not pay attention to the CC list until I got my reply on
the list :)
> > > > > + retval = __change_page_attr_set_clr(&cpa, 0);
> > > > > + __flush_tlb_all();
> > > >
> > > > So this looks like you copied it from kernel_map_pages_in_pgd() which
> > > > has been discussed before to be not sufficient, but it can't be
> > > > changed right now due to locking issues.
> > >
> > > Managed to confuse myself. The place which cannot be changed is a different
> > > one, but still for your call site __flush_tlb_all() might not be sufficient.
> >
> > Since the mappings are changed, I thought a flush_tlb() might be needed.
> > But, (to be honest), I don't completely understand the x86/mm code. So, could you
> > please elaborate the issue more for my better understanding?
> >
> > So some questions I have are,
> > 1. What did Peter Z mean here? "How is that not a TLB invalidation bug ?"
>
> __flush_tlb_all() flushes only the mapping on the current CPU. So in a SMP
> environment it's not sufficient.
>
> > 2. I assumed kernel_map_pages_in_pgd() to be a good code but you said that
> > it has some locking issues. So, could you please elaborate more on that.
>
> I corrected myself. It's the other function which cannot use the proper
> cpa_flush.*() functions.
>
> > Or, could you please provide me some pointers in the source code that I
> > can take a look at so that I could understand the issue much better.
>
> I'll have a second look at the whole thing and reply on list.
So actually for the problem at hand __flush_tlb_all() works, because that
is called way before the secondary CPUs are up.
Ditto for kernel_map_pages_in_pgd(). But both functions want to be marked
__init and aside of that they both should contain a warning when they are
called after the secondary CPUs have been brought up.
Thanks,
tglx
next prev parent reply other threads:[~2018-10-29 18:18 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-26 21:38 [PATCH V2 0/2] Unmap EFI boot services code/data regions after boot Sai Praneeth Prakhya
2018-10-26 21:38 ` [PATCH V2 1/2] x86/efi: Unmap EFI boot services code/data regions from efi_pgd Sai Praneeth Prakhya
2018-10-29 6:07 ` Ingo Molnar
2018-10-29 7:26 ` Prakhya, Sai Praneeth
2018-10-29 14:40 ` Peter Zijlstra
2018-10-29 17:13 ` Thomas Gleixner
2018-10-29 17:21 ` Thomas Gleixner
2018-10-29 18:01 ` Prakhya, Sai Praneeth
2018-10-29 18:11 ` Thomas Gleixner
2018-10-29 18:18 ` Thomas Gleixner [this message]
2018-10-29 18:32 ` Prakhya, Sai Praneeth
2018-10-29 18:38 ` Prakhya, Sai Praneeth
2018-10-26 21:38 ` [PATCH V2 2/2] x86/efi: Move efi_<reserve/free>_boot_services() to arch/x86 Sai Praneeth Prakhya
2018-10-29 17:14 ` Thomas Gleixner
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=alpine.DEB.2.21.1810291911570.5984@nanos.tec.linutronix.de \
--to=tglx@linutronix.de \
--cc=ard.biesheuvel@linaro.org \
--cc=bhsharma@redhat.com \
--cc=bp@alien8.de \
--cc=dave.hansen@intel.com \
--cc=linux-efi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=mingo@kernel.org \
--cc=peterz@infradead.org \
--cc=sai.praneeth.prakhya@intel.com \
--cc=x86@kernel.org \
--subject='RE: [PATCH V2 1/2] x86/efi: Unmap EFI boot services code/data regions from efi_pgd' \
/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
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).