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

Groups > linux.kernel > #1353712 > unrolled thread

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

Back to article view | Back to linux.kernel

Contents

  [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

Page 2 of 2 — ← Prev page 1 [2]

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

* Ingo Molnar <mingo@kernel.org> [2016-03-11 10:33:47 +0100]:
> * Rich Felker <dalias@libc.org> wrote:
> 
> > 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
> 
> As I (tried to!) describe it when describing the cancellation signal, if a 
> cancellation signal is in flight, it must be waited for in the unlikely event of 
> cancellation being disabled in the small window where the signal is sent.
> 
> So in your above example, it would do:
> 
> > 1. A has cancellation enabled
> > 2. B calls pthread_cancel(A) and sets sticky pending signal

blocking signals here is ok.

> > 3. A disables cancellation

blocking signals here is not ok. (libc changes cancelstate at
many places, there should be no syscall in that path.)

>   3b. Notices that cancellation request is pending and waits for it
>       and clears the sticky signal.

setcancelstate can be reentered between 'noticing' and 'waiting'
if interrupted by a signal.

the state change from expect-pending-signal to no-pending-signal
cannot be atomic wrt sigwaitinfo unless signals are blocked.

what i didnt think about yesterday is that it is ok and possible
to only block signals if there was a cancel.  (it is not trivial
since all the cancel related state changes have to be atomic and
there are at least canceled, signaled, cancelstate and canceltype,
which have to fit into 32bits and managed together.)

>   4. A calls cancellation point and syscall correctly executes
>   5. Once A enables cancellation again, the cancellation propagates.
> 
> So I still see no problem.
> 

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.

> > This can be solved with more synchronization in pthread_cancel and 
> > pthread_setcancelstate, but it seems costly. [...]
> 
> An active signal round trip in itself is very costly (thousands of cycles), a 
> thread exit is tens of thousands of cycles, and this is a 'slow path' anyway, and 
> the window is small in any case.
> 
> It's just a correctness synchronization to make sure no sticky signal is pending, 
> not a real performance concern in practice.
> 
> Thanks,
> 
> 	Ingo

[toc] | [prev] | [next] | [standalone]

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

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.

                Linus

[toc] | [prev] | [next] | [standalone]

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

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

[toc] | [prev] | [next] | [standalone]

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

On Fri, Mar 11, 2016 at 11:30 AM, Andy Lutomirski <luto@amacapital.net> wrote:
>
> 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.

So having tried to read the posix manual pages on this, it looks like
there is a list of *minimal* cancellation points, but that saying "any
system call is a cancellation point" is also perfectly valid.

 "An implementation may also mark other functions not specified in the
standard as cancellation  points"

Of course, musl may have more strict ideas than that on cancellation
points.  The "any system call" would make even trivial non-blocking
ones like "futex_wake()" and "getpid()" be cancellation points. So
maybe "any system call" isn't acceptable.

But if it *is* acceptable, that would be a pretty simple kernel mod, I think.

And I could see others possibly wanting to use synchronous signal
handlers. It's not like musl is the only project ever to have had
races with signals..

              Linus

[toc] | [prev] | [next] | [standalone]

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

On Fri, Mar 11, 2016 at 11:39 AM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
>  "An implementation may also mark other functions not specified in the
> standard as cancellation  points"

.. but that was from the Linux man-page. The open group has

 "An implementation shall not introduce cancellation points into any
other functions specified in this volume of POSIX.1-2008"

So yeah, it looks like there would need to be some way to filter things.

Oh well.

           Linus

[toc] | [prev] | [next] | [standalone]

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

* Linus Torvalds <torvalds@linux-foundation.org> wrote:

> On Fri, Mar 11, 2016 at 11:39 AM, Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
> >
> >  "An implementation may also mark other functions not specified in the
> > standard as cancellation  points"
> 
> .. but that was from the Linux man-page. The open group has
> 
>  "An implementation shall not introduce cancellation points into any
> other functions specified in this volume of POSIX.1-2008"
> 
> So yeah, it looks like there would need to be some way to filter things.
> 
> Oh well.

Is this really a big problem? Signals are asynchronous anyway, so if a C library 
uses signal delivery for cancellation, it has to be ready to get the signal 
delivered in the 'wrong' moment, for the wrong system call. The system call has to 
be restarted in that case - or the interruption result has to be returned.

The _cancellation_ itself will then still be executed during the next suitable 
cancellation point: which will be before doing the next cancellable system call 
(or libc API).

So I think it can still all be made work with SA_SYNCHRONOUS.

It would only be a show stopper if Linux didn't cover all required system calls. 
Covering _more_ system calls is not a problem AFAICS. But I might be missing 
something ...

Thanks,

	Ingo

[toc] | [prev] | [next] | [standalone]

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

On Sat, Mar 12, 2016 at 06:05:09PM +0100, Ingo Molnar wrote:
> 
> * Linus Torvalds <torvalds@linux-foundation.org> wrote:
> 
> > On Fri, Mar 11, 2016 at 11:39 AM, Linus Torvalds
> > <torvalds@linux-foundation.org> wrote:
> > >
> > >  "An implementation may also mark other functions not specified in the
> > > standard as cancellation  points"
> > 
> > .. but that was from the Linux man-page. The open group has
> > 
> >  "An implementation shall not introduce cancellation points into any
> > other functions specified in this volume of POSIX.1-2008"
> > 
> > So yeah, it looks like there would need to be some way to filter things.
> > 
> > Oh well.
> 
> Is this really a big problem? Signals are asynchronous anyway, so if a C library 
> uses signal delivery for cancellation, it has to be ready to get the signal 
> delivered in the 'wrong' moment, for the wrong system call. The system call has to 
> be restarted in that case - or the interruption result has to be returned.

The signals used for cancellation are not interrupting; the handler is
installed with SA_RESTART. If cancellation is disabled when the
handler is invoked, it does nothing at all. Otherwise, it first
modifies the saved signal mask to leave itself block after it returns
(the reason why involves complex nested-signal corner cases you
probably don't want to know about). Then, if the signal handler
determines the interrupted context is at a cancellation point, it
rewrites the saved program counter to act on cancellation rather than
restarting the syscall. If not, it does nothing else.

> The _cancellation_ itself will then still be executed during the next suitable 
> cancellation point: which will be before doing the next cancellable system call 
> (or libc API).
> 
> So I think it can still all be made work with SA_SYNCHRONOUS.
> 
> It would only be a show stopper if Linux didn't cover all required system calls. 
> Covering _more_ system calls is not a problem AFAICS. But I might be missing 
> something ...

You're missing a lot.

Rich

[toc] | [prev] | [next] | [standalone]

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

* Linus Torvalds <torvalds@linux-foundation.org> wrote:

> [...]
> 
> 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?)

Yes, I had similar 'deferred signal delivery' thoughts after having written up the 
sticky signals approach, I just couldn't map all details of the semantics: see the 
'internal libc functions' problem below.

If we can do this approach then there's another advantage as well: this way the C 
library does not even have to poll for cancellation at syscall boundaries: i.e. 
the regular system call fast path gets faster by 2-3 instructions as well.

> 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.

Yes, so this would need a bit of work, to handle the problem mentioned by Rich 
Felker: "internal" libc APIs (such as name server lookups) may consist of a series 
of complex system calls - some of which might be blocking. It should still be 
possible to execute such 'internal' system calls undisturbed, even if a 'deferred' 
signal is sent.

One workable solution I think would be to prepare the internal functions for 
eventual interruption by the cancellation signal. They have to be restartable 
anyway, because the application can send other signals. As long as the 
interruption is only transient it should be fine.

And note that this approach would also be pretty fast on the libc side: none of 
the 'fast' cancellation APIs would have to do anything complex like per call 
signal blocking/unblocking or other complex signal operations. They would just 
activate a straightforward new SA_ flag and rely on its semantics.

Thanks,

	Ingo

[toc] | [prev] | [next] | [standalone]

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

On Sat, Mar 12, 2016 at 06:00:40PM +0100, Ingo Molnar wrote:
> 
> * Linus Torvalds <torvalds@linux-foundation.org> wrote:
> 
> > [...]
> > 
> > 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?)
> 
> Yes, I had similar 'deferred signal delivery' thoughts after having written up the 
> sticky signals approach, I just couldn't map all details of the semantics: see the 
> 'internal libc functions' problem below.
> 
> If we can do this approach then there's another advantage as well: this way the C 
> library does not even have to poll for cancellation at syscall boundaries: i.e. 
> the regular system call fast path gets faster by 2-3 instructions as well.

