LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Thomas Gleixner <firstname.lastname@example.org>
To: "Prakhya, Sai Praneeth" <email@example.com>
Cc: "firstname.lastname@example.org" <email@example.com>,
"firstname.lastname@example.org" <email@example.com>, Borislav Petkov <firstname.lastname@example.org>,
Ingo Molnar <email@example.com>, Andy Lutomirski <firstname.lastname@example.org>,
"Hansen, Dave" <email@example.com>,
Bhupesh Sharma <firstname.lastname@example.org>,
Peter Zijlstra <email@example.com>,
Ard Biesheuvel <firstname.lastname@example.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:11:09 +0100 (CET) [thread overview]
Message-ID: <alpine.DEB.email@example.com> (raw)
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.
> > > > + 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
> 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.
next prev parent reply other threads:[~2018-10-29 18:11 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 [this message]
2018-10-29 18:18 ` Thomas Gleixner
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
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:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--subject='RE: [PATCH V2 1/2] x86/efi: Unmap EFI boot services code/data regions from efi_pgd' \
* 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).