All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrea Arcangeli <aarcange@redhat.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-mm@kvack.org, Andres Lagar-Cavilla <andreslc@google.com>,
	Gleb Natapov <gleb@kernel.org>, Radim Krcmar <rkrcmar@redhat.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Rik van Riel <riel@redhat.com>, Mel Gorman <mgorman@suse.de>,
	Andy Lutomirski <luto@amacapital.net>,
	Andrew Morton <akpm@linux-foundation.org>,
	Sasha Levin <sasha.levin@oracle.com>,
	Jianyu Zhan <nasa4836@gmail.com>,
	Paul Cassella <cassella@cray.com>,
	Hugh Dickins <hughd@google.com>,
	Peter Feiner <pfeiner@google.com>,
	"\\\"Dr. David Alan Gilbert\\\"" <dgilbert@redhat.com>
Subject: Re: [PATCH 2/4] mm: gup: add get_user_pages_locked and get_user_pages_unlocked
Date: Wed, 29 Oct 2014 17:39:08 +0100	[thread overview]
Message-ID: <20141029163908.GI19606@redhat.com> (raw)
In-Reply-To: <20141009105037.GM4750@worktop.programming.kicks-ass.net>

On Thu, Oct 09, 2014 at 12:50:37PM +0200, Peter Zijlstra wrote:
> On Wed, Oct 01, 2014 at 10:56:35AM +0200, Andrea Arcangeli wrote:
> 
> > +static inline long __get_user_pages_locked(struct task_struct *tsk,
> > +					   struct mm_struct *mm,
> > +					   unsigned long start,
> > +					   unsigned long nr_pages,
> > +					   int write, int force,
> > +					   struct page **pages,
> > +					   struct vm_area_struct **vmas,
> > +					   int *locked,
> > +					   bool notify_drop)
> > +{
> 
> > +	if (notify_drop && lock_dropped && *locked) {
> > +		/*
> > +		 * We must let the caller know we temporarily dropped the lock
> > +		 * and so the critical section protected by it was lost.
> > +		 */
> > +		up_read(&mm->mmap_sem);
> > +		*locked = 0;
> > +	}
> > +	return pages_done;
> > +}
> 
> > +long get_user_pages_locked(struct task_struct *tsk, struct mm_struct *mm,
> > +			   unsigned long start, unsigned long nr_pages,
> > +			   int write, int force, struct page **pages,
> > +			   int *locked)
> > +{
> > +	return __get_user_pages_locked(tsk, mm, start, nr_pages, write, force,
> > +				       pages, NULL, locked, true);
> > +}
> 
> > +long get_user_pages_unlocked(struct task_struct *tsk, struct mm_struct *mm,
> > +			     unsigned long start, unsigned long nr_pages,
> > +			     int write, int force, struct page **pages)
> > +{
> > +	long ret;
> > +	int locked = 1;
> > +	down_read(&mm->mmap_sem);
> > +	ret = __get_user_pages_locked(tsk, mm, start, nr_pages, write, force,
> > +				      pages, NULL, &locked, false);
> > +	if (locked)
> > +		up_read(&mm->mmap_sem);
> > +	return ret;
> > +}
> 
> >  long get_user_pages(struct task_struct *tsk, struct mm_struct *mm,
> >  		unsigned long start, unsigned long nr_pages, int write,
> >  		int force, struct page **pages, struct vm_area_struct **vmas)
> >  {
> > +	return __get_user_pages_locked(tsk, mm, start, nr_pages, write, force,
> > +				       pages, vmas, NULL, false);
> >  }
> 
> I'm wondering about that notify_drop parameter, what's the added
> benefit? If you look at these 3 callers we can do away with it, since in
> the second called where we have locked but !notify_drop we seem to do

The second (and third) caller pass notify_drop=false, so the
notify_drop parameter is always a noop for them. They certainly could
get away without it.

> the exact same thing afterwards anyway.

It makes a difference only to the first caller, if it wasn't for the
first caller notify_drop could be dropped. The first caller does this:

	return __get_user_pages_locked(tsk, mm, start, nr_pages, write, force,
				       pages, NULL, locked, true, FOLL_TOUCH);
				       	      	            ^ notify_drop = true

