[RFC][CFT] what's in signal.git queue

From: Al Viro
Date: Wed Feb 13 2013 - 20:26:01 EST

Mostly it's a unification of signal-related syscalls, both native and compat
ones; by the end of it we shouldn't have syscalls left in normal
arch/*/kernel/signal*.c - there are some exceptions due to genuine weirdness
of arch-specific calling conventions, but that's rare. Another (somewhat
related) story in there is more compat_sys_something() getting switched to
COMPAT_SYSCALL_DEFINE, giving us proper argument validation wrappers. Not
everything got switched, of course, but a lot of those guys has been.

FWIW, right now the queue is at -3.5KLoc. Tree topology: common stem,
splitting into a bunch of per-architecture branches. Those branches then
are octopus-merged and followed by a short linear piece.

In the stem:
* a bunch of compat syscalls switched to COMPAT_SYSCALL_DEFINE*
* definitions of struct k_sigaction and struct sigaction consolidated;
pretty much everything had identical definitions. The few exceptions:
+ alpha and sparc have k_sigaction.ka_restorer; selected by
+ some architectures have sigaction.sa_restorer, some do not;
selected by having __ARCH_HAS_SA_RESTORER
+ one architecture (mips) has sa_flags and sa_handler in
unusual order (IRIX compat legacy?); selected by having
* definition of struct compat_sigaction consolidated as well; quirks
are controlled by the same __ARCH_HAS_... as for struct sigaction.
* definitions of struct old_sigaction and struct compat_old_sigaction
* rt_sigprocmask(), rt_sigpending(), rt_sigqueueinfo(), sigsuspend(),
sigaction(), compat rt_sigaction(), compat sigaction() are ready to be
switched to generic versions (and so's sigaltstack(), but that had been in
mainline for a while already). All of them got matching CONFIG_GENERIC_...
config symbols, to be selected by an architecture that wants the suckers.
As the matter of fact, old sigsuspend() has *two* such symbols, what with
two variants of calling conventions we have. Most of that zoo of selects
is introduced only to be killed once every architecture switches to generics;
of course, ones that aren't really universal are going to stay. That way
we can do switching to generics independenty for different architectures.
* new helpers for simplifying the paths from get_signal_to_deliver() -
the thing is, all callers pass it a couple of pointers to their local
variables (k_sigaction and siginfo) and then pass the addresses of these
variables in tandem to functions that do actual signal delivery; we could
as well put them into a single object and deal with pointer to it. See
struct ksignal (that single object), get_signal() (get_signal_to_deliver()
wrapper filling struct ksignal), signal_setup_done() (the usual end of
sigframe building - "signal_delivered() if everything had been OK,
force_sigsegv() otherwise" logics) and sigsp() (usual altstack handling,
for use by get_sigframe() instances).

At that point the common stem ends; as far as I'm concerned, this part is
in never-rebase mode by now. Then comes a bunch of per-architecture branches;
all subject to ACK by maintainers (ones who are not MIA, that is ;-/). Once
maintainer(s) are OK with a branch, it's in no-rebase mode as well. Branch
names are of form arch-<arch name>, same as the last time around.

What happens in those is conversions to generic versions of signal-related
syscalls introduced in the common stem. For quite a few architectures that's
all that happens - arm, arm64, avr32, blackfin, c6x, frv, ia64, m32r, m68k,
mn10300, openrisc, parisc, score, sh, tile, unicore32 and xtensa fall into
that category. Below is the description of additional stuff happening for
the rest of architectures (additional to conversions to generic implementations
of syscalls, that is):
* alpha: trivial cleanup in copy_process() (unused variable killed)
* cris: bugfix - since sigreturn uses ->uc_stack, we'd better not leave
it uninitialized. Plus getting rid of pointless passing of pt_regs to
sigreturn - it's cheaper and simpler to use current_pt_regs() there.
* h8300: get rid of sigreturn wrappers
* hexagon: same bugfixe as on cris.
* microblaze: a bunch of old fixes for multiple signals delivered
simultaneously. ACKed by Michal.
* mips: in addition to usual conversions to generics, some n32 syscall
variants could've been switched to existing compat_sys_...() for quite a while
(they got missed somehow); done that now. Got rid of magic arguments to
pipe(2) (current_pt_regs() used instead). Switched to generic
* ppc: a bunch of compat wrappers had been pointless since
the introduction of CONFIG_HAVE_SYSCALL_WRAPPERS; kill 'em. Also trim
asm/syscalls.h a bit.
* s390: 32bit wrappers are not needed for anything defined
via COMPAT_SYSCALL_DEFINE*; kill the useless ones.
* sparc: bury some dead code (sys_sigpause() remnants). Kill
sign-extending wrappers for native syscalls - SYSCALL_DEFINE will do all
sanitizing we need. So will COMPAT_SYSCALL_DEFINE, so the stuff using it
also doesn't need a wrapper in sys32.S; killed those off as well.
* x86: get rid of pt_regs * passing to vm86, vm86old, iopl and
{rt_,}sigreturn, kill pointless wrappers.

There are several commits going after these branches rejoin. Some conversion
detritus gets killed (some symbols are true everywhere now, do_sigaltstack()
can be made static). Then there are examples of struct ksignal use - alpha,
x86 and sparc converted to it; the rest of architectures are left as is - if
somebody is willing to do conversions, more power to you, but as far as I'm
concerned that's next cycle fodder.

Fortunately, the arch-specific stuff in this round hadn't been as low-level as
for kernel_thread/kernel_execve/sys_execve unification, so I'm a lot more
optimistic about it. *Please*, review and yell if are unhappy with anything
in there. This had sat unchanged in linux-next for quite a while, plus it got
some local testing and most of the likely breakage is of "the sucker doesn't
compile anymore" variety, but...
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/