[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150715133107.GA20539@redhat.com>
Date: Wed, 15 Jul 2015 15:31:07 +0200
From: Oleg Nesterov <oleg@...hat.com>
To: David Ahern <dsahern@...il.com>
Cc: Andrey Vagin <avagin@...nvz.org>, linux-kernel@...r.kernel.org,
linux-api@...r.kernel.org,
Andrew Morton <akpm@...ux-foundation.org>,
Cyrill Gorcunov <gorcunov@...nvz.org>,
Pavel Emelyanov <xemul@...allels.com>,
Roger Luethi <rl@...lgate.ch>, Arnd Bergmann <arnd@...db.de>,
Arnaldo Carvalho de Melo <acme@...nel.org>,
Andy Lutomirski <luto@...capital.net>,
Pavel Odintsov <pavel.odintsov@...il.com>
Subject: Re: [PATCH 20/24] task_diag: Only add VMAs for thread_group leader
On 07/14, David Ahern wrote:
>
> On 7/14/15 1:47 PM, Oleg Nesterov wrote:
>>>
>>> if (show_flags & TASK_DIAG_SHOW_VMA) {
>>> + /* if the request is to dump all threads of all processes
>>> + * only show VMAs for group leader.
>>> + */
>>> + if (req->dump_strategy == TASK_DIAG_DUMP_ALL_THREAD &&
>>> + !thread_group_leader(tsk))
>>> + goto done;
>>> +
>>
>> This doesn't look right, group leader can be a zombie with ->mm == NULL,
>
> Seriously?
Yes, the main thread can do sys_exit() / pthread_exit(), although this
is not that common.
> I'll find some way to track whether VMAs have been dumped for
> a pid.
In case I confused you, the thread_group_leader() check and "goto done"
above are fine, just you can't trust tsk->mm, so
>>> if (i >= n)
>>> err = fill_vma(tsk, skb, cb, &progress, show_flags);
>>
>> so this probably needs something like find_lock_task_mm().
>
> ok.
Yes, you just need to (try) find a subthread with ->mm != NULL if !tsk->mm,
find_lock_task_mm() can help.
Oleg.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists