public inbox for linux-efi@vger.kernel.org
 help / color / mirror / Atom feed
From: Dan Williams <dan.j.williams@intel.com>
To: Bjorn Helgaas <helgaas@kernel.org>,
	Dan Williams <dan.j.williams@intel.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>,
	Ira Weiny <ira.weiny@intel.com>,
	Jonathan Cameron <jonathan.cameron@huawei.com>,
	Smita Koralahalli <Smita.KoralahalliChannabasappa@amd.com>,
	Shiju Jose <shiju.jose@huawei.com>,
	Yazen Ghannam <yazen.ghannam@amd.com>,
	Davidlohr Bueso <dave@stgolabs.net>,
	Dave Jiang <dave.jiang@intel.com>,
	Alison Schofield <alison.schofield@intel.com>,
	Vishal Verma <vishal.l.verma@intel.com>,
	"Ard Biesheuvel" <ardb@kernel.org>, <linux-efi@vger.kernel.org>,
	<linux-kernel@vger.kernel.org>, <linux-cxl@vger.kernel.org>,
	<linux-pci@vger.kernel.org>
Subject: Re: [PATCH v5 8/9] PCI: Define scoped based management functions
Date: Wed, 3 Jan 2024 16:21:02 -0800	[thread overview]
Message-ID: <6595f9eec5986_be70229443@dwillia2-xfh.jf.intel.com.notmuch> (raw)
In-Reply-To: <20240103230147.GA1800245@bhelgaas>

Bjorn Helgaas wrote:
> On Wed, Jan 03, 2024 at 02:38:57PM -0800, Dan Williams wrote:
> > Ira Weiny wrote:
> > > Users of pci_dev_get() can benefit from a scoped based put.  Also,
> > > locking a PCI device is often done within a single scope.
> > > 
> > > Define a pci_dev_put() free function and a PCI device lock guard.  These
> > > will initially be used in new CXL event processing code but is defined
> > > in a separate patch for others to pickup and use/backport easier.
> > 
> > Any heartburn if I take this through cxl.git with the rest in this
> > series? Patch 9 has a dependency on this one.
> 
> No real heartburn.  I was trying to figure out what this does
> since I'm not familiar with the "scoped based put" idea and
> 'git grep -i "scope.*base"' wasn't much help.
> 
> I would kind of like the commit log to say a little more about what
> the "scoped based put" (does that have too many past tenses in it?)
> means and how users of pci_dev_get() will benefit.

That is completely fair, and I should have checked to make sure that the
changelog clarified the impact of the change.

> I don't know what "locking a PCI device is often done within a single
> scope" is trying to tell me either.  What if it's *not* done within a
> single scope?
> 
> Does this change anything for callers of pci_dev_get() and
> pci_dev_put()?
> 
> Does this avoid a common programming error?  I just don't know what
> the benefit of this is yet.
> 
> I'm sure this is really cool stuff, but there's little documentation,
> few existing users, and I don't know what I need to look for when
> reviewing things.

Here a is a re-write of the changelog:

---
PCI: Introduce cleanup helpers for device reference counts and locks

The "goto error" pattern is notorious for introducing subtle resource
leaks. Use the new cleanup.h helpers for PCI device reference counts and
locks.

Similar to the new put_device() and device_lock() cleanup helpers,
__free(put_device) and guard(device), define the same for PCI devices,
__free(pci_dev_put) and guard(pci_dev).  These helpers eliminate the
need for "goto free;" and "goto unlock;" patterns. For example, A
'struct pci_dev *' instance declared as:

	struct pci_dev *pdev __free(pci_dev_put) = NULL;

...will automatically call pci_dev_put() if @pdev is non-NULL when @pdev
goes out of scope (automatic variable scope). If a function wants to
invoke pci_dev_put() on error, but return @pdev on success, it can do:

	return no_free_ptr(pdev);

...or:

	return_ptr(pdev);

For potential cleanup opportunity there are 587 open-coded calls to
pci_dev_put() in the kernel with 65 instances within 10 lines of a goto
statement with the CXL driver threatening to add another one.

The guard() helper holds the associated lock for the remainder of the
current scope in which it was invoked. So, for example:

	func(...)
	{
		if (...) {
			...
			guard(pci_dev); /* pci_dev_lock() invoked here */
			...
		} /* <- implied pci_dev_unlock() triggered here */
	}

There are 15 invocations of pci_dev_unlock() in the kernel with 5
instances within 10 lines of a goto statement. Again, the CXL driver is
threatening to add another.

Introduce these helpers to preclude the addition of new more error prone
goto put; / goto unlock; sequences. For now, these helpers are used in
drivers/cxl/pci.c to allow ACPI error reports to be fed back into the
CXL driver associated with the PCI device identified in the report.

---

