Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1639914 > unrolled thread

Threads stuck in zap_pid_ns_processes()

Started byGuenter Roeck <linux@roeck-us.net>
First post2017-05-11 19:20 +0200
Last post2017-05-12 05:50 +0200
Articles 1 on this page of 21 — 3 participants

Back to article view | Back to linux.kernel


Contents

  Threads stuck in zap_pid_ns_processes() Guenter Roeck <linux@roeck-us.net> - 2017-05-11 19:20 +0200
    Re: Threads stuck in zap_pid_ns_processes() ebiederm@xmission.com (Eric W. Biederman) - 2017-05-11 19:40 +0200
      Re: Threads stuck in zap_pid_ns_processes() Guenter Roeck <linux@roeck-us.net> - 2017-05-11 20:40 +0200
        Re: Threads stuck in zap_pid_ns_processes() ebiederm@xmission.com (Eric W. Biederman) - 2017-05-11 22:30 +0200
          Re: Threads stuck in zap_pid_ns_processes() Guenter Roeck <linux@roeck-us.net> - 2017-05-11 22:50 +0200
            Re: Threads stuck in zap_pid_ns_processes() ebiederm@xmission.com (Eric W. Biederman) - 2017-05-11 23:50 +0200
      Re: Threads stuck in zap_pid_ns_processes() Guenter Roeck <linux@roeck-us.net> - 2017-05-11 22:30 +0200
        Re: Threads stuck in zap_pid_ns_processes() ebiederm@xmission.com (Eric W. Biederman) - 2017-05-11 23:40 +0200
          Re: Threads stuck in zap_pid_ns_processes() Guenter Roeck <linux@roeck-us.net> - 2017-05-12 00:50 +0200
            Re: Threads stuck in zap_pid_ns_processes() ebiederm@xmission.com (Eric W. Biederman) - 2017-05-12 01:30 +0200
              Re: Threads stuck in zap_pid_ns_processes() Vovo Yang <vovoy@google.com> - 2017-05-12 11:40 +0200
                Re: Threads stuck in zap_pid_ns_processes() ebiederm@xmission.com (Eric W. Biederman) - 2017-05-12 15:40 +0200
                  Re: Threads stuck in zap_pid_ns_processes() Guenter Roeck <linux@roeck-us.net> - 2017-05-12 19:00 +0200
                    Re: Threads stuck in zap_pid_ns_processes() ebiederm@xmission.com (Eric W. Biederman) - 2017-05-12 19:40 +0200
                      [REVIEW][PATCH] pid_ns: Sleep in TASK_INTERRUPTIBLE in zap_pid_ns_processes ebiederm@xmission.com (Eric W. Biederman) - 2017-05-12 20:10 +0200
                        Re: [REVIEW][PATCH] pid_ns: Sleep in TASK_INTERRUPTIBLE in  zap_pid_ns_processes Guenter Roeck <linux@roeck-us.net> - 2017-05-12 21:40 +0200
                      Re: Threads stuck in zap_pid_ns_processes() Guenter Roeck <linux@roeck-us.net> - 2017-05-12 21:50 +0200
                        Re: Threads stuck in zap_pid_ns_processes() ebiederm@xmission.com (Eric W. Biederman) - 2017-05-12 22:20 +0200
                          Re: Threads stuck in zap_pid_ns_processes() Guenter Roeck <linux@roeck-us.net> - 2017-05-13 16:40 +0200
                            Re: Threads stuck in zap_pid_ns_processes() ebiederm@xmission.com (Eric W. Biederman) - 2017-05-13 20:30 +0200
            Re: Threads stuck in zap_pid_ns_processes() ebiederm@xmission.com (Eric W. Biederman) - 2017-05-12 05:50 +0200

Page 2 of 2 — ← Prev page 1 [2]


#1640176

Fromebiederm@xmission.com (Eric W. Biederman)
Date2017-05-12 05:50 +0200
Message-ID<tG9Ky-72q-7@gated-at.bofh.it>
In reply to#1640070
Guenter Roeck <linux@roeck-us.net> writes:

> On Thu, May 11, 2017 at 04:25:23PM -0500, Eric W. Biederman wrote:
>> Guenter Roeck <linux@roeck-us.net> writes:

>> > As an add-on to my previous mail: I added a function to count
>> > the number of threads in the pid namespace, using next_pidmap().
>> > Even though nr_hashed == 2, only the hanging thread is still
>> > present.
>> 
>> For your testcase?  I suspect you copied the code from
>> zap_pid_ns_processes and skipped pid 1.  It is going to be pid 1 that is
>> calling zap_pid_ns_processes.
>> 
>
> Almost. Something along the line of
>
> 	count = 0;
> 	nr = next_pidmap(pid_ns, 0);
> 	while (nr > 0) {
> 		count++;
> 		nr = next_pidmap(pid_ns, nr);
> 	}
>
> only I also call sched_show_task() for each thread, and the only
> one printed is the one that hangs in zap_pid_ns_processes().

The function sched_show_task() does:
	if (!try_get_task_stack(p))
        	return;
                
Which won't work on a zombie who has already released it's stack.
Which is exactly what child2 should be at that point.

Eric

[toc] | [prev] | [standalone]


Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | linux.kernel


csiph-web