Without "notify_drop=true" the first caller could make its own
respective caller think the lock has never been dropped, just because
it is locked by the time get_user_pages_locked returned. But the
caller must be made aware that the lock has been dropped during the
call and in turn any "vma" it got before inside the mmap_sem critical
section is now stale. That's all notify_drop achieves.

Thanks,
Andrea

--
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: Andrea Arcangeli <aarcange@redhat.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-mm@kvack.org, Andres Lagar-Cavilla <andreslc@google.com>,
	Gleb Natapov <gleb@kernel.org>, Radim Krcmar <rkrcmar@redhat.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Rik van Riel <riel@redhat.com>, Mel Gorman <mgorman@suse.de>,
	Andy Lutomirski <luto@amacapital.net>,
	Andrew Morton <akpm@linux-foundation.org>,
	Sasha Levin <sasha.levin@oracle.com>,
	Jianyu Zhan <nasa4836@gmail.com>,
	Paul Cassella <cassella@cray.com>,
	Hugh Dickins <hughd@google.com>,
	Peter Feiner <pfeiner@google.com>,
	"\\\"Dr. David Alan Gilbert\\\"" <dgilbert@redhat.com>
Subject: Re: [PATCH 2/4] mm: gup: add get_user_pages_locked and get_user_pages_unlocked
Date: Wed, 29 Oct 2014 17:39:08 +0100	[thread overview]
Message-ID: <20141029163908.GI19606@redhat.com> (raw)
In-Reply-To: <20141009105037.GM4750@worktop.programming.kicks-ass.net>

On Thu, Oct 09, 2014 at 12:50:37PM +0200, Peter Zijlstra wrote:
> On Wed, Oct 01, 2014 at 10:56:35AM +0200, Andrea Arcangeli wrote:
> 
> > +static inline long __get_user_pages_locked(struct task_struct *tsk,
> > +					   struct mm_struct *mm,
> > +					   unsigned long start,
> > +					   unsigned long nr_pages,
> > +					   int write, int force,
> > +					   struct page **pages,
> > +					   struct vm_area_struct **vmas,
> > +					   int *locked,
> > +					   bool notify_drop)
> > +{
> 
> > +	if (notify_drop && lock_dropped && *locked) {
> > +		/*
> > +		 * We must let the caller know we temporarily dropped the lock
> > +		 * and so the critical section protected by it was lost.
> > +		 */
> > +		up_read(&mm->mmap_sem);
> > +		*locked = 0;
> > +	}
> > +	return pages_done;
> > +}
> 
> > +long get_user_pages_locked(struct task_struct *tsk, struct mm_struct *mm,
> > +			   unsigned long start, unsigned long nr_pages,
> > +			   int write, int force, struct page **pages,
> > +			   int *locked)
> > +{
> > +	return __get_user_pages_locked(tsk, mm, start, nr_pages, write, force,
> > +				       pages, NULL, locked, true);
> > +}
> 
> > +long get_user_pages_unlocked(struct task_struct *tsk, struct mm_struct *mm,
> > +			     unsigned long start, unsigned long nr_pages,
> > +			     int write, int force, struct page **pages)
> > +{
> > +	long ret;
> > +	int locked = 1;
> > +	down_read(&mm->mmap_sem);
> > +	ret = __get_user_pages_locked(tsk, mm, start, nr_pages, write, force,
> > +				      pages, NULL, &locked, false);
> > +	if (locked)
> > +		up_read(&mm->mmap_sem);
> > +	return ret;
> > +}
> 
> >  long get_user_pages(struct task_struct *tsk, struct mm_struct *mm,
> >  		unsigned long start, unsigned long nr_pages, int write,
> >  		int force, struct page **pages, struct vm_area_struct **vmas)
> >  {
> > +	return __get_user_pages_locked(tsk, mm, start, nr_pages, write, force,
> > +				       pages, vmas, NULL, false);
> >  }
> 
> I'm wondering about that notify_drop parameter, what's the added
> benefit? If you look at these 3 callers we can do away with it, since in
> the second called where we have locked but !notify_drop we seem to do

