Syscalls and RSE

Marcel Moolenaar xcllnt at mac.com
Fri Jun 29 16:42:47 UTC 2007


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 at mac.com




More information about the freebsd-ia64 mailing list