As for reviewing conversions that use these new helpers, one of the
gotchas I have found is that it is easy to make a mistake if a goto
still exists in the function after the conversion. So unless and until
all of the resources a function acquires, that currently need a goto to
unwind them on error, can be converted to cleanup.h based helpers it is
best not to mix styles.

I think the function documentation in include/linux/cleanup.h does a
decent job of explaining how to use the helpers. However, I am happy to
suggest some updates if you think it would help.

  reply	other threads:[~2024-01-04  0:21 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-21  0:17 [PATCH v5 0/9] efi/cxl-cper: Report CPER CXL component events through trace events Ira Weiny
2023-12-21  0:17 ` [PATCH v5 1/9] cxl/trace: Pass uuid explicitly to event traces Ira Weiny
2024-01-08 12:56   ` Jonathan Cameron
2023-12-21  0:17 ` [PATCH v5 2/9] cxl/events: Promote CXL event structures to a core header Ira Weiny
2024-01-08 13:05   ` Jonathan Cameron
2023-12-21  0:17 ` [PATCH v5 3/9] cxl/events: Create common event UUID defines Ira Weiny
2024-01-08 13:07   ` Jonathan Cameron
2023-12-21  0:17 ` [PATCH v5 4/9] cxl/events: Remove passing a UUID to known event traces Ira Weiny
2024-01-08 13:23   ` Jonathan Cameron
2024-01-09 23:38     ` Dan Williams
2024-01-10 14:22       ` Jonathan Cameron
2023-12-21  0:17 ` [PATCH v5 5/9] cxl/events: Separate UUID from event structures Ira Weiny
2024-01-08 13:27   ` Jonathan Cameron
2023-12-21  0:17 ` [PATCH v5 6/9] cxl/events: Create a CXL event union Ira Weiny
2024-01-08 13:31   ` Jonathan Cameron
2023-12-21  0:17 ` [PATCH v5 7/9] acpi/ghes: Process CXL Component Events Ira Weiny
2024-01-08 13:41   ` Jonathan Cameron
2023-12-21  0:17 ` [PATCH v5 8/9] PCI: Define scoped based management functions Ira Weiny
2024-01-03 22:38   ` Dan Williams
2024-01-03 23:01     ` Bjorn Helgaas
2024-01-04  0:21       ` Dan Williams [this message]
2024-01-04 17:17         ` Ira Weiny
2024-01-04 18:32         ` Bjorn Helgaas
2024-01-04 18:59           ` Dan Williams
2024-01-04 21:46             ` Ira Weiny
2024-01-04 22:37               ` Bjorn Helgaas
2024-01-04 23:00                 ` Ira Weiny
2024-01-04  6:05   ` Lukas Wunner
2024-01-04  6:43     ` Dan Williams
2024-01-04  7:02       ` Lukas Wunner
2024-01-04  7:37         ` Ard Biesheuvel
2024-01-04 17:41           ` Dan Williams
2024-01-08 13:44   ` Jonathan Cameron
2023-12-21  0:17 ` [PATCH v5 9/9] cxl/pci: Register for and process CPER events Ira Weiny
2024-01-02 15:14   ` Smita Koralahalli
2024-01-02 20:29     ` Ira Weiny
2024-01-03 22:08   ` Dan Williams
2024-01-04 18:31   ` Ira Weiny
2024-01-08 13:50   ` Jonathan Cameron
2024-01-09 23:59     ` Dan Williams
2024-01-04 22:55 ` [PATCH v5 0/9] efi/cxl-cper: Report CPER CXL component events through trace events Bjorn Helgaas
2024-01-08 16:58 ` Jonathan Cameron
2024-01-08 20:04   ` Smita Koralahalli
2024-01-09  2:08     ` Dan Williams
2024-01-09  2:32       ` Ira Weiny
2024-01-09  2:59         ` Dan Williams
2024-01-09 16:04           ` Jonathan Cameron
2024-01-09 20:49             ` Dan Williams
2024-01-09 23:30               ` Dan Williams
2024-01-09 23:31                 ` Ard Biesheuvel
2024-01-10 14:24                   ` Jonathan Cameron

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=6595f9eec5986_be70229443@dwillia2-xfh.jf.intel.com.notmuch \
    --to=dan.j.williams@intel.com \
    --cc=Smita.KoralahalliChannabasappa@amd.com \
    --cc=alison.schofield@intel.com \
    --cc=ardb@kernel.org \
    --cc=bhelgaas@google.com \
    --cc=dave.jiang@intel.com \
    --cc=dave@stgolabs.net \
    --cc=helgaas@kernel.org \
    --cc=ira.weiny@intel.com \
    --cc=jonathan.cameron@huawei.com \
    --cc=linux-cxl@vger.kernel.org \
    --cc=linux-efi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=shiju.jose@huawei.com \
    --cc=vishal.l.verma@intel.com \
    --cc=yazen.ghannam@amd.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox