On 10/10/2014 03:47 PM, Leonid Yegoshin wrote:
On 10/10/2014 03:03 AM, James Hogan wrote:
I just mean an (illegal/undefined) sequence of FPU branch instructions
in one anothers delay slots shouldn't be able to crash the kernel.
Actually 2 of them would be enough to verify the kernel didn't get too
confused. Maybe the second will be detected & ignored, or maybe it
doesn't matter if the first emuframe gets overwritten by the second
one from the kernels point of view.
Yes, I am looking into that sequences. I try to keep both emulators
isolated from the rest of kernel and from each other as much as possible
but intercalls via illegal combinations are still possible.
> From Peter Zijlstra:
> Right, look at uprobes, it does exactly all this with a single page.
> Slot allocation will block waiting for a free slot when all are in use.
I don't see a reason to change my 300 lines design into much more
lengthy code. That code has more links to the rest of kernel and high
possibility to execute atomic operation/locks/mutex/etc - I can't do it
for emulation of MIPS locking instructions.
It isn't just the number of lines of code that is important.
Doesn't your solution consume an extra page for each thread requiring
emulation? That could be a significant amount of memory in a system
with many threads.
Are you are using this to emulate atomic operations in addition to FPU
branch delay slot instructions? Where is the code that does that?
David Daney
- Leonid.
