Date: Tue, 9 Oct 2001 22:41:59 +1000 (EST) From: Bruce Evans <bde@zeta.org.au> To: Dag-Erling Smorgrav <des@ofug.org> Cc: Peter Wemm <peter@wemm.org>, <arch@FreeBSD.ORG> Subject: Re: Removing ptrace(2)'s dependency on procfs(5) Message-ID: <20011009221951.B25192-100000@delplex.bde.org> In-Reply-To: <xzpvghsrj1z.fsf@flood.ping.uio.no>
next in thread | previous in thread | raw e-mail | index | archive | help
On 6 Oct 2001, Dag-Erling Smorgrav wrote:
> BTW, I'm intrigued by the following bit of code in kern_sig.c:
>
> do {
> mtx_lock_spin(&sched_lock);
> stop(p);
> PROC_UNLOCK_NOSWITCH(p);
> DROP_GIANT_NOSWITCH();
> p->p_stats->p_ru.ru_nivcsw++;
> mi_switch();
> mtx_unlock_spin(&sched_lock);
> PICKUP_GIANT();
> PROC_LOCK(p);
> } while (!trace_req(p)
> && p->p_flag & P_TRACED);
>
> It's the only reference to trace_req() (defined in sys_process.c) in
> the entire tree, and trace_req() has been a constant since revision
> 1.1 of sys_process.c, and true since revision 1.4 (1994/08/08), so
> this loop will always execute exactly once. Is there a good reason
> not to simply axe trace_req() and unroll the loop?
The correctness of not looping depends on nothing except the parent
making the process runnable (unless the process loses its P_TRACED
attribute). This is apparently what happens, since things have worked
for so long. But I don't completely understand what happens when a
signal is sent to the process. The comment before this section of
code suggests looping.
Bruce
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20011009221951.B25192-100000>