All of lore.kernel.org
 help / color / mirror / Atom feed
From: John Hubbard <jhubbard@nvidia.com>
To: Daniel Vetter <daniel.vetter@ffwll.ch>,
	DRI Development <dri-devel@lists.freedesktop.org>
Cc: LKML <linux-kernel@vger.kernel.org>,
	"Daniel Vetter" <daniel.vetter@intel.com>,
	"Andrew Morton" <akpm@linux-foundation.org>,
	"Jérôme Glisse" <jglisse@redhat.com>, "Jan Kara" <jack@suse.cz>,
	"Dan Williams" <dan.j.williams@intel.com>,
	linux-mm@kvack.org, linux-arm-kernel@lists.infradead.org,
	linux-samsung-soc@vger.kernel.org, linux-media@vger.kernel.org
Subject: Re: [PATCH 2/2] mm/frame-vec: use FOLL_LONGTERM
Date: Fri, 2 Oct 2020 15:39:18 -0700	[thread overview]
Message-ID: <cb56763e-4fda-a783-03ae-7f749ec55981@nvidia.com> (raw)
In-Reply-To: <20201002175303.390363-2-daniel.vetter@ffwll.ch>

On 10/2/20 10:53 AM, Daniel Vetter wrote:
> For $reasons I've stumbled over this code and I'm not sure the change
> to the new gup functions in 55a650c35fea ("mm/gup: frame_vector:
> convert get_user_pages() --> pin_user_pages()") was entirely correct.
> 
> This here is used for long term buffers (not just quick I/O) like
> RDMA, and John notes this in his patch. But I thought the rule for
> these is that they need to add FOLL_LONGTERM, which John's patch
> didn't do.

Yep. The earlier gup --> pup conversion patches were intended to not
have any noticeable behavior changes, and FOLL_LONGTERM, with it's
special cases and such, added some risk that I wasn't ready to take
on yet. Also, FOLL_LONGTERM rules are only *recently* getting firmed
up. So there was some doubt at least in my mind, about which sites
should have it.

But now that we're here, I think it's really good that you've brought
this up. It's definitely time to add FOLL_LONGTERM wherever it's missing.

thanks,
-- 
John Hubbard
NVIDIA

> 
> There is already a dax specific check (added in b7f0554a56f2 ("mm:
> fail get_vaddr_frames() for filesystem-dax mappings")), so this seems
> like the prudent thing to do.
> 
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: John Hubbard <jhubbard@nvidia.com>
> Cc: Jérôme Glisse <jglisse@redhat.com>
> Cc: Jan Kara <jack@suse.cz>
> Cc: Dan Williams <dan.j.williams@intel.com>
> Cc: linux-mm@kvack.org
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: linux-samsung-soc@vger.kernel.org
> Cc: linux-media@vger.kernel.org
> ---
> Hi all,
> 
> I stumbled over this and figured typing this patch can't hurt. Really
> just to maybe learn a few things about how gup/pup is supposed to be
> used (we have a bit of that in drivers/gpu), this here isn't really
> ralated to anything I'm doing.
> 
> I'm also wondering whether the explicit dax check should be removed,
> since FOLL_LONGTERM should take care of that already.
> -Daniel
> ---
>   mm/frame_vector.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/mm/frame_vector.c b/mm/frame_vector.c
> index 5d34c9047e9c..3507e09cb3ff 100644
> --- a/mm/frame_vector.c
> +++ b/mm/frame_vector.c
> @@ -35,7 +35,7 @@ int get_vaddr_frames(unsigned long start, unsigned int nr_frames,
>   {
>   	struct mm_struct *mm = current->mm;
>   	struct vm_area_struct *vma;
> -	unsigned int gup_flags = FOLL_WRITE | FOLL_FORCE;
> +	unsigned int gup_flags = FOLL_WRITE | FOLL_FORCE | FOLL_LONGTERM;
>   	int ret = 0;
>   	int err;
>   	int locked;
> 


WARNING: multiple messages have this Message-ID (diff)
From: John Hubbard <jhubbard@nvidia.com>
To: Daniel Vetter <daniel.vetter@ffwll.ch>,
	DRI Development <dri-devel@lists.freedesktop.org>
Cc: linux-samsung-soc@vger.kernel.org, "Jan Kara" <jack@suse.cz>,
	LKML <linux-kernel@vger.kernel.org>,
	linux-mm@kvack.org, "Jérôme Glisse" <jglisse@redhat.com>,
	"Daniel Vetter" <daniel.vetter@intel.com>,
	"Andrew Morton" <akpm@linux-foundation.org>,
	"Dan Williams" <dan.j.williams@intel.com>,
	linux-arm-kernel@lists.infradead.org,
	linux-media@vger.kernel.org
Subject: Re: [PATCH 2/2] mm/frame-vec: use FOLL_LONGTERM
Date: Fri, 2 Oct 2020 15:39:18 -0700	[thread overview]
Message-ID: <cb56763e-4fda-a783-03ae-7f749ec55981@nvidia.com> (raw)
In-Reply-To: <20201002175303.390363-2-daniel.vetter@ffwll.ch>

On 10/2/20 10:53 AM, Daniel Vetter wrote:
> For $reasons I've stumbled over this code and I'm not sure the change
> to the new gup functions in 55a650c35fea ("mm/gup: frame_vector:
> convert get_user_pages() --> pin_user_pages()") was entirely correct.
> 
> This here is used for long term buffers (not just quick I/O) like
> RDMA, and John notes this in his patch. But I thought the rule for
> these is that they need to add FOLL_LONGTERM, which John's patch
> didn't do.

Yep. The earlier gup --> pup conversion patches were intended to not
have any noticeable behavior changes, and FOLL_LONGTERM, with it's
special cases and such, added some risk that I wasn't ready to take
on yet. Also, FOLL_LONGTERM rules are only *recently* getting firmed
up. So there was some doubt at least in my mind, about which sites
should have it.

But now that we're here, I think it's really good that you've brought
this up. It's definitely time to add FOLL_LONGTERM wherever it's missing.

thanks,
-- 
John Hubbard
NVIDIA

> 
> There is already a dax specific check (added in b7f0554a56f2 ("mm:
> fail get_vaddr_frames() for filesystem-dax mappings")), so this seems
> like the prudent thing to do.
> 
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: John Hubbard <jhubbard@nvidia.com>
> Cc: Jérôme Glisse <jglisse@redhat.com>
> Cc: Jan Kara <jack@suse.cz>
> Cc: Dan Williams <dan.j.williams@intel.com>
> Cc: linux-mm@kvack.org
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: linux-samsung-soc@vger.kernel.org
> Cc: linux-media@vger.kernel.org
> ---
> Hi all,
> 
> I stumbled over this and figured typing this patch can't hurt. Really
> just to maybe learn a few things about how gup/pup is supposed to be
> used (we have a bit of that in drivers/gpu), this here isn't really
> ralated to anything I'm doing.
> 
> I'm also wondering whether the explicit dax check should be removed,
> since FOLL_LONGTERM should take care of that already.
> -Daniel
> ---
>   mm/frame_vector.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/mm/frame_vector.c b/mm/frame_vector.c
> index 5d34c9047e9c..3507e09cb3ff 100644
> --- a/mm/frame_vector.c
> +++ b/mm/frame_vector.c
> @@ -35,7 +35,7 @@ int get_vaddr_frames(unsigned long start, unsigned int nr_frames,
>   {
>   	struct mm_struct *mm = current->mm;
>   	struct vm_area_struct *vma;
> -	unsigned int gup_flags = FOLL_WRITE | FOLL_FORCE;
> +	unsigned int gup_flags = FOLL_WRITE | FOLL_FORCE | FOLL_LONGTERM;
>   	int ret = 0;
>   	int err;
>   	int locked;
> 


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

WARNING: multiple messages have this Message-ID (diff)
From: John Hubbard <jhubbard@nvidia.com>
To: Daniel Vetter <daniel.vetter@ffwll.ch>,
	DRI Development <dri-devel@lists.freedesktop.org>
Cc: linux-samsung-soc@vger.kernel.org, "Jan Kara" <jack@suse.cz>,
	LKML <linux-kernel@vger.kernel.org>,
	linux-mm@kvack.org, "Jérôme Glisse" <jglisse@redhat.com>,
	"Daniel Vetter" <daniel.vetter@intel.com>,
	"Andrew Morton" <akpm@linux-foundation.org>,
	"Dan Williams" <dan.j.williams@intel.com>,
	linux-arm-kernel@lists.infradead.org,
	linux-media@vger.kernel.org
Subject: Re: [PATCH 2/2] mm/frame-vec: use FOLL_LONGTERM
Date: Fri, 2 Oct 2020 15:39:18 -0700	[thread overview]
Message-ID: <cb56763e-4fda-a783-03ae-7f749ec55981@nvidia.com> (raw)
In-Reply-To: <20201002175303.390363-2-daniel.vetter@ffwll.ch>

On 10/2/20 10:53 AM, Daniel Vetter wrote:
> For $reasons I've stumbled over this code and I'm not sure the change
> to the new gup functions in 55a650c35fea ("mm/gup: frame_vector:
> convert get_user_pages() --> pin_user_pages()") was entirely correct.
> 
> This here is used for long term buffers (not just quick I/O) like
> RDMA, and John notes this in his patch. But I thought the rule for
> these is that they need to add FOLL_LONGTERM, which John's patch
> didn't do.

Yep. The earlier gup --> pup conversion patches were intended to not
have any noticeable behavior changes, and FOLL_LONGTERM, with it's
special cases and such, added some risk that I wasn't ready to take
on yet. Also, FOLL_LONGTERM rules are only *recently* getting firmed
up. So there was some doubt at least in my mind, about which sites
should have it.

But now that we're here, I think it's really good that you've brought
this up. It's definitely time to add FOLL_LONGTERM wherever it's missing.

thanks,
-- 
John Hubbard
NVIDIA

> 
> There is already a dax specific check (added in b7f0554a56f2 ("mm:
> fail get_vaddr_frames() for filesystem-dax mappings")), so this seems
> like the prudent thing to do.
> 
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: John Hubbard <jhubbard@nvidia.com>
> Cc: Jérôme Glisse <jglisse@redhat.com>
> Cc: Jan Kara <jack@suse.cz>
> Cc: Dan Williams <dan.j.williams@intel.com>
> Cc: linux-mm@kvack.org
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: linux-samsung-soc@vger.kernel.org
> Cc: linux-media@vger.kernel.org
> ---
> Hi all,
> 
> I stumbled over this and figured typing this patch can't hurt. Really
> just to maybe learn a few things about how gup/pup is supposed to be
> used (we have a bit of that in drivers/gpu), this here isn't really
> ralated to anything I'm doing.
> 
> I'm also wondering whether the explicit dax check should be removed,
> since FOLL_LONGTERM should take care of that already.
> -Daniel
> ---
>   mm/frame_vector.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/mm/frame_vector.c b/mm/frame_vector.c
> index 5d34c9047e9c..3507e09cb3ff 100644
> --- a/mm/frame_vector.c
> +++ b/mm/frame_vector.c
> @@ -35,7 +35,7 @@ int get_vaddr_frames(unsigned long start, unsigned int nr_frames,
>   {
>   	struct mm_struct *mm = current->mm;
>   	struct vm_area_struct *vma;
> -	unsigned int gup_flags = FOLL_WRITE | FOLL_FORCE;
> +	unsigned int gup_flags = FOLL_WRITE | FOLL_FORCE | FOLL_LONGTERM;
>   	int ret = 0;
>   	int err;
>   	int locked;
> 

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  parent reply	other threads:[~2020-10-02 22:39 UTC|newest]

Thread overview: 156+ 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 ` Daniel Vetter
2020-10-02 17:53 ` Daniel Vetter
2020-10-02 17:53 ` [PATCH 2/2] mm/frame-vec: use FOLL_LONGTERM Daniel Vetter
2020-10-02 17:53   ` Daniel Vetter
2020-10-02 17:53   ` Daniel Vetter
2020-10-02 18:06   ` Jason Gunthorpe
2020-10-02 18:06     ` Jason Gunthorpe
2020-10-02 18:06     ` Jason Gunthorpe
2020-10-02 18:16     ` Daniel Vetter
2020-10-02 18:16       ` Daniel Vetter
2020-10-02 18:16       ` Daniel Vetter
2020-10-02 23:31       ` Jason Gunthorpe
2020-10-02 23:31         ` Jason Gunthorpe
2020-10-02 23:31         ` Jason Gunthorpe
2020-10-03  8:34         ` Oded Gabbay
2020-10-03  8:34           ` Oded Gabbay
2020-10-03  8:34           ` Oded Gabbay
2020-10-03  9:40         ` Daniel Vetter
2020-10-03  9:40           ` Daniel Vetter
2020-10-03  9:40           ` Daniel Vetter
2020-10-04 12:50           ` Jason Gunthorpe
2020-10-04 12:50             ` Jason Gunthorpe
2020-10-04 12:50             ` Jason Gunthorpe
2020-10-04 16:09             ` Daniel Vetter
2020-10-04 16:09               ` Daniel Vetter
2020-10-04 16:09               ` Daniel Vetter
2020-10-05 17:28               ` Jason Gunthorpe
2020-10-05 17:28                 ` Jason Gunthorpe
2020-10-05 17:28                 ` Jason Gunthorpe
2020-10-05 18:16                 ` Daniel Vetter
2020-10-05 18:16                   ` Daniel Vetter
2020-10-05 18:16                   ` Daniel Vetter
2020-10-05 18:37                   ` Jason Gunthorpe
2020-10-05 18:37                     ` Jason Gunthorpe
2020-10-05 18:37                     ` Jason Gunthorpe
2020-10-05 18:54                     ` Daniel Vetter
2020-10-05 18:54                       ` Daniel Vetter
2020-10-05 18:54                       ` Daniel Vetter
2020-10-05 22:43                       ` Daniel Vetter
2020-10-05 22:43                         ` Daniel Vetter
2020-10-05 22:43                         ` Daniel Vetter
2020-10-05 23:41                         ` Jason Gunthorpe
2020-10-05 23:41                           ` Jason Gunthorpe
2020-10-05 23:41                           ` Jason Gunthorpe
2020-10-06  6:23                           ` Daniel Vetter
2020-10-06  6:23                             ` Daniel Vetter
2020-10-06  6:23                             ` Daniel Vetter
2020-10-06 12:26                             ` Jason Gunthorpe
2020-10-06 12:26                               ` Jason Gunthorpe
2020-10-06 12:26                               ` Jason Gunthorpe
2020-10-06 13:08                               ` Daniel Vetter
2020-10-06 13:08                                 ` Daniel Vetter
2020-10-06 13:08                                 ` Daniel Vetter
2020-10-07 10:47           ` Marek Szyprowski
2020-10-07 10:47             ` Marek Szyprowski
2020-10-07 10:47             ` Marek Szyprowski
2020-10-07 12:01             ` Daniel Vetter
2020-10-07 12:01               ` Daniel Vetter
2020-10-07 12:01               ` Daniel Vetter
2020-10-07 12:33               ` Marek Szyprowski
2020-10-07 12:33                 ` Marek Szyprowski
2020-10-07 12:33                 ` Marek Szyprowski
2020-10-07 12:44                 ` Jason Gunthorpe
2020-10-07 12:44                   ` Jason Gunthorpe
2020-10-07 12:44                   ` Jason Gunthorpe
2020-10-07 12:47                   ` Tomasz Figa
2020-10-07 12:47                     ` Tomasz Figa
2020-10-07 12:47                     ` Tomasz Figa
2020-10-07 12:58                     ` Daniel Vetter
2020-10-07 12:58                       ` Daniel Vetter
2020-10-07 12:58                       ` Daniel Vetter
2020-10-07 13:06                       ` Jason Gunthorpe
2020-10-07 13:06                         ` Jason Gunthorpe
2020-10-07 13:06                         ` Jason Gunthorpe
2020-10-07 13:34                         ` Tomasz Figa
2020-10-07 13:34                           ` Tomasz Figa
2020-10-07 13:34                           ` Tomasz Figa
2020-10-07 13:42                           ` Jason Gunthorpe
2020-10-07 13:42                             ` Jason Gunthorpe
2020-10-07 13:42                             ` Jason Gunthorpe
2020-10-07 14:08                           ` Daniel Vetter
2020-10-07 14:08                             ` Daniel Vetter
2020-10-07 14:08                             ` Daniel Vetter
2020-10-07 14:11                             ` Tomasz Figa
2020-10-07 14:11                               ` Tomasz Figa
2020-10-07 14:11                               ` Tomasz Figa
2020-10-07 14:22                               ` Daniel Vetter
2020-10-07 14:22                                 ` Daniel Vetter
2020-10-07 14:22                                 ` Daniel Vetter
2020-10-07 15:05                                 ` Tomasz Figa
2020-10-07 15:05                                   ` Tomasz Figa
2020-10-07 15:05                                   ` Tomasz Figa
2020-10-07 14:58                               ` Jason Gunthorpe
2020-10-07 14:58                                 ` Jason Gunthorpe
2020-10-07 14:58                                 ` Jason Gunthorpe
2020-10-07 13:06         ` Tomasz Figa
2020-10-07 13:06           ` Tomasz Figa
2020-10-07 13:06           ` Tomasz Figa
2020-10-07 13:14           ` Jason Gunthorpe
2020-10-07 13:14             ` Jason Gunthorpe
2020-10-07 13:14             ` Jason Gunthorpe
2020-10-05 15:03     ` Jan Kara
2020-10-05 15:03       ` Jan Kara
2020-10-05 15:03       ` Jan Kara
2020-10-02 22:39   ` John Hubbard [this message]
2020-10-02 22:39     ` John Hubbard
2020-10-02 22:39     ` John Hubbard
2020-10-03  9:45     ` Daniel Vetter
2020-10-03  9:45       ` Daniel Vetter
2020-10-03  9:45       ` Daniel Vetter
2020-10-03 22:52       ` John Hubbard
2020-10-03 22:52         ` John Hubbard
2020-10-03 22:52         ` John Hubbard
2020-10-03 23:24         ` Jason Gunthorpe
2020-10-03 23:24           ` Jason Gunthorpe
2020-10-03 23:24           ` Jason Gunthorpe
2020-10-04 11:20           ` Daniel Vetter
2020-10-04 11:20             ` Daniel Vetter
2020-10-04 11:20             ` Daniel Vetter
2020-10-05 17:35             ` Jason Gunthorpe
2020-10-05 17:35               ` Jason Gunthorpe
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 18:22   ` Tomasz Figa
2020-10-02 18:22   ` Tomasz Figa
2020-10-02 18:22   ` Tomasz Figa
2020-10-02 19:21   ` Oded Gabbay
2020-10-02 19:21     ` Oded Gabbay
2020-10-02 19:21     ` Oded Gabbay
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:38 ` Jason Gunthorpe
2020-10-05 17:47 ` Jason Gunthorpe
2020-10-05 17:47   ` Jason Gunthorpe
2020-10-05 17:47   ` Jason Gunthorpe
2020-10-06  3:36   ` Andrew Morton
2020-10-06  3:36     ` Andrew Morton
2020-10-06  3:36     ` Andrew Morton
2020-10-06 11:57     ` Jason Gunthorpe
2020-10-06 11:57       ` Jason Gunthorpe
2020-10-06 11:57       ` Jason Gunthorpe
2020-10-05 17:53 ` Jan Kara
2020-10-05 17:53   ` Jan Kara
2020-10-05 17:53   ` Jan Kara
2020-10-05 17:57   ` Jason Gunthorpe
2020-10-05 17:57     ` Jason Gunthorpe
2020-10-05 17:57     ` Jason Gunthorpe
2020-10-05 18:16     ` Daniel Vetter
2020-10-05 18:16       ` Daniel Vetter
2020-10-05 18:16       ` Daniel Vetter
2020-10-05 18:16       ` Daniel Vetter
2020-10-06 11:56     ` Daniel Vetter
2020-10-06 11:56       ` Daniel Vetter
2020-10-06 11:56       ` 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=cb56763e-4fda-a783-03ae-7f749ec55981@nvidia.com \
    --to=jhubbard@nvidia.com \
    --cc=akpm@linux-foundation.org \
    --cc=dan.j.williams@intel.com \
    --cc=daniel.vetter@ffwll.ch \
    --cc=daniel.vetter@intel.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=jack@suse.cz \
    --cc=jglisse@redhat.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 \
    /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.