From owner-freebsd-ia64@FreeBSD.ORG Fri Jun 29 07:48:11 2007 Return-Path: X-Original-To: ia64@freebsd.org Delivered-To: freebsd-ia64@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F2D3B16A468 for ; Fri, 29 Jun 2007 07:48:11 +0000 (UTC) (envelope-from christian.kandeler@hob.de) Received: from mailgate.hob.de (mailgate.hob.de [212.185.199.3]) by mx1.freebsd.org (Postfix) with ESMTP id 85FAE13C45A for ; Fri, 29 Jun 2007 07:48:11 +0000 (UTC) (envelope-from christian.kandeler@hob.de) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailgate.hob.de (Postfix) with ESMTP id AA5A5280C7 for ; Fri, 29 Jun 2007 09:48:10 +0200 (CEST) Received: from mailgate.hob.de ([127.0.0.1]) by localhost (mailgate.hob.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12552-03 for ; Fri, 29 Jun 2007 09:48:10 +0200 (CEST) Received: from imap.hob.de (mail2.hob.de [172.25.1.102]) by mailgate.hob.de (Postfix) with ESMTP id 1F5AF28092 for ; Fri, 29 Jun 2007 09:48:09 +0200 (CEST) Received: from [172.22.0.190] (linux03.hob.de [172.22.0.190]) by imap.hob.de (Postfix on SuSE eMail Server 2.0) with ESMTP id 78799C6A67 for ; Fri, 29 Jun 2007 09:48:08 +0200 (CEST) From: Christian Kandeler Organization: HOB To: ia64@freebsd.org Date: Fri, 29 Jun 2007 09:48:04 +0200 User-Agent: KMail/1.6.2 References: <200706211132.32524.christian.kandeler@hob.de> <200706271417.02968.christian.kandeler@hob.de> In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200706290948.04330.christian.kandeler@hob.de> X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at hob.de Cc: Subject: Re: Syscalls and RSE X-BeenThere: freebsd-ia64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the IA-64 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2007 07:48:12 -0000 On Friday 29 June 2007 06:42, Marcel Moolenaar wrote: > What you're saying is that ar.rnat is not preserved and in fact is > undefined. This is what the SDM actually says. So, you argue that > when we return, the NaT collection point that happened on the > kernel stack and which includes the NaT bits of registers of the > process are undefined after we return to the process and the RSE is > unwound to beyond said collection point. You demonstrated this by > putting a random (i.e. -1) value in ar.rnat and observing that the > process crached. Exactly. > The problem is in the assumption that ar.rnat is still valid after > writing to ar.bspstore. The SDM states that ar.rnat is undefined. > I haven't seen any indication that ar.rnat is anything other than > what it was before, but that's probably because without speculation > it's always 0 anyway :-) > The fact a bogus ar.rnat value affects a process simply means that > we in fact propagate the ar.rnat back to the process after a flush. > This is a good thing! Huh? But we don't "propagate back" anything - we manipulate the NaT collection. The process gets back a random collection of NaT bits instead of the one that it had before doing the syscall. It's not the process' fault that the backing store is switched in the kernel, so it must not be affected by it. And I don't understand how the process crashing is a good thing: -1 is a completely legal value for RNAT to have after the switch, so the process will crash on any hardware whose implementation of "undefined" is "all bits set to 1". > However, the question is: should we write the saved ar.rnat value > back to ar.rnat after the backing store switch? Doing so will make > the assumption that ar.rnat is preserved after a backing store > switch valid (in a programmatic manner). > > Would this address the problem you describe or did I misunderstand? The way I see it, the code right now either a) wrongly assumes RNAT is preserved by the backing store switch or b) wrongly assumes RNAT does not need to be preserved. But preserving RNAT over the backing store switch is necessary because it is possible that we leave the syscall with a BspLoad value that is higher than the one we entered it with, so the first NaT collection saved on the kernel backing store must reflect the state of RNAT on entry to the syscall. Regards, Christian Kandeler