- 01 Oct, 2012 40 commits
-
-
Al Viro authored
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
-
Al Viro authored
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
-
Al Viro authored
Tell signal_delivered() to do it instead. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
-
Al Viro authored
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
-
Al Viro authored
... just tell signal_delivered() to do it. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
-
Al Viro authored
signal_delivered() will do it in the same case... Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
-
Al Viro authored
no need to have the call of do_notify_resume() + checks around it duplicated for vm86 case - a bit of rearranging of ifdefs and we'll have a perfectly fine copy to jump back to. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
-
Al Viro authored
we can get into work_pending only if at least one of NEED_RESCHED, SIGPENDING or NOTIFY_RESUME is set. So once we'd found no NEED_RESCHED, there's no need to check that one of the other two is set. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
-
Al Viro authored
Only the three usual flags (NEED_RESCHED/SIGPENDING/NOTIFY_RESUME) are looked at in the code checking _TIF_WORK_MASK on that one. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
-
Al Viro authored
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
-
Al Viro authored
entry.S code had been looping until no pending signals are left since 2005 anyway; no need to bother with that in do_signal() itself. If the failure to set a sigframe up raises SIGSEGV, we'll just pick it up the next time around the loop(s) in entry.S anyway. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
-
Al Viro authored
Don't bother restoring r28 on syscall restarts; it's clobbered by syscall anyway. Reuse (now unused) ->orig_r28 as "no restarts allowed" flag. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
-
Al Viro authored
Some architectures had blindly copied it for no reason whatsoever. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
-
Al Viro authored
Make default just return 0. The current default (checking TIF_POLLING_NRFLAG) is taken to architectures that need it; ones that don't do polling in their idle threads don't need to defined TIF_POLLING_NRFLAG at all. ia64 defined both TS_POLLING (used by its tsk_is_polling()) and TIF_POLLING_NRFLAG (not used at all). Killed the latter... Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
-
Al Viro authored
never used... Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
-
Al Viro authored
bits 3..7 in flags are never set there, so this 0xff is pointless Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
-
Al Viro authored
If it's set, SIGPENDING is also set. And SIGPENDING is present in the masks... Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
-
Al Viro authored
No need to keep 4 copies of that stuff; merged and taken to entry.S, unused public symbols there killed off. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
-
Al Viro authored
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
-
Al Viro authored
too late to do anything there... Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
-
Al Viro authored
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
-
Al Viro authored
we *really* don't want to have restart logics hit when we are returning from sigreturn() - random replacement of %r4 with -4 just because a signal had been noticed from timer interrupt that came when %r4 happened to contain -514 is not nice at all. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
-
Al Viro authored
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
-
Al Viro authored
asm glue checks that Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
-
Al Viro authored
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
-
Mark Salter authored
Signed-off-by: Mark Salter <msalter@redhat.com> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
-
Mark Salter authored
Signed-off-by: Mark Salter <msalter@redhat.com> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
-
Mark Salter authored
Signed-off-by: Mark Salter <msalter@redhat.com> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
-
Al Viro authored
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
-
Al Viro authored
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
-
Al Viro authored
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
-
Al Viro authored
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
-
Al Viro authored
-
Al Viro authored
Acked-by: David Howells <dhowells@redhat.com> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
-
Al Viro authored
current_pt_regs() here is simply __frame Acked-by: David Howells <dhowells@redhat.com> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
-
Al Viro authored
Acked-by: David Howells <dhowells@redhat.com> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
-
Al Viro authored
The tricky part here is that task_pt_regs() on m68k works *only* for process inside do_signal(). However, we need something much simpler - pt_regs of a process inside do_signal() may be at different offsets from the stack bottom, depending on the way we'd entered the kernel, but for a task inside sys_execve() it *is* at constant offset. Moreover, for a kernel thread about to become a userland process the same location is also fine - setting sp to that will leave the kernel stack pointer at the very bottom of the kernel stack when we finally switch to userland. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
-
Al Viro authored
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
-
Greg Ungerer authored
The stack frame "format" field needs to be explicitly set on thread creation on ColdFire. For a normal long word aligned user stack pointer the frame format is 0x4. We were doing this for non-MMU ColdFire, but not for the case with MMU enabled. So fix it so we always do it if targeting ColdFire. The old code happend to rely on the stack frame format being inhereted from the process calling exec. Furture changes means that may not always work, so we really do want to set it explicitly. Signed-off-by: Greg Ungerer <gerg@uclinux.org> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
-
Al Viro authored
the only non-obvious part is that current_pt_regs() is really needed here - task_pt_regs() is NULL for kernel threads; it's OK for ptrace uses (the thing task_pt_regs() is intended for), but not for us. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
-