That is not a measurable benefit. You're talking about 2-3 cycles out
of 10k or more cycles (these are heavy blocking syscalls not light
things like SYS_time or SYS_getpid).

> > 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.
> 
> Yes, so this would need a bit of work, to handle the problem mentioned by Rich 
> Felker: "internal" libc APIs (such as name server lookups) may consist of a series 
> of complex system calls - some of which might be blocking. It should still be 
> possible to execute such 'internal' system calls undisturbed, even if a 'deferred' 
> signal is sent.

That's equivalent to setcancelstate(disabled), and actually the
mechanism we use for most "complex" functions since it's a lot simpler
and more maintainable to build these complex functins on top of public
APIs than direct inline syscalls or internal APIs that may change. In
musl, direct non-cancellable syscall variants are mainly used in
places where either it's just a single simple syscall (like close) or
where calling the public API is already impossible for namespace
reasons (e.g. inside stdio, which can't use POSIX namespace because
it's implementing ISO C not POSIX).

> One workable solution I think would be to prepare the internal functions for 
> eventual interruption by the cancellation signal. They have to be restartable 
> anyway, because the application can send other signals. As long as the 
> interruption is only transient it should be fine.

No, that does not work. EINTR from a non-restarting signal is a
specified, reportable error (despite being rather useles in practice
due to race conditions; of course you can solve those with repeated
signals and exponential backoff). We cannot just loop and retry on
spurious EINTR except in a few cases where EINTR is optional or not
used (like sem_wait).

> And note that this approach would also be pretty fast on the libc side: none of 
> the 'fast' cancellation APIs would have to do anything complex like per call 
> signal blocking/unblocking or other complex signal operations. They would just 
> activate a straightforward new SA_ flag and rely on its semantics.

It's already fast, aside from not being able to use sysenter/syscall
instructions. I'm really frustrated that, again and again, we have
kernel folks with no experience with libc implementation trying to
redesign something that already has a simple zero-cost design that
works on all existing systems, and proposing things that have a mix of
immediately-obvious flaws and potential future problems we haven't
even thought of yet.

Even if your designs were ideal, we would end up with libc
implementing two good designs and switching them at runtime based on
kernel version, instead of just one good design. As it stands, every
alternative proposed so far is _more_ complex on the libc side, _more_
complex on the kernel side, _and_ on top of that, requires having two
implementations.

Rich

[toc] | [prev] | [next] | [standalone]

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

* Rich Felker <dalias@libc.org> wrote:

> On Sat, Mar 12, 2016 at 06:00:40PM +0100, Ingo Molnar wrote:
> > 
> > * Linus Torvalds <torvalds@linux-foundation.org> wrote:
> > 
> > > [...]
> > > 
> > > 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?)
> > 
> > Yes, I had similar 'deferred signal delivery' thoughts after having written up the 
> > sticky signals approach, I just couldn't map all details of the semantics: see the 
> > 'internal libc functions' problem below.
> > 
> > If we can do this approach then there's another advantage as well: this way the C 
> > library does not even have to poll for cancellation at syscall boundaries: i.e. 
> > the regular system call fast path gets faster by 2-3 instructions as well.
> 
> That is not a measurable benefit. You're talking about 2-3 cycles out of 10k or 
> more cycles (these are heavy blocking syscalls not light things like SYS_time or 
> SYS_getpid).

