Date: Tue, 9 Apr 2013 21:49:26 +0200 From: Laurent Bercot <ska-skaware@...rnet.org> To: Rich Felker <dalias@...ifal.cx> Cc: musl@...ts.openwall.com Subject: Re: musl signalfd (was: selfpipe + musl libc info) Thank you for sending the e-mail again; I hadn't received it indeed. > This makes no sense. For SFD_NONBLOCK, setting it atomically does not > matter; the application could just fallback to setting it with fcntl > if opening it with the nonblocking flag failed. Falling back to using > a pipe in that situation makes no sense. If the issue were > SFD_CLOEXEC, non-atomicity is a problem, but there is no way to > fallback anyway. Using a pipe would still have the same non-atomicity > issue. Sorry if I wasn't clear. Talking about my library cluttered things up. My point is that there are 3 use cases in signalfd: 1. the signalfd4 syscall exists. (Recent kernels.) 2. the signalfd syscall exists, but the signalfd4 syscall does not. (Kernel 2.6.22 to 2.6.26.) 3. the signalfd call does not even exist. Case 1 is very clear, as is case 3. Case 2 is the one I'm addressing. The signalfd(2) man page specifies that the library call must not support a nonzero flags argument if the signalfd4 syscall is not available, and must return -1 EINVAL. You chose to not follow this specification, and honor the flags argument *even in case 2*. I am arguing that following the specification is safer: just fail the call when signalfd4 returns -ENOSYS and flags is nonzero. It is safer because the application might expect an atomic library call, which your workaround is not. If people really *need* signalfd with flags, they'll move to a more recent kernel. My library performs a compile-time test to check whether it can safely use the signalfd() libc call, with nonzero flags. This test obviously succeeds in case 1, and obviously fails in case 3. But it should also *fail* in case 2, and enable my own workaround instead. Your current implementation makes the test succeed in case 2, so my library *will* use signalfd(). This is not a real problem to me, because it does not rely on signalfd() atomicity, so I'll be happy with your current version; however, there are a few cases where the safer option might be preferable. (I'm thinking cross-compilation, where you do not autodetect sysdeps but feed them by hand. If you say signalfd is OK because you tested it on a target running musl and it worked, but your final target is running another libc that does not perform the same workaround, you're screwed. Pretty rare case, I'll agree.) -- Laurent
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.