Messages in this thread | | | Subject | Re: [RFC PATCH] kmemleak: Scan all thread stacks | From | Catalin Marinas <> | Date | Wed, 22 Jul 2009 18:03:29 +0100 |
| |
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.
Thanks.
-- Catalin
| |