Re: task_finder2 help

[David Smith <dsmith at redhat dot com>]

On 08/23/2011 01:31 PM, Josh Stone wrote:
> On 08/23/2011 09:23 AM, David Smith wrote:
>> However, on rawhide (3.1.0-0.rc1.git6.1.fc17.x86_64), the kernel
>> complains mightily about sleeping functions called from invalid contexts.
> 
> This is probably just because rawhide has more CONFIG_DEBUG flags on.

True.

>> There are a couple of classes of these bugs (after working through some
>> semi-minor issues):
>>
>> - Use of get_task_mm()/mmput().

...

> The get/put are only protecting from having the mm released.  So long as
> you're always doing this within the context of a task that owns this mm,
> then it seems safe to say that mm_users will always be >0 -- and so the
> get/put are really redundant.  You can see many examples in mmap.c  that
> don't bother with get/put on current->mm.
> 
> I don't think any of this prevents a *change* in the mm though.  If
> that's a concern, I believe you need to down_read mmap_sem.

When actually looking at the mm data, I do down_read mmap_sem, so I
should be OK there.

I think you are right that I'm doing this from with the context of the
task that owns the mm.  The fork/clone tracepoint happens in the context
of the parent, not the child, so I'll need to look at that code and make
sure I'm only looking at the parent's mm.

>> - Memory allocation.

...

>> Does anyone know of pitfalls of turning off __GFP_WAIT?

> I'm not sure what the full ramifications are for keeping __GFP_IO and
> __GFP_IO, but I think GFP_ATOMIC is for exactly these unsleepable
> allocations.  Or possibly GFP_NOWAIT to avoid the emergency pool.

GFP_NOWAIT sounds interesting.  Note that unless I add new functions in
runtime/alloc.c, we'd be changing all systemtap kmalloc's to use the new
flags, so I don't want to do this without proper thought.

> If possible, the best choice is to allocate from a safer context, but I
> assume you've already ruled that out...

There are 2 classes of allocations in the task_finder, both short term:
(1) pathnames, used when matching "interesting" task pathnames; and (2)
cached vma information.  The new tracepoint-based utrace code makes much
longer-term allocations, for engines and main structures whose lifetime
is that of the task itself (assuming the systemtap script doesn't exit
first).

If you've got ideas on how to allocate any of the above from a safer
context, I'm all ears.


Thanks for the advice.

-- 
David Smith
dsmith@redhat.com
Red Hat
http://www.redhat.com
256.217.0141 (direct)
256.837.0057 (fax)