All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jerome Glisse <jglisse@redhat.com>
To: Tejun Heo <tj@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	security@kernel.org, linux-kernel@vger.kernel.org,
	kernel-team@fb.com, linux-mm@kvack.org,
	torvalds@linux-foundation.org, jannh@google.com,
	paulmck@linux.vnet.ibm.com, bcrl@kvack.org,
	viro@zeniv.linux.org.uk, kent.overstreet@gmail.com
Subject: Re: [PATCH 4/8] HMM: Remove superflous RCU protection around radix tree lookup
Date: Tue, 27 Mar 2018 12:12:45 -0400	[thread overview]
Message-ID: <20180327161244.GA4251@redhat.com> (raw)
In-Reply-To: <20180326145431.GC1840639@devbig577.frc2.facebook.com>

On Mon, Mar 26, 2018 at 07:54:31AM -0700, Tejun Heo wrote:
> Hello, Andrew.
> 
> Do you mind picking up the following patch?  I can't find a good tree
> to route this through.  The raw patch can be found at
> 
>   https://marc.info/?l=linux-mm&m=152105674112496&q=raw
> 
> Thank you very much.

I am fine with which ever route there is low probability of conflict
when merging HMM through different tree.


> 
> On Wed, Mar 14, 2018 at 12:45:11PM -0700, Tejun Heo wrote:
> > hmm_devmem_find() requires rcu_read_lock_held() but there's nothing
> > which actually uses the RCU protection.  The only caller is
> > hmm_devmem_pages_create() which already grabs the mutex and does
> > superflous rcu_read_lock/unlock() around the function.
> > 
> > This doesn't add anything and just adds to confusion.  Remove the RCU
> > protection and open-code the radix tree lookup.  If this needs to
> > become more sophisticated in the future, let's add them back when
> > necessary.
> > 
> > Signed-off-by: Tejun Heo <tj@kernel.org>
> > Reviewed-by: Jérôme Glisse <jglisse@redhat.com>
> > Cc: linux-mm@kvack.org
> > Cc: Linus Torvalds <torvalds@linux-foundation.org>
> > ---
> > Hello,
> > 
> > Jérôme, how do you want to route this patch?  If you prefer, I can
> > route it together with other patches.
> > 
> > Thanks.
> > 
> >  mm/hmm.c | 12 ++----------
> >  1 file changed, 2 insertions(+), 10 deletions(-)
> > 
> > diff --git a/mm/hmm.c b/mm/hmm.c
> > index 320545b98..d4627c5 100644
> > --- a/mm/hmm.c
> > +++ b/mm/hmm.c
> > @@ -845,13 +845,6 @@ static void hmm_devmem_release(struct device *dev, void *data)
> >  	hmm_devmem_radix_release(resource);
> >  }
> >  
> > -static struct hmm_devmem *hmm_devmem_find(resource_size_t phys)
> > -{
> > -	WARN_ON_ONCE(!rcu_read_lock_held());
> > -
> > -	return radix_tree_lookup(&hmm_devmem_radix, phys >> PA_SECTION_SHIFT);
> > -}
> > -
> >  static int hmm_devmem_pages_create(struct hmm_devmem *devmem)
> >  {
> >  	resource_size_t key, align_start, align_size, align_end;
> > @@ -892,9 +885,8 @@ static int hmm_devmem_pages_create(struct hmm_devmem *devmem)
> >  	for (key = align_start; key <= align_end; key += PA_SECTION_SIZE) {
> >  		struct hmm_devmem *dup;
> >  
> > -		rcu_read_lock();
> > -		dup = hmm_devmem_find(key);
> > -		rcu_read_unlock();
> > +		dup = radix_tree_lookup(&hmm_devmem_radix,
> > +					key >> PA_SECTION_SHIFT);
> >  		if (dup) {
> >  			dev_err(device, "%s: collides with mapping for %s\n",
> >  				__func__, dev_name(dup->device));
> > -- 
> > 2.9.5
> > 
> 
> -- 
> tejun

WARNING: multiple messages have this Message-ID (diff)
From: Jerome Glisse <jglisse@redhat.com>
To: Tejun Heo <tj@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	security@kernel.org, linux-kernel@vger.kernel.org,
	kernel-team@fb.com, linux-mm@kvack.org,
	torvalds@linux-foundation.org, jannh@google.com,
	paulmck@linux.vnet.ibm.com, bcrl@kvack.org,
	viro@zeniv.linux.org.uk, kent.overstreet@gmail.com
Subject: Re: [PATCH 4/8] HMM: Remove superflous RCU protection around radix tree lookup
Date: Tue, 27 Mar 2018 12:12:45 -0400	[thread overview]
Message-ID: <20180327161244.GA4251@redhat.com> (raw)
In-Reply-To: <20180326145431.GC1840639@devbig577.frc2.facebook.com>

On Mon, Mar 26, 2018 at 07:54:31AM -0700, Tejun Heo wrote:
> Hello, Andrew.
> 
> Do you mind picking up the following patch?  I can't find a good tree
> to route this through.  The raw patch can be found at
> 
>   https://marc.info/?l=linux-mm&m=152105674112496&q=raw
> 
> Thank you very much.

I am fine with which ever route there is low probability of conflict
when merging HMM through different tree.


> 
> On Wed, Mar 14, 2018 at 12:45:11PM -0700, Tejun Heo wrote:
> > hmm_devmem_find() requires rcu_read_lock_held() but there's nothing
> > which actually uses the RCU protection.  The only caller is
> > hmm_devmem_pages_create() which already grabs the mutex and does
> > superflous rcu_read_lock/unlock() around the function.
> > 
> > This doesn't add anything and just adds to confusion.  Remove the RCU
> > protection and open-code the radix tree lookup.  If this needs to
> > become more sophisticated in the future, let's add them back when
> > necessary.
> > 
> > Signed-off-by: Tejun Heo <tj@kernel.org>
> > Reviewed-by: Jerome Glisse <jglisse@redhat.com>
> > Cc: linux-mm@kvack.org
> > Cc: Linus Torvalds <torvalds@linux-foundation.org>
> > ---
> > Hello,
> > 
> > Jerome, how do you want to route this patch?  If you prefer, I can
> > route it together with other patches.
> > 
> > Thanks.
> > 
> >  mm/hmm.c | 12 ++----------
> >  1 file changed, 2 insertions(+), 10 deletions(-)
> > 
> > diff --git a/mm/hmm.c b/mm/hmm.c
> > index 320545b98..d4627c5 100644
> > --- a/mm/hmm.c
> > +++ b/mm/hmm.c
> > @@ -845,13 +845,6 @@ static void hmm_devmem_release(struct device *dev, void *data)
> >  	hmm_devmem_radix_release(resource);
> >  }
> >  
> > -static struct hmm_devmem *hmm_devmem_find(resource_size_t phys)
> > -{
> > -	WARN_ON_ONCE(!rcu_read_lock_held());
> > -
> > -	return radix_tree_lookup(&hmm_devmem_radix, phys >> PA_SECTION_SHIFT);
> > -}
> > -
> >  static int hmm_devmem_pages_create(struct hmm_devmem *devmem)
> >  {
> >  	resource_size_t key, align_start, align_size, align_end;
> > @@ -892,9 +885,8 @@ static int hmm_devmem_pages_create(struct hmm_devmem *devmem)
> >  	for (key = align_start; key <= align_end; key += PA_SECTION_SIZE) {
> >  		struct hmm_devmem *dup;
> >  
> > -		rcu_read_lock();
> > -		dup = hmm_devmem_find(key);
> > -		rcu_read_unlock();
> > +		dup = radix_tree_lookup(&hmm_devmem_radix,
> > +					key >> PA_SECTION_SHIFT);
> >  		if (dup) {
> >  			dev_err(device, "%s: collides with mapping for %s\n",
> >  				__func__, dev_name(dup->device));
> > -- 
> > 2.9.5
> > 
> 
> -- 
> tejun

  reply	other threads:[~2018-03-27 16:12 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-14 19:41 [PATCHSET v2] percpu_ref, RCU: Audit RCU usages in percpu_ref users Tejun Heo
2018-03-14 19:45 ` [PATCH 1/8] fs/aio: Add explicit RCU grace period when freeing kioctx Tejun Heo
2018-03-14 19:45   ` [PATCH 2/8] fs/aio: Use RCU accessors for kioctx_table->table[] Tejun Heo
2018-03-14 19:45   ` [PATCH 3/8] RDMAVT: Fix synchronization around percpu_ref Tejun Heo
2018-03-15 22:24     ` Jason Gunthorpe
2018-03-14 19:45   ` [PATCH 4/8] HMM: Remove superflous RCU protection around radix tree lookup Tejun Heo
2018-03-14 19:45     ` Tejun Heo
2018-03-26 14:54     ` Tejun Heo
2018-03-26 14:54       ` Tejun Heo
2018-03-27 16:12       ` Jerome Glisse [this message]
2018-03-27 16:12         ` Jerome Glisse
2018-03-14 19:45   ` [PATCH 5/8] percpu_ref: Update doc to dissuade users from depending on internal RCU grace periods Tejun Heo
2018-03-19 17:10     ` Tejun Heo
2018-03-14 19:45   ` [PATCH 6/8] RCU, workqueue: Implement rcu_work Tejun Heo
2018-03-14 20:13     ` Paul E. McKenney
2018-03-16  6:01     ` Lai Jiangshan
2018-03-19 16:45       ` Tejun Heo
2018-03-20 10:04         ` Lai Jiangshan
2018-03-14 19:45   ` [PATCH 7/8] cgroup: Use rcu_work instead of explicit rcu and work item Tejun Heo
2018-03-14 19:45   ` [PATCH 8/8] fs/aio: " Tejun Heo
2018-03-19 17:12     ` Tejun Heo
2018-03-21 15:58     ` Oleg Nesterov
2018-03-21 16:40       ` Tejun Heo
2018-03-21 17:17         ` Oleg Nesterov
2018-03-21 17:53           ` Tejun Heo
2018-03-22 11:24             ` Oleg Nesterov
2018-03-26 15:04               ` Tejun Heo
2018-03-27 14:28                 ` Oleg Nesterov
2018-03-27 15:55                   ` Tejun Heo
2018-03-29 16:49                     ` Oleg Nesterov
2018-03-29 17:41                       ` Tejun Heo

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=20180327161244.GA4251@redhat.com \
    --to=jglisse@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=bcrl@kvack.org \
    --cc=jannh@google.com \
    --cc=kent.overstreet@gmail.com \
    --cc=kernel-team@fb.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=paulmck@linux.vnet.ibm.com \
    --cc=security@kernel.org \
    --cc=tj@kernel.org \
    --cc=torvalds@linux-foundation.org \
    --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.