Had not been used for more than a decade and half; it used
to be a part of (in-kernel) ->select() API and it has been pining
for fjords since 2.1.23pre1. This is an ex-parrot...
Signed-off-by: Al Viro <[email protected]>
replace_fd() began with "eats a reference, tries to insert into
descriptor table" semantics; at some point I'd switched it to
much saner current behaviour ("try to insert into descriptor
table, grabbing a new reference if inserted; caller should do
fput() in any case"), but forgot to update the callers.
Mea culpa...
[Spotted by Pavel Roskin, who has really weird system with pipe-fed
coredumps as part of what he considers a normal boot ;-)]
Signed-off-by: Al Viro <[email protected]>
* allow kernel_execve() leave the actual return to userland to
caller (selected by CONFIG_GENERIC_KERNEL_EXECVE). Callers
updated accordingly.
* architecture that does select GENERIC_KERNEL_EXECVE in its
Kconfig should have its ret_from_kernel_thread() do this:
call schedule_tail
call the callback left for it by copy_thread(); if it ever
returns, that's because it has just done successful kernel_execve()
jump to return from syscall
IOW, its only difference from ret_from_fork() is that it does call the
callback.
* such an architecture should also get rid of ret_from_kernel_execve()
and __ARCH_WANT_KERNEL_EXECVE
This is the last part of infrastructure patches in that area - from
that point on work on different architectures can live independently.
Signed-off-by: Al Viro <[email protected]>
Most of them never returned anyway - only two functions had to be
changed. That allows to simplify their callers a whole lot.
Note that this does *not* apply to kthread_run() callbacks - all of
those had been called from the same kernel_thread() callback, which
did do_exit() already. This is strictly about very few low-level
kernel_thread() callbacks (there are only 6 of those, mostly as part
of kthread.h and kmod.h exported mechanisms, plus kernel_init()
itself).
Signed-off-by: Al Viro <[email protected]>
The only place where kernel_execve() is called without a way to
return to the caller of kernel_thread() callback is kernel_post().
Reorganize kernel_init()/kernel_post() - instead of the former
calling the latter in the end (and getting freed by it), have the
latter *begin* with calling the former (and turn the latter into
kernel_thread() callback, of course).
Signed-off-by: Al Viro <[email protected]>
It's needed only in setup_sigcontext() and it's always reg - <constant>;
no point passing it all way down through the call chain. This is just
the signal.c side of that stuff; next will come the asm glue one...
Signed-off-by: Al Viro <[email protected]>
Turn the slow side of work_pending into C function, including all
the looping. What we get out of that:
* we do _not_ call get_signal_to_deliver() with IRQs disabled
anymore
* no need to save/restore volatiles on each pass if there
turns to be more than one (unlikely, but still)
* all double-restart prevention is in C now.
* glue gets simpler.
Signed-off-by: Al Viro <[email protected]>
In case we have both NEED_RESCHED and SIGPENDING/NOTIFY_RESUME,
handle the latter first. We'll get to original priorities in
the next commit, but now that allows to simplify the treatment
of NEED_RESCHED-only case nicely. Namely, now there no need to
preserve the data for restarts across the call of schedule() in
$work_resched; we can get there only if we had either returned
from syscall without SIGPENDING (in which case we should've
had no restart-worthy return value and want no restarts) or
already got through do_notify_resume() call (in which case we
want no restarts anymore). So we can just slap 0 into $19
instead of preserving it (and $20).
Signed-off-by: Al Viro <[email protected]>
we want syscall_trace_leave() called on exit from any syscall;
skipping its call in case we'd done force_successful_syscall_return()
is broken...
Signed-off-by: Al Viro <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Fix a braino in F_DUPFD_CLOEXEC; f_dupfd() expects flags for alloc_fd(),
get_unused_fd() etc and there clone-on-exec if O_CLOEXEC, not
FD_CLOEXEC.
Reported-by: Richard W.M. Jones <[email protected]>
Signed-off-by: Al Viro <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
When force_successful_syscall() triggers, the syscall return status
reported the ptrace applications gets garbled.
Fix this by reordering the events and tests in the ret_sys_call path.
Signed-off-by: David S. Miller <[email protected]>
After fixing a couple of brainos, it even seems to work. What's done here
is move of ->syscall_noerror right before FPDEPTH byte in ->flags and
using sth to [%g6 + TI_SYS_NOERROR] instead of stb to [%g6 + TI_FPDEPTH] in
both branches of etrap_save. AFAICS, that ought to be solid. Again,
deciding what to do with now unused delay slot of branch on ->syscall_noerror
and dealing with the order of tests in ret_from_sys is a separate question,
but at least that way we don't have to clean ->syscall_noerror in there at
all. AFAICS, it ought to be a clear win - sth is not going to cost more than
stb on etrap_64.S side of things, and we are losing write on syscalls.S one.
Signed-off-by: Al Viro <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
All increments and decrements are under the same spinlock - have to be,
since they need to protect the radix_tree it's found in. Just use
int, no need to wank with kref...
Signed-off-by: Al Viro <[email protected]>
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 <[email protected]>
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 <[email protected]>
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 <[email protected]>
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 <[email protected]>
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 <[email protected]>
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 <[email protected]>
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 <[email protected]>
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 <[email protected]>
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 <[email protected]>
32bit wrapper is lost on that; 64bit one is *not*, since
we need to arrange for full pt_regs on stack when we call
sys_execve() and we need to load callee-saved ones from
there afterwards.
Signed-off-by: Al Viro <[email protected]>
... no need to read current_thread_info()->task only to
feed it to task_thread_page() immediately afterwards.
Moreover, not using current_thread_info() at all ends
up with better assembler - we need a location very close
to the top of kernel stack page and it's actually better
to do or with 0x1fff, followed be subtracting a small
constant than and with ~0x1fff, followed by adding a large
one. Both & and | would be a couple of insns (mvn lsr/mvn lsl
for |, a pair of bic for &), but the following addition
would cost a pair of add while the subtraction ends up
as a single sub.
Signed-off-by: Al Viro <[email protected]>
Selected by __ARCH_WANT_SYS_EXECVE in unistd.h. Requires
* working current_pt_regs()
* *NOT* doing a syscall-in-kernel kind of kernel_execve()
implementation. Using generic kernel_execve() is fine.
Signed-off-by: Al Viro <[email protected]>
based mostly on arm and alpha versions. Architectures can define
__ARCH_WANT_KERNEL_EXECVE and use it, provided that
* they have working current_pt_regs(), even for kernel threads.
* kernel_thread-spawned threads do have space for pt_regs
in the normal location. Normally that's as simple as switching to
generic kernel_thread() and making sure that kernel threads do *not*
go through return from syscall path; call the payload from equivalent
of ret_from_fork if we are in a kernel thread (or just have separate
ret_from_kernel_thread and make copy_thread() use it instead of
ret_from_fork in kernel thread case).
* they have ret_from_kernel_execve(); it is called after
successful do_execve() done by kernel_execve() and gets normal
pt_regs location passed to it as argument. It's essentially
a longjmp() analog - it should set sp, etc. to the situation
expected at the return for syscall and go there. Eventually
the need for that sucker will disappear, but that'll take some
surgery on kernel_thread() payloads.
Signed-off-by: Al Viro <[email protected]>
Normally (and that's the default) it's just task_pt_regs(current).
However, if an architecture can optimize that, it can do so by
making a macro of its own available from asm/ptrace.h. More
importantly, some architectures have task_pt_regs() working only
for traced tasks blocked on signal delivery. current_pt_regs()
needs to work for *all* processes, so before those architectures
start using stuff relying on current_pt_regs() they'll need a
properly working variant.
Signed-off-by: Al Viro <[email protected]>
Let architectures select GENERIC_KERNEL_THREAD and have their copy_thread()
treat NULL regs as "it came from kernel_thread(), sp argument contains
the function new thread will be calling and stack_size - the argument for
that function". Switching the architectures begins shortly...
Signed-off-by: Al Viro <[email protected]>
we only use that to tell copy_thread() done by syscall from that
done by kernel_thread(). However, it's easier to do simply by
checking PF_KTHREAD in thread flags.
Merge sys_clone() guts for 32bit and 64bit, while we are at it...
Signed-off-by: Al Viro <[email protected]>
Al Viro