From: Ingo Molnar <mingo@kernel.org>
To: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: linux-efi@vger.kernel.org, Thomas Gleixner <tglx@linutronix.de>,
Sai Praneeth <sai.praneeth.prakhya@intel.com>,
linux-kernel@vger.kernel.org, "Lee, Chun-Yi" <jlee@suse.com>,
Borislav Petkov <bp@alien8.de>, Tony Luck <tony.luck@intel.com>,
Andy Lutomirski <luto@kernel.org>,
"Michael S . Tsirkin" <mst@redhat.com>,
Ricardo Neri <ricardo.neri@intel.com>,
Ravi Shankar <ravi.v.shankar@intel.com>
Subject: Re: [PATCH 07/12] efi: Use efi_mm in x86 as well as ARM
Date: Fri, 9 Mar 2018 08:40:34 +0100 [thread overview]
Message-ID: <20180309074034.put3ko6zxmaoizzr@gmail.com> (raw)
In-Reply-To: <20180308080020.22828-8-ard.biesheuvel@linaro.org>
* Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
> From: Sai Praneeth <sai.praneeth.prakhya@intel.com>
>
> Presently, only ARM uses mm_struct to manage efi page tables and efi
> runtime region mappings. As this is the preferred approach, let's make
> this data structure common across architectures. Specially, for x86,
> using this data structure improves code maintainability and readability.
> diff --git a/arch/x86/include/asm/efi.h b/arch/x86/include/asm/efi.h
> index 85f6ccb80b91..00f977ddd718 100644
> --- a/arch/x86/include/asm/efi.h
> +++ b/arch/x86/include/asm/efi.h
> @@ -2,10 +2,14 @@
> #ifndef _ASM_X86_EFI_H
> #define _ASM_X86_EFI_H
>
> +#include <linux/sched/mm.h>
> +#include <linux/sched/task.h>
> +
> #include <asm/fpu/api.h>
> #include <asm/pgtable.h>
> #include <asm/processor-flags.h>
> #include <asm/tlb.h>
> +#include <asm/mmu_context.h>
>
> /*
> * We map the EFI regions needed for runtime services non-contiguously,
> diff --git a/include/linux/efi.h b/include/linux/efi.h
> index f5083aa72eae..f1b7d68ac460 100644
> --- a/include/linux/efi.h
> +++ b/include/linux/efi.h
> @@ -966,6 +966,8 @@ extern struct efi {
> unsigned long flags;
> } efi;
>
> +extern struct mm_struct efi_mm;
> +
> static inline int
> efi_guidcmp (efi_guid_t left, efi_guid_t right)
> {
Ugh, I can see three problems with this patch:
1)
Why is the low level asm/efi.h header polluted with two of the biggest header
files in existence, to add a type to _another_ header (efi.h)?
2)
Why is <linux/sched/task.h> included if what is being relied on is mm_struct?
3)
But even <linux/sched/mm.h> looks unnecessary in efi.h, a simple forward
declaration of mm_struct would do ...
The high level MM and sched headers should be added to the actual .c files that
make use of them.
Thanks,
Ingo
next prev parent reply other threads:[~2018-03-09 7:40 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-08 8:00 [GIT PULL 00/12] first batch of EFI changes for v4.17 Ard Biesheuvel
2018-03-08 8:00 ` [PATCH 01/12] efi/arm*: Only register page tables when they exist Ard Biesheuvel
2018-03-08 8:00 ` [PATCH 02/12] efi/apple-properties: Device core takes care of empty properties Ard Biesheuvel
2018-03-08 8:00 ` [PATCH 03/12] efi/arm*: Stop printing addresses of virtual mappings Ard Biesheuvel
2018-03-08 8:00 ` [PATCH 04/12] efi/x86: Fix trailing semicolons Ard Biesheuvel
2018-03-08 8:00 ` [PATCH 05/12] efi: arm64: Check whether x18 is preserved by runtime services calls Ard Biesheuvel
2018-03-08 8:00 ` [PATCH 06/12] x86: efi: Replace GFP_ATOMIC with GFP_KERNEL in efi_query_variable_store Ard Biesheuvel
2018-03-09 7:54 ` Ingo Molnar
2018-03-08 8:00 ` [PATCH 07/12] efi: Use efi_mm in x86 as well as ARM Ard Biesheuvel
2018-03-09 7:40 ` Ingo Molnar [this message]
2018-03-09 8:37 ` Prakhya, Sai Praneeth
2018-03-09 9:56 ` Ard Biesheuvel
2018-03-08 8:00 ` [PATCH 08/12] x86/efi: Replace efi_pgd with efi_mm.pgd Ard Biesheuvel
2018-03-08 8:00 ` [PATCH 09/12] x86/efi: Use efi_switch_mm() rather than manually twiddling with %cr3 Ard Biesheuvel
2018-03-08 8:00 ` [PATCH 10/12] efi: reorder pr_notice() with add_device_randomness() call Ard Biesheuvel
2018-03-08 8:00 ` [PATCH 11/12] efi/apple-properties: Use memremap() instead of ioremap() Ard Biesheuvel
2018-03-08 8:00 ` [PATCH 12/12] efi: make const array 'apple' static Ard Biesheuvel
2018-03-08 11:05 ` Joe Perches
2018-03-09 7:43 ` Ard Biesheuvel
2018-03-09 7:44 ` Ard Biesheuvel
2018-03-09 9:37 ` Joe Perches
2018-03-09 7:47 ` Ingo Molnar
2018-03-09 7:52 ` Ard Biesheuvel
2018-03-09 8:04 ` Ingo Molnar
2018-03-09 8:07 ` Ard Biesheuvel
2018-03-09 8:19 ` Ard Biesheuvel
2018-03-09 8:31 ` Ingo Molnar
2018-03-09 8:29 ` Lukas Wunner
2018-03-09 8:33 ` Ard Biesheuvel
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=20180309074034.put3ko6zxmaoizzr@gmail.com \
--to=mingo@kernel.org \
--cc=ard.biesheuvel@linaro.org \
--cc=bp@alien8.de \
--cc=jlee@suse.com \
--cc=linux-efi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=mst@redhat.com \
--cc=ravi.v.shankar@intel.com \
--cc=ricardo.neri@intel.com \
--cc=sai.praneeth.prakhya@intel.com \
--cc=tglx@linutronix.de \
--cc=tony.luck@intel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox