linux-kernel - Re: problem with signal delivery SIGCHLD

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Date:	Tue, 19 Dec 2006 12:55:06 -0500
From:	Chuck Ebbert <76306.1226@...puserve.com>
To:	Nicholas Mc Guire <der.herr@...r.at>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: problem with signal delivery SIGCHLD

In-Reply-To: <Pine.LNX.4.60.0612181924470.2560@...14.hofr.at>

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 majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/