Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1355531

Re: [musl] Re: [RFC PATCH] x86/vdso/32: Add AT_SYSINFO cancellation helpers

From Rich Felker <dalias@libc.org>
Newsgroups linux.kernel
Subject Re: [musl] Re: [RFC PATCH] x86/vdso/32: Add AT_SYSINFO cancellation helpers
Date 2016-03-11 03:00 +0100
Message-ID <rbkwV-7et-1@gated-at.bofh.it> (permalink)
References (5 earlier) <rbdc6-2iB-9@gated-at.bofh.it> <rbibN-5JJ-27@gated-at.bofh.it> <rbiY9-6hN-1@gated-at.bofh.it> <rbjrb-6to-7@gated-at.bofh.it> <rbkdA-74F-13@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw

On Fri, Mar 11, 2016 at 02:39:47AM +0100, Szabolcs Nagy wrote:
> * Rich Felker <dalias@libc.org> [2016-03-10 19:48:59 -0500]:
> > On Fri, Mar 11, 2016 at 01:18:54AM +0100, Szabolcs Nagy wrote:
> > > * Rich Felker <dalias@libc.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

Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

[RFC PATCH] x86/vdso/32: Add AT_SYSINFO cancellation helpers Andy Lutomirski <luto@kernel.org> - 2016-03-09 02:30 +0100
  Re: [RFC PATCH] x86/vdso/32: Add AT_SYSINFO cancellation helpers Ingo Molnar <mingo@kernel.org> - 2016-03-09 10:00 +0100
    Re: [musl] Re: [RFC PATCH] x86/vdso/32: Add AT_SYSINFO cancellation  helpers Szabolcs Nagy <nsz@port70.net> - 2016-03-09 12:40 +0100
      Re: [musl] Re: [RFC PATCH] x86/vdso/32: Add AT_SYSINFO cancellation  helpers Szabolcs Nagy <nsz@port70.net> - 2016-03-09 12:50 +0100
      Re: [musl] Re: [RFC PATCH] x86/vdso/32: Add AT_SYSINFO cancellation helpers Linus Torvalds <torvalds@linux-foundation.org> - 2016-03-09 20:50 +0100
        Re: [musl] Re: [RFC PATCH] x86/vdso/32: Add AT_SYSINFO cancellation helpers Andy Lutomirski <luto@amacapital.net> - 2016-03-09 22:00 +0100
          Re: [musl] Re: [RFC PATCH] x86/vdso/32: Add AT_SYSINFO cancellation helpers Linus Torvalds <torvalds@linux-foundation.org> - 2016-03-09 22:30 +0100
          Re: [musl] Re: [RFC PATCH] x86/vdso/32: Add AT_SYSINFO cancellation  helpers Ingo Molnar <mingo@kernel.org> - 2016-03-10 12:00 +0100
        Re: [musl] Re: [RFC PATCH] x86/vdso/32: Add AT_SYSINFO cancellation  helpers Rich Felker <dalias@libc.org> - 2016-03-10 04:40 +0100
          Re: [musl] Re: [RFC PATCH] x86/vdso/32: Add AT_SYSINFO cancellation  helpers Ingo Molnar <mingo@kernel.org> - 2016-03-10 12:20 +0100
            Re: [musl] Re: [RFC PATCH] x86/vdso/32: Add AT_SYSINFO cancellation  helpers Rich Felker <dalias@libc.org> - 2016-03-10 17:50 +0100
              Re: [musl] Re: [RFC PATCH] x86/vdso/32: Add AT_SYSINFO cancellation  helpers Ingo Molnar <mingo@kernel.org> - 2016-03-10 19:10 +0100
                Re: [musl] Re: [RFC PATCH] x86/vdso/32: Add AT_SYSINFO cancellation  helpers Rich Felker <dalias@libc.org> - 2016-03-11 00:30 +0100
                Re: [musl] Re: [RFC PATCH] x86/vdso/32: Add AT_SYSINFO cancellation  helpers Szabolcs Nagy <nsz@port70.net> - 2016-03-11 01:20 +0100
                Re: [musl] Re: [RFC PATCH] x86/vdso/32: Add AT_SYSINFO cancellation  helpers Rich Felker <dalias@libc.org> - 2016-03-11 01:50 +0100
                Re: [musl] Re: [RFC PATCH] x86/vdso/32: Add AT_SYSINFO cancellation helpers Andy Lutomirski <luto@amacapital.net> - 2016-03-11 02:20 +0100
                Re: [musl] Re: [RFC PATCH] x86/vdso/32: Add AT_SYSINFO cancellation  helpers Szabolcs Nagy <nsz@port70.net> - 2016-03-11 02:40 +0100
                Re: [musl] Re: [RFC PATCH] x86/vdso/32: Add AT_SYSINFO cancellation  helpers Rich Felker <dalias@libc.org> - 2016-03-11 03:00 +0100
                Re: [musl] Re: [RFC PATCH] x86/vdso/32: Add AT_SYSINFO cancellation  helpers Szabolcs Nagy <nsz@port70.net> - 2016-03-11 03:00 +0100
                Re: [musl] Re: [RFC PATCH] x86/vdso/32: Add AT_SYSINFO cancellation  helpers Ingo Molnar <mingo@kernel.org> - 2016-03-11 10:40 +0100
                Re: [musl] Re: [RFC PATCH] x86/vdso/32: Add AT_SYSINFO cancellation  helpers Szabolcs Nagy <nsz@port70.net> - 2016-03-11 12:40 +0100
                Re: [musl] Re: [RFC PATCH] x86/vdso/32: Add AT_SYSINFO cancellation helpers Linus Torvalds <torvalds@linux-foundation.org> - 2016-03-11 20:30 +0100
                Re: [musl] Re: [RFC PATCH] x86/vdso/32: Add AT_SYSINFO cancellation helpers Andy Lutomirski <luto@amacapital.net> - 2016-03-11 20:40 +0100
                Re: [musl] Re: [RFC PATCH] x86/vdso/32: Add AT_SYSINFO cancellation helpers Linus Torvalds <torvalds@linux-foundation.org> - 2016-03-11 20:40 +0100
                Re: [musl] Re: [RFC PATCH] x86/vdso/32: Add AT_SYSINFO cancellation helpers Linus Torvalds <torvalds@linux-foundation.org> - 2016-03-11 20:50 +0100
                Re: [musl] Re: [RFC PATCH] x86/vdso/32: Add AT_SYSINFO cancellation  helpers Ingo Molnar <mingo@kernel.org> - 2016-03-12 18:10 +0100
                Re: [musl] Re: [RFC PATCH] x86/vdso/32: Add AT_SYSINFO cancellation  helpers Rich Felker <dalias@libc.org> - 2016-03-12 19:20 +0100
                Re: [musl] Re: [RFC PATCH] x86/vdso/32: Add AT_SYSINFO cancellation  helpers Ingo Molnar <mingo@kernel.org> - 2016-03-12 18:10 +0100
                Re: [musl] Re: [RFC PATCH] x86/vdso/32: Add AT_SYSINFO cancellation  helpers Rich Felker <dalias@libc.org> - 2016-03-12 19:10 +0100
                Re: [musl] Re: [RFC PATCH] x86/vdso/32: Add AT_SYSINFO cancellation  helpers Ingo Molnar <mingo@kernel.org> - 2016-03-12 19:50 +0100
                Re: [musl] Re: [RFC PATCH] x86/vdso/32: Add AT_SYSINFO cancellation  helpers Rich Felker <dalias@libc.org> - 2016-03-12 20:10 +0100
                Re: [musl] Re: [RFC PATCH] x86/vdso/32: Add AT_SYSINFO cancellation  helpers Ingo Molnar <mingo@kernel.org> - 2016-03-12 18:10 +0100
  Re: [RFC PATCH] x86/vdso/32: Add AT_SYSINFO cancellation helpers Andy Lutomirski <luto@amacapital.net> - 2016-03-09 19:00 +0100
    Re: [RFC PATCH] x86/vdso/32: Add AT_SYSINFO cancellation helpers Andy Lutomirski <luto@amacapital.net> - 2016-03-09 22:30 +0100
      Re: [RFC PATCH] x86/vdso/32: Add AT_SYSINFO cancellation helpers Andy Lutomirski <luto@amacapital.net> - 2016-03-12 19:20 +0100

csiph-web