From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f171.google.com (mail-pl1-f171.google.com [209.85.214.171]) (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 6A0843AF660 for ; Mon, 8 Jun 2026 21:35:02 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.171 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780954503; cv=none; b=D1dBRy36M32UMG7EF7T7QoWAU8cBt0sVW6t84RQSI8tVrfXmO9huRHFg8h1CDekxI1whe/fflip/+TB2unWMbIfPsxLvkWI7sEeQCicVX/iqNjVeseUrXX19byV7a9BWiinqnIMKmTdEOH2QmMDqF+FauFBFv3+FZ5c/RmvJDbo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780954503; c=relaxed/simple; bh=FADgUrimHtN+qEZsfk3vUT/NgVunEpha4jpRBuiDoYM=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=TayWGFqc+7RcLGcJvlma2pj6J6V8Od+q02sDnwpcA72lnV0B8wQn0qnCjP03/tpdD3NLWsjuW/E4jTucyOAXSjDctkpWNhiUc8tlHYk+3a/BvMsdbIjfbNaIwBrrgw8XBvcAGCdK4lhaGpEG6O76vFYVubJUWHTMswrCAC2KLVA= 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=UMmsSExK; arc=none smtp.client-ip=209.85.214.171 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="UMmsSExK" Received: by mail-pl1-f171.google.com with SMTP id d9443c01a7336-2c0c32f6ce1so32400085ad.2 for ; Mon, 08 Jun 2026 14:35:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1780954502; x=1781559302; 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=Mok13K1oI/5oKqM9t1zh4zoQDrWvB1QlqYCZOP0VV4Q=; b=UMmsSExKC3kF0ZY5LwxiZigzkAd+jd+HWct3x0m677Cb+Lpe6HCQv1i7z5609q2GiT KcXo2w52baFgfzRNg9utPHtxWpMMV+8qgOaLnpw/B1nTjVcUnN60IpSELPhRixEhv0A4 r0WLjSiETe4fTU2pwXEAbL6j1H+2IyQKlSKw+d650lTc0HoYIJP4/akpmG/e77ejvtwA +6ycFzQv3sawUifNXsNiCgT7wIklej49jg9JMBqc20+XcAUyDLlxKmE14SINvxGHRd6Q YlfAUcY/HmYYrbu01PK5QTj3zR5KI2qXHQianz0dwR73PUs1oo6Y6+6c+K2tjA4bXo/F /wng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1780954502; x=1781559302; 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=Mok13K1oI/5oKqM9t1zh4zoQDrWvB1QlqYCZOP0VV4Q=; b=iFW0bUN/yng+u/tKXQq6EwzQJyAbM0QRsdUuAHD7Z+SP8WjLJzTUnO0EWe+mYBnQZR wI/tUfLU5Tv+ngi/MVxbnMqYyLWlCB7kTUtzBCa3EdWNRlDOdkS3v+QQXu4e9WwJu9ip 3FOJYGoaFeJcVeTi5tOsb7OTT4NJCo9W487K2UdehcpZGlYZt0/pqWF0sT2iU9wurdv5 tfivifXgPwPDuyTVrDsM1VhwlQxnujvuzmABAr5KQXLqNM9RAzJdREhfPn0F4/GJutrN cXJRVdUwezkFJ2P80KSlFMN0a18xq/rO6XVOl0wV4XRUPsdMNyc5igEJSHlyO9/G1QC+ TQlw== X-Forwarded-Encrypted: i=1; AFNElJ+2+uPQJ4OWaxxOhIVYzMra9F2rfLEADAs8/u4FOD8cpDzuXQ0yQ1Rg3vQjExDF9CF99gwXTQpGALprOTM=@vger.kernel.org X-Gm-Message-State: AOJu0YwL2YScG5VY34ilBH7rm96OXeEbzrPRIVXH/jCvetOYFzPFvVz4 yzUNY6qFpD+1pr3Jru0WaLhhbQ0+qrEM+8+2Hj6rxyjR1iAAd+a+e/ALOyXXpwzSZQ== X-Gm-Gg: Acq92OHHRB2WebRjUMIEVcI5iPIhJueshVrrqYyLQYzAaXyJQN1wEOa89mYmjcL2EAM lEE26fjtqn/II/512z1b747iToebManbv9gTovrhvHi5t/DB49pvo1QOfDtWZ6ieSFBMKW4YFGH d6snkUrmBN/FYO6BPnkLN8ntQ5r2MI60c/QrZQsuOXjEhccnWGkLCHFFsrhx4vdkEPiqRrdvvA1 17ktJKfbgb/3OaSzYVAcvOkYe5oz4AA/49BFyoptzP+cz5BwYi972z0TRirjYnELaLfUdlDngLz UOpz4/aJe0QsWLahEVxNYcKQIcAtTvZ29JGcufODcLAp15bpTj7VmDxXSjghXVFD+pjQeZdxE48 TsKYL3Tog7MbZQRpTNuvZjDfTDsYhFnH+HRklD+/E1j0QZPu1cm1m77kgEGaXMYmPJcTdYnMkn0 z6KlLgutBPrKfIffCkrytP3CmWJAwjypCtA47JW2TXM9wOMzOC+2Jii1sxo+ZHN9K3oDxXYacW X-Received: by 2002:a17:903:2451:b0:2c0:d99a:2fc with SMTP id d9443c01a7336-2c1e78e4e7fmr195316255ad.2.1780954501183; Mon, 08 Jun 2026 14:35:01 -0700 (PDT) Received: from google.com (56.149.168.34.bc.googleusercontent.com. [34.168.149.56]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2c16609e05fsm197449205ad.54.2026.06.08.14.35.00 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 08 Jun 2026 14:35:00 -0700 (PDT) Date: Mon, 8 Jun 2026 21:34:57 +0000 From: David Matlack To: Pranjal Shrivastava 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 , Pasha Tatashin , Pratyush Yadav , Saeed Mahameed , Samiullah Khawaja , Shuah Khan , Vipin Sharma , William Tu , Yi Liu Subject: Re: [PATCH v6 06/12] PCI: liveupdate: Auto-preserve upstream bridges across Live Update Message-ID: References: <20260522202410.3104264-1-dmatlack@google.com> <20260522202410.3104264-7-dmatlack@google.com> 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: On 2026-06-06 10:15 PM, Pranjal Shrivastava wrote: > On Fri, May 22, 2026 at 08:24:04PM +0000, David Matlack wrote: > > When a PCI device is preserved across a Live Update, all of its upstream > > bridges up to the root port must also be preserved. This enables the PCI > > core and any drivers bound to the bridges to manage bridges correctly > > across a Live Update. > > > > Notably, this will be used in subsequent commits to ensure that > > preserved devices can continue performing memory transactions without a > > disruption or change in routing. > > > > To preserve bridges, the PCI core tracks the number of downstream > > devices preserved under each bridge using a reference count in struct > > pci_dev_ser. This allows a bridge to remain preserved until all its > > downstream preserved devices are unpreserved or finish their > > participation in the Live Update. > > > > Signed-off-by: David Matlack > > --- > > drivers/pci/liveupdate.c | 136 +++++++++++++++++++++++++++++++----- > > include/linux/kho/abi/pci.h | 5 +- > > 2 files changed, 122 insertions(+), 19 deletions(-) > > > > [...] > > > + > > +#define for_each_pci_dev_in_path(_d, _start, _end) \ > > + for ((_d) = (_start); (_d) != (_end); (_d) = (_d)->bus->self) > > + > > +static void __pci_liveupdate_unpreserve_path(struct pci_ser *ser, > > + struct pci_dev *start, > > + struct pci_dev *end) > > +{ > > + struct pci_dev *dev; > > + > > + for_each_pci_dev_in_path(dev, start, end) { > > + if (pci_liveupdate_unpreserve_device(ser, dev)) > > I might be reading this wrong but are we leaking some upstream devs if > an intermediate node fails? > > EP0 > / > Assume we have: RC -> B1 -> B2 > \ > EP1 > > and EP0 & EP1 were preserved successfully. > > And then we try unpreserving EP1, we follow: > > unpreserve EP1 -> unpreserve B2 failed due to a corruption. > > This aborts the loop, skipping B1 and RC completely? > Their refcounts remain elevated, effectively leaking them as preserved > state permanently? (i.e. if we unpreserve EP0 after this, B1 & RC will > still get preserved). Yes, but that would only happen if there is some sort of kernel bug or silent data corruption. I guess we could proceed with trying to unpreserve the bridges upstream. But I opted to log a big warning and bail immediately. pci_liveupdate_finish_path() has the same behavior BTW. > > > + return; > > + } > > +} > > + > > +static void pci_liveupdate_unpreserve_path(struct pci_ser *ser, > > + struct pci_dev *start) > > +{ > > + __pci_liveupdate_unpreserve_path(ser, start, /*end=*/NULL); > > +} > > + > > +static int pci_liveupdate_preserve_path(struct pci_ser *ser, > > + struct pci_dev *start) > > +{ > > + struct pci_dev *dev; > > + int ret; > > + > > + for_each_pci_dev_in_path(dev, start, NULL) { > > + ret = pci_liveupdate_preserve_device(ser, dev); > > + if (ret) { > > + __pci_liveupdate_unpreserve_path(ser, start, dev); > > + return ret; > > + } > > + } > > + > > + return 0; > > +} > > + > > /** > > * pci_liveupdate_preserve() - Preserve a PCI device across Live Update > > * @dev: The PCI device to preserve. > > @@ -321,6 +403,9 @@ static int pci_liveupdate_preserve_device(struct pci_ser *ser, struct pci_dev *d > > * pci_liveupdate_preserve() from their struct liveupdate_file_handler > > * preserve() callback to ensure the outgoing struct pci_ser is already set up. > > * > > + * pci_liveupdate_preserve() automatically preserves all bridges upstream of > > + * @dev. > > + * > > * Returns: 0 on success, <0 on failure. > > */ > > int pci_liveupdate_preserve(struct pci_dev *dev) > > @@ -336,7 +421,7 @@ int pci_liveupdate_preserve(struct pci_dev *dev) > > if (IS_ERR(ser)) > > return PTR_ERR(ser); > > > > - return pci_liveupdate_preserve_device(ser, dev); > > + return pci_liveupdate_preserve_path(ser, dev); > > Minor nit: I might be too nitpicky here (and it's NOT a strong opinion) > but naming it pci_liveupdate_preserve_path_for_dev() reads better to me. Noted :). I'll keep the current name for now since that is pretty long, but if anyone else votes for it I'm happy to be overridden. > > } > > EXPORT_SYMBOL_GPL(pci_liveupdate_preserve); > > > > [...] > > Thanks, > Praan