From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f170.google.com (mail-pl1-f170.google.com [209.85.214.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 6894A39D6DE for ; Thu, 30 Apr 2026 18:25:23 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.170 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777573525; cv=none; b=gyn6CTm0hAEw3oC+2HvaLTFzERJm0HMH3HCwAg/TUPcFUlwpbvWxjaDFP76V6lM8hBKZM0yXc/aWFsDbWID3oY41GWAh3xJPv84z2GlBOge8bvwZ6afpV52ud1VoMiy9r2Qux21K5E8lXWfZMU15CieHrZbIMSzdjiMX+QyxsAY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777573525; c=relaxed/simple; bh=ZDryYlw3wmD6yJlXYdxSZE6y0ltm6/Y3efuvn9gp+xo=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=VQHbXsCxWZ0T/Vzf+l2yOOvtNc6hB7U3BUUyFMTWghieVV5FhmhC0GYT3XQOPuxJ9ctu5jCMsBFos0iFE4zrzAB2jA82RRpplrt6WWCv2Mx/W5+6Y5XnrWWJ39qmiqcXpOSn0EvoheCW0VFd7uLUQwXWdcEbroXHxR+dNeBTQt8= 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=afjNWeYQ; arc=none smtp.client-ip=209.85.214.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="afjNWeYQ" Received: by mail-pl1-f170.google.com with SMTP id d9443c01a7336-2b46da8c48eso18915ad.1 for ; Thu, 30 Apr 2026 11:25:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1777573523; x=1778178323; darn=vger.kernel.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=eSG/yM4Jbprzjr8hlewRTOp1V59hFoclV98ulyGviIc=; b=afjNWeYQu3LjCB32c7/96seA2fhq+Hi/Gyx5Xo1Hn+5XdT+7fACUbM1U3JPRZI7Hv0 B7d6l9zps71Td/cArkdTNfZDMGVlh3Q4P/F2EunfOh78fy00NzbvdcJqT+n23a53SQAN n0oxsLXLEolhORpq6+/hBkEOGGf0TQjlW4KaWiaDocTn2foXvMGZ6H7vURYiroktyLPH ICgYU0msHUqQoTmeC9sPrps0Yio3A+tr8nNI5CCNGR5X9+dsInhnNAztPZAG9odzOuOE 5Md0UJ7KzuKRtkrBHzO0nFP7P3035zEZWwhm4ryQ8OK0kcH/rbooDXZXRNgBhIYaT/va OlcA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1777573523; x=1778178323; h=in-reply-to:content-transfer-encoding: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=eSG/yM4Jbprzjr8hlewRTOp1V59hFoclV98ulyGviIc=; b=nbkB+NmuFQHO31WpXdnjlkdTGiwXMcq4nZ36wZygLIvnq+c6WKDAAIDA/QklCFtsBq yKFHAOcgMnd4QAX5JWMDQYnI3thZSA44KNJfMeiOid/lh9PAlLPb/GLOymAyyd65DxX+ r+MNGJshiZStcp06mkYHwkVqFF72ETozNmYeAuXbJBZRjd9IoVhKknyQ8394JyXYRT2C FhTvRWbQ0IX61U6A5rjKcOC9b2rkomf9/e0DFe3mw95oXP3DmoEF7RNIL4HIdZ+TxqFe pjgUE1bm/7CGE05yi3gAyzxPBKOUt6j7N7C/QErQqkEBkNRi9Q89FE9ZDbWXPFD+FgVU Hw4w== X-Forwarded-Encrypted: i=1; AFNElJ/tskCLIGOyD+cwtJWIy10HxDJpjpWuJpC3zz21Dtmry/gj9q5ElGr72Hi2R9i4oSLV0GnKaqy/nYrGsdQ=@vger.kernel.org X-Gm-Message-State: AOJu0YzqmUtbU77ssVCTVo7rOJQq9vLKzVkAsixQJ33uUoEPcVvyIlsg a3GAX7U1cGIcd0EqicVaaTYMvk7PsS6rYHftllsyUtlUO7KHyOy5NaLFeMtfLqes4w== X-Gm-Gg: AeBDiesgVcBbhNcaBC5txRau/LjNLoikEenaZOVvbvLsV6cC+KF5k+E+f0vTh+HJW1R pGOrXS45SIZgBnAG5e34A9yJJ4EEPpeATi4QBi0yXCriX71WERU+TnPP6AZcObPlNF2O70sgDqY trGJXp0vHXkq1sZpNslDSi+HUAZszkdCxQvEQUzXlgsWCf4aFXMaJOpo5GfT5xZ1CmIdu3X2/I8 C3R//tmvjuZeNI06k4rJQ/ocFVLCje9DPt5vtP8Zz8GlC+scRaeSuY2OfF9UBn1y1ABDSCy/YO3 OCmoLEBM7JjBXziCrhxCAMhygA3UKk+IihnxMNq62KN3H0yp0HtUd8DVeA1mjaMy84ycbONF3aQ RZNvgAAcD9+YabxODdo8S+P1ypSHNZ5ANxuiINyqLtoDb66UEe8wILWicSOYEoBJ3AUybewipGQ 5MyNb/yS/MCLQTCzeCZlgT/XfGnZ6SuunMBMj09f6cmZQVJKLUjsxtPlxRYX3v8VM1YTkcrRZEz /4OQQk= X-Received: by 2002:a17:903:2a8f:b0:2b4:6153:e541 with SMTP id d9443c01a7336-2b9ce26a5dcmr69445ad.3.1777573521791; Thu, 30 Apr 2026 11:25:21 -0700 (PDT) Received: from google.com (60.89.247.35.bc.googleusercontent.com. [35.247.89.60]) by smtp.gmail.com with ESMTPSA id 41be03b00d2f7-c7ffbcaa477sm278266a12.31.2026.04.30.11.25.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 30 Apr 2026 11:25:21 -0700 (PDT) Date: Thu, 30 Apr 2026 11:25:16 -0700 From: Vipin Sharma To: David Matlack Cc: iommu@lists.linux.dev, 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 , Joerg Roedel , Jonathan Corbet , Josh Hilke , Leon Romanovsky , Lukas Wunner , Mike Rapoport , Parav Pandit , Pasha Tatashin , Pranjal Shrivastava , Pratyush Yadav , Robin Murphy , Saeed Mahameed , Samiullah Khawaja , Shuah Khan , Will Deacon , William Tu , Yi Liu Subject: Re: [PATCH v4 02/11] PCI: liveupdate: Track outgoing preserved PCI devices Message-ID: <20260430175916.GA13902.vipinsh@google.com> References: <20260423212316.3431746-1-dmatlack@google.com> <20260423212316.3431746-3-dmatlack@google.com> <20260428201231.GA3885809.vipinsh@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=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On Tue, Apr 28, 2026 at 02:12:13PM -0700, David Matlack wrote: > On Tue, Apr 28, 2026 at 1:20 PM Vipin Sharma wrote: > > > > On Thu, Apr 23, 2026 at 09:23:06PM +0000, David Matlack wrote: > > > +int pci_liveupdate_preserve(struct pci_dev *dev) > > > +{ > > > + struct pci_ser *ser; > > > + int i, ret; > > > + > > > + guard(mutex)(&pci_flb_outgoing_lock); > > > + > > > + ret = liveupdate_flb_get_outgoing(&pci_liveupdate_flb, (void **)&ser); > > > + if (ret) > > > + return ret; > > > + > > > + if (!ser) > > > + return -ENOENT; > > > + > > > + if (dev->is_virtfn) > > > + return -EINVAL; > > > + > > > + if (dev->liveupdate_outgoing) > > > + return -EBUSY; > > > + > > > + if (ser->nr_devices == ser->max_nr_devices) > > > + return -ENOSPC; > > > + > > > + for (i = 0; i < ser->max_nr_devices; i++) { > > > + /* > > > + * Start searching at index ser->nr_devices. This should result > > > + * in a constant time search under expected conditions (devices > > > + * are not getting unpreserved). > > > + */ > > > + int index = (ser->nr_devices + i) % ser->max_nr_devices; > > > + struct pci_dev_ser *dev_ser = &ser->devices[index]; > > > + > > > + if (dev_ser->refcount) > > > + continue; > > > + > > > + pci_info(dev, "Device will be preserved across next Live Update\n"); > > > + ser->nr_devices++; > > > + > > > + dev_ser->domain = pci_domain_nr(dev->bus); > > > + dev_ser->bdf = pci_dev_id(dev); > > > + dev_ser->refcount = 1; > > > + > > > + dev->liveupdate_outgoing = dev_ser; > > > + return 0; > > > + } > > > + > > > + return -ENOSPC; > > > > Since it is executing under a mutex, and we already failed > > 'if (ser->nr_devices == ser->max_nr_devices) check above, will we ever reach > > here and return -ENOSPC? > > Yeah I wouldn't expect to ever reach here. Will you be removing it or want to keep it just in case scenario? > > > > diff --git a/include/linux/kho/abi/pci.h b/include/linux/kho/abi/pci.h > > > index 5c0e92588c00..5b4c8d9e462c 100644 > > > --- a/include/linux/kho/abi/pci.h > > > +++ b/include/linux/kho/abi/pci.h > > > @@ -23,19 +23,20 @@ > > > * incrementing the version number in the PCI_LUO_FLB_COMPATIBLE string. > > > */ > > > > > > -#define PCI_LUO_FLB_COMPATIBLE "pci-v1" > > > +#define PCI_LUO_FLB_COMPATIBLE "pci-v2" > > > > Just curious, why did we change the version here? > > Because a field in struct pci_dev_ser changed. > > > It's not like just > > previous patch is working enough to perform a live update. As the config > > is experimental, can't we just keep it PCI-v1 for the whole series? > > What is the benefit of keeping "pci-v1"? > I don't see any benefit in keeping v1 or changing to v2 as well. My reasoning is that before this series is merged, there is no real need for versioning here. This is first series which is introducing PCI liveupdate. It is not gonna be that someone has merged patch 1 only, run its kernel and then kexec to next kernel which has patch 2. > I think it makes sense to follow the rule we set which is to update > the compatibility string in any commit that changes the ABI. Okay, this is also fine.