All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>
To: Bjorn Helgaas <helgaas@kernel.org>
Cc: "Alex Williamson" <alex.williamson@redhat.com>,
	"Christian König" <ckoenig.leichtzumerken@gmail.com>,
	linux-pci@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>,
	"Bjorn Helgaas" <bhelgaas@google.com>
Subject: Re: [PATCH 1/2] PCI: Avoid pointless capability searches
Date: Fri, 14 Feb 2025 16:20:34 +0200 (EET)	[thread overview]
Message-ID: <c45cf368-a31d-6b5d-f7fb-23dcc6cfc420@linux.intel.com> (raw)
In-Reply-To: <20250213163850.GA114277@bhelgaas>

[-- Attachment #1: Type: text/plain, Size: 3218 bytes --]

On Thu, 13 Feb 2025, Bjorn Helgaas wrote:

> On Thu, Feb 13, 2025 at 03:52:05PM +0200, Ilpo Järvinen wrote:
> > On Fri, 7 Feb 2025, Bjorn Helgaas wrote:
> > > Many of the save/restore functions in the pci_save_state() and
> > > pci_restore_state() paths depend on both a PCI capability of the device and
> > > a pci_cap_saved_state structure to hold the configuration data, and they
> > > skip the operation if either is missing.
> > > 
> > > Look for the pci_cap_saved_state first so if we don't have one, we can skip
> > > searching for the device capability, which requires several slow config
> > > space accesses.
> 
> > > +++ b/drivers/pci/vc.c
> > > @@ -355,20 +355,17 @@ int pci_save_vc_state(struct pci_dev *dev)
> > >  	int i;
> > >  
> > >  	for (i = 0; i < ARRAY_SIZE(vc_caps); i++) {
> > > -		int pos, ret;
> > >  		struct pci_cap_saved_state *save_state;
> > > +		int pos, ret;
> > > +
> > > +		save_state = pci_find_saved_ext_cap(dev, vc_caps[i].id);
> > > +		if (!save_state)
> > > +			return -ENOMEM;
> > >  
> > >  		pos = pci_find_ext_capability(dev, vc_caps[i].id);
> > >  		if (!pos)
> > >  			continue;
> > >  
> > > -		save_state = pci_find_saved_ext_cap(dev, vc_caps[i].id);
> > > -		if (!save_state) {
> > > -			pci_err(dev, "%s buffer not found in %s\n",
> > > -				vc_caps[i].name, __func__);
> > > -			return -ENOMEM;
> > > -		}
> > 
> > I think this order change will cause a functional change because 
> > pci_allocate_vc_save_buffers() only allocated for those capabilities that 
> > are exist for dev. Thus, the loop will prematurely exit.
> 
> Oof, thank you for catching this!  I'll drop this for now.
> 
> It would be nice to make pci_save_vc_state() parallel with
> pci_restore_vc_state() (and with most other pci_save_*_state()
> functions) and have it return void.  But pci_save_state() returns the
> pci_save_vc_state() return value, and there are ~20 pci_save_state()
> callers that pay attention to that return value.
> 
> I'm not convinced there's real value in pci_save_state() error
> returns, given that so few callers check it, but it definitely
> requires more analysis before removing it.

Indeed, I also though that -ENOMEM even in the original is questionable.
These are not the real sources of the failure but just secondary effect 
from the failure that occurred earlier in _pci_add_cap_save_buffer().

-- 
 i.

> > >  		ret = pci_vc_do_save_buffer(dev, pos, save_state, true);
> > >  		if (ret) {
> > >  			pci_err(dev, "%s save unsuccessful %s\n",
> > > @@ -392,12 +389,15 @@ void pci_restore_vc_state(struct pci_dev *dev)
> > >  	int i;
> > >  
> > >  	for (i = 0; i < ARRAY_SIZE(vc_caps); i++) {
> > > -		int pos;
> > >  		struct pci_cap_saved_state *save_state;
> > > +		int pos;
> > > +
> > > +		save_state = pci_find_saved_ext_cap(dev, vc_caps[i].id);
> > > +		if (!save_state)
> > > +			continue;
> > >  
> > >  		pos = pci_find_ext_capability(dev, vc_caps[i].id);
> > > -		save_state = pci_find_saved_ext_cap(dev, vc_caps[i].id);
> > > -		if (!save_state || !pos)
> > > +		if (!pos)
> > >  			continue;
> > >  
> > >  		pci_vc_do_save_buffer(dev, pos, save_state, false);


  reply	other threads:[~2025-02-14 14:20 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-02-08  5:03 [PATCH 0/2] PCI: Avoid capability searches in save/restore state Bjorn Helgaas
2025-02-08  5:03 ` [PATCH 1/2] PCI: Avoid pointless capability searches Bjorn Helgaas
2025-02-13 13:52   ` Ilpo Järvinen
2025-02-13 16:38     ` Bjorn Helgaas
2025-02-14 14:20       ` Ilpo Järvinen [this message]
2025-02-08  5:03 ` [PATCH 2/2] PCI: Cache offset of Resizable BAR capability Bjorn Helgaas
2025-02-13 13:54   ` Ilpo Järvinen
2025-02-12 22:35 ` [PATCH 0/2] PCI: Avoid capability searches in save/restore state Bjorn Helgaas

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=c45cf368-a31d-6b5d-f7fb-23dcc6cfc420@linux.intel.com \
    --to=ilpo.jarvinen@linux.intel.com \
    --cc=alex.williamson@redhat.com \
    --cc=bhelgaas@google.com \
    --cc=ckoenig.leichtzumerken@gmail.com \
    --cc=helgaas@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.