From owner-freebsd-current Tue Jan 11 3:18:56 2000 Delivered-To: freebsd-current@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id DF4F215366; Tue, 11 Jan 2000 03:18:51 -0800 (PST) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (beefcake.zeta.org.au [203.26.10.12]) by mailman.zeta.org.au (8.8.7/8.8.7) with ESMTP id WAA30653; Tue, 11 Jan 2000 22:18:48 +1100 Date: Tue, 11 Jan 2000 22:18:44 +1100 (EST) From: Bruce Evans X-Sender: bde@alphplex.bde.org To: Brian Fundakowski Feldman Cc: Stephen McKay , freebsd-current@FreeBSD.ORG, dt@FreeBSD.ORG Subject: Re: Crash from ^T during heavy paging In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 11 Jan 2000, Brian Fundakowski Feldman wrote: > On Mon, 10 Jan 2000, Stephen McKay wrote: > > > The problem is that calcru() thinks that P_INMEM means that the proc > > structure is fully and accurately populated. But P_INMEM is one of the > > first flags set. > > > > So, calcru() and possibly some other places, are looking at a struct proc > > before it's all there. What's the "proper" way to do it? > > It should really be one of the _last_ flags set, if it's to mean anything. > I don't know how to explain the prevalance of race conditions in the old > code, except to say it probably has to do with not planning ahead. > [patch deleted] I broke calcru() with the monotonicity fixes (kern_resource.c rev.1.45 (1999/03/13). Accessing p->p_stats at interrupt time is only valid if p == curproc. Fix: move the new monotonicity fields from struct pstats to struct proc. I only put them in struct pstats because they logically go with some fields in struct rusage. P_INMEM is probably not supposed to work in interrupt contexts. Checking it in ttyinfo() is a wrong fix for the bug in calcru(). It was committed in tty.c rev.1.119 (1999/05/22). Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message