From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9E94DC2D0CD for ; Mon, 19 May 2025 12:10:48 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id BBC6E6B0095; Mon, 19 May 2025 08:10:45 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B677C6B00CD; Mon, 19 May 2025 08:10:45 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A0BB36B00D5; Mon, 19 May 2025 08:10:45 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 771426B0095 for ; Mon, 19 May 2025 08:10:45 -0400 (EDT) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 7C8E11CA162 for ; Mon, 19 May 2025 12:10:47 +0000 (UTC) X-FDA: 83459540934.12.2B8209F Received: from mail-qk1-f177.google.com (mail-qk1-f177.google.com [209.85.222.177]) by imf25.hostedemail.com (Postfix) with ESMTP id 81FFFA0005 for ; Mon, 19 May 2025 12:10:45 +0000 (UTC) Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=soleen-com.20230601.gappssmtp.com header.s=20230601 header.b=f+XjjS2r; spf=pass (imf25.hostedemail.com: domain of pasha.tatashin@soleen.com designates 209.85.222.177 as permitted sender) smtp.mailfrom=pasha.tatashin@soleen.com; dmarc=pass (policy=none) header.from=soleen.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1747656645; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=sxj5tV4ZjtLTjypVmyMI86S9Wm14CRi4YEthyQjDYJE=; b=ZVoyOwBlpYaF6zAKf2eGCA44o69TBZlHh0tRTBPQ4p83GX8LezJXCDsWanfvZS4NB/Grud O0Zzm+LzHdKcpGPjSxkX/KLAExRBVHwTWRPBRqG0nNluep+HPQaLs+BesQUinBroXxczAf DK0iM/qDJfuiWXnWVVE6cI5nSZxPZIs= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=pass header.d=soleen-com.20230601.gappssmtp.com header.s=20230601 header.b=f+XjjS2r; spf=pass (imf25.hostedemail.com: domain of pasha.tatashin@soleen.com designates 209.85.222.177 as permitted sender) smtp.mailfrom=pasha.tatashin@soleen.com; dmarc=pass (policy=none) header.from=soleen.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1747656645; a=rsa-sha256; cv=none; b=f5lDCkI/nuG5etzxQWX7iNTvQ24givJugKB1zAwxeqMiRsPTH0KGNy7v/h4iR37PNvuuEj 2oYLDMRm6kRRvWMb/bRU3SBCMLJ/UAI2I0WWO/YbO3Ga+Xv1KoQPxiID8wTSZw8Qn74Enq P7BK8cP6c52JeJ1lq5Z9VFfofX28jxg= Received: by mail-qk1-f177.google.com with SMTP id af79cd13be357-7c559b3eb0bso277891685a.1 for ; Mon, 19 May 2025 05:10:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=soleen-com.20230601.gappssmtp.com; s=20230601; t=1747656644; x=1748261444; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=sxj5tV4ZjtLTjypVmyMI86S9Wm14CRi4YEthyQjDYJE=; b=f+XjjS2rXPCmJHZeQjHZkogFIVrC0Xf5XUF6a1C+yhW0gNinlOtCS3/cPPSY0VR/Yz iPUF739RYzUraD2x7z4tWbJeFppjT2aiETgAFtT2AyUNSwKg7dPikV5WEJ6MUcm+WFVe ULoWhgLj5lONDJWHr5VDaU/+xr5TFOUFY3CL8pWlzfhCm1m0WDqkbjH8j156ENU01OwH biVR5T3hm6jlx0UNROxnX+WDdpxOykN+7PiAm4pKRYpD4cUYOkmFYonzSB6rFFqumyHV khbseNuQvQzgbnfSHCciLO/bF5fRbBGhG758du9AleoZ8fCd9Q/r/yqhkjvPIi5DgUiy BjpQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1747656644; x=1748261444; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=sxj5tV4ZjtLTjypVmyMI86S9Wm14CRi4YEthyQjDYJE=; b=J8BOueDy2kMlCuYpKz7twdNZBiGpefqjq5LWqd+3Qome+HdIvD+1TMUaG+SnALmIBW HuoBP4MLx4WyUswFXJm59AXd4ul5VkT+/nCrfK73s0M7XsZgvmh4cQH82W+I49zXAwFa Qyny1XZora0JiJm01gbJazsl/ALfEdTUSycxUwRXJOUHschxWDG8HUT/pE6KJVu5ZCAl emwMNdtL8zWNS/yttjKyOsAxU5+O8wc+ZySHSFGd9XgQY8nh0Ibb7GD1XMn0UaHDij5A NSAqpozmt3VBXRQIFxriUVB3CaaOOnA1GJoCuExUu1zNwK8T3lj0g4cvf5OaTcBeG60o EGMg== X-Forwarded-Encrypted: i=1; AJvYcCVy7va0YNbw4dMYD9ZMFkNFsKbTgpw8LLzosGE15xNOBAZMISmGqGXLZUKgv9a1cP2r+uYET0DwkA==@kvack.org X-Gm-Message-State: AOJu0YyjfuKpABkka5AuerWgt806kOOtTDgv96xM+v+GRpLvnzMIVCoh qw0ihGYcVF+kiJwcNEWd1/0k5hNGGtTFlFbFINzuBA/aRUmbR03IlgHXg/PvSj5vI8iLO4eMbbc fhuLtuigKRILROKfSyY+watR8cOBfPD9lIU6urQFiyN/jpjc/9iqa7Oo= X-Gm-Gg: ASbGnctexgvGVlSUTaD/eSJcMknzAEUChC+WcRZVMPscf545928/yI1KIUJqqhw14If i4Sk7KX1nO94RGTHxsrL4BKgi86cTiliN6dizKDZ1poiFsL9yNkga9BxzMyYBSimrdNbnP6tZFI UsV8XJTUpzvKGJosnKVSXZCpNJTaAGMw== X-Google-Smtp-Source: AGHT+IHFVZaN/KoXQKmix7VBW6TAlcDBvQWjHHP9O9i0WPdPw4x+eCBlpXYOmcHm5M0gwFeXPJdS+ox//5pK2zRXTgs= X-Received: by 2002:a05:622a:1b10:b0:48a:d21f:4ea with SMTP id d75a77b69052e-494ae377aadmr250581171cf.13.1747656644392; Mon, 19 May 2025 05:10:44 -0700 (PDT) MIME-Version: 1.0 References: <20250518142315.241670-1-changyuanl@google.com> <20250518142315.241670-3-changyuanl@google.com> In-Reply-To: From: Pasha Tatashin Date: Mon, 19 May 2025 08:10:07 -0400 X-Gm-Features: AX0GCFvC73OzkVuPTBSZiZm6D6fkjt14tbJiCBHbeRPZlSwcNy9mM8PHVLc8h78 Message-ID: Subject: Re: [PATCH 2/2] KHO: init new_physxa->phys_bits to fix lockdep To: Mike Rapoport Cc: Changyuan Lyu , 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, jasonmiu@google.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 81FFFA0005 X-Rspam-User: X-Rspamd-Server: rspam11 X-Stat-Signature: gk6ofred6fpb53gqbbjup6zwib3pgsyi X-HE-Tag: 1747656645-677058 X-HE-Meta: U2FsdGVkX1+FSY9F2ZYfhMuI4qbLRIsqqRrpmZqx33A8RsZQwsZlH5cxIWp4MTlPwHEhi71Evo8P+aPk5A+1Kq2bfC8Ynbr8ihJorh4fTKa+6zwEoOsb3CZ7vrO/KK4AS/3n8U9IG2bssG39f6erzfGMR54ko1VSZ//5KZbJNRgbvns80PPvz3+Rl53tM6p/NPQcc3fAz8d/RaZTvzFUg0MfroSSsOF5+TzExnAvpfoMlHH0xNgL1BnAhYfo3hckcQsHSbXj+nrcQv88/2klJ8ItTl5iR2eylIB7Fc+tzc5pA3Voe5tQQruQWPOV3GEJwjYPJ9qXfXT2V2w2AjwuqOcknorVKfuIaaSd39PgBGEEb2VVzmDNxEp0DzOGhwAo+PSjpLFvuLaG3XOvvf6wnbALMxe7G2pElyxUlKdZ8HL5jan4jFD1N6tnS2OGsqZMSDfWWXBU6ATJxkrHlW7l9Yww/r5HJ1fGAcZ43l5LzR/XHySs9WahTnZlVMNLfwzcUihDnY8r3zq96tsSlrjc64fwmBsjVae/lHknlOUL9hXWCbIP0nLByOloOs8nRXecCgaMb7mWXW2mrELXBfs7mCiQ9I0cMSq4XrNfKTrx4C5Vp5nxNMmb1VURksqzrc83lmNndpzjopqUJlCZ0O1U0fiEeKM5Fun+wKlQ+zn/B3WzgClnqbM+DtKfYXDNZFwtADYjgBEA77X6tJEQGvPiP+qbOUwQh5k3nsHIJ+R5YMdA/jfzT6jjD1aq6anU/3q7jU/xMomdzEuHWpdskWAvkHyQEUWsGs7F2vzcZJGE3L2MX8CK6LwpBtVvauPlBgVo4bD2+RE7gWpLRlf1EvdQQ78alO4QXTv3SBhfqAFt2IstLJIrYcjDjCSRuSb7ajdqZQLlU5LiBLhK8VXPiLs5YXgEzhmFXc4Sz1Kr8srGVgQOHLsZQjFmF/OO/JvVhx5NPX169YHkwJnqeQSpBbJ Q9SnV5jZ aBiIFAM1sUWTP4REXWN7pM6/ABB1KpLDR92TQErw3Un29IPBTey0z6lj0Fw1Oj7zCSVqy+SCOe+tgQ+t5kFbvHarnzalW3FQ1f+4Fi8xkB+RFNb/M5sJDCLSrgMknRSwxymmvrZZlI9dkkNXVBVMdLTfR9dYogCFg020kYm0+kMsynfjMzL3bJUyPC78/j0AxUSa6z+C7GBiCqFAP9EvdqC4Ho8r46Jtp/JiOD6HlgffqjBisr9r041Q2PeIwQnqsOJfbCOfajDVs1xf9bu2CEiL7q7n2wQcob9vemlJAMd0B5abEZsUiIXlxFKvr1fZYdQqBgWyCbY5Wz/5Bkf5QhHgOvw0BeFc5qaYPyBlcWC2MMAtwsD7HbB92FTkxEInr0rjy8KOY0AK00LW/Zdr/CybIPw== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Sun, May 18, 2025 at 11:51=E2=80=AFAM Mike Rapoport wr= ote: > > On Sun, May 18, 2025 at 07:23:15AM -0700, Changyuan Lyu wrote: > > From: Pasha Tatashin > > > > 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. > > > > [] dump_stack_lvl+0x66/0xa0 > > [] assign_lock_key+0x10c/0x120 > > [] register_lock_class+0xf4/0x2f0 > > [] __lock_acquire+0x7f/0x2c40 > > [] ? __pfx_hlock_conflict+0x10/0x10 > > [] ? native_flush_tlb_global+0x8e/0xa0 > > [] ? __flush_tlb_all+0x4e/0xa0 > > [] ? __kernel_map_pages+0x112/0x140 > > [] ? xa_load_or_alloc+0x67/0xe0 > > [] lock_acquire+0xe6/0x280 > > [] ? xa_load_or_alloc+0x67/0xe0 > > [] _raw_spin_lock+0x30/0x40 > > [] ? xa_load_or_alloc+0x67/0xe0 > > [] xa_load_or_alloc+0x67/0xe0 > > [] kho_preserve_folio+0x90/0x100 > > [] __kho_finalize+0xcf/0x400 > > [] 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 > > Signed-off-by: Changyuan Lyu > > --- > > 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_tr= ack *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 =3D pfn >> order; > > > > might_sleep(); > > > > - physxa =3D xa_load_or_alloc(&track->orders, order, sizeof(*physxa= )); > > - if (IS_ERR(physxa)) > > - return PTR_ERR(physxa); > > + physxa =3D xa_load(&track->orders, order); > > + if (!physxa) { > > + new_physxa =3D kzalloc(sizeof(*physxa), GFP_KERNEL); > > + if (!new_physxa) > > + return -ENOMEM; > > + > > + xa_init(&new_physxa->phys_bits); > > + physxa =3D xa_cmpxchg(&track->orders, order, NULL, new_ph= ysxa, > > + GFP_KERNEL); > > + if (xa_is_err(physxa)) { > > + int err_ret =3D 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 =3D 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: I wanted to do proper xa_destroy(), as the whole point of this patch is to satisfy lockdep, and do a proper xa_init(). The patch fixes a warning in linux-next, and I think should be taken as is. We can do a separate clean-up once the series lands, where xa_load_or_alloc() could either take another argument, or split into two functions. Pasha