Subject: Re: port-sparc64/29824
To: None <port-sparc64-maintainer@netbsd.org, gnats-admin@netbsd.org,>
From: Christos Zoulas <christos@zoulas.com>
List: netbsd-bugs
Date: 05/02/2005 16:50:01
The following reply was made to PR port-sparc64/29824; it has been noted by GNATS.

From: christos@zoulas.com (Christos Zoulas)
To: gnats-bugs@netbsd.org, port-sparc64-maintainer@netbsd.org,
	gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
Cc: 
Subject: Re: port-sparc64/29824
Date: Mon, 2 May 2005 12:48:58 -0400

 On May 2,  3:07pm, chuq@chuq.com (Chuck Silvers) wrote:
 -- Subject: Re: port-sparc64/29824
 
 | The following reply was made to PR port-sparc64/29824; it has been noted by GNATS.
 | 
 | From: Chuck Silvers <chuq@chuq.com>
 | To: Matthias Scheler <tron@zhadum.de>
 | Cc: port-sparc64-maintainer@netbsd.org, xsrc-manager@netbsd.org,
 | 	netbsd-bugs@netbsd.org, NetBSD GNATS <gnats-bugs@netbsd.org>,
 | 	macallan18@earthlink.net
 | Subject: Re: port-sparc64/29824
 | Date: Mon, 2 May 2005 08:06:04 -0700
 | 
 |  On Sun, May 01, 2005 at 10:44:20PM +0100, Matthias Scheler wrote:
 |  > On Sun, May 01, 2005 at 02:37:17PM -0700, Chuck Silvers wrote:
 |  > > > Responsible-Changed-From-To: xsrc-manager->port-sparc64-maintainer
 |  > > > Responsible-Changed-By: tron@netbsd.org
 |  > > > Responsible-Changed-When: Sun, 01 May 2005 18:14:03 +0000
 |  > > > Responsible-Changed-Why:
 |  > > > 1.) XFree86's signal handling code does *not* cause this. It will not
 |  > > >     unblock SIGIO from a the SIGIO signal handler.
 |  > > 
 |  > > I just read the code again, it sure looks like it does to me.
 |  > > the call stack in the initial PR comments looks like it could really happen.
 |  > 
 |  > How?
 |  
 |  sorry, I misread your comment.  you're right that it does not unblock
 |  SIGIO in the SIGIO handler, but that's not the problem.  just calling
 |  sigprocmask() in a signal handler is not safe, at least with our pthreads
 |  implementation.   I looked briefly for any mention in our manpages of
 |  what library functions are or are not safe to call in a signal handler,
 |  but I didn't find it.
 |  
 
 The SUS in section 2.4 "Signal Concepts",
 http://www.unix.org/single_unix_specification, mentions the following functions
 as being safe to be called from a signal handler and sigprocmask is one of
 them. Thus we should fix our implementation.
 
 christos
 
 _Exit()
 _exit()
 abort()
 accept()
 access()
 aio_error()
 aio_return()
 aio_suspend()
 alarm()
 bind()
 cfgetispeed()
 cfgetospeed()
 cfsetispeed()
 cfsetospeed()
 chdir()
 chmod()
 chown()
 clock_gettime()
 close()
 connect()
 creat()
 dup()
 dup2()
 execle()
 execve()
 fchmod()
 fchown()
 fcntl()
 fdatasync()
 fork()
 fpathconf()
 fstat()
 fsync()
 ftruncate()
 getegid()
 geteuid()
 getgid()
 getgroups()
 getpeername()
 getpgrp()
 getpid()
 getppid()
 getsockname()
 getsockopt()
 getuid()
 kill()
 link()
 listen()
 lseek()
 lstat()
 mkdir()
 mkfifo()
 open()
 pathconf()
 pause()
 pipe()
 poll()
 posix_trace_event()
 pselect()
 raise()
 read()
 readlink()
 recv()
 recvfrom()
 recvmsg()
 rename()
 rmdir()
 select()
 sem_post()
 send()
 sendmsg()
 sendto()
 setgid()
 setpgid()
 setsid()
 setsockopt()
 setuid()
 shutdown()
 sigaction()
 sigaddset()
 sigdelset()
 sigemptyset()
 sigfillset()
 sigismember()
 sleep()
 signal()
 sigpause()
 sigpending()
 sigprocmask()
 sigqueue()
 sigset()
 sigsuspend()
 sockatmark()
 socket()
 socketpair()
 stat()
 symlink()
 sysconf()
 tcdrain()
 tcflow()
 tcflush()
 tcgetattr()
 tcgetpgrp()
 tcsendbreak()
 tcsetattr()
 tcsetpgrp()
 time()
 timer_getoverrun()
 timer_gettime()
 timer_settime()
 times()
 umask()
 uname()
 unlink()
 utime()
 wait()
 waitpid()
 write()