Re: [PATCH v2 2/3] MIPS: Setup an instruction emulation in VDSO protected page instead of user stack

[David Daney]

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.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/