Date: Fri, 29 Jun 2007 09:48:04 +0200 From: Christian Kandeler <christian.kandeler@hob.de> To: ia64@freebsd.org Subject: Re: Syscalls and RSE Message-ID: <200706290948.04330.christian.kandeler@hob.de> In-Reply-To: <CE7EFE79-2859-4CFD-8EA2-62B2709C30CF@mac.com> References: <200706211132.32524.christian.kandeler@hob.de> <200706271417.02968.christian.kandeler@hob.de> <CE7EFE79-2859-4CFD-8EA2-62B2709C30CF@mac.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200706290948.04330.christian.kandeler>