lkml.org 
[lkml]   [2010]   [Feb]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH 02/10] rcu: annotated list rcu code
Date
On Wednesday 24 February 2010, Mathieu Desnoyers wrote:
> * Arnd Bergmann (arnd@arndb.de) wrote:
> > The listrcu implementation now defines new rcu_list_head,
> > rcu_hlist_head and rcu_hlist_entry structures that are
> > annotated with __rcu. Only these can now be passed into
> > rcu_list_for_each and related interfaces.
> >
> > When not running sparse, the types are defined to the
> > original list_head etc in order to not break working
> > setups that are lacking annotation.
>
> Hrm, wait.. dumb question: how can an annotation break compilation ? If there is
> any way out of this, I would prefer if we can do without a #ifdef __CHECKER__ if
> possible. It calls for bugs and implementation mismatch.

The problem is that you can not (currently) declare a list_head
to be RCU protected by writing 'struct list_head __rcu list;',
because address space annotations only work on pointers.

The solution I used was to define a new struct rcu_list_head that
has the ->next member annotated as __rcu. Unfortunately, this
means that it is now incompatible to a struct list_head from
the compiler's point of view.

We could get rid of the #ifdef by unconditionally defining
the separate rcu_list_head, as long as all users are correctly
converted to it. This does have problems in cases such as the
module code that uses the same list with and without RCU, as
Alexey mentioned.

The alternative would be not to annotate list RCU at all and
__force away the warnings for these so we can still keep the
normal __rcu annotations.

Arnd



\
 
 \ /
  Last update: 2010-02-24 21:41    [W:0.075 / U:0.132 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site