Date:        27 Nov 2000 15:59:32 +0100
    From:        Sean Doran <smd@ebone.net>
    Message-ID:  <52wvdppijv.fsf@sean.ebone.net>

  | Well, it is the same mechanism as receiving a signal
  | immediately between magic_next_syscall() and the signal
  | handler... what happens to the very first syscall in the
  | signal handler?

That's a better question ... I guess that signals would need to be
blocked in the region (not that magic_next_syscall() was ever
anything but a step in the argument anyway).

But your general point is valid, programs with signal handlers
that do anything significant (which is generally a bad thing to
do anyway) need to be very careful if they engage in uid swapping.
If all they do is the recommended "set a volatile global and return"
then they're safe anyway.   Once they get to longjmp() though, or
almost anything else, then they need to be very careful.

  | and in practical terms becomes identical to a flag given to an atomic
  | syscall anyway.)

except that there are a lot of syscalls all of which would need to be
modified to have this extra flag.   Many (most) of them have no easy way
to be extended to pass a flag though (not having a convenient flags arg
like open(2)).   I suppose you could redefine link(2) so that if the
first byte in the first filename was 0xff then that was a flag, and
not part of the pathname, or something, but I doubt any of us would like
to see that...

kre