From: AKASHI Takahiro <takahiro.akashi@linaro.org>
To: dyoung@redhat.com, vgoyal@redhat.com, bhe@redhat.com,
mpe@ellerman.id.au, bauerman@linux.vnet.ibm.com,
prudo@linux.vnet.ibm.com
Cc: kexec@lists.infradead.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-s390@vger.kernel.org,
AKASHI Takahiro <takahiro.akashi@linaro.org>
Subject: [PATCH v2 5/7] x86: kexec_file: lift CRASH_MAX_RANGES limit on crash_mem buffer
Date: Tue, 6 Mar 2018 19:23:01 +0900 [thread overview]
Message-ID: <20180306102303.9063-6-takahiro.akashi@linaro.org> (raw)
In-Reply-To: <20180306102303.9063-1-takahiro.akashi@linaro.org>
While CRASH_MAX_RANGES (== 16) seems to be good enough, fixed-number
array is not a good idea in general.
In this patch, size of crash_mem buffer is calculated as before and
the buffer is now dynamically allocated. This change also allows removing
crash_elf_data structure.
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Cc: Dave Young <dyoung@redhat.com>
Cc: Vivek Goyal <vgoyal@redhat.com>
Cc: Baoquan He <bhe@redhat.com>
---
arch/x86/kernel/crash.c | 82 +++++++++++++++++++------------------------------
1 file changed, 31 insertions(+), 51 deletions(-)
diff --git a/arch/x86/kernel/crash.c b/arch/x86/kernel/crash.c
index b328153cee65..0f20a6330bd6 100644
--- a/arch/x86/kernel/crash.c
+++ b/arch/x86/kernel/crash.c
@@ -41,32 +41,14 @@
/* Alignment required for elf header segment */
#define ELF_CORE_HEADER_ALIGN 4096
-/* This primarily represents number of split ranges due to exclusion */
-#define CRASH_MAX_RANGES 16
-
struct crash_mem_range {
u64 start, end;
};
struct crash_mem {
- unsigned int nr_ranges;
- struct crash_mem_range ranges[CRASH_MAX_RANGES];
-};
-
-/* Misc data about ram ranges needed to prepare elf headers */
-struct crash_elf_data {
- struct kimage *image;
- /*
- * Total number of ram ranges we have after various adjustments for
- * crash reserved region, etc.
- */
unsigned int max_nr_ranges;
-
- /* Pointer to elf header */
- void *ehdr;
- /* Pointer to next phdr */
- void *bufp;
- struct crash_mem mem;
+ unsigned int nr_ranges;
+ struct crash_mem_range ranges[0];
};
/* Used while preparing memory map entries for second kernel */
@@ -217,26 +199,31 @@ static int get_nr_ram_ranges_callback(struct resource *res, void *arg)
return 0;
}
-
/* Gather all the required information to prepare elf headers for ram regions */
-static void fill_up_crash_elf_data(struct crash_elf_data *ced,
- struct kimage *image)
+static struct crash_mem *fill_up_crash_elf_data(void)
{
unsigned int nr_ranges = 0;
-
- ced->image = image;
+ struct crash_mem *cmem;
walk_system_ram_res(0, -1, &nr_ranges,
get_nr_ram_ranges_callback);
+ if (!nr_ranges)
+ return NULL;
- ced->max_nr_ranges = nr_ranges;
+ /*
+ * Exclusion of crash region and/or crashk_low_res may cause
+ * another range split. So add extra two slots here.
+ */
+ nr_ranges += 2;
+ cmem = vzalloc(sizeof(struct crash_mem) +
+ sizeof(struct crash_mem_range) * nr_ranges);
+ if (!cmem)
+ return NULL;
- /* Exclusion of crash region could split memory ranges */
- ced->max_nr_ranges++;
+ cmem->max_nr_ranges = nr_ranges;
+ cmem->nr_ranges = 0;
- /* If crashk_low_res is not 0, another range split possible */
- if (crashk_low_res.end)
- ced->max_nr_ranges++;
+ return cmem;
}
static int exclude_mem_range(struct crash_mem *mem,
@@ -293,10 +280,8 @@ static int exclude_mem_range(struct crash_mem *mem,
return 0;
/* Split happened */
- if (i == CRASH_MAX_RANGES - 1) {
- pr_err("Too many crash ranges after split\n");
+ if (i == mem->max_nr_ranges - 1)
return -ENOMEM;
- }
/* Location where new range should go */
j = i + 1;
@@ -314,11 +299,10 @@ static int exclude_mem_range(struct crash_mem *mem,
/*
* Look for any unwanted ranges between mstart, mend and remove them. This
- * might lead to split and split ranges are put in ced->mem.ranges[] array
+ * might lead to split and split ranges are put in cmem->ranges[] array
*/
-static int elf_header_exclude_ranges(struct crash_elf_data *ced)
+static int elf_header_exclude_ranges(struct crash_mem *cmem)
{
- struct crash_mem *cmem = &ced->mem;
int ret = 0;
/* Exclude crashkernel region */
@@ -337,8 +321,7 @@ static int elf_header_exclude_ranges(struct crash_elf_data *ced)
static int prepare_elf64_ram_headers_callback(struct resource *res, void *arg)
{
- struct crash_elf_data *ced = arg;
- struct crash_mem *cmem = &ced->mem;
+ struct crash_mem *cmem = arg;
cmem->ranges[cmem->nr_ranges].start = res->start;
cmem->ranges[cmem->nr_ranges].end = res->end;
@@ -347,7 +330,7 @@ static int prepare_elf64_ram_headers_callback(struct resource *res, void *arg)
return 0;
}
-static int prepare_elf64_headers(struct crash_elf_data *ced, bool kernel_map,
+static int prepare_elf64_headers(struct crash_mem *cmem, bool kernel_map,
void **addr, unsigned long *sz)
{
Elf64_Ehdr *ehdr;
@@ -356,12 +339,11 @@ static int prepare_elf64_headers(struct crash_elf_data *ced, bool kernel_map,
unsigned char *buf, *bufp;
unsigned int cpu, i;
unsigned long long notes_addr;
- struct crash_mem *cmem = &ced->mem;
unsigned long mstart, mend;
/* extra phdr for vmcoreinfo elf note */
nr_phdr = nr_cpus + 1;
- nr_phdr += ced->max_nr_ranges;
+ nr_phdr += cmem->nr_ranges;
/*
* kexec-tools creates an extra PT_LOAD phdr for kernel text mapping
@@ -455,29 +437,27 @@ static int prepare_elf64_headers(struct crash_elf_data *ced, bool kernel_map,
static int prepare_elf_headers(struct kimage *image, void **addr,
unsigned long *sz)
{
- struct crash_elf_data *ced;
+ struct crash_mem *cmem;
Elf64_Ehdr *ehdr;
Elf64_Phdr *phdr;
int ret, i;
- ced = kzalloc(sizeof(*ced), GFP_KERNEL);
- if (!ced)
+ cmem = fill_up_crash_elf_data();
+ if (!cmem)
return -ENOMEM;
- fill_up_crash_elf_data(ced, image);
-
- ret = walk_system_ram_res(0, -1, ced,
+ ret = walk_system_ram_res(0, -1, cmem,
prepare_elf64_ram_headers_callback);
if (ret)
goto out;
/* Exclude unwanted mem ranges */
- ret = elf_header_exclude_ranges(ced);
+ ret = elf_header_exclude_ranges(cmem);
if (ret)
goto out;
/* By default prepare 64bit headers */
- ret = prepare_elf64_headers(ced, IS_ENABLED(CONFIG_X86_64), addr, sz);
+ ret = prepare_elf64_headers(cmem, IS_ENABLED(CONFIG_X86_64), addr, sz);
if (ret)
goto out;
@@ -495,7 +475,7 @@ static int prepare_elf_headers(struct kimage *image, void **addr,
break;
}
out:
- kfree(ced);
+ vfree(cmem);
return ret;
}
--
2.16.2
next prev parent reply other threads:[~2018-03-06 10:23 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-06 10:22 [PATCH v2 0/7] kexec_file, x86, powerpc: refactoring for other architecutres AKASHI Takahiro
2018-03-06 10:22 ` [PATCH v2 1/7] kexec_file: make an use of purgatory optional AKASHI Takahiro
2018-03-06 10:22 ` [PATCH v2 2/7] kexec_file,x86,powerpc: factor out kexec_file_ops functions AKASHI Takahiro
2018-03-08 1:13 ` Dave Young
2018-03-14 1:00 ` Thiago Jung Bauermann
2018-03-14 2:14 ` [PATCH v2 2/7] kexec_file, x86, powerpc: " Michael Ellerman
2018-03-06 10:22 ` [PATCH v2 3/7] x86: kexec_file: purge system-ram walking from prepare_elf64_headers() AKASHI Takahiro
2018-03-06 10:23 ` [PATCH v2 4/7] x86: kexec_file: remove X86_64 dependency " AKASHI Takahiro
2018-03-06 10:23 ` AKASHI Takahiro [this message]
2018-03-06 10:23 ` [PATCH v2 6/7] x86: kexec_file: clean up prepare_elf64_headers() AKASHI Takahiro
2018-03-06 10:23 ` [PATCH v2 7/7] kexec_file, x86: move re-factored code to generic side AKASHI Takahiro
2018-03-08 1:05 ` [PATCH v2 0/7] kexec_file, x86, powerpc: refactoring for other architecutres Dave Young
2018-03-09 6:02 ` Dave Young
2018-03-09 6:44 ` Dave Young
2018-03-09 7:18 ` AKASHI Takahiro
2018-03-09 7:46 ` Dave Young
2018-03-09 7:55 ` Dave Young
2018-03-09 9:33 ` AKASHI Takahiro
2018-03-12 3:18 ` Dave Young
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=20180306102303.9063-6-takahiro.akashi@linaro.org \
--to=takahiro.akashi@linaro.org \
--cc=bauerman@linux.vnet.ibm.com \
--cc=bhe@redhat.com \
--cc=dyoung@redhat.com \
--cc=kexec@lists.infradead.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=mpe@ellerman.id.au \
--cc=prudo@linux.vnet.ibm.com \
--cc=vgoyal@redhat.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;
as well as URLs for NNTP newsgroup(s).