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

* [RFC][CFT] what's in signal.git queue
@ 2013-02-14  1:25 ` Al Viro
  0 siblings, 0 replies; 10+ messages in thread
From: Al Viro @ 2013-02-14  1:25 UTC (permalink / raw)
  To: linux-kernel
  Cc: linux-arch, Linus Torvalds, Catalin Marinas, Haavard Skinnemoen,
	Mike Frysinger, Jesper Nilsson, David Howells, Tony Luck,
	Benjamin Herrenschmidt, Hirokazu Takata, Geert Uytterhoeven,
	Michal Simek, Jonas Bonn, James E.J. Bottomley, Richard Kuo,
	Martin Schwidefsky, Lennox Wu, David S. Miller, Paul Mundt,
	Chris Zankel, Chris Metcalf, Yoshinori Sato, Guan Xuetao,
	Russell King

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
		  having __ARCH_HAS_KA_RESTORER
		+ 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
		  __ARCH_HAS_ODD_SIGACTION
	* 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
consolidated.
	* 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
fork()/clone()/vfork().
	* 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...

^ permalink raw reply	[flat|nested] 10+ messages in thread