From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 15 13:21:13 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AA19A16A4CE for ; Tue, 15 Feb 2005 13:21:13 +0000 (GMT) Received: from comsys.ntu-kpi.kiev.ua (comsys.ntu-kpi.kiev.ua [195.245.194.142]) by mx1.FreeBSD.org (Postfix) with ESMTP id CB76943D41 for ; Tue, 15 Feb 2005 13:20:51 +0000 (GMT) (envelope-from simon@comsys.ntu-kpi.kiev.ua) Received: from pm514-9.comsys.ntu-kpi.kiev.ua (pm514-9.comsys.ntu-kpi.kiev.ua [10.18.54.109]) (authenticated bits=0)j1FDNGl0013689 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 15 Feb 2005 15:23:20 +0200 (EET) Received: by pm514-9.comsys.ntu-kpi.kiev.ua (Postfix, from userid 1000) id 9D60E83; Tue, 15 Feb 2005 15:20:20 +0200 (EET) Date: Tue, 15 Feb 2005 15:20:20 +0200 From: Andrey Simonenko To: Ashwin Chandra Message-ID: <20050215132020.GA376@pm514-9.comsys.ntu-kpi.kiev.ua> References: <000801c51327$0e2bf020$58e243a4@ash> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <000801c51327$0e2bf020$58e243a4@ash> User-Agent: Mutt/1.4.2.1i X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.0.1 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on comsys.ntu-kpi.kiev.ua X-Virus-Scanned: ClamAV 0.80/706/Mon Feb 14 02:14:02 2005 clamav-milter version 0.80j on comsys.ntu-kpi.kiev.ua X-Virus-Status: Clean cc: freebsd-hackers@freebsd.org Subject: Re: Kernel monitor, the return X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Feb 2005 13:21:13 -0000 On Mon, Feb 14, 2005 at 10:24:50PM -0800, Ashwin Chandra wrote: > In trying to create a simple kernel thread that prints out all > the processes data and stack size, i still get a panic fault > (vm_fault on no entry) at the printf statement...ive narrowed > it down to the ru_idrss variable that is causing the problem, Definitely ru_idrss cannot cause any error, may be you made such desition, because arguments are pushed to the stack in the reverse order. p->p_stats pointer causes the error. > im not sure why (I think that) If some process is not running, then you cannot use p->p_stats without additional checks for memory p->p_stats points to, since p->p_stats points to u_stats in struct user{}, which can be swapped out if a process is not running. Actually you can read this in the comment before struct user{} in /sys/sys/user.h. >. I thought maybe I was not locking properly or > obseriving correct mutexes, but I have tried everything. You'll get an error at some time, because of incorrect usage (really not usage) of locks. > If anyone > knows why the fault is occurring at the printf, please let me know. =) Following code works on my system: ---- sx_slock(&allproc_lock); FOREACH_PROC_IN_SYSTEM(p) { mtx_lock_spin(&sched_lock); PROC_LOCK(p); printf("proc %ld:", (long)p->p_pid); if ((p->p_sflag & PS_INMEM) && p->p_stats != NULL) printf(" ru_isrss %ld, rui_idrss %ld\n", p->p_stats->p_ru.ru_isrss, p->p_stats->p_ru.ru_idrss); else { if (!(p->p_sflag & PS_INMEM)) printf(" !PS_INMEM"); if (p->p_stats == NULL) printf(" p_stats == NULL"); } printf("\n"); PROC_UNLOCK(p); mtx_unlock(&sched_lock); } sx_sunlock(&allproc_lock); ---- Follow this code: vm_glue.c:vm_proc_new() allocates memory for u-area with MAP_NOFAULT vm_glue.c:vm_proc_swapout() calls pmap_qremove() for u-area vm_glue.c:vm_proc_swapin() fills u-area and calls pmap_qenter() for it vm_fault.c:vm_failt() panics if a page fault occurred for vm_map_entry which has MAP_ENTRY_NOFAULT, you got this panic I think. ps: not related to topic, but I think that ru_idrss and ru_isrss are not something you need, according to first lines of your letter.