From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1423820AbcFMNuc (ORCPT ); Mon, 13 Jun 2016 09:50:32 -0400 Received: from mx1.redhat.com ([209.132.183.28]:41710 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1423299AbcFMNua (ORCPT ); Mon, 13 Jun 2016 09:50:30 -0400 Date: Mon, 13 Jun 2016 15:50:20 +0200 From: Oleg Nesterov To: Andy Lutomirski Cc: Dmitry Safonov , "H. Peter Anvin" , Dmitry Safonov <0x7f454c46@gmail.com>, khorenko@virtuozzo.com, "linux-kernel@vger.kernel.org" , Thomas Gleixner , Cyrill Gorcunov , xemul@virtuozzo.com, X86 ML , Ingo Molnar Subject: Re: [PATCH 5/6] x86/ptrace: down with test_thread_flag(TIF_IA32) Message-ID: <20160613135020.GA27007@redhat.com> References: <1464786697-20639-1-git-send-email-dsafonov@virtuozzo.com> <1464786697-20639-6-git-send-email-dsafonov@virtuozzo.com> <20160606211918.GB23681@redhat.com> <20160610200739.GA14789@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.32]); Mon, 13 Jun 2016 13:50:30 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 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.