All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Vetter <daniel@ffwll.ch>
To: Lorenzo Stoakes <lstoakes@gmail.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	dri-devel@lists.freedesktop.org, linux-mm <linux-mm@kvack.org>
Subject: Re: [PATCH RESEND] drm/via: use get_user_pages_unlocked()
Date: Wed, 1 Mar 2017 09:43:26 +0100	[thread overview]
Message-ID: <20170301084326.tdz32zvjg62znclq@phenom.ffwll.local> (raw)
In-Reply-To: <CAA5enKa4Asp4qSHkeV3saLZrhOMf2DJ9vuiwTDo1t5t54z4sTQ@mail.gmail.com>

On Tue, Feb 28, 2017 at 08:28:08PM +0000, Lorenzo Stoakes wrote:
> On 28 February 2017 at 19:35, Al Viro <viro@zeniv.linux.org.uk> wrote:
> > On Tue, Feb 28, 2017 at 10:01:10AM +0100, Daniel Vetter wrote:
> >
> >> > +   ret = get_user_pages_unlocked((unsigned long)xfer->mem_addr,
> >> > +                   vsg->num_pages, vsg->pages,
> >> > +                   (vsg->direction == DMA_FROM_DEVICE) ? FOLL_WRITE : 0);
> >
> > Umm...  Why not
> >         ret = get_user_pages_fast((unsigned long)xfer->mem_addr,
> >                         vsg->num_pages,
> >                         vsg->direction == DMA_FROM_DEVICE,
> >                         vsg->pages);
> >
> > IOW, do you really need a warranty that ->mmap_sem will be grabbed and
> > released?
> 
> Daniel will be better placed to answer in this specific case, but more
> generally is there any reason why we can't just use
> get_user_pages_fast() in all such cases? These patches were simply a
> mechanical/cautious replacement for code that is more or less exactly
> equivalent but if this would make sense perhaps it'd be worth using
> gup_fast() where possible?

I have no idea. drm/via is unmaintained, it's a dri1 racy driver with
problems probably everywhere, and I'm not sure we even have someone left
who cares (there's an out-of-tree kms conversion of via, but it's stuck
since years).

In short, it's the drm dungeons and the only reason I merge patches is to
give people an easy target for test driving the patch submission process
to dri-devel. And to avoid drm being a blocker for tree-wide refactorings.
Otherwise 0 reasons to change anything here.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

WARNING: multiple messages have this Message-ID (diff)
From: Daniel Vetter <daniel@ffwll.ch>
To: Lorenzo Stoakes <lstoakes@gmail.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	dri-devel@lists.freedesktop.org, linux-mm <linux-mm@kvack.org>
Subject: Re: [PATCH RESEND] drm/via: use get_user_pages_unlocked()
Date: Wed, 1 Mar 2017 09:43:26 +0100	[thread overview]
Message-ID: <20170301084326.tdz32zvjg62znclq@phenom.ffwll.local> (raw)
In-Reply-To: <CAA5enKa4Asp4qSHkeV3saLZrhOMf2DJ9vuiwTDo1t5t54z4sTQ@mail.gmail.com>

On Tue, Feb 28, 2017 at 08:28:08PM +0000, Lorenzo Stoakes wrote:
> On 28 February 2017 at 19:35, Al Viro <viro@zeniv.linux.org.uk> wrote:
> > On Tue, Feb 28, 2017 at 10:01:10AM +0100, Daniel Vetter wrote:
> >
> >> > +   ret = get_user_pages_unlocked((unsigned long)xfer->mem_addr,
> >> > +                   vsg->num_pages, vsg->pages,
> >> > +                   (vsg->direction == DMA_FROM_DEVICE) ? FOLL_WRITE : 0);
> >
> > Umm...  Why not
> >         ret = get_user_pages_fast((unsigned long)xfer->mem_addr,
> >                         vsg->num_pages,
> >                         vsg->direction == DMA_FROM_DEVICE,
> >                         vsg->pages);
> >
> > IOW, do you really need a warranty that ->mmap_sem will be grabbed and
> > released?
> 
> Daniel will be better placed to answer in this specific case, but more
> generally is there any reason why we can't just use
> get_user_pages_fast() in all such cases? These patches were simply a
> mechanical/cautious replacement for code that is more or less exactly
> equivalent but if this would make sense perhaps it'd be worth using
> gup_fast() where possible?

