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


Groups > linux.kernel > #1356153

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

From Andy Lutomirski <luto@amacapital.net>
Newsgroups linux.kernel
Subject Re: [musl] Re: [RFC PATCH] x86/vdso/32: Add AT_SYSINFO cancellation helpers
Date 2016-03-11 20:40 +0100
Message-ID <rbB4K-2v3-9@gated-at.bofh.it> (permalink)
References (7 earlier) <rbdc6-2iB-9@gated-at.bofh.it> <rbibN-5JJ-27@gated-at.bofh.it> <rbrI5-44N-3@gated-at.bofh.it> <rbtAe-5vz-3@gated-at.bofh.it> <rbAV4-2r7-19@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


On Fri, Mar 11, 2016 at 11:27 AM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Fri, Mar 11, 2016 at 3:39 AM, Szabolcs Nagy <nsz@port70.net> wrote:
>>
>> i think the sticky signal design would work, but more
>> complex than what we have and adds some atomic rmw ops
>> into common code paths and not backward compatible.
>>
>> not using vsyscalls for cancellation-points sounds easier.
>
> Hmm. Ok, so I think I understand your needs, and your current model
> does sound easier. But the cost of not using vsyscalls is really quite
> high.
>
> It sounds like the main worry is that some system calls are guaranteed
> cancellation points, and if the signal slips in between your
> cancellation point check and the system call, you lose that ability.
>
> I'm assuming that if the "canceltype" is asynchronous, you never have
> this problem, because the cancellation can be done in the signal
> handler itself, which avoids the whole race.
>
> Am I getting closer to understanding the particular semantics you are
> looking for?
>
> Because if that's the case, I wonder if what you really want is not
> "sticky signals" as much as "synchronous signals" - ie the ability to
> say that a signal shouldn't ever interrupt in random places, but only
> at well-defined points (where a system call would be one such point -
> are there others?)
>
> So then you could make "pthread_setcanceltype()" just set that flag
> for the cancellation signal, and just know that the signal itself will
> always be deferred to such a synchronous point (ie system call entry).
>
> We already have the ability to catch things at system call entry
> (ptrace needs it, for example), so we could possibly make our signal
> delivery have a mode where a signal does *not* cause user space
> execution to be interrupted by a signal handler, but instead just sets
> a bit in the thread info state that then causes the next system call
> to take the signal.

I think that this would almost work for musl, except that musl would
still need to be able to tell whether the syscall that eventually gets
interrupted is a cancellation point, which still may require some
ability to unwind from the vdso.  The syscall handler can easily tell
the syscall number (it's in EAX), but it may need the effective EIP as
well.

--Andy

Back to linux.kernel | Previous | NextPrevious 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