linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Daniel Vetter <daniel.vetter@ffwll.ch>
To: Tomasz Figa <tfiga@chromium.org>
Cc: "Jason Gunthorpe" <jgg@ziepe.ca>,
	"Marek Szyprowski" <m.szyprowski@samsung.com>,
	"DRI Development" <dri-devel@lists.freedesktop.org>,
	LKML <linux-kernel@vger.kernel.org>,
	"Daniel Vetter" <daniel.vetter@intel.com>,
	"Andrew Morton" <akpm@linux-foundation.org>,
	"John Hubbard" <jhubbard@nvidia.com>,
	"Jérôme Glisse" <jglisse@redhat.com>, "Jan Kara" <jack@suse.cz>,
	"Dan Williams" <dan.j.williams@intel.com>,
	"Linux MM" <linux-mm@kvack.org>,
	"Linux ARM" <linux-arm-kernel@lists.infradead.org>,
	"Pawel Osciak" <pawel@osciak.com>,
	"Kyungmin Park" <kyungmin.park@samsung.com>,
	"Inki Dae" <inki.dae@samsung.com>,
	"Joonyoung Shim" <jy0922.shim@samsung.com>,
	"Seung-Woo Kim" <sw0312.kim@samsung.com>,
	linux-samsung-soc <linux-samsung-soc@vger.kernel.org>,
	"open list:DMA BUFFER SHARING FRAMEWORK"
	<linux-media@vger.kernel.org>,
	"Oded Gabbay" <oded.gabbay@gmail.com>
Subject: Re: [PATCH 2/2] mm/frame-vec: use FOLL_LONGTERM
Date: Wed, 7 Oct 2020 14:58:33 +0200	[thread overview]
Message-ID: <CAKMK7uG3fds79Yf9VhMstnJ2+UHYUEVdODkoOvtwFC28_+T6RA@mail.gmail.com> (raw)
In-Reply-To: <CAAFQd5D0ahP-3hp_vGEmJ2cyBOMXeW9HX5yKaVPcQTsFwwOE8Q@mail.gmail.com>

On Wed, Oct 7, 2020 at 2:48 PM Tomasz Figa <tfiga@chromium.org> wrote:
>
> On Wed, Oct 7, 2020 at 2:44 PM Jason Gunthorpe <jgg@ziepe.ca> wrote:
> >
> > On Wed, Oct 07, 2020 at 02:33:56PM +0200, Marek Szyprowski wrote:
> > > Well, it was in vb2_get_vma() function, but now I see that it has been
> > > lost in fb639eb39154 and 6690c8c78c74 some time ago...
> >
> > There is no guarentee that holding a get on the file says anthing
> > about the VMA. This needed to check that the file was some special
> > kind of file that promised the VMA layout and file lifetime are
> > connected.
> >
> > Also, cloning a VMA outside the mm world is just really bad. That
> > would screw up many assumptions the drivers make.
> >
> > If it is all obsolete I say we hide it behind a default n config
> > symbol and taint the kernel if anything uses it.
> >
> > Add a big comment above the follow_pfn to warn others away from this
> > code.
>
> Sadly it's just verbally declared as deprecated and not formally noted
> anyway. There are a lot of userspace applications relying on user
> pointer support.

