From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1756083Ab3EVM2v (ORCPT <rfc822;w@1wt.eu>);
	Wed, 22 May 2013 08:28:51 -0400
Received: from mail-da0-f51.google.com ([209.85.210.51]:55402 "EHLO
	mail-da0-f51.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1755760Ab3EVM2t (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Wed, 22 May 2013 08:28:49 -0400
Message-ID: <1369225727.3301.322.camel@edumazet-glaptop>
Subject: Re: [PATCH v2] rcu: fix a race in hlist_nulls_for_each_entry_rcu
 macro
From: Eric Dumazet <eric.dumazet@gmail.com>
To: paulmck@linux.vnet.ibm.com
Cc: Roman Gushchin <klamm@yandex-team.ru>,
        Dipankar Sarma <dipankar@in.ibm.com>, zhmurov@yandex-team.ru,
        linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
        "David S. Miller" <davem@davemloft.net>,
        Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>,
        James Morris <jmorris@namei.org>,
        Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>,
        Patrick McHardy <kaber@trash.net>
Date: Wed, 22 May 2013 05:28:47 -0700
In-Reply-To: <20130522095839.GC3578@linux.vnet.ibm.com>
References: <519B38EC.90401@yandex-team.ru>
	 <20130521120906.GD3578@linux.vnet.ibm.com>
	 <1369143885.3301.221.camel@edumazet-glaptop>
	 <519B8908.9080007@yandex-team.ru>
	 <1369150693.3301.233.camel@edumazet-glaptop>
	 <519BB90B.6080706@yandex-team.ru>
	 <1369188080.3301.268.camel@edumazet-glaptop>
	 <20130522095839.GC3578@linux.vnet.ibm.com>
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.2.3-0ubuntu6 
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Wed, 2013-05-22 at 02:58 -0700, Paul E. McKenney wrote:

> Now that I am more awake...
> 
> The RCU list macros assume that the list header is either statically
> allocated (in which case no ACCESS_ONCE() or whatever is needed) or
> that the caller did whatever was necessary to protect the list header,
> whether that be holding the right lock, using rcu_dereference() when
> traversing the pointer to the list header, or whatever.

Not sure what you mean, we do hold rcu_read_lock() here.

But when we jump back to begin, we do not do
"rcu_read_unlock()/rcu_read_lock()" pair.