From owner-freebsd-current Mon Feb 17 14:28:49 2003 Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AB64C37B401 for ; Mon, 17 Feb 2003 14:28:47 -0800 (PST) Received: from k6.locore.ca (k6.locore.ca [198.96.117.170]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9E77543F93 for ; Mon, 17 Feb 2003 14:28:46 -0800 (PST) (envelope-from jake@k6.locore.ca) Received: from k6.locore.ca (jake@localhost.locore.ca [127.0.0.1]) by k6.locore.ca (8.12.6/8.12.6) with ESMTP id h1HMWBNk083606; Mon, 17 Feb 2003 17:32:11 -0500 (EST) (envelope-from jake@k6.locore.ca) Received: (from jake@localhost) by k6.locore.ca (8.12.6/8.12.6/Submit) id h1HMWBd2083605; Mon, 17 Feb 2003 17:32:11 -0500 (EST) Date: Mon, 17 Feb 2003 17:32:11 -0500 From: Jake Burkholder To: Bruce Evans Cc: FreeBSD current users Subject: Re: question on profiling code Message-ID: <20030217173211.G81102@locore.ca> References: <20030217021512.O63597@locore.ca> <20030218075519.Y7132-100000@gamplex.bde.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20030218075519.Y7132-100000@gamplex.bde.org>; from bde@zeta.org.au on Tue, Feb 18, 2003 at 08:54:59AM +1100 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > > Can you explain how fuswintr() and suswintr() work on sparc64's? They > seem to cause traps if the user counter is not mapped, and I can't see > where the traps are handled. ia64/trap.c has a comment about where these > traps are handled, but has dummies for fuswintr() and suswintr() so the > traps never occur. Depending on traps in fast interrupt handlers is > a bug IMO. It extends the scope of the fast interrupt handler to the > trap handler, and it is difficult to limit this scope and verify the > locking for it. Ok. Sparc64 uses "lazy trap handling", similar to how I saw you'd done in your sys.dif. The functions that access user space are delimited by labels, and in trap and trap_pfault we check to see if the pc is inside of the labels. fuswintr and suswintr and bracketed by fs_nofault_intr_begin and fs_nofault_intr_end, which trap_pfault checks for specifically before doing much of anything: if (ctx != TLB_CTX_KERNEL) { if ((tf->tf_tstate & TSTATE_PRIV) != 0 && (tf->tf_tpc >= (u_long)fs_nofault_intr_begin && tf->tf_tpc <= (u_long)fs_nofault_intr_end)) { tf->tf_tpc = (u_long)fs_fault; tf->tf_tnpc = tf->tf_tpc + 4; return (0); } ... handle fault ctx != TLB_CTX_KERNEL is akin to va < VM_MAXUSER_ADDRESS (the address spaces overlap on sparc64 so we can only rely on tlb context numbers). Note that the range bracketed by the fs_nofault_intr_* is included in the fs_nofault range, which handles alignment or data access exception faults. It does take some special care in trap() and trap_pfault() not to access important data, or acquire any locks before this test. Non-trivial interrupts are still masked here, which buys us something. Probably the vmspace pointer should not be counted on in this context, but I don't think it will ever be invalid for the current process, especially since the original interrupt occured in usermode. The only locking that's required that I can see is that PS_PROFIL not be set when the profiling buffer is invalid. But all that will happen is that attempts to update the profiling buffer will be ignored. Technically the process should get a signal but addupc_task doesn't check the return value of copyin/out (oops). Jake To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message