From: matt@codeblueprint.co.uk (Matt Fleming)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 2/3] arm64: efi: Ensure efi_create_mapping() does not map overlapping regions
Date: Thu, 2 Jun 2016 15:52:46 +0100 [thread overview]
Message-ID: <20160602145246.GH2658@codeblueprint.co.uk> (raw)
In-Reply-To: <1464707672-21882-3-git-send-email-catalin.marinas@arm.com>
On Tue, 31 May, at 04:14:31PM, Catalin Marinas wrote:
> Since the EFI page size is 4KB, it is possible for a !4KB page kernel to
> align an EFI runtime map boundaries in a way that they can overlap
> within the same page. This requires the current create_pgd_mapping()
> code to be able to split existing larger mappings when an overlapping
> region needs to be mapped.
>
> With this patch, efi_create_mapping() scans the EFI memory map for
> overlapping regions and trims the length of the current map to avoid a
> large block mapping and subsequent split.
>
> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
> ---
> arch/arm64/kernel/efi.c | 22 +++++++++++++++++++---
> 1 file changed, 19 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm64/kernel/efi.c b/arch/arm64/kernel/efi.c
> index 78f52488f9ff..0d5753c31c7f 100644
> --- a/arch/arm64/kernel/efi.c
> +++ b/arch/arm64/kernel/efi.c
> @@ -62,10 +62,26 @@ struct screen_info screen_info __section(.data);
> int __init efi_create_mapping(struct mm_struct *mm, efi_memory_desc_t *md)
> {
> pteval_t prot_val = create_mapping_protection(md);
> + phys_addr_t length = md->num_pages << EFI_PAGE_SHIFT;
> + efi_memory_desc_t *next = md;
>
> - create_pgd_mapping(mm, md->phys_addr, md->virt_addr,
> - md->num_pages << EFI_PAGE_SHIFT,
> - __pgprot(prot_val | PTE_NG));
> + /*
> + * Search for the next EFI runtime map and check for any overlap with
> + * the current map when aligned to PAGE_SIZE. In such case, defer
> + * mapping the end of the current range until the next
> + * efi_create_mapping() call.
> + */
> + for_each_efi_memory_desc_continue(next) {
> + if (!(next->attribute & EFI_MEMORY_RUNTIME))
> + continue;
> + if (next->phys_addr < PAGE_ALIGN(md->phys_addr + length))
> + length -= (md->phys_addr + length) & ~PAGE_MASK;
> + break;
> + }
> +
> + if (length)
> + create_pgd_mapping(mm, md->phys_addr, md->virt_addr, length,
> + __pgprot(prot_val | PTE_NG));
> return 0;
> }
>
Is this mapping in chunks scheme required because of the EFI
Properties Table restriction whereby relative offsets between regions
must be maintained?
Because if that's not the reason, I'm wondering why you can't simply
update efi_get_virtmap() to align the virtual addresses to 64K?
next prev parent reply other threads:[~2016-06-02 14:52 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-31 15:14 [PATCH 0/3] arm64: Avoid overlapping EFI regions Catalin Marinas
2016-05-31 15:14 ` [PATCH 1/3] efi: Introduce *_continue efi_memory_desc iterators Catalin Marinas
2016-06-01 10:34 ` Mark Rutland
2016-06-01 10:43 ` Catalin Marinas
2016-06-02 14:36 ` Matt Fleming
2016-06-02 16:29 ` Catalin Marinas
2016-06-02 16:31 ` Jeremy Linton
2016-06-02 17:11 ` Catalin Marinas
2016-06-02 17:15 ` Jeremy Linton
2016-06-03 20:43 ` Matt Fleming
2016-05-31 15:14 ` [PATCH 2/3] arm64: efi: Ensure efi_create_mapping() does not map overlapping regions Catalin Marinas
2016-06-02 14:52 ` Matt Fleming [this message]
2016-06-02 16:56 ` Catalin Marinas
2016-06-03 20:56 ` Matt Fleming
2016-06-06 9:43 ` Ard Biesheuvel
2016-06-06 17:09 ` Catalin Marinas
2016-06-06 17:26 ` Ard Biesheuvel
2016-06-06 17:42 ` Catalin Marinas
2016-06-06 21:18 ` Ard Biesheuvel
2016-06-28 16:05 ` Catalin Marinas
2016-06-28 16:12 ` Ard Biesheuvel
2016-06-29 9:39 ` Catalin Marinas
2016-06-29 10:03 ` Ard Biesheuvel
2016-06-29 10:50 ` Catalin Marinas
2016-06-29 11:03 ` Ard Biesheuvel
2016-06-29 12:03 ` Catalin Marinas
2016-05-31 15:14 ` [PATCH 3/3] arm64: mm: Remove split_p*d() functions Catalin Marinas
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=20160602145246.GH2658@codeblueprint.co.uk \
--to=matt@codeblueprint.co.uk \
--cc=linux-arm-kernel@lists.infradead.org \
/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;
as well as URLs for NNTP newsgroup(s).