From: Baoquan He <bhe@redhat.com>
To: Yuntao Wang <ytcoode@gmail.com>
Cc: linux-kernel@vger.kernel.org, kexec@lists.infradead.org,
x86@kernel.org, Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
Dave Hansen <dave.hansen@linux.intel.com>,
"H. Peter Anvin" <hpa@zytor.com>, Vivek Goyal <vgoyal@redhat.com>,
Dave Young <dyoung@redhat.com>,
Hari Bathini <hbathini@linux.ibm.com>,
Eric DeVolder <eric.devolder@oracle.com>,
Andrew Morton <akpm@linux-foundation.org>,
Sourabh Jain <sourabhjain@linux.ibm.com>,
Sean Christopherson <seanjc@google.com>,
Takashi Iwai <tiwai@suse.de>, Lianbo Jiang <lijiang@redhat.com>
Subject: Re: [PATCH 3/3] crash_core: fix and simplify the logic of crash_exclude_mem_range()
Date: Fri, 15 Dec 2023 23:15:10 +0800 [thread overview]
Message-ID: <ZXxtfpXpuFXLd+ge@MiWiFi-R3L-srv> (raw)
In-Reply-To: <20231214163842.129139-4-ytcoode@gmail.com>
On 12/15/23 at 12:38am, Yuntao Wang wrote:
> The purpose of crash_exclude_mem_range() is to remove all memory ranges
> that overlap with [mstart-mend]. However, the current logic only removes
> the first overlapping memory range.
>
> Commit a2e9a95d2190 ("kexec: Improve & fix crash_exclude_mem_range() to
> handle overlapping ranges") attempted to address this issue, but it did not
> fix all error cases.
Hmm, this is a specific function for kdump kernel loading. So far it's
sufficiently meet demands. Say so because we only need to exclude
crashk_res and crashk_low_res when constructing elfcorehdr. region
crashk_res/crashk_low_res are digged out from system RAM region. That's
why the break is taken in the for loop in the current code. X86 needs
exclude low 1M, the low 1M could span several system RAM regions because
BIOS under low 1M reserved some spaces. And the elfcorehdr exluding from
crashkernel region taken in x86 is also a splitting.
Generally speaking, crashk_res/crashk_low_res is inside a big chunk of
continuous region. On x86, low 1M spans several complete region on x86,
elfcorehdr region is inside continuous crashk_res region.
You can see why crash_exclude_mem_range() looks like now it is. This patch
makes crash_exclude_mem_range() be a generic region removing function. I do
see the memmove can improve code readbility, while I have concern about the
while loop.
Imagine we have a crashkernel region 256M reserved under 4G, say [2G, 2G+256M].
Then after excluding the 256M from a region, it should stop. But now, this patch
will make it continue scanning. Not sure if it's all in my mind.
>
> Let's fix and simplify the logic of crash_exclude_mem_range().
>
> Signed-off-by: Yuntao Wang <ytcoode@gmail.com>
> ---
> kernel/crash_core.c | 70 ++++++++++++---------------------------------
> 1 file changed, 19 insertions(+), 51 deletions(-)
>
> diff --git a/kernel/crash_core.c b/kernel/crash_core.c
> index efe87d501c8c..0292a4c8bb2f 100644
> --- a/kernel/crash_core.c
> +++ b/kernel/crash_core.c
> @@ -565,9 +565,8 @@ int crash_prepare_elf64_headers(struct crash_mem *mem, int need_kernel_map,
> int crash_exclude_mem_range(struct crash_mem *mem,
> unsigned long long mstart, unsigned long long mend)
> {
> - int i, j;
> + int i;
> unsigned long long start, end, p_start, p_end;
> - struct range temp_range = {0, 0};
>
> for (i = 0; i < mem->nr_ranges; i++) {
> start = mem->ranges[i].start;
> @@ -575,72 +574,41 @@ int crash_exclude_mem_range(struct crash_mem *mem,
> p_start = mstart;
> p_end = mend;
>
> - if (mstart > end || mend < start)
> + if (p_start > end || p_end < start)
> continue;
>
> /* Truncate any area outside of range */
> - if (mstart < start)
> + if (p_start < start)
> p_start = start;
> - if (mend > end)
> + if (p_end > end)
> p_end = end;
>
> /* Found completely overlapping range */
> if (p_start == start && p_end == end) {
> - mem->ranges[i].start = 0;
> - mem->ranges[i].end = 0;
> - if (i < mem->nr_ranges - 1) {
> - /* Shift rest of the ranges to left */
> - for (j = i; j < mem->nr_ranges - 1; j++) {
> - mem->ranges[j].start =
> - mem->ranges[j+1].start;
> - mem->ranges[j].end =
> - mem->ranges[j+1].end;
> - }
> -
> - /*
> - * Continue to check if there are another overlapping ranges
> - * from the current position because of shifting the above
> - * mem ranges.
> - */
> - i--;
> - mem->nr_ranges--;
> - continue;
> - }
> + memmove(&mem->ranges[i], &mem->ranges[i + 1],
> + (mem->nr_ranges - (i + 1)) * sizeof(mem->ranges[i]));
> + i--;
> mem->nr_ranges--;
> - return 0;
> - }
> -
> - if (p_start > start && p_end < end) {
> + } else if (p_start > start && p_end < end) {
> /* Split original range */
> + if (mem->nr_ranges >= mem->max_nr_ranges)
> + return -ENOMEM;
> +
> + memmove(&mem->ranges[i + 2], &mem->ranges[i + 1],
> + (mem->nr_ranges - (i + 1)) * sizeof(mem->ranges[i]));
> +
> mem->ranges[i].end = p_start - 1;
> - temp_range.start = p_end + 1;
> - temp_range.end = end;
> + mem->ranges[i + 1].start = p_end + 1;
> + mem->ranges[i + 1].end = end;
> +
> + i++;
> + mem->nr_ranges++;
> } else if (p_start != start)
> mem->ranges[i].end = p_start - 1;
> else
> mem->ranges[i].start = p_end + 1;
> - break;
> - }
> -
> - /* If a split happened, add the split to array */
> - if (!temp_range.end)
> - return 0;
> -
> - /* Split happened */
> - if (i == mem->max_nr_ranges - 1)
> - return -ENOMEM;
> -
> - /* Location where new range should go */
> - j = i + 1;
> - if (j < mem->nr_ranges) {
> - /* Move over all ranges one slot towards the end */
> - for (i = mem->nr_ranges - 1; i >= j; i--)
> - mem->ranges[i + 1] = mem->ranges[i];
> }
>
> - mem->ranges[j].start = temp_range.start;
> - mem->ranges[j].end = temp_range.end;
> - mem->nr_ranges++;
> return 0;
> }
>
> --
> 2.43.0
>
next prev parent reply other threads:[~2023-12-15 15:15 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-14 16:38 [PATCH 0/3] Some cleanups and fixes Yuntao Wang
2023-12-14 16:38 ` [PATCH 1/3] x86/crash: remove the unused image parameter from prepare_elf_headers() Yuntao Wang
2023-12-15 3:27 ` Baoquan He
2023-12-14 16:38 ` [PATCH 2/3] x86/crash: use SZ_1M macro instead of hardcoded value Yuntao Wang
2023-12-15 3:28 ` Baoquan He
2023-12-14 16:38 ` [PATCH 3/3] crash_core: fix and simplify the logic of crash_exclude_mem_range() Yuntao Wang
2023-12-15 15:15 ` Baoquan He [this message]
2023-12-16 1:54 ` Yuntao Wang
2023-12-16 3:31 ` Baoquan He
2023-12-29 20:10 ` Andrew Morton
2023-12-30 10:16 ` Baoquan He
2024-01-02 8:41 ` Baoquan He
2024-01-02 15:06 ` Yuntao Wang
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=ZXxtfpXpuFXLd+ge@MiWiFi-R3L-srv \
--to=bhe@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=dyoung@redhat.com \
--cc=eric.devolder@oracle.com \
--cc=hbathini@linux.ibm.com \
--cc=hpa@zytor.com \
--cc=kexec@lists.infradead.org \
--cc=lijiang@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=seanjc@google.com \
--cc=sourabhjain@linux.ibm.com \
--cc=tglx@linutronix.de \
--cc=tiwai@suse.de \
--cc=vgoyal@redhat.com \
--cc=x86@kernel.org \
--cc=ytcoode@gmail.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