From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1752929AbcFJUIT (ORCPT <rfc822;w@1wt.eu>);
	Fri, 10 Jun 2016 16:08:19 -0400
Received: from mx1.redhat.com ([209.132.183.28]:49319 "EHLO mx1.redhat.com"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1751951AbcFJUIJ (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Fri, 10 Jun 2016 16:08:09 -0400
Date: Fri, 10 Jun 2016 22:07:49 +0200
From: Oleg Nesterov <oleg@redhat.com>
To: Andy Lutomirski <luto@amacapital.net>
Cc: Dmitry Safonov <dsafonov@virtuozzo.com>, "H. Peter Anvin" <hpa@zytor.com>,
        Dmitry Safonov <0x7f454c46@gmail.com>, khorenko@virtuozzo.com,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        Thomas Gleixner <tglx@linutronix.de>,
        Cyrill Gorcunov <gorcunov@openvz.org>, xemul@virtuozzo.com,
        X86 ML <x86@kernel.org>, Ingo Molnar <mingo@redhat.com>
Subject: Re: [PATCH 5/6] x86/ptrace: down with test_thread_flag(TIF_IA32)
Message-ID: <20160610200739.GA14789@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>
 <CALCETrWD8cvyNqW_2rxSDd2A345nOv47t+i2JhrCU2V7TpPNBQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CALCETrWD8cvyNqW_2rxSDd2A345nOv47t+i2JhrCU2V7TpPNBQ@mail.gmail.com>
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.25]); Fri, 10 Jun 2016 20:08:08 +0000 (UTC)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 06/09, Andy Lutomirski wrote:
>
> On Jun 6, 2016 3:21 PM, "Oleg Nesterov" <oleg@redhat.com> wrote:
> >
> > On 06/01, Dmitry Safonov wrote:
> > >
> > > Note, that this will work only if application has changed it's CS.
> >
> > So, suppose it changes it's CS and crashes,
> >
> > > If the application does 32-bit syscall with __USER_CS, ptrace
> > > @@ -1355,7 +1355,7 @@ void update_regset_xstate_info(unsigned int size, u64 xstate_mask)
> > >  const struct user_regset_view *task_user_regset_view(struct task_struct *task)
> > >  {
> > >  #ifdef CONFIG_IA32_EMULATION
> > > -     if (test_tsk_thread_flag(task, TIF_IA32))
> > > +     if (!user_64bit_mode(task_pt_regs(task)))
> > >  #endif
> >
> > then coredump will do fill_elf_header(view->e_machine) and use EM_X86_64
> > instead of EM_386, or vice versa...
> >
> > I simply can't understand is this better or worse, I guess gdb or any
> > other tool which looks at this coredump will be confused anyway.
> >
>
> I think it's better.

and I tend to agree, I didn't try to argue with this change, but

> CRIU will change CS and someone will make the
> restored process crash afterwards.

I don't understand what do you mean... could you explain?

IIRC, CRIU can't c/r the 32-bit applications, or this is no longer true?

Oleg.