[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140527190134.GD507@brightrain.aerifal.cx>
Date: Tue, 27 May 2014 15:01:34 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: [UGLY PATCH v3] Support for no-legacy-syscalls archs
On Tue, May 27, 2014 at 01:29:54PM +0200, Szabolcs Nagy wrote:
> * Rich Felker <dalias@...c.org> [2014-05-27 01:26:25 -0400]:
> > In the case of epoll, etc. I reworked the code to always prefer the
> > new syscalls and only fallback to the old ones if (1) they exist, and
> > (2) the new one returned ENOSYS. signalfd already has fallback code
> > that handles FD_CLOEXEC as best it can when the new syscall is not
> > available, but the others seem to be lacking the proper fallback code
> > so I should perhaps add that too.
>
> SOCK_CLOEXEC and SOCK_NONBLOCK fallbacks for socketpair are missing too
I thought I'd already added them, but you're right.
Perhaps if we're emulating the fallback cases we should go ahead and
make it race-free. This can be done by a combination of locking and
signal masking that prevents fork, posix_spawn, and exec* during the
interval where the close-on-exec flag is not yet set on the new fd. It
would basically look like:
__block_app_sigs(&set);
__lock(cloexec_lock);
[do fallback work here]
__restore_sigs(&set);
This would not work if the fallback work were supposed to be
interruptible by signals; I'm not sure if any such cases would need to
be considered.
Our fork and posix_spawn implementations already run with all signals
blocked, so all that would need to be added to them is the locking.
Adding the code to exec* would incur some additional cost, and I'm
actually not sure how to do it right without the new program
inheriting the all-blocked signal mask.
> > +#ifdef SYS_pausex
> > + __syscall(SYS_pause);
> > +#else
> > + __syscall(SYS_futex, &lock, FUTEX_WAIT, 1, 0);
> > +#endif
>
> pausex typo
Actually it was my cheap test of the fallback case that I forgot to
remove. :) Fixed. BTW do you have any better ideas for a fallback
here? Maybe some sleep variant? I just want something that will avoid
spinning and consuming cpu while we wait for exit to finish.
Rich
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.
