__kernel_vsyscall () hangs in SIGCHLD handler

From: John Z. Bohach
Date: Wed Sep 26 2007 - 10:57:43 EST


Is there some reason that syslog() sleeps in __kernel_vsyscall() when
invoked from a signal handler? Is it that I am not allowed to call any
system calls from inside a signal handler?

I use syslog() from a daemon client/server sys. app. that (tries) to log
whenever a child exits. I've registered a sigChld handler via
sigaction(using SA_SIGINFO semantics), and everything works fine and is
fully functional, including calls to syslog() in the normal program
flow. However, if I try to use syslog() from inside the signal handler
itself, it never returns.

Tracing the program with gdb, I get:

Attaching to program: lfsad, process 8845
`system-supplied DSO at 0xffffe000' has disappeared; keeping its
symbols.
[Thread debugging using libthread_db enabled]
[New Thread -1211890000 (LWP 8845)]
Loaded symbols for /usr/lib/libxml2.so.2
Loaded symbols for /lib/libz.so.1
Loaded symbols for /lib/libm.so.6
Loaded symbols for /lib/librt.so.1
Loaded symbols for /lib/libc.so.6
Loaded symbols for /lib/libdl.so.2
Loaded symbols for /lib/ld-linux.so.2
Loaded symbols for /lib/libpthread.so.0
Reading symbols from /lib/libnss_files.so.2...done.
Loaded symbols for /lib/libnss_files.so.2
0xffffe410 in __kernel_vsyscall ()
(gdb) bt
#0 0xffffe410 in __kernel_vsyscall ()
#1 0xb7d2457e in __lll_mutex_lock_wait () from /lib/libc.so.6
#2 0xb7d14d6d in _L_mutex_lock_621 () from /lib/libc.so.6
#3 0x08511b18 in ?? ()
#4 0xbf86b64d in ?? ()
#5 0xbf86b628 in ?? ()
#6 0xbf86b578 in ?? ()
#7 0xb7d76320 in ?? () from /lib/libc.so.6
#8 0xfbad8001 in ?? ()
#9 0x00000014 in ?? ()
#10 0x00000000 in ?? ()

If I check its status in /proc/8845/status, I see that its sleeping. If
I remove the call to syslog() in the signal handler, everything is
fine, no sleeping, and the rest of the syslog() work fine.

Am I doing something wrong?

Thanks,
John

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/