Date: Fri, 29 Jun 2007 09:42:12 -0700 From: Marcel Moolenaar <xcllnt@mac.com> To: Christian Kandeler <christian.kandeler@hob.de> Cc: ia64@freebsd.org Subject: Re: Syscalls and RSE Message-ID: <23365936-A0DB-48FF-A051-2E18816FC742@mac.com> In-Reply-To: <200706290948.04330.christian.kandeler@hob.de> References: <200706211132.32524.christian.kandeler@hob.de> <200706271417.02968.christian.kandeler@hob.de> <CE7EFE79-2859-4CFD-8EA2-62B2709C30CF@mac.com> <200706290948.04330.christian.kandeler@hob.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Jun 29, 2007, at 12:48 AM, Christian Kandeler wrote: >> 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". You misunderstand the point I was trying to make. While it's not a good thing to clobber the ar.rnat register, it's a good thing that clobbering it causes the process to fail for it means that exit out of the kernel through the epc_syscall code path will indeed restore the ar.rnat register that was clobbered on entry. It simply means that the kernel exit is correct. That's a good thing. Yes, it's not a good thing that kernel entry isn't, but we know it's only the entry that's broken and not also the exit. >> 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. Both. If A then B :-) -- Marcel Moolenaar xcllnt@mac.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?23365936-A0DB-48FF-A051-2E18816FC742>