Re: sleeping, locks and debug kernels

[Oleg Nesterov <oleg at redhat dot com>]

On 12/12, David Smith wrote:
>
> On 12/12/2011 11:54 AM, Oleg Nesterov wrote:
>
> > On 12/12, Mark Wielaard wrote:
> >>
> >> On Mon, Dec 12, 2011 at 05:58:51PM +0100, Oleg Nesterov wrote:
> >>>
> >>> Yes, this is the problem. Although I am not sure how "goes over every
> >>> task" can work under rcu_read_lock() without races with clone(). For
> >>> example, even "attach all threads in this thread group" is not simple.
> >>> But this is off-topic.
> >>
> >> Maybe off-topic, but it would be useful to know what the issues with
> >> going over all threads while holding (or even while not holding)
> >> rcu_read_lock.
> >
> > You can miss a freshly cloned thread. UTRACE_ATTACH_CREATE_ATOMIC makes
> > this easier, you can use tasklist_lock. But even in this case you probably
> > need to hook ->report_clone().
>
>
> We certainly do hook report_clone().
>
> If I remember correctly, the tasklist_lock (or perhaps the functions
> that access it) wasn't exported, but I haven't looked in a year so I
> could be wrong now.

Ah, yes, it is not exported. You can use kallsyms_lookup_name(tasklist)
but this is not nice.

Starting from 2.6.39 we have signal_struct->threadgroup_fork_lock, but
it depends on CONFIG_CGROUPS. And probably this interface will be changed
soon.

As for "attach to the whole thread-group", I think it is possible to
do this without holding rcu_read_lock or tasklist, just this is not
simple. https://www.redhat.com/archives/utrace-devel/2010-November/msg00006.html
tries to do this, see ugdb_attach_all_threads(). Not sure this is
the best approach.

Oleg.