Date: Mon, 30 Nov 2015 10:39:15 +1100
From: Paul Mackerras <paulus@ozlabs.org>
To: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Cc: Alexey Kardashevskiy <aik@ozlabs.ru>, Steven Rostedt <rostedt@goodmis.org>,
        David Gibson <david@gibson.dropbear.id.au>,
        linux-kernel@vger.kernel.org
Subject: Re: [PATCH kernel] rcu: Define lockless version of
 list_for_each_entry_rcu
Message-ID: <20151129233915.GA8991@fergus.ozlabs.ibm.com>
References: <1446533825-30160-1-git-send-email-aik@ozlabs.ru>
 <20151103093913.346374e2@gandalf.local.home>
 <563C0DAD.8070100@ozlabs.ru>
 <20151118191328.GK5184@linux.vnet.ibm.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20151118191328.GK5184@linux.vnet.ibm.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2719
Lines: 55

On Wed, Nov 18, 2015 at 11:13:28AM -0800, Paul E. McKenney wrote:
> On Fri, Nov 06, 2015 at 01:17:17PM +1100, Alexey Kardashevskiy wrote:
[snip]
> > Still, is my approach correct? What does the comment for
> > lockless_dereference() actally mean - it won't work together with
> > RCU at all or this is to force people not to use it as
> > "list_for_each_entry_rcu() should really be used in 99.99% of the
> > time"? :)
> 
> Well, it depends...
> 
> The key difference between lockless_dereference() and rcu_dereference()
> is that lockless_dereference() won't complain if used outside of
> an RCU read-side critical section.  When there is no RCU read-side
> critical section, lockless_dereference() cannot rely on RCU's normal
> action of keeping the data item around.  Therefore, when you are using
> lockless_dereference(), you have to have some mechanism other than RCU
> to keep the data item around.  The usual approach is for the data item
> to never be freed, for example, if data is only ever added to the list
> and never removed.  Other approaches include reference counting, hazard
> pointers, hashed arrays of locks, garbage collectors, transactional
> memory, and so on.

So, the situation is that we have an RCU-protected list, which in this
case we are traversing without modifying the list.  We are in an
restricted environment (hypervisor real mode) where we can't be
preempted, both because interrupts are hard-disabled and because our
caller has done preempt_disable().  In this restricted environment we
can access the linear mapping (thus kmalloc'd data) but not the
vmalloc or ioremap regions.

Thus we are not formally in a RCU read-side critical section, though
we believe that having preemption disabled gives us equivalent
protection.  Probably what we should do is to add a
rcu_read_lock/unlock pair in a function higher up the call chain
so that we are actually in a RCU read-side critical section.

Then the only reason not to use list_for_each_entry_rcu would be that
we don't trust the checking machinery not to ever access vmalloc'd
data.  In other words, we want a list_for_each_entry_nocheck
or list_for_each_entry_restricted which omits all the lockdep
checking.  That would need a list_entry_rcu_nocheck which would need a
thing like rcu_dereference_raw that does no lockdep checking - which
is where I thought you suggested lockless_dereference.

So, what name do you like for these primitives, and where should they
go?

Thanks,
Paul.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/