Messages in this thread | | | Date | Wed, 22 Jul 2009 13:16:38 -0700 | From | "Paul E. McKenney" <> | Subject | Re: [RFC PATCH] kmemleak: Scan all thread stacks |
| |
On Wed, Jul 22, 2009 at 06:03:29PM +0100, Catalin Marinas wrote: > On Wed, 2009-07-22 at 09:18 -0700, Paul E. McKenney wrote: > > On Fri, Jul 17, 2009 at 07:01:09PM +0200, Peter Zijlstra wrote: > > > On Fri, 2009-07-17 at 17:57 +0100, Catalin Marinas wrote: > > > > On Fri, 2009-07-17 at 18:43 +0200, Ingo Molnar wrote: > > > > > * Catalin Marinas <catalin.marinas@arm.com> wrote: > > > > > > 2. Is it safe to use rcu_read_lock() and task_lock() when scanning the > > > > > > corresponding kernel stack (thread_info structure)? The loop doesn't > > > > > > do any modification to the task list. The reason for this is to > > > > > > allow kernel preemption when scanning the stacks. > > > > > > > > > > you cannot generally preempt while holding the RCU read-lock. > > > > > > > > This may work with rcupreempt enabled. But, with classic RCU is it safe > > > > to call schedule (or cond_resched) while holding the RCU read-lock? > > > > > > No. > > > > What Peter said! ;-) > > > > However, you might be able to use SRCU (http://lwn.net/Articles/202847/), > > which does allow blocking within read-side critical sections. > > Thanks for the suggestion. But this would mean that the task_struct > creation/deletion code should use the SRCU as well which I wouldn't > modify. I'm also not entirely sure this could replace > read_lock(&tasklist_lock)/read_unlock (as per the initial question). > > The simplest fix for kmemleak is to not traverse the task list at all - > http://lkml.org/lkml/2009/7/20/55. The patch is just like any other > kmemleak annotation in the kernel.
Even better, agreed!
Thanx, Paul
| |