From: Eric DeVolder <eric.devolder@oracle.com>
To: Baoquan He <bhe@redhat.com>, linux-kernel@vger.kernel.org
Cc: kexec@lists.infradead.org, akpm@linux-foundation.org,
vschneid@redhat.com, sourabhjain@linux.ibm.com
Subject: Re: [PATCH v3] Crash: add lock to serialize crash hotplug handling
Date: Tue, 26 Sep 2023 09:55:31 -0500 [thread overview]
Message-ID: <4d6c291b-9b10-a4fe-6486-14b0a0e9ee86@oracle.com> (raw)
In-Reply-To: <20230926120905.392903-1-bhe@redhat.com>
On 9/26/23 07:09, Baoquan He wrote:
> Eric reported that handling corresponding crash hotplug event can be
> failed easily when many memory hotplug event are notified in a short
> period. They failed because failing to take __kexec_lock.
>
> =======
> [ 78.714569] Fallback order for Node 0: 0
> [ 78.714575] Built 1 zonelists, mobility grouping on. Total pages: 1817886
> [ 78.717133] Policy zone: Normal
> [ 78.724423] crash hp: kexec_trylock() failed, elfcorehdr may be inaccurate
> [ 78.727207] crash hp: kexec_trylock() failed, elfcorehdr may be inaccurate
> [ 80.056643] PEFILE: Unsigned PE binary
> =======
>
> The memory hotplug events are notified very quickly and very many,
> while the handling of crash hotplug is much slower relatively. So the
> atomic variable __kexec_lock and kexec_trylock() can't guarantee the
> serialization of crash hotplug handling.
>
> Here, add a new mutex lock __crash_hotplug_lock to serialize crash
> hotplug handling specifically. This doesn't impact the usage of
> __kexec_lock.
>
> Signed-off-by: Baoquan He <bhe@redhat.com>
I've run this patch in my regression environment and I do not see any
lock failures! And I've done this with a variety of DIMM sizes up to 8GiB in
order to vary the "size of the swarm". Both with kexec_load and kexec_file_load.
Tested-by: Eric DeVolder <eric.devolder@oracle.com>
Reviewed-by: Eric DeVolder <eric.devolder@oracle.com>
> ---
> v2->v3:
> - crash_check_update_elfcorehdr() need take __crash_hotplug_lock
> too because there's tiny racing window when kexec_load interface
> is taken. Eric pointed out this.
> v1->v2:
> - Move mutex lock definition into CONFIG_CRASH_HOTPLUG ifdeffery
> scope in kernel/crash_core.c because the lock is only needed and
> used in that scope. Suggested by Eric.
> kernel/crash_core.c | 17 +++++++++++++++++
> 1 file changed, 17 insertions(+)
>
> diff --git a/kernel/crash_core.c b/kernel/crash_core.c
> index 03a7932cde0a..2f675ef045d4 100644
> --- a/kernel/crash_core.c
> +++ b/kernel/crash_core.c
> @@ -739,6 +739,17 @@ subsys_initcall(crash_notes_memory_init);
> #undef pr_fmt
> #define pr_fmt(fmt) "crash hp: " fmt
>
> +/*
> + * Different than kexec/kdump loading/unloading/jumping/shrinking which
> + * usually rarely happen, there will be many crash hotplug events notified
> + * during one short period, e.g one memory board is hot added and memory
> + * regions are online. So mutex lock __crash_hotplug_lock is used to
> + * serialize the crash hotplug handling specifically.
> + */
> +DEFINE_MUTEX(__crash_hotplug_lock);
> +#define crash_hotplug_lock() mutex_lock(&__crash_hotplug_lock)
> +#define crash_hotplug_unlock() mutex_unlock(&__crash_hotplug_lock)
> +
> /*
> * This routine utilized when the crash_hotplug sysfs node is read.
> * It reflects the kernel's ability/permission to update the crash
> @@ -748,9 +759,11 @@ int crash_check_update_elfcorehdr(void)
> {
> int rc = 0;
>
> + crash_hotplug_lock();
> /* Obtain lock while reading crash information */
> if (!kexec_trylock()) {
> pr_info("kexec_trylock() failed, elfcorehdr may be inaccurate\n");
> + crash_hotplug_unlock();
> return 0;
> }
> if (kexec_crash_image) {
> @@ -761,6 +774,7 @@ int crash_check_update_elfcorehdr(void)
> }
> /* Release lock now that update complete */
> kexec_unlock();
> + crash_hotplug_unlock();
>
> return rc;
> }
> @@ -783,9 +797,11 @@ static void crash_handle_hotplug_event(unsigned int hp_action, unsigned int cpu)
> {
> struct kimage *image;
>
> + crash_hotplug_lock();
> /* Obtain lock while changing crash information */
> if (!kexec_trylock()) {
> pr_info("kexec_trylock() failed, elfcorehdr may be inaccurate\n");
> + crash_hotplug_unlock();
> return;
> }
>
> @@ -852,6 +868,7 @@ static void crash_handle_hotplug_event(unsigned int hp_action, unsigned int cpu)
> out:
> /* Release lock now that update complete */
> kexec_unlock();
> + crash_hotplug_unlock();
> }
>
> static int crash_memhp_notifier(struct notifier_block *nb, unsigned long val, void *v)
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
WARNING: multiple messages have this Message-ID (diff)
From: Eric DeVolder <eric.devolder@oracle.com>
To: Baoquan He <bhe@redhat.com>, linux-kernel@vger.kernel.org
Cc: kexec@lists.infradead.org, akpm@linux-foundation.org,
vschneid@redhat.com, sourabhjain@linux.ibm.com
Subject: Re: [PATCH v3] Crash: add lock to serialize crash hotplug handling
Date: Tue, 26 Sep 2023 09:55:31 -0500 [thread overview]
Message-ID: <4d6c291b-9b10-a4fe-6486-14b0a0e9ee86@oracle.com> (raw)
In-Reply-To: <20230926120905.392903-1-bhe@redhat.com>
On 9/26/23 07:09, Baoquan He wrote:
> Eric reported that handling corresponding crash hotplug event can be
> failed easily when many memory hotplug event are notified in a short
> period. They failed because failing to take __kexec_lock.
>
> =======
> [ 78.714569] Fallback order for Node 0: 0
> [ 78.714575] Built 1 zonelists, mobility grouping on. Total pages: 1817886
> [ 78.717133] Policy zone: Normal
> [ 78.724423] crash hp: kexec_trylock() failed, elfcorehdr may be inaccurate
> [ 78.727207] crash hp: kexec_trylock() failed, elfcorehdr may be inaccurate
> [ 80.056643] PEFILE: Unsigned PE binary
> =======
>
> The memory hotplug events are notified very quickly and very many,
> while the handling of crash hotplug is much slower relatively. So the
> atomic variable __kexec_lock and kexec_trylock() can't guarantee the
> serialization of crash hotplug handling.
>
> Here, add a new mutex lock __crash_hotplug_lock to serialize crash
> hotplug handling specifically. This doesn't impact the usage of
> __kexec_lock.
>
> Signed-off-by: Baoquan He <bhe@redhat.com>
I've run this patch in my regression environment and I do not see any
lock failures! And I've done this with a variety of DIMM sizes up to 8GiB in
order to vary the "size of the swarm". Both with kexec_load and kexec_file_load.
Tested-by: Eric DeVolder <eric.devolder@oracle.com>
Reviewed-by: Eric DeVolder <eric.devolder@oracle.com>
> ---
> v2->v3:
> - crash_check_update_elfcorehdr() need take __crash_hotplug_lock
> too because there's tiny racing window when kexec_load interface
> is taken. Eric pointed out this.
> v1->v2:
> - Move mutex lock definition into CONFIG_CRASH_HOTPLUG ifdeffery
> scope in kernel/crash_core.c because the lock is only needed and
> used in that scope. Suggested by Eric.
> kernel/crash_core.c | 17 +++++++++++++++++
> 1 file changed, 17 insertions(+)
>
> diff --git a/kernel/crash_core.c b/kernel/crash_core.c
> index 03a7932cde0a..2f675ef045d4 100644
> --- a/kernel/crash_core.c
> +++ b/kernel/crash_core.c
> @@ -739,6 +739,17 @@ subsys_initcall(crash_notes_memory_init);
> #undef pr_fmt
> #define pr_fmt(fmt) "crash hp: " fmt
>
> +/*
> + * Different than kexec/kdump loading/unloading/jumping/shrinking which
> + * usually rarely happen, there will be many crash hotplug events notified
> + * during one short period, e.g one memory board is hot added and memory
> + * regions are online. So mutex lock __crash_hotplug_lock is used to
> + * serialize the crash hotplug handling specifically.
> + */
> +DEFINE_MUTEX(__crash_hotplug_lock);
> +#define crash_hotplug_lock() mutex_lock(&__crash_hotplug_lock)
> +#define crash_hotplug_unlock() mutex_unlock(&__crash_hotplug_lock)
> +
> /*
> * This routine utilized when the crash_hotplug sysfs node is read.
> * It reflects the kernel's ability/permission to update the crash
> @@ -748,9 +759,11 @@ int crash_check_update_elfcorehdr(void)
> {
> int rc = 0;
>
> + crash_hotplug_lock();
> /* Obtain lock while reading crash information */
> if (!kexec_trylock()) {
> pr_info("kexec_trylock() failed, elfcorehdr may be inaccurate\n");
> + crash_hotplug_unlock();
> return 0;
> }
> if (kexec_crash_image) {
> @@ -761,6 +774,7 @@ int crash_check_update_elfcorehdr(void)
> }
> /* Release lock now that update complete */
> kexec_unlock();
> + crash_hotplug_unlock();
>
> return rc;
> }
> @@ -783,9 +797,11 @@ static void crash_handle_hotplug_event(unsigned int hp_action, unsigned int cpu)
> {
> struct kimage *image;
>
> + crash_hotplug_lock();
> /* Obtain lock while changing crash information */
> if (!kexec_trylock()) {
> pr_info("kexec_trylock() failed, elfcorehdr may be inaccurate\n");
> + crash_hotplug_unlock();
> return;
> }
>
> @@ -852,6 +868,7 @@ static void crash_handle_hotplug_event(unsigned int hp_action, unsigned int cpu)
> out:
> /* Release lock now that update complete */
> kexec_unlock();
> + crash_hotplug_unlock();
> }
>
> static int crash_memhp_notifier(struct notifier_block *nb, unsigned long val, void *v)
next prev parent reply other threads:[~2023-09-26 14:55 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-26 12:09 [PATCH v3] Crash: add lock to serialize crash hotplug handling Baoquan He
2023-09-26 12:09 ` Baoquan He
2023-09-26 14:55 ` Eric DeVolder [this message]
2023-09-26 14:55 ` Eric DeVolder
2023-09-26 20:50 ` Andrew Morton
2023-09-26 20:50 ` Andrew Morton
2023-09-26 21:53 ` Eric DeVolder
2023-09-26 21:53 ` Eric DeVolder
2023-09-27 0:14 ` Baoquan He
2023-09-27 0:14 ` Baoquan He
2023-09-28 8:51 ` Valentin Schneider
2023-09-28 8:51 ` Valentin Schneider
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=4d6c291b-9b10-a4fe-6486-14b0a0e9ee86@oracle.com \
--to=eric.devolder@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=bhe@redhat.com \
--cc=kexec@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=sourabhjain@linux.ibm.com \
--cc=vschneid@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.