The second (and third) caller pass notify_drop=false, so the
notify_drop parameter is always a noop for them. They certainly could
get away without it.

> the exact same thing afterwards anyway.

It makes a difference only to the first caller, if it wasn't for the
first caller notify_drop could be dropped. The first caller does this:

	return __get_user_pages_locked(tsk, mm, start, nr_pages, write, force,
				       pages, NULL, locked, true, FOLL_TOUCH);
				       	      	            ^ notify_drop = true

Without "notify_drop=true" the first caller could make its own
respective caller think the lock has never been dropped, just because
it is locked by the time get_user_pages_locked returned. But the
caller must be made aware that the lock has been dropped during the
call and in turn any "vma" it got before inside the mmap_sem critical
section is now stale. That's all notify_drop achieves.

Thanks,
Andrea

  reply	other threads:[~2014-10-29 16:39 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-01  8:56 [PATCH 0/4] leverage FAULT_FOLL_ALLOW_RETRY in get_user_pages Andrea Arcangeli
2014-10-01  8:56 ` Andrea Arcangeli
2014-10-01  8:56 ` [PATCH 1/4] mm: gup: add FOLL_TRIED Andrea Arcangeli
2014-10-01  8:56   ` Andrea Arcangeli
2014-10-01  8:56   ` Andrea Arcangeli
2014-10-09 10:35   ` Peter Zijlstra
2014-10-09 10:35     ` Peter Zijlstra
2014-10-09 10:35     ` Peter Zijlstra
2014-10-01  8:56 ` [PATCH 2/4] mm: gup: add get_user_pages_locked and get_user_pages_unlocked Andrea Arcangeli
2014-10-01  8:56   ` Andrea Arcangeli
2014-10-01 15:51   ` Peter Feiner
2014-10-01 15:51     ` Peter Feiner
2014-10-01 17:06     ` Andres Lagar-Cavilla
2014-10-01 17:06       ` Andres Lagar-Cavilla
2014-10-02 12:40       ` Andrea Arcangeli
2014-10-02 12:40         ` Andrea Arcangeli
2014-10-09 10:47   ` Peter Zijlstra
2014-10-09 10:47     ` Peter Zijlstra
2014-10-29 16:41     ` Andrea Arcangeli
2014-10-29 16:41       ` Andrea Arcangeli
2014-10-09 10:50   ` Peter Zijlstra
2014-10-09 10:50     ` Peter Zijlstra
2014-10-29 16:39     ` Andrea Arcangeli [this message]
2014-10-29 16:39       ` Andrea Arcangeli
2014-10-01  8:56 ` [PATCH 3/4] mm: gup: use get_user_pages_fast " Andrea Arcangeli
2014-10-01  8:56   ` Andrea Arcangeli
2014-10-01  9:10   ` Andrea Arcangeli
2014-10-01  9:10     ` Andrea Arcangeli
2014-10-01 16:54   ` Sasha Levin
2014-10-01 16:54     ` Sasha Levin
2014-10-09 10:52   ` Peter Zijlstra
2014-10-09 10:52     ` Peter Zijlstra
2014-10-12 13:24     ` Andrea Arcangeli
2014-10-12 13:24       ` Andrea Arcangeli
2014-10-01  8:56 ` [PATCH 4/4] mm: gup: use get_user_pages_unlocked within get_user_pages_fast Andrea Arcangeli
2014-10-01  8:56   ` Andrea Arcangeli

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=20141029163908.GI19606@redhat.com \
    --to=aarcange@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=andreslc@google.com \
    --cc=cassella@cray.com \
    --cc=dgilbert@redhat.com \
    --cc=gleb@kernel.org \
    --cc=hughd@google.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=luto@amacapital.net \
    --cc=mgorman@suse.de \
    --cc=nasa4836@gmail.com \
    --cc=pbonzini@redhat.com \
    --cc=peterz@infradead.org \
    --cc=pfeiner@google.com \
    --cc=riel@redhat.com \
    --cc=rkrcmar@redhat.com \
    --cc=sasha.levin@oracle.com \
    /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.