All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Tejun Heo <tj@kernel.org>
Cc: Dipankar Sarma <dipankar@in.ibm.com>,
	Fengguang Wu <fengguang.wu@intel.com>,
	"David S. Miller" <davem@davemloft.net>,
	Li Zefan <lizefan@huawei.com>, Patrick McHardy <kaber@trash.net>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] rculist: list_first_or_null_rcu() should use list_entry_rcu()
Date: Fri, 28 Jun 2013 10:24:55 -0700	[thread overview]
Message-ID: <20130628172455.GA3773@linux.vnet.ibm.com> (raw)
In-Reply-To: <20130626172753.GC4405@mtj.dyndns.org>

On Wed, Jun 26, 2013 at 10:27:53AM -0700, Tejun Heo wrote:
> list_first_or_null() should test whether the list is empty and return
> pointer to the first entry if not in a RCU safe manner.  It's broken
> in several ways.
> 
> * It compares __kernel @__ptr with __rcu @__next triggering the
>   following sparse warning.
> 
>   net/core/dev.c:4331:17: error: incompatible types in comparison expression (different address spaces)
> 
> * It doesn't perform rcu_dereference*() and computes the entry address
>   using container_of() directly from the __rcu pointer which is
>   inconsitent with other rculist interface.  As a result, all three
>   in-kernel users - net/core/dev.c, macvlan, cgroup - are buggy.  They
>   dereference the pointer w/o going through read barrier.
> 
> * While ->next dereference passes through list_next_rcu(), the
>   compiler is still free to fetch ->next more than once and thus
>   nullify the "__ptr != __next" condition check.
> 
> Fix it by making list_first_or_null_rcu() dereference ->next directly
> using ACCESS_ONCE() and then use list_entry_rcu() on it like other
> rculist accessors.
> 
> v2: Paul pointed out that the compiler may fetch the pointer more than
>     once nullifying the condition check.  ACCESS_ONCE() added on
>     ->next dereference.
> 
> Signed-off-by: Tejun Heo <tj@kernel.org>
> Reported-by: Fengguang Wu <fengguang.wu@intel.com>
> Cc: Dipankar Sarma <dipankar@in.ibm.com>
> Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
> Cc: "David S. Miller" <davem@davemloft.net>
> Cc: Li Zefan <lizefan@huawei.com>
> Cc: Patrick McHardy <kaber@trash.net>
> Cc: stable@vger.kernel.org
> ---
> Paul, I was mistaken.  For list_first_or_null_rcu(), @ptr is constant.
> It's a value which can't change and usually not even a l-value.
> ACCESS_ONCE() is necessary when dereferencing @ptr->next, which may
> change while list_first_or_null_rcu() is in progress.
> 
> Thanks.

Fair enough!

But why drop the parens around "ptr"?

							Thanx, Paul

>  include/linux/rculist.h |    7 ++++---
>  1 file changed, 4 insertions(+), 3 deletions(-)
> 
> --- a/include/linux/rculist.h
> +++ b/include/linux/rculist.h
> @@ -266,9 +266,10 @@ static inline void list_splice_init_rcu(
>   * primitives such as list_add_rcu() as long as it's guarded by rcu_read_lock().
>   */
>  #define list_first_or_null_rcu(ptr, type, member) \
> -	({struct list_head *__ptr = (ptr); \
> -	  struct list_head __rcu *__next = list_next_rcu(__ptr); \
> -	  likely(__ptr != __next) ? container_of(__next, type, member) : NULL; \
> +	({struct list_head *__ptr = ptr; \
> +	  struct list_head *__next = ACCESS_ONCE(__ptr->next); \
> +	  likely(__ptr != __next) ? \
> +		list_entry_rcu(__next, type, member) : NULL; \
>  	})
> 
>  /**
> 


  reply	other threads:[~2013-06-28 17:25 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-06-21  0:32 [PATCH] rculist: list_first_or_null_rcu() should use list_entry_rcu() Tejun Heo
2013-06-25 18:51 ` Tejun Heo
2013-06-25 22:57 ` Paul E. McKenney
2013-06-25 23:09   ` Tejun Heo
2013-06-26 14:17     ` Paul E. McKenney
2013-06-26 15:25       ` Tejun Heo
2013-06-26 17:27 ` [PATCH v2] " Tejun Heo
2013-06-28 17:24   ` Paul E. McKenney [this message]
2013-06-28 17:31     ` Tejun Heo
2013-06-28 17:34   ` [PATCH v3] " Tejun Heo
2013-06-28 19:25     ` Paul E. McKenney
2013-07-23 14:48       ` Tejun Heo
2013-07-23 15:01         ` Paul E. McKenney

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=20130628172455.GA3773@linux.vnet.ibm.com \
    --to=paulmck@linux.vnet.ibm.com \
    --cc=davem@davemloft.net \
    --cc=dipankar@in.ibm.com \
    --cc=fengguang.wu@intel.com \
    --cc=kaber@trash.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lizefan@huawei.com \
    --cc=tj@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.