public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: David Howells <dhowells@redhat.com>
To: Linus Torvalds <torvalds@transmeta.com>
Cc: David Howells <dhowells@redhat.com>, linux-kernel@vger.kernel.org
Subject: Re: thread groups bug?
Date: Fri, 01 Mar 2002 16:38:11 +0000	[thread overview]
Message-ID: <22890.1015000691@warthog.cambridge.redhat.com> (raw)
In-Reply-To: Message from Dave McCracken <dmccr@us.ibm.com>  of "Fri, 01 Mar 2002 10:24:30 CST." <36310000.1014999870@baldur>


Hi Linus,

I've attached a patch to kill all subsidiary threads in a thread group when
the main thread exits. I've made it against 2.5.6-pre1 since -pre2 fails to
compile in the IDE code somewhere.

I've tested it, and it appears to work.

Note that it sends the subsidiary threads SIGKILL with SI_DETHREAD.

Note also that subsidiary threads doing an execve() just leave the thread
group (rather than forcing the master thread to do an execve() which would be
more POSIX like).

David

diff -uNr linux-2.5.6-pre1/fs/exec.c linux-execve-256p1/fs/exec.c
--- linux-2.5.6-pre1/fs/exec.c	Wed Feb 27 08:26:55 2002
+++ linux-execve-256p1/fs/exec.c	Fri Mar  1 15:37:36 2002
@@ -513,23 +513,49 @@
 
 /*
  * An execve() will automatically "de-thread" the process.
- * Note: we don't have to hold the tasklist_lock to test
- * whether we migth need to do this. If we're not part of
- * a thread group, there is no way we can become one
- * dynamically. And if we are, we only need to protect the
- * unlink - even if we race with the last other thread exit,
- * at worst the list_del_init() might end up being a no-op.
+ * - if a master thread (PID==TGID) is doing this, then all subsidiary threads
+ *   will be killed (otherwise there will end up being two independent thread
+ *   groups with the same TGID).
+ * - if a subsidary thread is doing this, then it just leaves the thread group
  */
-static inline void de_thread(struct task_struct *tsk)
+static void de_thread(struct task_struct *tsk)
 {
-	if (!list_empty(&tsk->thread_group)) {
-		write_lock_irq(&tasklist_lock);
+	struct task_struct *sub;
+	struct list_head *head, *ptr;
+	struct siginfo info;
+	int pause;
+
+	write_lock_irq(&tasklist_lock);
+
+	if (tsk->tgid != tsk->pid) {
+		/* subsidiary thread - just escapes the group */
+		list_del_init(&tsk->thread_group);
+		tsk->tgid = tsk->pid;
+		pause = 0;
+	}
+	else {
+		/* master thread - kill all subsidiary threads */
+		info.si_signo = SIGKILL;
+		info.si_errno = 0;
+		info.si_code = SI_DETHREAD;
+		info.si_pid = current->pid;
+		info.si_uid = current->uid;
+
+		head = tsk->thread_group.next;
 		list_del_init(&tsk->thread_group);
-		write_unlock_irq(&tasklist_lock);
+
+		list_for_each(ptr,head) {
+			sub = list_entry(ptr,struct task_struct,thread_group);
+			send_sig_info(SIGKILL,&info,sub);
+		}
+
+		pause = 1;
 	}
 
-	/* Minor oddity: this might stay the same. */
-	tsk->tgid = tsk->pid;
+	write_unlock_irq(&tasklist_lock);
+
+	/* give the subsidiary threads a chance to clean themselves up */
+	if (pause) yield();
 }
 
 int flush_old_exec(struct linux_binprm * bprm)
@@ -570,7 +596,8 @@
 
 	flush_thread();
 
-	de_thread(current);
+	if (!list_empty(&current->thread_group))
+		de_thread(current);
 
 	if (bprm->e_uid != current->euid || bprm->e_gid != current->egid || 
 	    permission(bprm->file->f_dentry->d_inode,MAY_READ))
diff -uNr linux-2.5.6-pre1/include/asm-i386/siginfo.h linux-execve-256p1/include/asm-i386/siginfo.h
--- linux-2.5.6-pre1/include/asm-i386/siginfo.h	Wed Feb 27 08:27:01 2002
+++ linux-execve-256p1/include/asm-i386/siginfo.h	Fri Mar  1 15:25:47 2002
@@ -108,6 +108,7 @@
 #define SI_ASYNCIO	-4		/* sent by AIO completion */
 #define SI_SIGIO	-5		/* sent by queued SIGIO */
 #define SI_TKILL	-6		/* sent by tkill system call */
+#define SI_DETHREAD	-7		/* sent by execve() killing subsidiary threads */
 
 #define SI_FROMUSER(siptr)	((siptr)->si_code <= 0)
 #define SI_FROMKERNEL(siptr)	((siptr)->si_code > 0)

  reply	other threads:[~2002-03-01 16:39 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-02-28 15:09 thread groups bug? David Howells
2002-02-28 17:16 ` Linus Torvalds
2002-02-28 21:57   ` David Howells
2002-03-01  0:20     ` Linus Torvalds
2002-03-01 16:24       ` Dave McCracken
2002-03-01 16:38         ` David Howells [this message]
2002-03-01 17:01           ` Martin Dalecki
2002-03-01 17:05           ` Dave McCracken
  -- strict thread matches above, loose matches on Subject: below --
2002-02-28 14:52 David Howells
2002-02-28 15:18 ` Benjamin LaHaise
2002-02-28 15:36   ` David Howells
2002-02-28 15:59     ` Benjamin LaHaise
2002-02-28 16:28       ` David Howells

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=22890.1015000691@warthog.cambridge.redhat.com \
    --to=dhowells@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@transmeta.com \
    /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