From owner-freebsd-arch  Tue Oct  9  5:42:59 2001
Delivered-To: freebsd-arch@freebsd.org
Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16])
	by hub.freebsd.org (Postfix) with ESMTP id 02AF637B401
	for <arch@FreeBSD.ORG>; Tue,  9 Oct 2001 05:42:55 -0700 (PDT)
Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102])
	by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id WAA04571;
	Tue, 9 Oct 2001 22:42:42 +1000
Date: Tue, 9 Oct 2001 22:41:59 +1000 (EST)
From: Bruce Evans <bde@zeta.org.au>
X-X-Sender:  <bde@delplex.bde.org>
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)
In-Reply-To: <xzpvghsrj1z.fsf@flood.ping.uio.no>
Message-ID: <20011009221951.B25192-100000@delplex.bde.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-arch@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-arch.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-arch>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-arch>
X-Loop: FreeBSD.ORG

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