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 <o...@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.