linux-kernel - Re: [PATCH kernel] rcu: Define lockless version of list_for_each_entry

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 30 Nov 2015 10:39:15 +1100
From:	Paul Mackerras <paulus@...abs.org>
To:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
Cc:	Alexey Kardashevskiy <aik@...abs.ru>,
	Steven Rostedt <rostedt@...dmis.org>,
	David Gibson <david@...son.dropbear.id.au>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH kernel] rcu: Define lockless version of
 list_for_each_entry_rcu

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/