Linux CXL
 help / color / mirror / Atom feed
From: Lukas Wunner <lukas@wunner.de>
To: Jonathan Cameron <Jonathan.Cameron@Huawei.com>
Cc: Bjorn Helgaas <helgaas@kernel.org>,
	linux-pci@vger.kernel.org,
	Gregory Price <gregory.price@memverge.com>,
	Ira Weiny <ira.weiny@intel.com>,
	Dan Williams <dan.j.williams@intel.com>,
	Alison Schofield <alison.schofield@intel.com>,
	Vishal Verma <vishal.l.verma@intel.com>,
	Dave Jiang <dave.jiang@intel.com>,
	"Li, Ming" <ming4.li@intel.com>, Hillf Danton <hdanton@sina.com>,
	Ben Widawsky <bwidawsk@kernel.org>,
	linuxarm@huawei.com, linux-cxl@vger.kernel.org
Subject: Re: [PATCH v2 06/10] PCI/DOE: Allow mailbox creation without devres management
Date: Fri, 10 Feb 2023 23:03:53 +0100	[thread overview]
Message-ID: <20230210220353.GC15326@wunner.de> (raw)
In-Reply-To: <20230124121543.00002600@Huawei.com>

On Tue, Jan 24, 2023 at 12:15:43PM +0000, Jonathan Cameron wrote:
> On Mon, 23 Jan 2023 11:16:00 +0100 Lukas Wunner <lukas@wunner.de> wrote:
> > DOE mailbox creation is currently only possible through a devres-managed
> > API.  The lifetime of mailboxes thus ends with driver unbinding.
> > 
> > An upcoming commit will create DOE mailboxes upon device enumeration by
> > the PCI core.  Their lifetime shall not be limited by a driver.
> > 
> > Therefore rework pcim_doe_create_mb() into the non-devres-managed
> > pci_doe_create_mb().  Add pci_doe_destroy_mb() for mailbox destruction
> > on device removal.
[...]
> I'd like to understand why flushing in the tear down
> can't always be done as that makes the code more complex.

After sending out v2, I realized I had made a mistake:

In v2, on device removal I canceled any ongoing DOE exchanges
and declared the DOE mailbox dead before unbinding the driver
from a device.  That's the right thing to do for surprise removal
because you don't want to wait for an ongoing exchange to time out.

However we also have a code path for orderly device removal,
either via sysfs or by pressing the Attention Button (if present).
In that case, it should be legal for the driver to still perform
DOE exchanges in its ->remove() hook.

So in v3 I've changed the behavior to only cancel requests on
surprise removal.  By doing so, I was able to always flush on
mailbox destruction, as you've requested, and thereby simplify
the error paths.


> > +err_flush:
> > +	pci_doe_flush_mb(doe_mb);
> > +	xa_destroy(&doe_mb->prots);
> 
> Why the reorder wrt to the original devm managed cleanup?
> I'd expect this to happen on any error path after the xa_init.
> 
> It doesn't matter in practice because there isn't anything to
> do until after pci_doe_cache_protocols though.

Right, it's unnecessary to call xa_destroy() if
alloc_ordered_workqueue() failed because the xarray is still empty
at that point.  It doesn't need to be destroyed until it's been
populated by pci_doe_cache_protocols().

I've amended the commit message to explain that, but otherwise
did not change the code in v3.  Let me know if you have any
objections or feel strongly about moving xa_init().

Thanks,

Lukas

  parent reply	other threads:[~2023-02-10 22:04 UTC|newest]

