Re: sigwait return 4
On Thu, Aug 25, 2011 at 12:29:29AM +0300, Kostik Belousov wrote: On Wed, Aug 24, 2011 at 10:56:09PM +0200, Jilles Tjoelker wrote: sigwait() was fixed not to return EINTR in 9-current in r212405 (fixed up in r219709). The discussion started at http://lists.freebsd.org/pipermail/freebsd-threads/2010-September/004892.html Solaris is simply wrong in the same way we were wrong. Although POSIX may not be as clear on this as one may like, its intention is clear and additionally not returning EINTR reduces subtle portability problems. Can you, please, describe why do you consider the behaviour prohibiting return of EINTR reasonable ? I do consider that the Solaris behaviour is useful. Applications need to cope with EINTR returns (usually by retrying the call); if they do not do this, bugs arise in uncommon cases. In the case of sigwait(), applications do not really need EINTR: they can include the respective signal into the signal set and do the work inline that was originally in the signal handler. This might require additional pthread_sigmask() calls. This also fixes the race condition almost always associated with EINTR. Historically, this is because sigwait() came with POSIX threads, which also explains why it returns an error number rather than setting errno. The threads group considered EINTR errors not useful enough, given that they may lead to subtle bugs. This is fully standardized for functions like pthread_cond_wait() and pthread_mutex_lock(). In the case of sigwait(), it also plays a role that glibc has decided not to return EINTR, so that returning EINTR may lead to subtle bugs appearing on FreeBSD in software originally written for GNU/Linux. The functions sigwaitinfo() and sigtimedwait() came with POSIX realtime and therefore follow different conventions. -- Jilles Tjoelker ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: sigwait return 4
On Sat, Aug 27, 2011 at 04:25:36PM +0200, Jilles Tjoelker wrote:
On Thu, Aug 25, 2011 at 12:29:29AM +0300, Kostik Belousov wrote:
On Wed, Aug 24, 2011 at 10:56:09PM +0200, Jilles Tjoelker wrote:
sigwait() was fixed not to return EINTR in 9-current in r212405 (fixed
up in r219709). The discussion started at
http://lists.freebsd.org/pipermail/freebsd-threads/2010-September/004892.html
Solaris is simply wrong in the same way we were wrong. Although POSIX
may not be as clear on this as one may like, its intention is clear and
additionally not returning EINTR reduces subtle portability problems.
Can you, please, describe why do you consider the behaviour prohibiting
return of EINTR reasonable ? I do consider that the Solaris behaviour is
useful.
Applications need to cope with EINTR returns (usually by retrying the
call); if they do not do this, bugs arise in uncommon cases.
In the case of sigwait(), applications do not really need EINTR: they
can include the respective signal into the signal set and do the work
inline that was originally in the signal handler. This might require
additional pthread_sigmask() calls. This also fixes the race condition
almost always associated with EINTR.
Historically, this is because sigwait() came with POSIX threads, which
also explains why it returns an error number rather than setting errno.
The threads group considered EINTR errors not useful enough, given that
they may lead to subtle bugs. This is fully standardized for functions
like pthread_cond_wait() and pthread_mutex_lock().
In the case of sigwait(), it also plays a role that glibc has decided
not to return EINTR, so that returning EINTR may lead to subtle bugs
appearing on FreeBSD in software originally written for GNU/Linux.
The functions sigwaitinfo() and sigtimedwait() came with POSIX realtime
and therefore follow different conventions.
I think I finally realized what was the problem Slawa searched the
fix for. The fix from r212405 indeed does not allow EINTR to be returned
from the sigwait() for new libc, but it still leaves the compat libc
and libthr with EINTR.
Below is the patch that I provided to Slawa to handle EINTR condition
in kernel. The meat is in kern_sig.c two lines, everything else is
the r212405 revert.
diff --git a/lib/libc/sys/Makefile.inc b/lib/libc/sys/Makefile.inc
index fe5061d..aa0959b 100644
--- a/lib/libc/sys/Makefile.inc
+++ b/lib/libc/sys/Makefile.inc
@@ -24,9 +24,6 @@ SRCS+=${SYSCALL_COMPAT_SRCS}
NOASM+=${SYSCALL_COMPAT_SRCS:S/.c/.o/}
PSEUDO+= _fcntl.o
.endif
-SRCS+= sigwait.c
-NOASM+= sigwait.o
-PSEUDO+= _sigwait.o
# Add machine dependent asm sources:
SRCS+=${MDASM}
diff --git a/lib/libc/sys/Symbol.map b/lib/libc/sys/Symbol.map
index 095751a..2ba1f8f 100644
--- a/lib/libc/sys/Symbol.map
+++ b/lib/libc/sys/Symbol.map
@@ -937,7 +937,6 @@ FBSDprivate_1.0 {
_sigtimedwait;
__sys_sigtimedwait;
_sigwait;
- __sigwait;
__sys_sigwait;
_sigwaitinfo;
__sys_sigwaitinfo;
diff --git a/lib/libc/sys/sigwait.c b/lib/libc/sys/sigwait.c
deleted file mode 100644
index 2fdffdd..000
--- a/lib/libc/sys/sigwait.c
+++ /dev/null
@@ -1,46 +0,0 @@
-/*-
- * Copyright (c) 2010 davi...@freebsd.org
- *
- * Redistribution and use in source and binary forms, with or without
- * modification, are permitted provided that the following conditions
- * are met:
- * 1. Redistributions of source code must retain the above copyright
- *notice, this list of conditions and the following disclaimer.
- * 2. Redistributions in binary form must reproduce the above copyright
- *notice, this list of conditions and the following disclaimer in the
- *documentation and/or other materials provided with the distribution.
- *
- * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
- * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
- * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
- * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
- * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
- * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
- * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
- * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
- * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
- * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
- * SUCH DAMAGE.
- */
-
-#include sys/cdefs.h
-__FBSDID($FreeBSD$);
-
-#include errno.h
-#include signal.h
-
-int __sys_sigwait(const sigset_t * restrict, int * restrict);
-
-__weak_reference(__sigwait, sigwait);
-
-int
-__sigwait(const sigset_t * restrict set, int * restrict sig)
-{
- int ret;
-
- /* POSIX does not allow EINTR to be returned */
- do {
- ret = __sys_sigwait(set, sig);
-
sigwait return 4
System is 8.2-RELEASE (GENERIC), amd64. Application -- i386 for freebsd7. In ktrace dump I find some strange result: 22951 100556 kas-milter CALL sigwait(0xffdfdf80,0xffdfdf7c) 22951 100556 kas-milter RET sigwait 4 22951 100556 kas-milter PSIG SIGUSR2 caught handler=0x804c0f0 mask=0x4003 code=0x0 RET sigwait 4 confused me, and, I think, confused application too. man sigwait: ERRORS The sigwait() system call will fail if: [EINVAL] The set argument specifies one or more invalid signal numbers. [EFAULT] Any arguments point outside the allocated address space or there is a memory protection fault. How sigwait can return '4'? May be EINTR, converted from ERESTART? But kern_sigtimedwait from sigwait must be called with timeout == NULL... ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: sigwait return 4
On Wed, Aug 24, 2011 at 10:19:07PM +0400, Slawa Olhovchenkov wrote: System is 8.2-RELEASE (GENERIC), amd64. Application -- i386 for freebsd7. In ktrace dump I find some strange result: 22951 100556 kas-milter CALL sigwait(0xffdfdf80,0xffdfdf7c) 22951 100556 kas-milter RET sigwait 4 22951 100556 kas-milter PSIG SIGUSR2 caught handler=0x804c0f0 mask=0x4003 code=0x0 RET sigwait 4 confused me, and, I think, confused application too. man sigwait: ERRORS The sigwait() system call will fail if: [EINVAL] The set argument specifies one or more invalid signal numbers. [EFAULT] Any arguments point outside the allocated address space or there is a memory protection fault. How sigwait can return '4'? May be EINTR, converted from ERESTART? But kern_sigtimedwait from sigwait must be called with timeout == NULL... What should the system do for a delivered signal not present in the set ? I guess this is the case of your ktrace. Looking at the SUSv4, I see no mention of the situation, but in Oracle SunOS 5.10 man page for sigwait(2), it is said explicitely EINTR The wait was interrupted by an unblocked, caught signal. So I think that we have a bug in the man page. diff --git a/lib/libc/sys/sigwait.2 b/lib/libc/sys/sigwait.2 index 8c00cf4..b462201 100644 --- a/lib/libc/sys/sigwait.2 +++ b/lib/libc/sys/sigwait.2 @@ -27,7 +27,7 @@ .\ .\ $FreeBSD$ .\ -.Dd November 11, 2005 +.Dd August 24, 2011 .Dt SIGWAIT 2 .Os .Sh NAME @@ -94,6 +94,8 @@ The .Fn sigwait system call will fail if: .Bl -tag -width Er +.It Bq Er EINTR +The system call was interrupted by an unblocked, caught signal. .It Bq Er EINVAL The .Fa set pgpWlJF1UhSzz.pgp Description: PGP signature
Re: sigwait return 4
On Wed, Aug 24, 2011 at 10:07:03PM +0300, Kostik Belousov wrote: On Wed, Aug 24, 2011 at 10:19:07PM +0400, Slawa Olhovchenkov wrote: System is 8.2-RELEASE (GENERIC), amd64. Application -- i386 for freebsd7. In ktrace dump I find some strange result: 22951 100556 kas-milter CALL sigwait(0xffdfdf80,0xffdfdf7c) 22951 100556 kas-milter RET sigwait 4 22951 100556 kas-milter PSIG SIGUSR2 caught handler=0x804c0f0 mask=0x4003 code=0x0 RET sigwait 4 confused me, and, I think, confused application too. man sigwait: ERRORS The sigwait() system call will fail if: [EINVAL] The set argument specifies one or more invalid signal numbers. [EFAULT] Any arguments point outside the allocated address space or there is a memory protection fault. How sigwait can return '4'? May be EINTR, converted from ERESTART? But kern_sigtimedwait from sigwait must be called with timeout == NULL... What should the system do for a delivered signal not present in the set ? I guess this is the case of your ktrace. Looking at the SUSv4, I see no mention of the situation, but in Oracle SunOS 5.10 man page for sigwait(2), it is said explicitely EINTR The wait was interrupted by an unblocked, caught signal. I don't think you right in this case. This is kas-milter and in this thread (this is multi-thread application) kas-milter wait for USR2 for reload config. System return from sigwait only on USR2, but not each return w/ non-zero return code. On freebsd7 this application don't complain about sigwait's return value. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: sigwait return 4
On Wed, Aug 24, 2011 at 11:24:46PM +0400, Slawa Olhovchenkov wrote: On Wed, Aug 24, 2011 at 10:07:03PM +0300, Kostik Belousov wrote: On Wed, Aug 24, 2011 at 10:19:07PM +0400, Slawa Olhovchenkov wrote: System is 8.2-RELEASE (GENERIC), amd64. Application -- i386 for freebsd7. In ktrace dump I find some strange result: 22951 100556 kas-milter CALL sigwait(0xffdfdf80,0xffdfdf7c) 22951 100556 kas-milter RET sigwait 4 22951 100556 kas-milter PSIG SIGUSR2 caught handler=0x804c0f0 mask=0x4003 code=0x0 RET sigwait 4 confused me, and, I think, confused application too. man sigwait: ERRORS The sigwait() system call will fail if: [EINVAL] The set argument specifies one or more invalid signal numbers. [EFAULT] Any arguments point outside the allocated address space or there is a memory protection fault. How sigwait can return '4'? May be EINTR, converted from ERESTART? But kern_sigtimedwait from sigwait must be called with timeout == NULL... What should the system do for a delivered signal not present in the set ? I guess this is the case of your ktrace. Looking at the SUSv4, I see no mention of the situation, but in Oracle SunOS 5.10 man page for sigwait(2), it is said explicitely EINTR The wait was interrupted by an unblocked, caught signal. I don't think you right in this case. This is kas-milter and in this thread (this is multi-thread application) kas-milter wait for USR2 for reload config. System return from sigwait only on USR2, but not each return w/ non-zero return code. On freebsd7 this application don't complain about sigwait's return value. Could it be that some other thread has the signal unblocked ? (You can verify this with procstat -j). Can you write the self-contained test case that demonstrates the behaviour ? pgpgqCL1Hl1XD.pgp Description: PGP signature
Re: sigwait return 4
On Wed, Aug 24, 2011 at 10:32:02PM +0300, Kostik Belousov wrote: What should the system do for a delivered signal not present in the set ? I guess this is the case of your ktrace. Looking at the SUSv4, I see no mention of the situation, but in Oracle SunOS 5.10 man page for sigwait(2), it is said explicitely EINTR The wait was interrupted by an unblocked, caught signal. I don't think you right in this case. This is kas-milter and in this thread (this is multi-thread application) kas-milter wait for USR2 for reload config. System return from sigwait only on USR2, but not each return w/ non-zero return code. On freebsd7 this application don't complain about sigwait's return value. Could it be that some other thread has the signal unblocked ? (You can verify this with procstat -j). Can you write the self-contained test case that demonstrates the behaviour ? This is closed-source software. # procstat -j PIDTID COMM SIG FLAGS 1395 100199 kas-milter HUP -B 1395 100199 kas-milter INT -B 1395 100199 kas-milter QUIT -- 1395 100199 kas-milter ILL -- 1395 100199 kas-milter TRAP -- 1395 100199 kas-milter ABRT -- 1395 100199 kas-milter EMT -- 1395 100199 kas-milter FPE -- 1395 100199 kas-milter KILL -- 1395 100199 kas-milter BUS -- 1395 100199 kas-milter SEGV -- 1395 100199 kas-milter SYS -- 1395 100199 kas-milter PIPE -- 1395 100199 kas-milter ALRM -- 1395 100199 kas-milter TERM -B 1395 100199 kas-milter URG -- 1395 100199 kas-milter STOP -- 1395 100199 kas-milter TSTP -- 1395 100199 kas-milter CONT -- 1395 100199 kas-milter CHLD -- 1395 100199 kas-milter TTIN -- 1395 100199 kas-milter TTOU -- 1395 100199 kas-milter IO -- 1395 100199 kas-milter XCPU -- 1395 100199 kas-milter XFSZ -- 1395 100199 kas-milter VTALRM -- 1395 100199 kas-milter PROF -- 1395 100199 kas-milter WINCH-- 1395 100199 kas-milter INFO -- 1395 100199 kas-milter USR1 -- 1395 100199 kas-milter USR2 -- 1395 100199 kas-milter 32 -- 1395 100199 kas-milter 33 -- 1395 100199 kas-milter 34 -- 1395 100199 kas-milter 35 -- 1395 100199 kas-milter 36 -- 1395 100199 kas-milter 37 -- 1395 100199 kas-milter 38 -- 1395 100199 kas-milter 39 -- 1395 100199 kas-milter 40 -- 1395 100199 kas-milter 41 -- 1395 100199 kas-milter 42 -- 1395 100199 kas-milter 43 -- 1395 100199 kas-milter 44 -- 1395 100199 kas-milter 45 -- 1395 100199 kas-milter 46 -- 1395 100199 kas-milter 47 -- 1395 100199 kas-milter 48 -- 1395 100199 kas-milter 49 -- 1395 100199 kas-milter 50 -- 1395 100199 kas-milter 51 -- 1395 100199 kas-milter 52 -- 1395 100199 kas-milter 53 -- 1395 100199 kas-milter 54 -- 1395 100199 kas-milter 55 -- 1395 100199 kas-milter 56 -- 1395 100199 kas-milter 57 -- 1395 100199 kas-milter 58 -- 1395 100199 kas-milter 59 -- 1395 100199 kas-milter 60 -- 1395 100199 kas-milter 61 -- 1395 100199 kas-milter 62 -- 1395 100199 kas-milter 63 -- 1395 100199 kas-milter 64 -- 1395 100199 kas-milter 65 -- 1395 100199 kas-milter 66 -- 1395 100199 kas-milter 67 -- 1395 100199 kas-milter 68 -- 1395 100199 kas-milter 69 -- 1395 100199 kas-milter 70 -- 1395 100199 kas-milter 71 -- 1395 100199 kas-milter 72 -- 1395 100199 kas-milter 73 -- 1395 100199 kas-milter 74 -- 1395 100199 kas-milter 75 -- 1395 100199 kas-milter 76 -- 1395 100199 kas-milter 77 -- 1395 100199 kas-milter 78 -- 1395 100199 kas-milter 79 -- 1395 100199 kas-milter 80 -- 1395 100199 kas-milter 81 -- 1395 100199 kas-milter 82 -- 1395 100199 kas-milter 83 -- 1395 100199 kas-milter 84 -- 1395 100199 kas-milter 85 -- 1395 100199 kas-milter 86 -- 1395 100199 kas-milter 87 -- 1395 100199 kas-milter 88 -- 1395 100199 kas-milter 89 -- 1395 100199 kas-milter 90 -- 1395 100199 kas-milter 91 -- 1395 100199 kas-milter 92 -- 1395 100199 kas-milter 93 -- 1395 100199 kas-milter 94 -- 1395 100199 kas-milter 95 --
Re: sigwait return 4
On Wed, Aug 24, 2011 at 11:42:29PM +0400, Slawa Olhovchenkov wrote: On Wed, Aug 24, 2011 at 10:32:02PM +0300, Kostik Belousov wrote: What should the system do for a delivered signal not present in the set ? I guess this is the case of your ktrace. Looking at the SUSv4, I see no mention of the situation, but in Oracle SunOS 5.10 man page for sigwait(2), it is said explicitely EINTR The wait was interrupted by an unblocked, caught signal. I don't think you right in this case. This is kas-milter and in this thread (this is multi-thread application) kas-milter wait for USR2 for reload config. System return from sigwait only on USR2, but not each return w/ non-zero return code. On freebsd7 this application don't complain about sigwait's return value. Could it be that some other thread has the signal unblocked ? (You can verify this with procstat -j). Can you write the self-contained test case that demonstrates the behaviour ? This is closed-source software. How is this statement related to the creation of the standalone test case ? # procstat -j PIDTID COMM SIG FLAGS 1395 100199 kas-milter USR2 -- 1395 100232 kas-milter USR2 -- Both threads have the signal not blocked. This is not definitive, since signal must be blocked during the call to sigwait(2). Note that the SUSv4 says that The signals defined by set shall have been blocked at the time of the call to sigwait(); otherwise, the behavior is undefined. pgpOjMqGVVeyP.pgp Description: PGP signature
Re: sigwait return 4
On Wed, Aug 24, 2011 at 11:42:29PM +0400, Slawa Olhovchenkov wrote: On Wed, Aug 24, 2011 at 10:32:02PM +0300, Kostik Belousov wrote: What should the system do for a delivered signal not present in the set ? I guess this is the case of your ktrace. Looking at the SUSv4, I see no mention of the situation, but in Oracle SunOS 5.10 man page for sigwait(2), it is said explicitely EINTR The wait was interrupted by an unblocked, caught signal. I don't think you right in this case. This is kas-milter and in this thread (this is multi-thread application) kas-milter wait for USR2 for reload config. System return from sigwait only on USR2, but not each return w/ non-zero return code. On freebsd7 this application don't complain about sigwait's return value. Could it be that some other thread has the signal unblocked ? (You can verify this with procstat -j). Can you write the self-contained test case that demonstrates the behaviour ? This is closed-source software. # procstat -j PIDTID COMM SIG FLAGS 1395 100199 kas-milter HUP -B 1395 100199 kas-milter INT -B 1395 100199 kas-milter QUIT -- 1395 100199 kas-milter ILL -- 1395 100199 kas-milter TRAP -- 1395 100199 kas-milter ABRT -- 1395 100199 kas-milter EMT -- 1395 100199 kas-milter FPE -- 1395 100199 kas-milter KILL -- 1395 100199 kas-milter BUS -- 1395 100199 kas-milter SEGV -- 1395 100199 kas-milter SYS -- 1395 100199 kas-milter PIPE -- 1395 100199 kas-milter ALRM -- 1395 100199 kas-milter TERM -B 1395 100199 kas-milter URG -- 1395 100199 kas-milter STOP -- 1395 100199 kas-milter TSTP -- 1395 100199 kas-milter CONT -- 1395 100199 kas-milter CHLD -- 1395 100199 kas-milter TTIN -- 1395 100199 kas-milter TTOU -- 1395 100199 kas-milter IO -- 1395 100199 kas-milter XCPU -- 1395 100199 kas-milter XFSZ -- 1395 100199 kas-milter VTALRM -- 1395 100199 kas-milter PROF -- 1395 100199 kas-milter WINCH-- 1395 100199 kas-milter INFO -- 1395 100199 kas-milter USR1 -- 1395 100199 kas-milter USR2 -- 1395 100199 kas-milter 32 -- 1395 100199 kas-milter 33 -- 1395 100199 kas-milter 34 -- 1395 100199 kas-milter 35 -- 1395 100199 kas-milter 36 -- 1395 100199 kas-milter 37 -- 1395 100199 kas-milter 38 -- 1395 100199 kas-milter 39 -- 1395 100199 kas-milter 40 -- 1395 100199 kas-milter 41 -- 1395 100199 kas-milter 42 -- 1395 100199 kas-milter 43 -- 1395 100199 kas-milter 44 -- 1395 100199 kas-milter 45 -- 1395 100199 kas-milter 46 -- 1395 100199 kas-milter 47 -- 1395 100199 kas-milter 48 -- 1395 100199 kas-milter 49 -- 1395 100199 kas-milter 50 -- 1395 100199 kas-milter 51 -- 1395 100199 kas-milter 52 -- 1395 100199 kas-milter 53 -- 1395 100199 kas-milter 54 -- 1395 100199 kas-milter 55 -- 1395 100199 kas-milter 56 -- 1395 100199 kas-milter 57 -- 1395 100199 kas-milter 58 -- 1395 100199 kas-milter 59 -- 1395 100199 kas-milter 60 -- 1395 100199 kas-milter 61 -- 1395 100199 kas-milter 62 -- 1395 100199 kas-milter 63 -- 1395 100199 kas-milter 64 -- 1395 100199 kas-milter 65 -- 1395 100199 kas-milter 66 -- 1395 100199 kas-milter 67 -- 1395 100199 kas-milter 68 -- 1395 100199 kas-milter 69 -- 1395 100199 kas-milter 70 -- 1395 100199 kas-milter 71 -- 1395 100199 kas-milter 72 -- 1395 100199 kas-milter 73 -- 1395 100199 kas-milter 74 -- 1395 100199 kas-milter 75 -- 1395 100199 kas-milter 76 -- 1395 100199 kas-milter 77 -- 1395 100199 kas-milter 78 -- 1395 100199 kas-milter 79 -- 1395 100199 kas-milter 80 -- 1395 100199 kas-milter 81 -- 1395 100199 kas-milter 82 -- 1395 100199 kas-milter 83 -- 1395 100199 kas-milter 84 -- 1395 100199 kas-milter 85 -- 1395 100199 kas-milter 86 -- 1395 100199 kas-milter 87 -- 1395 100199 kas-milter 88 -- 1395 100199 kas-milter 89 -- 1395 100199 kas-milter 90 -- 1395 100199
Re: sigwait return 4
On Wed, Aug 24, 2011 at 10:50:35PM +0300, Kostik Belousov wrote: On Wed, Aug 24, 2011 at 11:42:29PM +0400, Slawa Olhovchenkov wrote: On Wed, Aug 24, 2011 at 10:32:02PM +0300, Kostik Belousov wrote: What should the system do for a delivered signal not present in the set ? I guess this is the case of your ktrace. Looking at the SUSv4, I see no mention of the situation, but in Oracle SunOS 5.10 man page for sigwait(2), it is said explicitely EINTR The wait was interrupted by an unblocked, caught signal. I don't think you right in this case. This is kas-milter and in this thread (this is multi-thread application) kas-milter wait for USR2 for reload config. System return from sigwait only on USR2, but not each return w/ non-zero return code. On freebsd7 this application don't complain about sigwait's return value. Could it be that some other thread has the signal unblocked ? (You can verify this with procstat -j). Can you write the self-contained test case that demonstrates the behaviour ? This is closed-source software. How is this statement related to the creation of the standalone test case ? I don't know what testing. # procstat -j PIDTID COMM SIG FLAGS 1395 100199 kas-milter USR2 -- 1395 100232 kas-milter USR2 -- Both threads have the signal not blocked. This is not definitive, since signal must be blocked during the call to sigwait(2). Note that the SUSv4 says that The signals defined by set shall have been blocked at the time of the call to sigwait(); otherwise, the behavior is undefined. This is not suitable to return '4'. And where root of this '4'? In /sys/kern/kern_sig.c:sigwait we call error = kern_sigtimedwait(td, set, ksi, NULL); --- no timeout. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: sigwait return 4
On Wed, Aug 24, 2011 at 10:50:35PM +0300, Kostik Belousov wrote: On Wed, Aug 24, 2011 at 11:42:29PM +0400, Slawa Olhovchenkov wrote: On Wed, Aug 24, 2011 at 10:32:02PM +0300, Kostik Belousov wrote: What should the system do for a delivered signal not present in the set ? I guess this is the case of your ktrace. Looking at the SUSv4, I see no mention of the situation, but in Oracle SunOS 5.10 man page for sigwait(2), it is said explicitely EINTR The wait was interrupted by an unblocked, caught signal. I don't think you right in this case. This is kas-milter and in this thread (this is multi-thread application) kas-milter wait for USR2 for reload config. System return from sigwait only on USR2, but not each return w/ non-zero return code. On freebsd7 this application don't complain about sigwait's return value. Could it be that some other thread has the signal unblocked ? (You can verify this with procstat -j). Can you write the self-contained test case that demonstrates the behaviour ? This is closed-source software. How is this statement related to the creation of the standalone test case ? # procstat -j PIDTID COMM SIG FLAGS 1395 100199 kas-milter USR2 -- 1395 100232 kas-milter USR2 -- Both threads have the signal not blocked. This is not definitive, since signal must be blocked during the call to sigwait(2). Note that the SUSv4 says that The signals defined by set shall have been blocked at the time of the call to sigwait(); otherwise, the behavior is undefined. I see some strange in debug: # kdump -H -f /ktrace.out | grep sigw 1396 100228 kas-milter CALL sigwait(0xffdfdf80,0xffdfdf7c) # ktrdump | grep sigw 738 syscall: td=0xff002549d900 pid 1396 sigwait (0xffdfdf80, 0xffdfdf7c, 0xff8117827bf0) 666 syscall: td=0xff000c3d9900 pid 1286 sigwait (0x7fbfef70, 0x7fbfef8c, 0) 660 syscall: td=0xff00251ed900 pid 1277 sigwait (0x7ddeff70, 0x7ddeff8c, 0) 51 syscall: td=0xff0004ac5000 pid 787 sigwait (0x7fffebb0, 0x7fffebdc, 0) now I see 3'th non-zero argument from pid 1396. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: sigwait return 4
On Wed, Aug 24, 2011 at 10:07:03PM +0300, Kostik Belousov wrote: On Wed, Aug 24, 2011 at 10:19:07PM +0400, Slawa Olhovchenkov wrote: System is 8.2-RELEASE (GENERIC), amd64. Application -- i386 for freebsd7. In ktrace dump I find some strange result: 22951 100556 kas-milter CALL sigwait(0xffdfdf80,0xffdfdf7c) 22951 100556 kas-milter RET sigwait 4 22951 100556 kas-milter PSIG SIGUSR2 caught handler=0x804c0f0 mask=0x4003 code=0x0 RET sigwait 4 confused me, and, I think, confused application too. man sigwait: ERRORS The sigwait() system call will fail if: [EINVAL] The set argument specifies one or more invalid signal numbers. [EFAULT] Any arguments point outside the allocated address space or there is a memory protection fault. How sigwait can return '4'? May be EINTR, converted from ERESTART? But kern_sigtimedwait from sigwait must be called with timeout == NULL... What should the system do for a delivered signal not present in the set ? I guess this is the case of your ktrace. Looking at the SUSv4, I see no mention of the situation, but in Oracle SunOS 5.10 man page for sigwait(2), it is said explicitely EINTR The wait was interrupted by an unblocked, caught signal. So I think that we have a bug in the man page. diff --git a/lib/libc/sys/sigwait.2 b/lib/libc/sys/sigwait.2 index 8c00cf4..b462201 100644 --- a/lib/libc/sys/sigwait.2 +++ b/lib/libc/sys/sigwait.2 @@ -27,7 +27,7 @@ .\ .\ $FreeBSD$ .\ -.Dd November 11, 2005 +.Dd August 24, 2011 .Dt SIGWAIT 2 .Os .Sh NAME @@ -94,6 +94,8 @@ The .Fn sigwait system call will fail if: .Bl -tag -width Er +.It Bq Er EINTR +The system call was interrupted by an unblocked, caught signal. .It Bq Er EINVAL The .Fa set This patch would be wrong, except to document existing behaviour in -stable branches. sigwait() was fixed not to return EINTR in 9-current in r212405 (fixed up in r219709). The discussion started at http://lists.freebsd.org/pipermail/freebsd-threads/2010-September/004892.html Solaris is simply wrong in the same way we were wrong. Although POSIX may not be as clear on this as one may like, its intention is clear and additionally not returning EINTR reduces subtle portability problems. Note that sigwaitinfo() and sigtimedwait() may return EINTR. SA_RESTART applies to sigwaitinfo() but not to sigtimedwait() (because the timeout cannot be restarted). -- Jilles Tjoelker ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: sigwait return 4
On Wed, Aug 24, 2011 at 10:56:09PM +0200, Jilles Tjoelker wrote: sigwait() was fixed not to return EINTR in 9-current in r212405 (fixed up in r219709). The discussion started at http://lists.freebsd.org/pipermail/freebsd-threads/2010-September/004892.html As I see this revisions not MFCed. No plans to fix this in 8-STABLE? Solaris is simply wrong in the same way we were wrong. Although POSIX may not be as clear on this as one may like, its intention is clear and additionally not returning EINTR reduces subtle portability problems. Note that sigwaitinfo() and sigtimedwait() may return EINTR. SA_RESTART applies to sigwaitinfo() but not to sigtimedwait() (because the timeout cannot be restarted). -- Jilles Tjoelker ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: sigwait return 4
On Wed, Aug 24, 2011 at 10:56:09PM +0200, Jilles Tjoelker wrote: On Wed, Aug 24, 2011 at 10:07:03PM +0300, Kostik Belousov wrote: On Wed, Aug 24, 2011 at 10:19:07PM +0400, Slawa Olhovchenkov wrote: System is 8.2-RELEASE (GENERIC), amd64. Application -- i386 for freebsd7. In ktrace dump I find some strange result: 22951 100556 kas-milter CALL sigwait(0xffdfdf80,0xffdfdf7c) 22951 100556 kas-milter RET sigwait 4 22951 100556 kas-milter PSIG SIGUSR2 caught handler=0x804c0f0 mask=0x4003 code=0x0 RET sigwait 4 confused me, and, I think, confused application too. man sigwait: ERRORS The sigwait() system call will fail if: [EINVAL] The set argument specifies one or more invalid signal numbers. [EFAULT] Any arguments point outside the allocated address space or there is a memory protection fault. How sigwait can return '4'? May be EINTR, converted from ERESTART? But kern_sigtimedwait from sigwait must be called with timeout == NULL... What should the system do for a delivered signal not present in the set ? I guess this is the case of your ktrace. Looking at the SUSv4, I see no mention of the situation, but in Oracle SunOS 5.10 man page for sigwait(2), it is said explicitely EINTR The wait was interrupted by an unblocked, caught signal. So I think that we have a bug in the man page. diff --git a/lib/libc/sys/sigwait.2 b/lib/libc/sys/sigwait.2 index 8c00cf4..b462201 100644 --- a/lib/libc/sys/sigwait.2 +++ b/lib/libc/sys/sigwait.2 @@ -27,7 +27,7 @@ .\ .\ $FreeBSD$ .\ -.Dd November 11, 2005 +.Dd August 24, 2011 .Dt SIGWAIT 2 .Os .Sh NAME @@ -94,6 +94,8 @@ The .Fn sigwait system call will fail if: .Bl -tag -width Er +.It Bq Er EINTR +The system call was interrupted by an unblocked, caught signal. .It Bq Er EINVAL The .Fa set This patch would be wrong, except to document existing behaviour in -stable branches. sigwait() was fixed not to return EINTR in 9-current in r212405 (fixed up in r219709). The discussion started at http://lists.freebsd.org/pipermail/freebsd-threads/2010-September/004892.html Solaris is simply wrong in the same way we were wrong. Although POSIX may not be as clear on this as one may like, its intention is clear and additionally not returning EINTR reduces subtle portability problems. Can you, please, describe why do you consider the behaviour prohibiting return of EINTR reasonable ? I do consider that the Solaris behaviour is useful. Since we went the other route, the addition to sigwait(2) manpage that clarifies this looks useful. And, sigwait(2) shall be sigwait(3). Also, the sentence the sigwaitinfo() function is equivalent to sigwait() ... in the sigwaitinfo(2) is not complete, due to EINTR. Note that sigwaitinfo() and sigtimedwait() may return EINTR. SA_RESTART applies to sigwaitinfo() but not to sigtimedwait() (because the timeout cannot be restarted). -- Jilles Tjoelker pgpyJTXjtKSeq.pgp Description: PGP signature
Re: sigwait return 4
On Thu, Aug 25, 2011 at 12:29:29AM +0300, Kostik Belousov wrote: Solaris is simply wrong in the same way we were wrong. Although POSIX may not be as clear on this as one may like, its intention is clear and additionally not returning EINTR reduces subtle portability problems. Can you, please, describe why do you consider the behaviour prohibiting return of EINTR reasonable ? I do consider that the Solaris behaviour is useful. Since we went the other route, the addition to sigwait(2) manpage that clarifies this looks useful. And, sigwait(2) shall be sigwait(3). Also, the sentence the sigwaitinfo() function is equivalent to sigwait() ... in the sigwaitinfo(2) is not complete, due to EINTR. Like this (svn cp to be applied). diff --git a/lib/libc/sys/sigwait.2 b/lib/libc/sys/sigwait.2 index 8c00cf4..a9e605c 100644 --- a/lib/libc/sys/sigwait.2 +++ b/lib/libc/sys/sigwait.2 @@ -27,7 +27,7 @@ .\ .\ $FreeBSD$ .\ -.Dd November 11, 2005 +.Dd August 24, 2011 .Dt SIGWAIT 2 .Os .Sh NAME @@ -82,6 +82,14 @@ selected, it will be the lowest numbered one. The selection order between realtime and non-realtime signals, or between multiple pending non-realtime signals, is unspecified. +.Sh IMPLEMENTATION NOTES +The +.Fn sigwait +function is implemented as a wrapper around the +.Fn __sys_sigwait +system call, which retries the call on +.Er EINTR +error. .Sh RETURN VALUES If successful, .Fn sigwait diff --git a/lib/libc/sys/sigwaitinfo.2 b/lib/libc/sys/sigwaitinfo.2 index 41be9e2..a83de06 100644 --- a/lib/libc/sys/sigwaitinfo.2 +++ b/lib/libc/sys/sigwaitinfo.2 @@ -27,7 +27,7 @@ .\ .\ $FreeBSD$ .\ -.Dd November 11, 2005 +.Dd August 24, 2011 .Dt SIGTIMEDWAIT 2 .Os .Sh NAME @@ -116,6 +116,16 @@ except that the selected signal number shall be stored in the member, and the cause of the signal shall be stored in the .Va si_code member. +Besides this, the +.Fn sigwaitinfo +and +.Fn sigtimedwait +system calls may return +.Er EINTR +if interrupted by signal, which is not allowed for the +.Fn sigwait +function. +.Pp If any value is queued to the selected signal, the first such queued value is dequeued and, if the info argument is .Pf non- Dv NULL , pgppSwqcBJsag.pgp Description: PGP signature
