From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pf1-f175.google.com (mail-pf1-f175.google.com [209.85.210.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 11FDA3ACEEB for ; Mon, 15 Jun 2026 20:29:07 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.175 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781555349; cv=none; b=gdyXjRbIAXMqpqXZ5w61S9LZoeuXvENXTRkelYAk4Y6OU43G/NrQUKuvHpXPvY5TAW6uCPD33ShfiVty0krXmCKQRUmUrx3I8V0S9z4gzDZmtctROroSrtkFO9utR00ASAN7m0kSxkIjZusKzsmJqsXE+QT/KCIRve80xavQX4A= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781555349; c=relaxed/simple; bh=MZP5jsTbH3zCF15JCNmbPOVPmIbEoMMWjjli0bis5Uo=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=pz3CN4fjMC14wLSCQsnDdw0vOcbQLkBSXipUIeH5hND7YVFYFJFddc2dZZotEGYN7n8uF+A3e1WeH1nJwokeXQhXO1YgT7oTqzCuC9MLLJ5J+lnLQZ1J9hxXrchgNhnGf6N5c1YT80GXvfDb7/F9eAufK6rtzAETPIv8dgAuDEM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=mGEtl5oV; arc=none smtp.client-ip=209.85.210.175 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="mGEtl5oV" Received: by mail-pf1-f175.google.com with SMTP id d2e1a72fcca58-842d37438d8so1479697b3a.0 for ; Mon, 15 Jun 2026 13:29:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1781555347; x=1782160147; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=6tMpN87VW6G86K/AtehrHKHoQYLtgbv5+V4AdiXXmO0=; b=mGEtl5oVj7s0B+gAHjFDHSSTBMUBtEimCD4gFk5ceH6MTScffwq8MlcjPkAr7HwpCn lToUmP6Vg1zI65O2hxA3lq8Bq5qZ71zMRPTWL4lJUem/tLLez2wqd6R+E0eirW36yVvp RINY2l59nCD2fy26f0RX9p4nQ7R+YLU0ACjVRQg5jdJR0yrA1DXzVHA5EV0iLSwkU1cS KlMOxjpfueE1CdyjsvEDsy+kQVgh2+vVISrDjs3wFkjHUYnkiWYfcxnRirf38u5Js2on XRAjQ6B245Y7V76DoRvtW7DecD4aZiHJIFBfvBrw7qVS4kTDw1foKstHnjOXZgtajE+O K/eg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1781555347; x=1782160147; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=6tMpN87VW6G86K/AtehrHKHoQYLtgbv5+V4AdiXXmO0=; b=HokmntdugmrTj4hJUfUBZI7EFId/v2GvBVt7BQvx9z3hugNEyR7JwP5eye1i4+lc3A k6R84JaqivEW4iU/QOfUD1bHcHFIB30EmZMi0UqQU0kMGOmX6tQJnVCmXS5rT1oo5ylb wEjIZYHt4UKki83ypi2Dtlz/zS/d3hezcUxm/+RIYvzgaCxIbyaxOrW8hjtbnMJAQTKr 4cY7WcUq7ypNtNwE7wKz62CLBDIhx62WG4t/r9pM/p0GdsYlVax+CTDvZe9hhIzbfO4B JY4rLYgh+izrs9RE4SnkWk/j36AByYGFGziEqMDEIvQ4/rBfd0VTYly632q1F10qBrfN a4Vw== X-Forwarded-Encrypted: i=1; AFNElJ8qN0147FDF6Y3jZ0sZSzPOr82EVw+u2S9gNCVWk/lza3BgLLEcB/T1k6QkAOoiFiF5wFG8wyihLPh0dMI=@vger.kernel.org X-Gm-Message-State: AOJu0YzK6sgPi5Rp8ibMJN9JSByKWsnLJ3yKzQRk7KFK5s+By/mFJaGT T6rEACpGNhogD2hB+UOgfGtsAWHkbC3XP1KJC6M54oBjh1fx59l6G/5kE3dCs8ZvZ3meLbge5Ut si1XrsizV X-Gm-Gg: Acq92OFvQU0hGqZ2QPBrXuUTEF/w2QNGmWseINnyq/y9I8QLku8cvSMZVssbHaK+r2W oQUpuSgTYtk2MsfLiT+EPAkUAVGSxaVZsozd+qvDYbhcZZmnF6fpy4MEDWi/zEdhabM8SLP/kia R1tuDlCtTPuH9MjArjLXlkxOp41okWsl2NuaruItk55OIouYkoZvvP1xfpsFSvZxdUyQ7GbdX/e bWvSg9wet4PkGAB1L0A6gd4oQW0Rnj911oEpxJIddLyICvaPNowsW1Z0ZQ4zQtSnvVJnyCtBZQp lh6FYm/4RbI89+lrYOG2m1bRK37GfB+/Q84V1JPdzEfEsf9sYs6GR6n40PMOIq250aWvF5Ffrx/ bMgr1b5cxeL4gYiTM/hHdNiXH01X61ld6ZvtRCWndkuhDuxzeJFrxJLI8ghaxCr1J0wr3u4FZnl cYG7JHalVtM5wkKMOO76cCgY8mA3t6Pk7lSKYr0uW2dRU72SZilU41iOzOVC/Phw== X-Received: by 2002:a05:6a00:2d01:b0:842:380a:1ee8 with SMTP id d2e1a72fcca58-8451530e10amr465722b3a.17.1781555346795; Mon, 15 Jun 2026 13:29:06 -0700 (PDT) Received: from google.com (56.149.168.34.bc.googleusercontent.com. [34.168.149.56]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-8434afc8a84sm12817496b3a.38.2026.06.15.13.29.06 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 15 Jun 2026 13:29:06 -0700 (PDT) Date: Mon, 15 Jun 2026 20:29:03 +0000 From: David Matlack To: Pasha Tatashin Cc: kexec@lists.infradead.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-pci@vger.kernel.org, Adithya Jayachandran , Alexander Graf , Alex Williamson , Bjorn Helgaas , Chris Li , David Rientjes , Jacob Pan , Jason Gunthorpe , Jonathan Corbet , Josh Hilke , Leon Romanovsky , Lukas Wunner , Mike Rapoport , Parav Pandit , Pranjal Shrivastava , Pratyush Yadav , Saeed Mahameed , Samiullah Khawaja , Shuah Khan , Vipin Sharma , William Tu , Yi Liu Subject: Re: [PATCH v6 03/12] PCI: liveupdate: Track incoming preserved PCI devices Message-ID: References: <20260522202410.3104264-1-dmatlack@google.com> <20260522202410.3104264-4-dmatlack@google.com> <178144432039.1257322.9644414453415904478.b4-review@b4> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <178144432039.1257322.9644414453415904478.b4-review@b4> On 2026-06-14 01:38 PM, Pasha Tatashin wrote: > On Fri, 22 May 2026 20:24:01 +0000, David Matlack wrote: > > diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig > > index 10c9b65aa242..e68ae5c172d4 100644 > > --- a/drivers/pci/Kconfig > > +++ b/drivers/pci/Kconfig > > @@ -330,7 +330,7 @@ config VGA_ARB_MAX_GPUS > > > > config PCI_LIVEUPDATE > > bool "PCI Live Update Support" > > - depends on PCI && LIVEUPDATE > > + depends on PCI && LIVEUPDATE && 64BIT > > Please move this to the first patch, fewer changes between patches, and > also KHO does not support anything but 64-bit mode. I think it is preferred to introduce changes when they are needed. This is the exact patch that requires 64BIT so it makes sense to add the dependency within this patch no? > > > > > diff --git a/drivers/pci/liveupdate.c b/drivers/pci/liveupdate.c > > index 065d5af822f7..96c43b84532c 100644 > > --- a/drivers/pci/liveupdate.c > > +++ b/drivers/pci/liveupdate.c > > @@ -128,13 +157,49 @@ static void pci_flb_unpreserve(struct liveupdate_flb_op_args *args) > > [ ... skip 31 lines ... ] > > + > > +err_xa_destroy: > > + xa_destroy(&incoming->xa); > > + kfree(incoming); > > +err_restore_free: > > + kho_restore_free(ser); > > This is the pattern we have been enforcing in other places in LUO. If > the first retrieval fails, return the same error thereafter. > > > @@ -270,6 +335,91 @@ void pci_liveupdate_unpreserve(struct pci_dev *dev) > > } > > EXPORT_SYMBOL_GPL(pci_liveupdate_unpreserve); > > > > +static struct pci_flb_incoming *pci_liveupdate_flb_get_incoming(void) > > +{ > > + struct pci_flb_incoming *incoming = NULL; > > + int ret; > > Maybe make the error return static, and avoid another search through compatible > FLBs if it failed before? Good idea, will do. > > 1. Add "saved_err;"; if it is set, return it right away. > 2. Change all errors to use goto save_err;, and at the end of the > function, assign ret to saved_err; > > > [ ... skip 15 lines ... ] > > + * This could mean that no PCI FLB data was passed by the previous > > + * kernel, but it could also mean the previous kernel used a different > > + * compatibility string (i.e. a different ABI). > > + */ > > + if (ret == -ENOENT) { > > + pr_info_once("No incoming FLB matched %s\n", pci_liveupdate_flb.compatible); > > I would assume this is very normal, e.g., no devices were preserved but > memfd+hugetlb was preserved. Maybe use pr_debug_once(). The problem is described in the comment above. The PCI core cannot distinguish between: 1. There was not PCI FLB preserved. and 2. There was PCI FLB preserved, but it was not compatible. I agree we should not log anything for (1) but (2) definitely requires at least some kind of logging so that's why I went with info-level here and not debug. > > > + return NULL; > > + } > > + > > + /* > > + * There is incoming FLB data that matches pci_liveupdate_flb.compatible > > + * but it cannot be retrieved. > > + */ > > + if (ret) { > > + WARN_ONCE(ret, "Failed to retrieve incoming FLB data\n"); > > No need to print backtrace, please just print a warning: > pr_warn_once("Failed to retrieve incoming FLB data: %pe\n", ERR_PTR(ret)); SGTM > > > [ ... skip 34 lines ... ] > > + * through pci_liveupdate_finish(). This can happen if PCI core probes > > + * the same device multiple times, e.g. due to hotplug. > > + */ > > + if (!dev_ser->refcount) { > > + pci_liveupdate_flb_put_incoming(); > > + return; > > Pleaes use 'goto put_incoming' SGTM. > > > + } > > + > > + pci_info(dev, "Device was preserved by previous kernel across Live Update\n"); > > + dev->liveupdate.incoming = dev_ser; > > + > > + /* > > + * Hold the ref on the incoming FLB until pci_liveupdate_finish() so > > + * that dev->liveupdate.incoming does not get freed while it is in use. > > + */ > > How would that work? If finish is not called FLB stays around until the > next reboot. True... I think if the PCI core trusts drivers to call pci_liveupdate_finish() then we don't need to hold onto the incoming reference here. > > -- > Pasha Tatashin