In-Reply-To: <[email protected]>
On Mon, 18 Dec 2006 20:05:35 +0100, Nicholas Mc Guire wrote:
> I have a phenomena that I don't quite understand. gdbserver forks and
> after setting ptrace (PTRACE_TRACEME, 0, 0, 0); it then execv
> (program, allargs); when this child process hits ptrace_stoped (breakpoint
> it does the following in kernel space:
>
> pid
> 1 559 5 1242 ptrace_stop
> 3 6 2 1242 | do_notify_parent_cldstop
> 4 3 2 1242 | | __group_send_sig_info
> 5 1 1 1242 | | | handle_stop_signal
> 7 0 0 1242 | | | sig_ignored
> 8 1 0 1242 | | __wake_up_sync
> 8 1 1 1242 | | | __wake_up_common
> 10 547 541 1242 | schedule
> 10 2 2 1242 | | profile_hit
> 13 1 1 1242 | | sched_clock
> 15 1 0 1242 | | deactivate_task
> 15 1 1 1242 | | | dequeue_task
> 19 2 2 0 | | __switch_to
> 24 574 574 0 default_idle
> So basically child signals -> delayed to next tick -> parent wakes up.
What do the first three columns represent?
Do you see __wake_up_common() calling default_wake_function()?
Can you trace through schedule() and see exactly how it decides to
run the idle task instead of the newly-woken parent? Exactly what
path does it take? (And which kernel version is this?)
--
MBTI: IXTP
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
