this should not matter since the reality is that either all the sysv
sem syscalls are individual syscalls, or all of them are multiplexed
on the SYS_ipc syscall (depending on arch). but best to be consistent
anyway.
rather than returning an error, we have to increase the size argument
so high that the kernel will have no choice but to fail. this is
because POSIX only permits the EINVAL error for size errors when a new
shared memory segment would be created; if it already exists, the size
argument must be ignored. unfortunately Linux is non-conforming in
this regard, but I want to keep the code correct in userspace anyway
so that if/when Linux is fixed, the behavior applications see will be
conforming.
rejecting invalid values for n is fine even in the case where a new
sem will not be created, since the kernel does its range checks on n
even in this case as well.
by default, the kernel will bound the limit well below USHRT_MAX
anyway, but it's presumably possible that an administrator could
override this limit and break things.
this patch improves the correctness, simplicity, and size of
cancellation-related code. modulo any small errors, it should now be
completely conformant, safe, and resource-leak free.
the notion of entering and exiting cancellation-point context has been
completely eliminated and replaced with alternative syscall assembly
code for cancellable syscalls. the assembly is responsible for setting
up execution context information (stack pointer and address of the
syscall instruction) which the cancellation signal handler can use to
determine whether the interrupted code was in a cancellable state.
these changes eliminate race conditions in the previous generation of
cancellation handling code (whereby a cancellation request received
just prior to the syscall would not be processed, leaving the syscall
to block, potentially indefinitely), and remedy an issue where
non-cancellable syscalls made from signal handlers became cancellable
if the signal handler interrupted a cancellation point.
x86_64 asm is untested and may need a second try to get it right.
some of these definitions were just plain wrong, others based on
outdated ancient "non-64" versions of the kernel interface.
as much as possible has now been moved out of bits/*
these changes break abi (the old abi for these functions was wrong),
but since they were not working anyway it can hardly matter.
Rich Felker