Date: Thu, 10 Mar 2016 20:55:00 -0500 From: Rich Felker <dalias@...c.org> To: Ingo Molnar <mingo@...nel.org>, Linus Torvalds <torvalds@...ux-foundation.org>, Andy Lutomirski <luto@...nel.org>, the arch/x86 maintainers <x86@...nel.org>, Linux Kernel Mailing List <linux-kernel@...r.kernel.org>, Borislav Petkov <bp@...en8.de>, "musl@...ts.openwall.com" <musl@...ts.openwall.com>, Andrew Morton <akpm@...ux-foundation.org>, Thomas Gleixner <tglx@...utronix.de>, Peter Zijlstra <a.p.zijlstra@...llo.nl> Subject: Re: Re: [RFC PATCH] x86/vdso/32: Add AT_SYSINFO cancellation helpers On Fri, Mar 11, 2016 at 02:39:47AM +0100, Szabolcs Nagy wrote: > * Rich Felker <dalias@...c.org> [2016-03-10 19:48:59 -0500]: > > On Fri, Mar 11, 2016 at 01:18:54AM +0100, Szabolcs Nagy wrote: > > > * Rich Felker <dalias@...c.org> [2016-03-10 18:28:20 -0500]: > > > > On Thu, Mar 10, 2016 at 07:03:31PM +0100, Ingo Molnar wrote: > > > > > > > > > > The sticky signal is only ever sent when the thread is in cancellable state - and > > > > > if the target thread notices the cancellation request before the signal arrives, > ^^^^^^... > > > > > it first waits for its arrival before executing any new system calls (as part of > ^^^^^^... > > > > > the teardown, etc.). > > > > > > > > > > So the C library never has to do complex work with a sticky signal pending. > > > > > > > > > > Does that make more sense to you? > > > > > > > > No, it doesn't work. Cancellability of the target thread at the time > > > > of the cancellation request (when you would decide whether or not to > > > > send the signal) has no relation to cancellability at the time of > > > > calling the cancellation point. Consider 2 threads A and B and the > > > > following sequence of events: > > > > > > > > 1. A has cancellation enabled > > > > 2. B calls pthread_cancel(A) and sets sticky pending signal > > > > 3. A disables cancellation > > > > 4. A calls cancellation point and syscall wrongly gets interrupted > > > > > > > > This can be solved with more synchronization in pthread_cancel and > > > > pthread_setcancelstate, but it seems costly. pthread_setcancelstate > > > > would have to clear pending sticky cancellation signals, and any > > > > internal non-cancellable syscalls would have to be made using the same > > > > mechanism (effectively calling pthread_setcancelstate). A naive > > > > implementation of such clearing would involve a syscall itself, > > > > > > i think a syscall in setcancelstate in case of pending sticky signal > > > is not that bad given that cancellation is very rarely used. > > > > I agree, but it's not clear to me whether you could eliminate syscalls > > in the case where it's not pending, since AS-safe lock machinery is > > hard to get right. I don't see a way it can be done with just atomics > > because the syscall that sends the signal cannot be atomic with the > > memory operating setting a flag, which suggests a lock is needed, and > > then there are all sorts of issues to deal with. > > i think this is not a problem and the above marked text hints for > a solution: just call pause() to wait for the sticky signal if > self->cancelstate indicates that there is one comming or pending. There are multiple problems with this approach, at least: - pause does not 'consume' the signal; sigwaitinfo might. - pause might return on a different signal that happens to arrive between setting the flag and sending the cancel signal - If the thread calling pthread_cancel is interrupted by a signal after setting the flag but before sending the signal, the target thread may be arbitrarily delayed; in complex cases it may even deadlock. This should be easy to solve though by having pthread_cancel run with signals masked. > t->cancelstate always have to be atomically modified but sending > the sticky signal can be delayed (does not have to be atomic with > the memory op). Right. > (of course there migth be other caveats and it certainly needs > more atomic ops and more state than the current design) I think it might be possible to do by having pthread_cancel run with signals blocked and having sigwaitinfo consume the sticky signal if the atomic-set cancellation-pending flag was seen, but I haven't thought about all the corner cases of signal handlers and nested cancellation points. POSIX might be making the behavior of the affected cases undefined, though. So I think solving this might be plausible, but nontrivial. 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.