Huh? The list of 'must be' cancellable system calls includes key system calls 
like:

           open()
           close()
           read() variants
           write() variants
           poll()
           select()

which can be and often are very lightweight. The list of 'may be cancellable' 
system calls includes even more lightweight system calls.

I think you are confusing 'might block' with 'will block'. Most IO operations on a 
modern kernel with modern hardware will not block!

You are scaring me ... :-(

Thanks,

	Ingo

[toc] | [prev] | [next] | [standalone]

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

On Sat, Mar 12, 2016 at 07:48:36PM +0100, Ingo Molnar wrote:
> 
> * Rich Felker <dalias@libc.org> wrote:
> 
> > On Sat, Mar 12, 2016 at 06:00:40PM +0100, Ingo Molnar wrote:
> > > 
> > > * Linus Torvalds <torvalds@linux-foundation.org> wrote:
> > > 
> > > > [...]
> > > > 
> > > > 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?)
> > > 
> > > Yes, I had similar 'deferred signal delivery' thoughts after having written up the 
> > > sticky signals approach, I just couldn't map all details of the semantics: see the 
> > > 'internal libc functions' problem below.
> > > 
> > > If we can do this approach then there's another advantage as well: this way the C 
> > > library does not even have to poll for cancellation at syscall boundaries: i.e. 
> > > the regular system call fast path gets faster by 2-3 instructions as well.
> > 
> > That is not a measurable benefit. You're talking about 2-3 cycles out of 10k or 
> > more cycles (these are heavy blocking syscalls not light things like SYS_time or 
> > SYS_getpid).
> 
> Huh? The list of 'must be' cancellable system calls includes key system calls 
> like:
> 
>            open()
>            close()
>            read() variants
>            write() variants
>            poll()
>            select()
> 
> which can be and often are very lightweight. The list of 'may be cancellable' 
> system calls includes even more lightweight system calls.
> 
> I think you are confusing 'might block' with 'will block'. Most IO operations on a 
> modern kernel with modern hardware will not block!