userptr can stay, it's the userptr abuse for zerocpy buffer sharing
which doesn't work anymore. At least without major surgery (you'd need
an mmu notifier to zap mappings and recreate them, and that pretty
much breaks the v4l model of preallocating all buffers to make sure we
never underflow the buffer queue). And static mappings are not coming
back I think, we'll go ever more into the direction of dynamic
mappings and moving stuff around as needed.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch


  reply	other threads:[~2020-10-07 12:58 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-02 17:53 [PATCH 1/2] mm/frame-vec: Drop gup_flags from get_vaddr_frames() Daniel Vetter
2020-10-02 17:53 ` [PATCH 2/2] mm/frame-vec: use FOLL_LONGTERM Daniel Vetter
2020-10-02 18:06   ` Jason Gunthorpe
2020-10-02 18:16     ` Daniel Vetter
2020-10-02 23:31       ` Jason Gunthorpe
2020-10-03  8:34         ` Oded Gabbay
2020-10-03  9:40         ` Daniel Vetter
2020-10-04 12:50           ` Jason Gunthorpe
2020-10-04 16:09             ` Daniel Vetter
2020-10-05 17:28               ` Jason Gunthorpe
2020-10-05 18:16                 ` Daniel Vetter
2020-10-05 18:37                   ` Jason Gunthorpe
2020-10-05 18:54                     ` Daniel Vetter
2020-10-05 22:43                       ` Daniel Vetter
2020-10-05 23:41                         ` Jason Gunthorpe
2020-10-06  6:23                           ` Daniel Vetter
2020-10-06 12:26                             ` Jason Gunthorpe
2020-10-06 13:08                               ` Daniel Vetter
2020-10-07 10:47           ` Marek Szyprowski
2020-10-07 12:01             ` Daniel Vetter
2020-10-07 12:33               ` Marek Szyprowski
2020-10-07 12:44                 ` Jason Gunthorpe
2020-10-07 12:47                   ` Tomasz Figa
2020-10-07 12:58                     ` Daniel Vetter [this message]
2020-10-07 13:06                       ` Jason Gunthorpe
2020-10-07 13:34                         ` Tomasz Figa
2020-10-07 13:42                           ` Jason Gunthorpe
2020-10-07 14:08                           ` Daniel Vetter
2020-10-07 14:11                             ` Tomasz Figa
2020-10-07 14:22                               ` Daniel Vetter
2020-10-07 15:05                                 ` Tomasz Figa
2020-10-07 14:58                               ` Jason Gunthorpe
2020-10-07 13:06         ` Tomasz Figa
2020-10-07 13:14           ` Jason Gunthorpe
2020-10-05 15:03     ` Jan Kara
2020-10-02 22:39   ` John Hubbard
2020-10-03  9:45     ` Daniel Vetter
2020-10-03 22:52       ` John Hubbard
2020-10-03 23:24         ` Jason Gunthorpe
2020-10-04 11:20           ` Daniel Vetter
2020-10-05 17:35             ` Jason Gunthorpe
2020-10-02 18:22 ` [PATCH 1/2] mm/frame-vec: Drop gup_flags from get_vaddr_frames() Tomasz Figa
2020-10-02 19:21   ` Oded Gabbay
2020-10-05 17:38 [PATCH 2/2] mm/frame-vec: use FOLL_LONGTERM Jason Gunthorpe
2020-10-05 17:47 ` Jason Gunthorpe
2020-10-06  3:36   ` Andrew Morton
2020-10-06 11:57     ` Jason Gunthorpe
2020-10-05 17:53 ` Jan Kara
2020-10-05 17:57   ` Jason Gunthorpe
2020-10-05 18:16     ` Daniel Vetter
2020-10-06 11:56     ` Daniel Vetter

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=CAKMK7uG3fds79Yf9VhMstnJ2+UHYUEVdODkoOvtwFC28_+T6RA@mail.gmail.com \
    --to=daniel.vetter@ffwll.ch \
    --cc=akpm@linux-foundation.org \
    --cc=dan.j.williams@intel.com \
    --cc=daniel.vetter@intel.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=inki.dae@samsung.com \
    --cc=jack@suse.cz \
    --cc=jgg@ziepe.ca \
    --cc=jglisse@redhat.com \
    --cc=jhubbard@nvidia.com \
    --cc=jy0922.shim@samsung.com \
    --cc=kyungmin.park@samsung.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-samsung-soc@vger.kernel.org \
    --cc=m.szyprowski@samsung.com \
    --cc=oded.gabbay@gmail.com \
    --cc=pawel@osciak.com \
    --cc=sw0312.kim@samsung.com \
    --cc=tfiga@chromium.org \
    /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;
as well as URLs for NNTP newsgroup(s).