public inbox for glibc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug nptl/10184] New: setuid functions can stall pthread exit code
@ 2009-05-22  6:27 samandbernie at guarana dot org
  2009-05-22 13:35 ` [Bug nptl/10184] " pasky at suse dot cz
                   ` (6 more replies)
  0 siblings, 7 replies; 8+ messages in thread
From: samandbernie at guarana dot org @ 2009-05-22  6:27 UTC (permalink / raw)
  To: glibc-bugs

It appears that calling any of the setuid functions from one thread while
another thread is exiting can sometimes cause the exiting thread to get stuck.
The stuck thread is not visible to gdb but does appear in the output of ps. If
another thread is trying to join the stuck thread, it will wait forever.

It can become stuck either waiting for a futex wake or busy looping. In both
cases the location is in thread_start, from pthread_create.c (around line 388 in
the git trunk code). As follows:

      do
	lll_futex_wait (&pd->setxid_futex, 0, LLL_PRIVATE);
      while (pd->cancelhandling & SETXID_BITMASK);

>From our investigation, it happens with a tgkill from setxid_signal_thread
fails. This causes the SETDIX_BIT to be set in the target thread, but no signal
is sent and no other thread is actually waiting on it. It seems like a naive fix
would be to change the last statement in that function from:

  if (!INTERNAL_SYSCALL_ERROR_P (val, err))
    atomic_increment (&cmdp->cntr);

To:

  if (INTERNAL_SYSCALL_ERROR_P (val, err))
    t->cancelhandling &= ~SETXID_BITMASK;
  else
    atomic_increment (&cmdp->cntr);

This change appears to correct the problem on our machines.

On our machines (Ubuntu 9.04 with 2 or 4 way SMP) the following program
replicates the problem within a few minutes (just run it and watch for the
output to change to a continuous stream of the letter u):

#include <sys/types.h>
#include <unistd.h>
#include <pthread.h>
#include <stdio.h>

void *noop(void *arg) {
        usleep(rand() % 10000);
        return 0;
}

void *spawner(void *arg) {
        pthread_t t;

        for (;;) {
                fprintf(stderr, "c");
                pthread_create(&t, 0, noop, 0);
                fprintf(stderr, "j");
                pthread_join(t, 0);
        }
}

int main() {
        pthread_t spawner_id;

        pthread_create(&spawner_id, 0, spawner, 0);
        for(;;) {
                fprintf(stderr, "u");
                setuid(getuid());
                usleep(10000);
        }
        return 0;
}

We've run the test code on several RedHat machines, with the bug happening on
machines with glibc-2.3.4-2.41, glibc-2.5-18.el5_1.1 or glibc-2.5-24. For some
reason it takes several minutes to fail on 8-way SMP machines.

-- 
           Summary: setuid functions can stall pthread exit code
           Product: glibc
           Version: 2.9
            Status: NEW
          Severity: normal
          Priority: P2
         Component: nptl
        AssignedTo: drepper at redhat dot com
        ReportedBy: samandbernie at guarana dot org
                CC: glibc-bugs at sources dot redhat dot com


http://sourceware.org/bugzilla/show_bug.cgi?id=10184

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.


^ permalink raw reply	[flat|nested] 8+ messages in thread
end of thread, other threads:[~2010-04-20 12:07 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-05-22  6:27 [Bug nptl/10184] New: setuid functions can stall pthread exit code samandbernie at guarana dot org
2009-05-22 13:35 ` [Bug nptl/10184] " pasky at suse dot cz
2009-05-22 23:18 ` samandbernie at guarana dot org
2009-05-25  1:43 ` samandbernie at guarana dot org
2009-05-27  3:07 ` samandbernie at guarana dot org
2009-10-29 16:54 ` schwab at linux-m68k dot org
2010-04-20  9:21 ` soda at sra dot co dot jp
2010-04-20 12:07 ` drepper at redhat dot com

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).