public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Sripathi Kodi <sripathik@in.ibm.com>
To: linux-kernel@vger.kernel.org
Cc: akpm@osdl.org, patrics@interia.pl
Subject: [PATCH 2.6.13.1] Patch for invisible threads
Date: Mon, 12 Sep 2005 12:46:27 -0500	[thread overview]
Message-ID: <4325BEF3.2070901@in.ibm.com> (raw)

Hi,

When the main thread of a multi-threaded program calls 'pthread_exit' before
other threads have exited, it results in the other threads becoming
'invisible' to commands like 'ps'. This problem was discussed here :
http://lkml.org/lkml/2004/10/5/234 and http://kerneltrap.org/node/3930, but
I can't find a patch or explanation for it anywhere. This problem is only
seen with NPTL and not with LinuxThreads, because Linuxthreads does not let
the main thread exit (puts it to sleep) until all other threads have exited.

The problem can be easily recreated with this simple program:
#include <pthread.h>
#include <sys/types.h>
#include <unistd.h>
void *run(void *arg)
{
     sleep(60);
     printf("Thread: Exiting\n");
     pthread_exit(NULL);
}
int main()
{
     pthread_t t;
     pthread_create(&t, NULL, run, NULL);
     sleep(20);
     printf("Main: exiting\n");
     pthread_exit(NULL);
}

After the main thread calls 'pthread_exit', it is shown to be defunct. We
can still see the directory /proc/<pid_of_main_thread>/task using 'ls',
'stat' on it returns success, but 'open' on that directory returns ENOENT.
Hence though the other thread is still running, it can't be seen.

The reason appears to be the call to __exit_fs from do_exit when the main
thread exits. This sets the 'fs' pointer in the task struct to NULL. It also
decrements the reference count on the fs structure, but does not release the
memory because the other thread still holds a reference (__put_fs_struct).
When we do open() on /proc/<pid>/task, proc_root_link() (flow is open_namei
- may_open - proc_permission - proc_check_root - proc_root_link) tries to
obtain the task_struct->fs of the main thread, which is now NULL. So it
returns ENOENT.

I think we can fix this problem by the following patch. We set the fs
pointer to NULL only if either the thread is not a thread group leader or if
the whole thread group has exited. If the main thread is the last to exit,
it will set the fs pointer to NULL. However, if it is not the last, it won't
set fs pointer to NULL so that other threads can still use it. Behavior of
__put_fs_struct is not affected.

Please let me know if this is reasonable or if there are other ways to fix
the problem.

Thanks and regards,
Sripathi.


Signed-off-by: Sripathi Kodi <sripathik@in.ibm.com>

--- linux-2.6.13.1/kernel/exit.c	2005-09-12 02:46:26.000000000 -0500
+++ /home/sripathi/17794/patch_2.6.13.1/exit.c	2005-09-12 02:46:15.000000000 
-0500
@@ -463,9 +463,11 @@ static inline void __exit_fs(struct task
  	struct fs_struct * fs = tsk->fs;

  	if (fs) {
-		task_lock(tsk);
-		tsk->fs = NULL;
-		task_unlock(tsk);
+		if (!thread_group_leader(tsk) || !atomic_read(&tsk->signal->live)) {
+			task_lock(tsk);
+			tsk->fs = NULL;
+			task_unlock(tsk);
+		}
  		__put_fs_struct(fs);
  	}
  }

             reply	other threads:[~2005-09-12 17:46 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-09-12 17:46 Sripathi Kodi [this message]
2005-09-12 20:49 ` [PATCH 2.6.13.1] Patch for invisible threads Andrew Morton
2005-09-13 13:10   ` Sripathi Kodi
2005-09-13 14:53     ` Linus Torvalds
2005-09-13 16:51       ` Al Viro
2005-09-13 17:01         ` Linus Torvalds
2005-09-13 17:12           ` Al Viro
2005-09-13 21:30             ` Sripathi Kodi
2005-09-13 21:56               ` Roland McGrath
2005-09-13 21:57               ` Al Viro
2005-09-13 23:10               ` Linus Torvalds
2005-09-14  1:47                 ` Sripathi Kodi
2005-09-14  1:52                   ` Al Viro
2005-09-14 14:37                   ` Bill Davidsen
2005-09-15  0:30                     ` Sripathi Kodi
2005-09-14  1:50                 ` Al Viro
2005-09-15  0:31                   ` Sripathi Kodi
2005-09-15  0:55                     ` Roland McGrath
2005-09-15  1:38                       ` Sripathi Kodi
2005-09-15  2:12                         ` Al Viro
2005-09-15  7:29                           ` Roland McGrath
2005-09-15  1:18                     ` Al Viro
2005-09-16  0:54                       ` Sripathi Kodi
2005-09-16  7:46                         ` Al Viro
2005-09-16 15:06                           ` Sripathi Kodi
2005-09-16 18:05                           ` Daniel Jacobowitz
2005-09-16 18:14                             ` Al Viro

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4325BEF3.2070901@in.ibm.com \
    --to=sripathik@in.ibm.com \
    --cc=akpm@osdl.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=patrics@interia.pl \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox