[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20130409194926.GA3515@skarnet.org>
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.
