Russell,
thanks. So, the insertion of the signal handler code into the
user's execution space is fairly clean/efficient but after each signal
has been handled, the process transitions back through the
kernel to get the stack unwound? Assuming that transitions into
and out of the kernel are expensive, that's what I'm trying to
track.
Dave
Russell King - ARM Linux wrote:
> On Fri, Jun 08, 2001 at 02:32:37PM +0100, David Rusling wrote:
> > Looks to me like you get a ret_from_sys_call()
> > call that first checks to see if there is a signal pending.
>
> Yep.
>
> > If there is one, then it does a reschedule.
>
> Not actually quite right.
>
> If a signal is sent to a task, and it is accepted (ie not ignored),
> then the task is marked running, and moved onto the list of runnable
> processes. If this tasks priority for this quantum is higher than
> the currently running task, the current task need_resched flag is set.
>
> When returning to user space from kernel space, we always check
> the need_resched flag. If it is set, we reschedule, optionally
> switching to another task.
>
> Of course, none of the above happens if its the current task, since
> it is already running.
>
> In either case, the next thing that is checked after need_resched
> is to see if a signal is pending. If it is, we call do_signal, which
> fiddles around with the user and kernel stack frames to cause any
> signal handler to be invoked, or if its using the "default handler",
> do_signal takes the appropriate action (eg, terminating the process).
>
> > The mechanisms look the same (I think). Are they?
>
> Yes, they're the same.
>
> > What I really need to know is - where does the signal return
> > to when it completes? From my reading of the code, it looks very
> > like the signal handler alters the PC (to point at the registered signal
> > handler code)
>
> Correct.
>
> > but leaves the lr set to the instruction as per the fault
> > (usually the next instruction).
>
> When we setup the frame on the user stack, we insert some code which
> includes a SWI to call the "sys_sigreturn" or "sys_rt_sigreturn" code
> in the kernel. This knows how to unwind the user stack one level,
> and restore the state.
> _____
> |_____| ------------------------------------------------- ---+---+-
> | | Russell King [EMAIL PROTECTED] --- ---
> | | | | http://www.arm.linux.org.uk/ / / |
> | +-+-+ --- -+-
> / | THE developer of ARM Linux |+| /|\
> / | | | --- |
> +-+-+ ------------------------------------------------- /\\\ |
>
> _______________________________________________
> http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm
> Please visit the above address for information on this list.
--
----------------------------------------------------------------------
David A Rusling Consulting Engineer
ARM Limited
Liberty House,
Moorbridge Road,
Maidenhead, SL6 8LT
Tel: UK-(0)1628-427754
Fax: UK-(0)1628-780551
e-mail: [EMAIL PROTECTED]
----------------------------------------------------------------------
_______________________________________________
http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm
Please visit the above address for information on this list.