I have no idea. drm/via is unmaintained, it's a dri1 racy driver with
problems probably everywhere, and I'm not sure we even have someone left
who cares (there's an out-of-tree kms conversion of via, but it's stuck
since years).

In short, it's the drm dungeons and the only reason I merge patches is to
give people an easy target for test driving the patch submission process
to dri-devel. And to avoid drm being a blocker for tree-wide refactorings.
Otherwise 0 reasons to change anything here.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

WARNING: multiple messages have this Message-ID (diff)
From: Daniel Vetter <daniel@ffwll.ch>
To: Lorenzo Stoakes <lstoakes@gmail.com>
Cc: linux-mm <linux-mm@kvack.org>, Al Viro <viro@zeniv.linux.org.uk>,
	dri-devel@lists.freedesktop.org,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH RESEND] drm/via: use get_user_pages_unlocked()
Date: Wed, 1 Mar 2017 09:43:26 +0100	[thread overview]
Message-ID: <20170301084326.tdz32zvjg62znclq@phenom.ffwll.local> (raw)
In-Reply-To: <CAA5enKa4Asp4qSHkeV3saLZrhOMf2DJ9vuiwTDo1t5t54z4sTQ@mail.gmail.com>

On Tue, Feb 28, 2017 at 08:28:08PM +0000, Lorenzo Stoakes wrote:
> On 28 February 2017 at 19:35, Al Viro <viro@zeniv.linux.org.uk> wrote:
> > On Tue, Feb 28, 2017 at 10:01:10AM +0100, Daniel Vetter wrote:
> >
> >> > +   ret = get_user_pages_unlocked((unsigned long)xfer->mem_addr,
> >> > +                   vsg->num_pages, vsg->pages,
> >> > +                   (vsg->direction == DMA_FROM_DEVICE) ? FOLL_WRITE : 0);
> >
> > Umm...  Why not
> >         ret = get_user_pages_fast((unsigned long)xfer->mem_addr,
> >                         vsg->num_pages,
> >                         vsg->direction == DMA_FROM_DEVICE,
> >                         vsg->pages);
> >
> > IOW, do you really need a warranty that ->mmap_sem will be grabbed and
> > released?
> 
> Daniel will be better placed to answer in this specific case, but more
> generally is there any reason why we can't just use
> get_user_pages_fast() in all such cases? These patches were simply a
> mechanical/cautious replacement for code that is more or less exactly
> equivalent but if this would make sense perhaps it'd be worth using
> gup_fast() where possible?

I have no idea. drm/via is unmaintained, it's a dri1 racy driver with
problems probably everywhere, and I'm not sure we even have someone left
who cares (there's an out-of-tree kms conversion of via, but it's stuck
since years).

In short, it's the drm dungeons and the only reason I merge patches is to
give people an easy target for test driving the patch submission process
to dri-devel. And to avoid drm being a blocker for tree-wide refactorings.
Otherwise 0 reasons to change anything here.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  reply	other threads:[~2017-03-01  8:43 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-27 21:50 [PATCH RESEND] drm/via: use get_user_pages_unlocked() Lorenzo Stoakes
2017-02-27 21:50 ` Lorenzo Stoakes
2017-02-28  9:01 ` Daniel Vetter
2017-02-28  9:01   ` Daniel Vetter
2017-02-28  9:01   ` Daniel Vetter
2017-02-28 19:35   ` Al Viro
2017-02-28 19:35     ` Al Viro
2017-02-28 20:28     ` Lorenzo Stoakes
2017-02-28 20:28       ` Lorenzo Stoakes
2017-03-01  8:43       ` Daniel Vetter [this message]
2017-03-01  8:43         ` Daniel Vetter
2017-03-01  8:43         ` 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=20170301084326.tdz32zvjg62znclq@phenom.ffwll.local \
    --to=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=lstoakes@gmail.com \
    --cc=viro@zeniv.linux.org.uk \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.