Thread overview: 53+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-23 10:10 [PATCH v2 00/10] Collection of DOE material Lukas Wunner
2023-01-23 10:11 ` [PATCH v2 01/10] PCI/DOE: Silence WARN splat with CONFIG_DEBUG_OBJECTS=y Lukas Wunner
2023-01-24  0:33   ` Ira Weiny
2023-01-24 10:32     ` Jonathan Cameron
2023-01-25 21:05       ` Lukas Wunner
2023-01-24 16:18   ` Gregory Price
2023-02-10 23:50   ` Dan Williams
2023-01-23 10:12 ` [PATCH v2 02/10] PCI/DOE: Fix memory leak " Lukas Wunner
2023-01-24  0:35   ` Ira Weiny
2023-01-24 10:33     ` Jonathan Cameron
2023-02-10 23:52   ` Dan Williams
2023-01-23 10:13 ` [PATCH v2 03/10] PCI/DOE: Provide synchronous API and use it internally Lukas Wunner
2023-01-24  0:48   ` Ira Weiny
2023-01-24 10:40   ` Jonathan Cameron
2023-01-24 20:07     ` Ira Weiny
2023-02-10 23:57   ` Dan Williams
2023-01-23 10:14 ` [PATCH v2 04/10] cxl/pci: Use synchronous API for DOE Lukas Wunner
2023-01-24  0:52   ` Ira Weiny
2023-02-03  8:53     ` Li, Ming
2023-02-03  8:56       ` Li, Ming
2023-02-03  9:54       ` Lukas Wunner
2023-01-24 11:01   ` Jonathan Cameron
2023-02-10 22:17     ` Lukas Wunner
2023-01-23 10:15 ` [PATCH v2 05/10] PCI/DOE: Make asynchronous API private Lukas Wunner
2023-01-24  0:55   ` Ira Weiny
2023-01-24 11:03   ` Jonathan Cameron
2023-01-23 10:16 ` [PATCH v2 06/10] PCI/DOE: Allow mailbox creation without devres management Lukas Wunner
2023-01-24 12:15   ` Jonathan Cameron
2023-01-24 12:18     ` Jonathan Cameron
2023-02-03  9:06     ` Li, Ming
2023-02-03  9:09       ` Li, Ming
2023-02-03 10:08       ` Lukas Wunner
2023-02-10 22:03     ` Lukas Wunner [this message]
2023-01-23 10:17 ` [PATCH v2 07/10] PCI/DOE: Create mailboxes on device enumeration Lukas Wunner
2023-01-24  1:14   ` Ira Weiny
2023-01-24 12:21   ` Jonathan Cameron
2023-01-23 10:18 ` [PATCH v2 08/10] cxl/pci: Use CDAT DOE mailbox created by PCI core Lukas Wunner
2023-01-24  1:18   ` Ira Weiny
2023-01-24 12:25   ` Jonathan Cameron
2023-01-23 10:19 ` [PATCH v2 09/10] PCI/DOE: Make mailbox creation API private Lukas Wunner
2023-01-24  1:25   ` Ira Weiny
2023-01-24 12:26   ` Jonathan Cameron
2023-01-23 10:20 ` [PATCH v2 10/10] PCI/DOE: Relax restrictions on request and response size Lukas Wunner
2023-01-23 22:29   ` Bjorn Helgaas
2023-01-24  1:43   ` Ira Weiny
2023-02-10 21:47     ` Lukas Wunner
2023-01-24 12:43   ` Jonathan Cameron
2023-01-24 23:51     ` Bjorn Helgaas
2023-01-25  9:47       ` Jonathan Cameron
2023-02-10 22:10       ` Lukas Wunner
2023-01-23 22:30 ` [PATCH v2 00/10] Collection of DOE material Bjorn Helgaas
2023-02-10 21:39   ` Lukas Wunner
2023-02-11  0:04     ` Dan Williams

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=20230210220353.GC15326@wunner.de \
    --to=lukas@wunner.de \
    --cc=Jonathan.Cameron@Huawei.com \
    --cc=alison.schofield@intel.com \
    --cc=bwidawsk@kernel.org \
    --cc=dan.j.williams@intel.com \
    --cc=dave.jiang@intel.com \
    --cc=gregory.price@memverge.com \
    --cc=hdanton@sina.com \
    --cc=helgaas@kernel.org \
    --cc=ira.weiny@intel.com \
    --cc=linux-cxl@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linuxarm@huawei.com \
    --cc=ming4.li@intel.com \
    --cc=vishal.l.verma@intel.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