linux-kernel - Re: [PATCH v5 3/4] mm/gup: allow FOLL_LONGTERM & FOLL_PCI

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]

Message-ID: <20240814000245.GV1985367@ziepe.ca>
Date: Tue, 13 Aug 2024 21:02:45 -0300
From: Jason Gunthorpe <jgg@...pe.ca>
To: Dan Williams <dan.j.williams@...el.com>
Cc: Christoph Hellwig <hch@...radead.org>,
	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>,
	David Sloan <david.sloan@...eticom.com>
Subject: Re: [PATCH v5 3/4] mm/gup: allow FOLL_LONGTERM & FOLL_PCI_P2PDMA

On Tue, Aug 13, 2024 at 10:03:55AM -0700, Dan Williams wrote:
> Jason Gunthorpe wrote:
> > 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.
> 
> ...but there is a distinction between transient and permanent waits,
> right? The difficult aspect of FOLL_LONGTERM is the holder has no idea
> someone is trying to cleanup and may never drop its pin.

It is the quite similar to userspace holding a FD open while a driver
is trying to unbind. The FD holder has possibly no idea things are
waiting on it.

Nice subsystems allow the FD to keep existing while the driver is
unplugged, but still many have to wait for the FD to close as
disconnecting an active driver from it's FD requires some pretty
careful design.

Jason