[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20220223143011.GQ10061@nvidia.com>
Date: Wed, 23 Feb 2022 10:30:11 -0400
From: Jason Gunthorpe <jgg@...dia.com>
To: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc: Robin Murphy <robin.murphy@....com>,
Lu Baolu <baolu.lu@...ux.intel.com>,
Christoph Hellwig <hch@...radead.org>,
Joerg Roedel <joro@...tes.org>,
Alex Williamson <alex.williamson@...hat.com>,
Bjorn Helgaas <bhelgaas@...gle.com>,
Kevin Tian <kevin.tian@...el.com>,
Ashok Raj <ashok.raj@...el.com>, kvm@...r.kernel.org,
rafael@...nel.org, David Airlie <airlied@...ux.ie>,
linux-pci@...r.kernel.org,
Thierry Reding <thierry.reding@...il.com>,
Diana Craciun <diana.craciun@....nxp.com>,
Dmitry Osipenko <digetx@...il.com>,
Will Deacon <will@...nel.org>,
Stuart Yoder <stuyoder@...il.com>,
Jonathan Hunter <jonathanh@...dia.com>,
Chaitanya Kulkarni <kch@...dia.com>,
Dan Williams <dan.j.williams@...el.com>,
Cornelia Huck <cohuck@...hat.com>,
linux-kernel@...r.kernel.org, Li Yang <leoyang.li@....com>,
iommu@...ts.linux-foundation.org,
Jacob jun Pan <jacob.jun.pan@...el.com>,
Daniel Vetter <daniel@...ll.ch>
Subject: Re: [PATCH v6 02/11] driver core: Add dma_cleanup callback in
bus_type
On Wed, Feb 23, 2022 at 10:09:01AM -0400, Jason Gunthorpe wrote:
> On Wed, Feb 23, 2022 at 03:06:35PM +0100, Greg Kroah-Hartman wrote:
> > On Wed, Feb 23, 2022 at 09:46:27AM -0400, Jason Gunthorpe wrote:
> > > On Wed, Feb 23, 2022 at 01:04:00PM +0000, Robin Murphy wrote:
> > >
> > > > 1 - tmp->driver is non-NULL because tmp is already bound.
> > > > 1.a - If tmp->driver->driver_managed_dma == 0, the group must currently be
> > > > DMA-API-owned as a whole. Regardless of what driver dev has unbound from,
> > > > its removal does not release someone else's DMA API (co-)ownership.
> > >
> > > This is an uncommon locking pattern, but it does work. It relies on
> > > the mutex being an effective synchronization barrier for an unlocked
> > > store:
> > >
> > > WRITE_ONCE(dev->driver, NULL)
> >
> > Only the driver core should be messing with the dev->driver pointer as
> > when it does so, it already has the proper locks held. Do I need to
> > move that to a "private" location so that nothing outside of the driver
> > core can mess with it?
>
> It would be nice, I've seen a abuse and mislocking of it in drivers
Though to be clear, what Robin is describing is still keeping the
dev->driver stores in dd.c, just reading it in a lockless way from
other modules.
Jason
Powered by blists - more mailing lists