From: Mark Salter <msalter@redhat.com> To: Catalin Marinas <catalin.marinas@arm.com>, Will Deacon <will.deacon@arm.com>, x86@kernel.org Cc: Andrew Morton <akpm@linux-foundation.org>, Arnd Bergmann <arnd@arndb.de>, Ard Biesheuvel <ard.biesheuvel@linaro.org>, Mark Rutland <mark.rutland@arm.com>, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-mm@kvack.org, linux-arch@vger.kernel.org, Mark Salter <msalter@redhat.com> Subject: [PATCH V3 0/3] mm: Add generic copy from early unmapped RAM Date: Sun, 16 Aug 2015 16:49:25 -0400 [thread overview] Message-ID: <1439758168-29427-1-git-send-email-msalter@redhat.com> (raw) When booting an arm64 kernel w/initrd using UEFI/grub, use of mem= will likely cut off part or all of the initrd. This leaves it outside the kernel linear map which leads to failure when unpacking. The x86 code has a similar need to relocate an initrd outside of mapped memory in some cases. The current x86 code uses early_memremap() to copy the original initrd from unmapped to mapped RAM. This patchset creates a generic copy_from_early_mem() utility based on that x86 code and has arm64 and x86 share it in their respective initrd relocation code. Changes from V2: * Fixed sparse warning in copy_from_early_mem() * Removed unneeded MAX_MAP_CHUNK from x86 setup.c * Moved #ifdef outside arm64 relocate_initrd() definition. Changes from V1: * Change cover letter subject to highlight the added generic code * Add patch for x86 to use common copy_from_early_mem() Mark Salter (3): mm: add utility for early copy from unmapped ram arm64: support initrd outside kernel linear map x86: use generic early mem copy arch/arm64/kernel/setup.c | 59 +++++++++++++++++++++++++++++++++++++ arch/x86/kernel/setup.c | 22 +------------- include/asm-generic/early_ioremap.h | 6 ++++ mm/early_ioremap.c | 22 ++++++++++++++ 4 files changed, 88 insertions(+), 21 deletions(-) -- 2.4.3 -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
WARNING: multiple messages have this Message-ID (diff)
From: Mark Salter <msalter@redhat.com> To: Catalin Marinas <catalin.marinas@arm.com>, Will Deacon <will.deacon@arm.com>, x86@kernel.org Cc: Andrew Morton <akpm@linux-foundation.org>, Arnd Bergmann <arnd@arndb.de>, Ard Biesheuvel <ard.biesheuvel@linaro.org>, Mark Rutland <mark.rutland@arm.com>, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-mm@kvack.org, linux-arch@vger.kernel.org, Mark Salter <msalter@redhat.com> Subject: [PATCH V3 0/3] mm: Add generic copy from early unmapped RAM Date: Sun, 16 Aug 2015 16:49:25 -0400 [thread overview] Message-ID: <1439758168-29427-1-git-send-email-msalter@redhat.com> (raw) Message-ID: <20150816204925.45ozZT6a0S-bnSg3kGs14hl3LRRnVfBW7__QHCT-6FM@z> (raw) When booting an arm64 kernel w/initrd using UEFI/grub, use of mem= will likely cut off part or all of the initrd. This leaves it outside the kernel linear map which leads to failure when unpacking. The x86 code has a similar need to relocate an initrd outside of mapped memory in some cases. The current x86 code uses early_memremap() to copy the original initrd from unmapped to mapped RAM. This patchset creates a generic copy_from_early_mem() utility based on that x86 code and has arm64 and x86 share it in their respective initrd relocation code. Changes from V2: * Fixed sparse warning in copy_from_early_mem() * Removed unneeded MAX_MAP_CHUNK from x86 setup.c * Moved #ifdef outside arm64 relocate_initrd() definition. Changes from V1: * Change cover letter subject to highlight the added generic code * Add patch for x86 to use common copy_from_early_mem() Mark Salter (3): mm: add utility for early copy from unmapped ram arm64: support initrd outside kernel linear map x86: use generic early mem copy arch/arm64/kernel/setup.c | 59 +++++++++++++++++++++++++++++++++++++ arch/x86/kernel/setup.c | 22 +------------- include/asm-generic/early_ioremap.h | 6 ++++ mm/early_ioremap.c | 22 ++++++++++++++ 4 files changed, 88 insertions(+), 21 deletions(-) -- 2.4.3
next reply other threads:[~2015-08-16 20:49 UTC|newest] Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top 2015-08-16 20:49 Mark Salter [this message] 2015-08-16 20:49 ` [PATCH V3 0/3] mm: Add generic copy from early unmapped RAM Mark Salter 2015-08-16 20:49 ` [PATCH V3 1/3] mm: add utility for early copy from unmapped ram Mark Salter 2015-08-16 20:49 ` Mark Salter 2015-08-16 20:49 ` [PATCH V3 2/3] arm64: support initrd outside kernel linear map Mark Salter 2015-08-16 20:49 ` Mark Salter 2015-08-17 11:22 ` Will Deacon 2015-08-17 13:32 ` Mark Salter 2015-08-16 20:49 ` [PATCH V3 3/3] x86: use generic early mem copy Mark Salter 2015-08-16 20:49 ` Mark Salter
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=1439758168-29427-1-git-send-email-msalter@redhat.com \ --to=msalter@redhat.com \ --cc=akpm@linux-foundation.org \ --cc=ard.biesheuvel@linaro.org \ --cc=arnd@arndb.de \ --cc=catalin.marinas@arm.com \ --cc=linux-arch@vger.kernel.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=mark.rutland@arm.com \ --cc=will.deacon@arm.com \ --cc=x86@kernel.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: linkBe 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).