1. 19 9月, 2010 3 次提交
    • A
      alpha: deal with multiple simultaneously pending signals · 494486a1
      Al Viro 提交于
      Unlike the other targets, alpha sets _one_ sigframe and
      buggers off until the next syscall/interrupt, even if
      more signals are pending.  It leads to quite a few unpleasant
      inconsistencies, starting with SIGSEGV potentially arriving
      not where it should and including e.g. mess with sigsuspend();
      consider two pending signals blocked until sigsuspend()
      unblocks them.  We pick the first one; then, if we are hit
      by interrupt while in the handler, we process the second one
      as well.  If we are not, and if no syscalls had been made,
      we get out of the first handler and leave the second signal
      pending; normally sigreturn() would've picked it anyway, but
      here it starts with restoring the original mask and voila -
      the second signal is blocked again.  On everything else we
      get both delivered consistently.
      
      It's actually easy to fix; the only thing to watch out for
      is prevention of double syscall restart.  Fortunately, the
      idea I've nicked from arm fix by rmk works just fine...
      
      Testcase demonstrating the behaviour in question; on alpha
      we get one or both flags set (usually one), on everything
      else both are always set.
      	#include <signal.h>
      	#include <stdio.h>
      	int had1, had2;
      	void f1(int sig) { had1 = 1; }
      	void f2(int sig) { had2 = 1; }
      	main()
      	{
      		sigset_t set1, set2;
      		sigemptyset(&set1);
      		sigemptyset(&set2);
      		sigaddset(&set2, 1);
      		sigaddset(&set2, 2);
      		signal(1, f1);
      		signal(2, f2);
      		sigprocmask(SIG_SETMASK, &set2, NULL);
      		raise(1);
      		raise(2);
      		sigsuspend(&set1);
      		printf("had1:%d had2:%d\n", had1, had2);
      	}
      Tested-by: NMichael Cree <mcree@orcon.net.nz>
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: NMatt Turner <mattst88@gmail.com>
      494486a1
    • A
      alpha: fix a 14 years old bug in sigreturn tracing · 53293638
      Al Viro 提交于
      The way sigreturn() is implemented on alpha breaks PTRACE_SYSCALL,
      all way back to 1.3.95 when alpha has grown PTRACE_SYSCALL support.
      
      What happens is direct return to ret_from_syscall, in order to bypass
      mangling of a3 (error indicator) and prevent other mutilations of
      registers (e.g. by syscall restart).  That's fine, but... the entire
      TIF_SYSCALL_TRACE codepath is kept separate on alpha and post-syscall
      stopping/notifying the tracer is after the syscall.  And the normal
      path we are forcibly switching to doesn't have it.
      
      So we end up with *one* stop in traced sigreturn() vs. two in other
      syscalls.  And yes, strace is visibly broken by that; try to strace
      the following
      	#include <signal.h>
      	#include <stdio.h>
      	void f(int sig) {}
      	main()
      	{
      		signal(SIGHUP, f);
      		raise(SIGHUP);
      		write(1, "eeeek\n", 6);
      	}
      and watch the show.  The
      	close(1)                                = 405
      in the end of strace output is coming from return value of write() (6 ==
      __NR_close on alpha) and syscall number of exit_group() (__NR_exit_group ==
      405 there).
      
      The fix is fairly simple - the only thing we end up missing is the call
      of syscall_trace() and we can tell whether we'd been called from the
      SYSCALL_TRACE path by checking ra value.  Since we are setting the
      switch_stack up (that's what sys_sigreturn() does), we have the right
      environment for calling syscall_trace() - just before we call
      undo_switch_stack() and return.  Since undo_switch_stack() will overwrite
      s0 anyway, we can use it to store the result of "has it been called from
      SYSCALL_TRACE path?" check.  The same thing applies in rt_sigreturn().
      Tested-by: NMichael Cree <mcree@orcon.net.nz>
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: NMatt Turner <mattst88@gmail.com>
      53293638
    • A
      alpha: unb0rk sigsuspend() and rt_sigsuspend() · 392fb6e3
      Al Viro 提交于
      Old code used to set regs->r0 and regs->r19 to force the right
      return value.  Leaving that after switch to ERESTARTNOHAND
      was a Bad Idea(tm), since now that screws the restart - if we
      hit the case when get_signal_to_deliver() returns 0, we will
      step back to syscall insn, with v0 set to EINTR and a3 to 1.
      The latter won't matter, since EINTR is 4, aka __NR_write.
      
      Testcase:
      
      	#include <signal.h>
      	#define _GNU_SOURCE
      	#include <unistd.h>
      	#include <sys/syscall.h>
      
      	main()
      	{
      		sigset_t mask;
      		sigemptyset(&mask);
      		sigaddset(&mask, SIGCONT);
      		sigprocmask(SIG_SETMASK, &mask, NULL);
      		kill(0, SIGCONT);
      		syscall(__NR_sigsuspend, 1, "b0rken\n", 7);
      	}
      
      results on alpha in immediate message to stdout...
      
      Fix is obvious; moreover, since we don't need regs anymore, we can
      switch to normal prototypes for these guys and lose the wrappers.
      Even better, rt_sigsuspend() is identical to generic version in
      kernel/signal.c now.
      Tested-by: NMichael Cree <mcree@orcon.net.nz>
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: NMatt Turner <mattst88@gmail.com>
      392fb6e3
  2. 28 3月, 2009 1 次提交
  3. 30 1月, 2009 1 次提交
  4. 14 1月, 2009 1 次提交
  5. 14 11月, 2008 1 次提交
  6. 17 10月, 2007 1 次提交
  7. 31 5月, 2007 1 次提交
  8. 02 10月, 2006 1 次提交
    • A
      [PATCH] rename the provided execve functions to kernel_execve · 3db03b4a
      Arnd Bergmann 提交于
      Some architectures provide an execve function that does not set errno, but
      instead returns the result code directly.  Rename these to kernel_execve to
      get the right semantics there.  Moreover, there is no reasone for any of these
      architectures to still provide __KERNEL_SYSCALLS__ or _syscallN macros, so
      remove these right away.
      
      [akpm@osdl.org: build fix]
      [bunk@stusta.de: build fix]
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Cc: Andi Kleen <ak@muc.de>
      Acked-by: NPaul Mackerras <paulus@samba.org>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Richard Henderson <rth@twiddle.net>
      Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
      Cc: Russell King <rmk@arm.linux.org.uk>
      Cc: Ian Molton <spyro@f2s.com>
      Cc: Mikael Starvik <starvik@axis.com>
      Cc: David Howells <dhowells@redhat.com>
      Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
      Cc: Hirokazu Takata <takata.hirokazu@renesas.com>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Kyle McMartin <kyle@mcmartin.ca>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Paul Mundt <lethal@linux-sh.org>
      Cc: Kazumoto Kojima <kkojima@rr.iij4u.or.jp>
      Cc: Richard Curnow <rc@rc0.org.uk>
      Cc: William Lee Irwin III <wli@holomorphy.com>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Jeff Dike <jdike@addtoit.com>
      Cc: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
      Cc: Miles Bader <uclinux-v850@lsi.nec.co.jp>
      Cc: Chris Zankel <chris@zankel.net>
      Cc: "Luck, Tony" <tony.luck@intel.com>
      Cc: Geert Uytterhoeven <geert@linux-m68k.org>
      Cc: Roman Zippel <zippel@linux-m68k.org>
      Signed-off-by: NAdrian Bunk <bunk@stusta.de>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      3db03b4a
  9. 01 7月, 2006 1 次提交
  10. 02 2月, 2006 1 次提交
  11. 03 10月, 2005 1 次提交
  12. 10 9月, 2005 1 次提交
  13. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      
      Let it rip!
      1da177e4