From owner-freebsd-ia64@FreeBSD.ORG Fri Jun 29 04:43: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 8CF8516A469 for ; Fri, 29 Jun 2007 04:43:11 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.185]) by mx1.freebsd.org (Postfix) with ESMTP id 7775F13C448 for ; Fri, 29 Jun 2007 04:43:11 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from mac.com (smtpin02-en2 [10.13.10.147]) by smtpout.mac.com (Xserve/smtpout15/MantshX 4.0) with ESMTP id l5T4hAQs001605; Thu, 28 Jun 2007 21:43:10 -0700 (PDT) Received: from [172.16.1.4] (209-128-86-226.bayarea.net [209.128.86.226]) (authenticated bits=0) by mac.com (Xserve/smtpin02/MantshX 4.0) with ESMTP id l5T4h8xA020747 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 28 Jun 2007 21:43:09 -0700 (PDT) In-Reply-To: <200706271417.02968.christian.kandeler@hob.de> References: <200706211132.32524.christian.kandeler@hob.de> <3700F902-9CC0-4A6A-B625-8E81C12C5D5E@mac.com> <200706271417.02968.christian.kandeler@hob.de> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Marcel Moolenaar Date: Thu, 28 Jun 2007 21:42:39 -0700 To: Christian Kandeler X-Mailer: Apple Mail (2.752.3) X-Brightmail-Tracker: AAAAAA== X-Brightmail-scanned: yes Cc: ia64@freebsd.org 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 04:43:11 -0000 On Jun 27, 2007, at 5:17 AM, Christian Kandeler wrote: *snip* > The problem, I think, is not the RNAT on the way out of the > syscall, but a > collection of undefined NaT bits saved in the kernel and loaded > later in user > space. *snip* > I've tried to verify my theory, and I believe I have succeeded: If > the code in > epc_syscall is correct, then it should tolerate any value in RNAT > after the > backing store switch, since the value of this register is undefined > anyway. *snip* > However, when I manually set RNAT to -1 and boot the resulting > kernel, the > system crashes right after entering user space (Illegal Instruction > in the sh > process). I assume this is due to one of the many NaT bits the process > receives after making a system call. Ok, I think I see what you mean -- and it's a valid point. The current epc_syscall path saves ar.rnat and switches the backing store. It assumes that ar.rnat is not clobbered because we keep ar.bspstore aligned WRT to NaT collections. As such, it is assumed that it's safe to flush the dirty stacked registers on the kernel, whether or not we cross NaT collection points. 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. 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! 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? -- Marcel Moolenaar xcllnt@mac.com