lkml.org 
[lkml]   [2011]   [May]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Mysterious CFQ crash and RCU
On Sat, May 21, 2011 at 02:00:13PM -0700, Paul E. McKenney wrote:

[..]
> > Is there any known issue or is there any quick tip on how can I
> > go about debugging it further from rcu point of view.
>
> First for uses of RCU:
>
> o One thing to try would be CONFIG_PROVE_RCU, which could help
> find missing rcu_read_lock()s and similar. Some years back, it
> used to be the case that spin_lock() implied rcu_read_lock(),
> but it no longer does. There might still be some cases where
> spin_lock() needs to have an rcu_read_lock() added.

In this case we take explicit rcu_read_lock() in call_for_each_cic()
and do not rely on that spin_lock() also means rcu_read_lock().

call_for_each_cic() {
rcu_read_lock();
hlist_for_each_entry_rcu(cic, n, &ioc->cic_list, cic_list)
func(ioc, cic);
rcu_read_unlock();
}

>
> o There are a few entries in the bugzilla mentioning that elements
> are being removed more often than expected.

Are you referring to my comments about additional messages of cgroup
changed. If yes, that issue has now been identified and I have posted
a fix to get rid of thos unnecessary calls.

https://lkml.org/lkml/2011/5/23/201

Is still there a need to enable CONFIG_DEBUG_OBJECTS_RCU_HEAD as the
kernel in question is non-preemptible one.

Thanks
Vivek


\
 
 \ /
  Last update: 2011-05-23 17:39    [W:0.375 / U:0.240 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site