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.