This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: sleeping, locks and debug kernels


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().

> > > I don't know how we could split up that loop.  Perhaps Oleg might have
> > > some thoughts or might be persuaded to change the memory allocation
> > > flags in utrace itself.
> >
> > Yes, it is very simple to add UTRACE_ATTACH_CREATE_ATOMIC.
>
> That would be useful I think.

OK, I'll try to recheck and make the patch.

Oleg.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]