No, I just mean syscalls that may block are generally heavy
operations. There may be a few exceptions (especially close in the
case where it's not the last fd for an open file) but I think you'd be
hard pressed to find a case where 2-3 cycles is even 0.2% of the
syscall time. But my point was not to get derailed on an argument
about the exact performance (non-)benefits of "saving 2-3 cycles",
just to say this is not an interesting argument for one approach vs
another and that it's a distraction from other much-more-important
issues.

> You are scaring me ... :-(

I'm not sure how to interpret this, but if you really feel what I'm
writing is scary/hostile I'll try to convey my ideas differently.

Rich

[toc] | [prev] | [next] | [standalone]

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

(Argh: Mail-Followup-To spam your mailer sets up is nasty!)

* Szabolcs Nagy <nsz@port70.net> wrote:

> >   4. A calls cancellation point and syscall correctly executes
> >   5. Once A enables cancellation again, the cancellation propagates.
> > 
> > So I still see no problem.
> 
> 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.

Agreed about complexity, but note that the RMW ops shouldn't really be expensive 
here, as this should be a well-cached flag. Especially compared to:

> not using vsyscalls for cancellation-points sounds easier.

... FYI not using vsyscalls has _far_ higher cost than using well-cached RMW ops.

So ... what do you think about Linus's SA_SYNCHRONOUS approach? I think it can be 
made to work without much fuss.

There will still be different code paths on old and new kernels, but that's 
unavoidable.

Thanks,

	Ingo

[toc] | [prev] | [next] | [standalone]

#1354324

On Tue, Mar 8, 2016 at 5:24 PM, Andy Lutomirski <luto@kernel.org> wrote:
> musl implements system call cancellation in an unusual but clever way.
> When a thread issues a cancellable syscall, musl issues the syscall
> through a special thunk that looks roughly like this:
>

FWIW, this patch fails disastrously on 64-bit kernels.  I fixed it,
but it needs kbuild changes.  I'll send those out to the maintainers.

--Andy

[toc] | [prev] | [next] | [standalone]

#1354469

On Wed, Mar 9, 2016 at 9:58 AM, Andy Lutomirski <luto@amacapital.net> wrote:
> On Tue, Mar 8, 2016 at 5:24 PM, Andy Lutomirski <luto@kernel.org> wrote:
>> musl implements system call cancellation in an unusual but clever way.
>> When a thread issues a cancellable syscall, musl issues the syscall
>> through a special thunk that looks roughly like this:
>>
>
> FWIW, this patch fails disastrously on 64-bit kernels.  I fixed it,
> but it needs kbuild changes.  I'll send those out to the maintainers.

This version should be okay:

https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git/commit/?h=x86/vdso&id=fed6d35d3941bc53896ab80b5c8d68d54cc00347

You'll need the parent, too, if you want to test.  I'm going to give
the 0day bot a good long chew, since the parent change is a little bit
scary.

--Andy

[toc] | [prev] | [next] | [standalone]

#1356516

On Wed, Mar 9, 2016 at 1:19 PM, Andy Lutomirski <luto@amacapital.net> wrote:
> On Wed, Mar 9, 2016 at 9:58 AM, Andy Lutomirski <luto@amacapital.net> wrote:
>> On Tue, Mar 8, 2016 at 5:24 PM, Andy Lutomirski <luto@kernel.org> wrote:
>>> musl implements system call cancellation in an unusual but clever way.
>>> When a thread issues a cancellable syscall, musl issues the syscall
>>> through a special thunk that looks roughly like this:
>>>
>>
>> FWIW, this patch fails disastrously on 64-bit kernels.  I fixed it,
>> but it needs kbuild changes.  I'll send those out to the maintainers.
>
> This version should be okay:
>
> https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git/commit/?h=x86/vdso&id=fed6d35d3941bc53896ab80b5c8d68d54cc00347
>
> You'll need the parent, too, if you want to test.  I'm going to give
> the 0day bot a good long chew, since the parent change is a little bit
> scary.

Nope, that version was also not okay.  But the version currently in
that branch has survived the kbuild bot for a while now.

Yikes our build process for usermode code sucks.

--Andy

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | linux.kernel

csiph-web