* Andy Lutomirski <l...@amacapital.net> wrote:
> > So assuming you fix the UML build I'm inclined to go for it, even in this
> > incomplete form, to increase testing coverage.
> >
> > Doing that will also decrease ongoing merge friction between your work and
> > other entry code cleanups ...
>
> Sounds good to me. I'm not convinced this is 4.2 material, though. Would it
> go
> in a separate branch for now?
Please send it out as a separate series, on top of -tip, I'll probably stick it
into a separate branch for the time being.
> On a related note, do you have any idea what work_notifysig_v86 in entry_32.S
> is
> for? It seems unnecessary and wrong to me. Unnecessary because we have
> return_to_32bit. Wrong because I don't see how we can reliably enter vm86
> mode
> if we have exit work enabled -- one of the giant turds in vm86_32.c literally
> jumps from C code to resume_userspace on vm86 entry, and resume_userspace
> promptly checks for work and might land in work_notifysig_v86 before we ever
> make it to v8086/user mode.
>
> I think it may actually be impossible to use vm86 under ptrace. ISTR I had
> some
> trouble when trying to strace my test case...
Should be tested really, I'm all for removing it if simple vm86 mode games
continue to work ;-)
Thanks,
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
