linux-kernel - RE: [PATCH] PCI/DOE: Remove asynchronous task support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 21 Nov 2022 14:17:37 +0000
From:   "Zhuo, Qiuxu" <qiuxu.zhuo@...el.com>
To:     Jonathan Cameron <Jonathan.Cameron@...wei.com>
CC:     "Weiny, Ira" <ira.weiny@...el.com>,
        "Williams, Dan J" <dan.j.williams@...el.com>,
        Bjorn Helgaas <bhelgaas@...gle.com>,
        "Gregory Price" <gregory.price@...verge.com>,
        "Li, Ming4" <ming4.li@...el.com>,
        "Verma, Vishal L" <vishal.l.verma@...el.com>,
        Lukas Wunner <lukas@...ner.de>,
        "Schofield, Alison" <alison.schofield@...el.com>,
        "linux-cxl@...r.kernel.org" <linux-cxl@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>
Subject: RE: [PATCH] PCI/DOE: Remove asynchronous task support

> From: Jonathan Cameron <Jonathan.Cameron@...wei.com>
> ...
> On Mon, 21 Nov 2022 02:01:32 +0000
> "Zhuo, Qiuxu" <qiuxu.zhuo@...el.com> wrote:
> 
> > > From: Ira Weiny <ira.weiny@...el.com>
> > ＞　...
> > >
> > > @@ -423,25 +399,13 @@ struct pci_doe_mb
> *pcim_doe_create_mb(struct
> > > pci_dev *pdev, u16 cap_offset)
> > >  	doe_mb->pdev = pdev;
> > >  	doe_mb->cap_offset = cap_offset;
> > >  	init_waitqueue_head(&doe_mb->wq);
> > > +	mutex_init(&doe_mb->exec_lock);
> >
> > In real world, not sure whether there is a case that
> > pcim_doe_create_mb() is invoked by multiple drivers to create multiple
> > DOE mailbox instances? If there is such a case, we may need to ensure
> there is only one DOE mailbox instance for a physical DOE of pdev
> @cap_offset.
> 
> I think if that happened we'd have a lot of mess.  The main PCI driver for a
> given EP, switch port etc needs to handle this part.
> 
> Sub drivers can then do similar to
> https://elixir.bootlin.com/linux/latest/source/drivers/cxl/core/pci.c#L465
> to find a DOE instance that supports what they need and use it.
> The DOE code 'should' work fine when doing this - the request/response
> pairs will be serialized.
> 
> We have discussed moving that 'find' logic and the xarray into the PCI core
> and that will need to happen to support CMA etc. For the first submission it
> was easier to just do it in the CXL drivers..

For the 1st submission, yes, it's easier in current way.

> 
> Jonathan

It's good that this potential issue has been noticed. I think moving the 'find' logic and the xarray 
from CXL to the PCI core should save a lot of such duplicated works for other drivers using DOE.

One more though:
For a driver, I think it's only interested in getting a DOE mailbox from a PCI device with specified VID+protocol and using it.
The driver doesn't care how is the DOE mailbox instance created and the driver also doesn't want to maintain it.
After using the DOE mailbox instance then the driver puts it back. 
A pair of get-put APIs implemented in the PCI core like below might make drivers' lives easy 😊

         struct pci_doe_mb *mb = pci_doe_get(struct pci_dev *pdev, u16 vid, u8 protocol); 
         // if (!mb) return;
         // The driver uses the 'mb' to send requests and receive responses ...
        pci_doe_put(mb);

The creation and all the heavy maintenance works on the 'mb' are hidden in the get-put APIs.       

-Qiuxu