From: Mike Rapoport <rppt@kernel.org>
To: Changyuan Lyu <changyuanl@google.com>
Cc: akpm@linux-foundation.org, graf@amazon.com, bhe@redhat.com,
kexec@lists.infradead.org, linux-kernel@vger.kernel.org,
linux-mm@kvack.org, chrisl@kernel.org, pasha.tatashin@soleen.com,
jasonmiu@google.com
Subject: Re: [PATCH 2/2] KHO: init new_physxa->phys_bits to fix lockdep
Date: Sun, 18 May 2025 18:51:04 +0300 [thread overview]
Message-ID: <aCoB6KkQr4xFBlEu@kernel.org> (raw)
In-Reply-To: <20250518142315.241670-3-changyuanl@google.com>
On Sun, May 18, 2025 at 07:23:15AM -0700, Changyuan Lyu wrote:
> From: Pasha Tatashin <pasha.tatashin@soleen.com>
>
> Lockdep shows the following warning:
>
> INFO: trying to register non-static key.
> The code is fine but needs lockdep annotation, or maybe
> you didn't initialize this object before use?
> turning off the locking correctness validator.
>
> [<ffffffff810133a6>] dump_stack_lvl+0x66/0xa0
> [<ffffffff8136012c>] assign_lock_key+0x10c/0x120
> [<ffffffff81358bb4>] register_lock_class+0xf4/0x2f0
> [<ffffffff813597ff>] __lock_acquire+0x7f/0x2c40
> [<ffffffff81360cb0>] ? __pfx_hlock_conflict+0x10/0x10
> [<ffffffff811707be>] ? native_flush_tlb_global+0x8e/0xa0
> [<ffffffff8117096e>] ? __flush_tlb_all+0x4e/0xa0
> [<ffffffff81172fc2>] ? __kernel_map_pages+0x112/0x140
> [<ffffffff813ec327>] ? xa_load_or_alloc+0x67/0xe0
> [<ffffffff81359556>] lock_acquire+0xe6/0x280
> [<ffffffff813ec327>] ? xa_load_or_alloc+0x67/0xe0
> [<ffffffff8100b9e0>] _raw_spin_lock+0x30/0x40
> [<ffffffff813ec327>] ? xa_load_or_alloc+0x67/0xe0
> [<ffffffff813ec327>] xa_load_or_alloc+0x67/0xe0
> [<ffffffff813eb4c0>] kho_preserve_folio+0x90/0x100
> [<ffffffff813ebb7f>] __kho_finalize+0xcf/0x400
> [<ffffffff813ebef4>] kho_finalize+0x34/0x70
>
> This is becase xa has its own lock, that is not initialized in
> xa_load_or_alloc.
>
> Modifiy __kho_preserve_order(), to properly call
> xa_init(&new_physxa->phys_bits);
>
> Fixes: fc33e4b44b27 ("kexec: enable KHO support for memory preservation")
> Signed-off-by: Pasha Tatashin <pasha.tatashin@soleen.com>
> Signed-off-by: Changyuan Lyu <changyuanl@google.com>
> ---
> kernel/kexec_handover.c | 29 +++++++++++++++++++++++++----
> 1 file changed, 25 insertions(+), 4 deletions(-)
>
> diff --git a/kernel/kexec_handover.c b/kernel/kexec_handover.c
> index 69b953551677..f0ac6a9170f8 100644
> --- a/kernel/kexec_handover.c
> +++ b/kernel/kexec_handover.c
> @@ -144,14 +144,35 @@ static int __kho_preserve_order(struct kho_mem_track *track, unsigned long pfn,
> unsigned int order)
> {
> struct kho_mem_phys_bits *bits;
> - struct kho_mem_phys *physxa;
> + struct kho_mem_phys *physxa, *new_physxa;
> const unsigned long pfn_high = pfn >> order;
>
> might_sleep();
>
> - physxa = xa_load_or_alloc(&track->orders, order, sizeof(*physxa));
> - if (IS_ERR(physxa))
> - return PTR_ERR(physxa);
> + physxa = xa_load(&track->orders, order);
> + if (!physxa) {
> + new_physxa = kzalloc(sizeof(*physxa), GFP_KERNEL);
> + if (!new_physxa)
> + return -ENOMEM;
> +
> + xa_init(&new_physxa->phys_bits);
> + physxa = xa_cmpxchg(&track->orders, order, NULL, new_physxa,
> + GFP_KERNEL);
> + if (xa_is_err(physxa)) {
> + int err_ret = xa_err(physxa);
> +
> + xa_destroy(&new_physxa->phys_bits);
> + kfree(new_physxa);
> +
> + return err_ret;
> + }
> + if (physxa) {
> + xa_destroy(&new_physxa->phys_bits);
> + kfree(new_physxa);
> + } else {
> + physxa = new_physxa;
> + }
> + }
You are nearly duplicating xa_load_or_alloc() here.
Is xa_destroy() is really needed here? In the end we destroying an empty
xarray.
Unless xa_destroy() is a must something like this would be simpler IMHO:
diff --git a/kernel/kexec_handover.c b/kernel/kexec_handover.c
index ef21db6c59d5..4c8303fbf97a 100644
--- a/kernel/kexec_handover.c
+++ b/kernel/kexec_handover.c
@@ -91,10 +91,12 @@ struct kho_serialization {
struct khoser_mem_chunk *preserved_mem_map;
};
-static void *xa_load_or_alloc(struct xarray *xa, unsigned long index, size_t sz)
+static void *xa_load_or_alloc(struct xarray *xa, unsigned long index, size_t sz,
+ bool *new)
{
void *elm, *res;
+ *new = false;
elm = xa_load(xa, index);
if (elm)
return elm;
@@ -112,6 +114,7 @@ static void *xa_load_or_alloc(struct xarray *xa, unsigned long index, size_t sz)
return res;
}
+ *new = true;
return elm;
}
@@ -146,15 +149,18 @@ static int __kho_preserve_order(struct kho_mem_track *track, unsigned long pfn,
struct kho_mem_phys_bits *bits;
struct kho_mem_phys *physxa;
const unsigned long pfn_high = pfn >> order;
+ bool new;
might_sleep();
- physxa = xa_load_or_alloc(&track->orders, order, sizeof(*physxa));
+ physxa = xa_load_or_alloc(&track->orders, order, sizeof(*physxa), &new);
if (IS_ERR(physxa))
return PTR_ERR(physxa);
+ if (new)
+ xa_init(&physxa->phys_bits);
bits = xa_load_or_alloc(&physxa->phys_bits, pfn_high / PRESERVE_BITS,
- sizeof(*bits));
+ sizeof(*bits), &new);
if (IS_ERR(bits))
return PTR_ERR(bits);
And if xa_destroy() is actually required, the allocation of new xarray
should be a helper function.
> bits = xa_load_or_alloc(&physxa->phys_bits, pfn_high / PRESERVE_BITS,
> sizeof(*bits));
> --
> 2.49.0.1101.gccaa498523-goog
--
Sincerely yours,
Mike.
next prev parent reply other threads:[~2025-05-18 15:51 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-18 14:23 [PATCH 0/2] KHO Fixes Changyuan Lyu
2025-05-18 14:23 ` [PATCH 1/2] memblock: show a warning if allocation in KHO scratch fails Changyuan Lyu
2025-05-18 16:07 ` Mike Rapoport
2025-05-21 7:03 ` Changyuan Lyu
2025-05-21 7:43 ` Mike Rapoport
2025-05-21 8:48 ` Oscar Salvador
2025-05-21 15:27 ` Mike Rapoport
2025-05-18 14:23 ` [PATCH 2/2] KHO: init new_physxa->phys_bits to fix lockdep Changyuan Lyu
2025-05-18 15:51 ` Mike Rapoport [this message]
2025-05-19 12:10 ` Pasha Tatashin
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=aCoB6KkQr4xFBlEu@kernel.org \
--to=rppt@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=bhe@redhat.com \
--cc=changyuanl@google.com \
--cc=chrisl@kernel.org \
--cc=graf@amazon.com \
--cc=jasonmiu@google.com \
--cc=kexec@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=pasha.tatashin@soleen.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.