From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pg1-f170.google.com (mail-pg1-f170.google.com [209.85.215.170]) (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 B2DDB34DCFF for ; Wed, 25 Mar 2026 20:06:53 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.215.170 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774469214; cv=none; b=avI/P8BOcZgXtwZYhR8G7ez3BXShsbPXr5WOsTh2oM9PIQhUaukvM/ytMv6vO35OvWlPwo5jyDVd5jlnxPyOGC23ceZ4/U/axb59naNDss70DlSY8/Zx9K/G6A5eg0TfdBEOq1PI6MWa6l1TzoMCiD0SrWncZpb+YcNzF5qzrdQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774469214; c=relaxed/simple; bh=QWkkdA+pFF8rjilsaUm1i/vpWu+c/k23cgJdC8WUDOw=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=VeV0962gHrcRXsRWYvMuhW+38SFLml+zG/CEhDhsSEHLK0DDigOdyCvs+YrHfbn3A0eR9uYJF0HMX1F0pqp3u5svAjqwTupqwx1e6I2FvuH0MBlwqDiBP53PR4jRQ606ZXOhC0alC1hZxu6LrmnmStY3lyfbROVJ3kCC2puCtAM= 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=XOmpIf3w; arc=none smtp.client-ip=209.85.215.170 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="XOmpIf3w" Received: by mail-pg1-f170.google.com with SMTP id 41be03b00d2f7-c742723c863so183687a12.0 for ; Wed, 25 Mar 2026 13:06:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1774469213; x=1775074013; 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=+fZRp4AJi5cb/F6jA80ZrndPdXYxEQL1IK9u8/P+m9k=; b=XOmpIf3wx3OAbYuBhazQbr1ZVOYiuW+8XsO0/K8RYWS3pqy/6NzSJ5O/zdVru6DhcX TN6TGjZnxbzAHb449USGJQVZniTerw0en2lgBy3FjoXYn0yAjHyngXhNjCR82oB3iiht gfGhIRTHxeS9ZrUjf6Lr+jDGi5pJA//Jg1aa6+rgnMwl0FD0kx++MMoKWg6pjEvs4ES5 FwzwIixpP2SiehviX4OWfOpTkR2ae0/WarXcOTsbL/obTaljzRiwBU9Oh5K9PunnEmBi wgLr3NLM5/3w6YM131plNM2nDc2A7DgzxLS+xfohjZ4x8siHv+E7wnBG6STMqu4yfXsp PYzg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1774469213; x=1775074013; 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=+fZRp4AJi5cb/F6jA80ZrndPdXYxEQL1IK9u8/P+m9k=; b=M9KpAshlovAHsz2yeqaiTy1F3L618JGVGbGcmegoXxNBbTXM6h1GAzXOjBaTCNiZsi +r6Ht7kNRLNEXB/UYvrnGuZkS/Wgpm/FysrPAUBEdDGOZjWWk+heqCdQhyl1Lv9jmbgB wUfMIv99RWnYB0UjaJkOcvk9qNOZ8epIydK6N4mBl8UZ9/+yiJA/IUasAuJkFkVhgbDE JwJr3zADHeK9W9fCpY7ne+J+H9DoLjJGj853j2ifcct25NT11me7VKWPGZpO5WZQZ5ly a7SME5Onf/zRHwJPg0GL7l5RSEWABgUvRo9enjlZoxaLZjV22DKgG8kKkfVMXGZkAKoR 0L6g== X-Forwarded-Encrypted: i=1; AJvYcCXM7GUN9XLG09qhz/E+bx7IEJfv74TXkrwlt/qbTyopb+tuiccc6TICrUjMYKF6/2GGAdWKkm8RyHA=@vger.kernel.org X-Gm-Message-State: AOJu0YxQ+bD4tV01ikyts2UByPXihnP+lUSSKrwxReB/Dk+P6LGmmwk3 F94cRZjgyIHyVnbEmcsxTvpQBgVwSqKs+AQK6Usp01K/f4SdlQK6fEKRkdxjLxnxNA== X-Gm-Gg: ATEYQzyaCuT4m6FpbAbRUEDZCjqTJBaJk83cbGBHEvKv5vz0FLrKCkCbSl02mSem4Wz /vI8eZeXFi1PyaFiAdHgReYqaHS3vEC+PGQ1b7U5HI+grp5fnWpccWQRElX3qA3cTnbV6oz8EhA UidZY6BXU9LpfIYs+isrGmBPByrJ99C0GhSgA8wne4o3SLRZxp+XnaAM4qAzyGWfts0o/WHlrl3 YJx/sX/J06UQ39HHFAXp76h76Y/oiLpfsz6GW6VcLfq1b/vms40OgGYBun3kRXRMf9rGgGrPHkQ oDT4LIB3xbs/bVjScUAfLm/FpIy8nRLq7+2u6imNP1mZADNTYF1RncyZ2kUSlxPIvBjXiWBYdOy KPymabFDTlGMJ/tbDXjBvfwdDR8jdxqVKgHvOMsTfrj8hieF2yhoDNhJiGcRAESadE/YcoXrjXe hjrONOBTaNAUGFSW03RdYnF13hJyInund7tEEfkct0HLiovX7gYIO2nPlxujzajQ== X-Received: by 2002:a05:6a20:8ca6:b0:398:b3bd:de58 with SMTP id adf61e73a8af0-39c4aed5082mr3746836637.65.1774469212632; Wed, 25 Mar 2026 13:06:52 -0700 (PDT) Received: from google.com (239.23.105.34.bc.googleusercontent.com. [34.105.23.239]) by smtp.gmail.com with ESMTPSA id 41be03b00d2f7-c7673819da1sm305751a12.11.2026.03.25.13.06.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 25 Mar 2026 13:06:51 -0700 (PDT) Date: Wed, 25 Mar 2026 20:06:47 +0000 From: David Matlack To: Alex Williamson , Bjorn Helgaas Cc: Adithya Jayachandran , Alexander Graf , Alex Mastro , Andrew Morton , Ankit Agrawal , Arnd Bergmann , Askar Safin , "Borislav Petkov (AMD)" , Chris Li , Dapeng Mi , David Rientjes , Feng Tang , Jacob Pan , Jason Gunthorpe , Jason Gunthorpe , Jonathan Corbet , Josh Hilke , Kees Cook , Kevin Tian , kexec@lists.infradead.org, kvm@vger.kernel.org, Leon Romanovsky , Leon Romanovsky , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, linux-mm@kvack.org, linux-pci@vger.kernel.org, Li RongQing , Lukas Wunner , Marco Elver , =?utf-8?Q?Micha=C5=82?= Winiarski , Mike Rapoport , Parav Pandit , Pasha Tatashin , "Paul E. McKenney" , Pawan Gupta , "Peter Zijlstra (Intel)" , Pranjal Shrivastava , Pratyush Yadav , Raghavendra Rao Ananta , Randy Dunlap , Rodrigo Vivi , Saeed Mahameed , Samiullah Khawaja , Shuah Khan , Vipin Sharma , Vivek Kasireddy , William Tu , Yi Liu , Zhu Yanjun Subject: Re: [PATCH v3 02/24] PCI: Add API to track PCI devices preserved across Live Update Message-ID: References: <20260323235817.1960573-1-dmatlack@google.com> <20260323235817.1960573-3-dmatlack@google.com> Precedence: bulk X-Mailing-List: linux-doc@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: <20260323235817.1960573-3-dmatlack@google.com> On 2026-03-23 11:57 PM, David Matlack wrote: > +static void pci_flb_finish(struct liveupdate_flb_op_args *args) > +{ > + kho_restore_free(args->obj); > +} > + > +static struct liveupdate_flb_ops pci_liveupdate_flb_ops = { > + .preserve = pci_flb_preserve, > + .unpreserve = pci_flb_unpreserve, > + .retrieve = pci_flb_retrieve, > + .finish = pci_flb_finish, > + .owner = THIS_MODULE, > +}; ... > +static int pci_liveupdate_flb_get_incoming(struct pci_ser **serp) > +{ > + int ret; > + > + ret = liveupdate_flb_get_incoming(&pci_liveupdate_flb, (void **)serp); > + > + /* Live Update is not enabled. */ > + if (ret == -EOPNOTSUPP) > + return ret; > + > + /* Live Update is enabled, but there is no incoming FLB data. */ > + if (ret == -ENODATA) > + return ret; > + > + /* > + * Live Update is enabled and there is incoming FLB data, but none of it > + * matches pci_liveupdate_flb.compatible. > + * > + * 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). The latter deserves at > + * least a WARN_ON_ONCE() but it cannot be distinguished from the > + * former. > + */ > + if (ret == -ENOENT) { > + pr_info_once("PCI: No incoming FLB data detected during Live Update"); > + return ret; > + } > + > + /* > + * There is incoming FLB data that matches pci_liveupdate_flb.compatible > + * but it cannot be retrieved. Proceed with standard initialization as > + * if there was not incoming PCI FLB data. > + */ > + WARN_ONCE(ret, "PCI: Failed to retrieve incoming FLB data during Live Update"); > + return ret; > +} > + > +u32 pci_liveupdate_incoming_nr_devices(void) > +{ > + struct pci_ser *ser; > + > + if (pci_liveupdate_flb_get_incoming(&ser)) > + return 0; > + > + return ser->nr_devices; > +} > + > +void pci_liveupdate_setup_device(struct pci_dev *dev) > +{ > + struct pci_ser *ser; > + > + if (pci_liveupdate_flb_get_incoming(&ser)) > + return; > + > + if (!pci_ser_find(ser, dev)) > + return; > + > + dev->liveupdate_incoming = true; > +} There is an inerent race between callers of liveupdate_flb_get_incoming() and liveupdate_flb_ops.finish(). There is no way for callers to protect themselves against the finish() callback running and freeing the incoming FLB after liveupdate_flb_get_incoming() returns. Sashiko flagged this as well [1]. After some off list discussion with Pasha and Sami, the proposal to fix this is to have liveupdate_flb_get_incoming() increment the reference count on the incoming FLB. We will add a liveupdate_flb_put_incoming() to drop the reference when the caller is done using the incoming FLB. I plan to include a patch for this in v4. [1] https://sashiko.dev/#/patchset/20260323235817.1960573-1-dmatlack%40google.com?patch=7974