[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240813160502.GH1985367@ziepe.ca>
Date: Tue, 13 Aug 2024 13:05:02 -0300
From: Jason Gunthorpe <jgg@...pe.ca>
To: Christoph Hellwig <hch@...radead.org>
Cc: Martin Oliveira <martin.oliveira@...eticom.com>,
linux-rdma@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-mm@...ck.org, Andrew Morton <akpm@...ux-foundation.org>,
Artemy Kovalyov <artemyko@...dia.com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Leon Romanovsky <leon@...nel.org>,
Logan Gunthorpe <logang@...tatee.com>,
Michael Guralnik <michaelgur@...dia.com>,
Mike Marciniszyn <mike.marciniszyn@...el.com>,
Shiraz Saleem <shiraz.saleem@...el.com>, Tejun Heo <tj@...nel.org>,
John Hubbard <jhubbard@...dia.com>,
Dan Williams <dan.j.williams@...el.com>,
David Sloan <david.sloan@...eticom.com>
Subject: Re: [PATCH v5 3/4] mm/gup: allow FOLL_LONGTERM & FOLL_PCI_P2PDMA
On Mon, Aug 12, 2024 at 10:41:20PM -0700, Christoph Hellwig wrote:
> On Mon, Aug 12, 2024 at 08:12:49PM -0300, Jason Gunthorpe wrote:
> > > This is unfortunately not really minor unless we have a well documented
> > > way to force this :(
> >
> > It is not that different from blocking driver unbind while FDs are
> > open which a lot of places do in various ways?
>
> Where do we block driver unbind with an open resource?
I keep seeing it in different subsystems, safe driver unbind is really
hard. :\ eg I think VFIO has some waits in it
> The whole concept is that open resources will pin the in-memory
> object (and modulo for a modular driver), but never an unbind or
> hardware unplug, of which unbind really just is a simulation.
Yes, ideally, but not every part of the kernel hits that ideal in my
experience. It is alot of work and some places don't have any good
solutions, like here.
Jason
Powered by blists - more mailing lists