Messages in this thread | | | Date | Mon, 13 Jun 2016 15:50:20 +0200 | From | Oleg Nesterov <> | Subject | Re: [PATCH 5/6] x86/ptrace: down with test_thread_flag(TIF_IA32) |
| |
To avoid the confusion, let me first say that I am not going to argue with these changes, I simply do not understand the problem space enough.
On 06/10, Andy Lutomirski wrote: > > On Fri, Jun 10, 2016 at 1:07 PM, Oleg Nesterov <oleg@redhat.com> wrote: > > > > IIRC, CRIU can't c/r the 32-bit applications, or this is no longer true? > > > > CRIU has a horrible, nasty, brilliant idea: it will start restoring > 32-bit processes by treating them mostly like 64-bit processes. The > restorer will start out 64-bit, set everything up, and long > jump/return/sigreturn/whatever back to 32-bit mode.
OK, I see,
> My proposal was > that, rather than coming up with nasty hacks to switch the kernel's > idea of the task bitness,
Well, I can't resist but to me SA_IA32_ABI/SA_X32_ABI looks like a hack too. We actually shift TIF_*32 into k_sigaction->flags, and the fact that we do this per-signal looks, well, interesting ;)
And at first glance it would be very simple to change the task bitness, CRIU can simply exec a dummy 32-bit application before anything else. In this case (I think) we also do not need do_map_vdso/ARCH_MAP_VDSO_* at least right now.
Yes, I guess this will complicate CRIU significantly.
> we instead teach the kernel to respect that > actual bitness as indicated by CS and the syscalls used to the extent > possible.
I am still not sure the idea to remove TIF_IA32/TIF_X32 is really good. But again, I won't argue, I do not feel I understand pro/cons enough.
> So, yes, a restored 32-bit process that crashes should dump core as > though it's 32-bit even though it was 64-bit when execve was last > called :)
OK, thanks for you explanation Andy.
Oleg.
| |