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 S1755890AbbCRS1V (ORCPT <rfc822;w@1wt.eu>);
	Wed, 18 Mar 2015 14:27:21 -0400
Received: from mx1.redhat.com ([209.132.183.28]:39752 "EHLO mx1.redhat.com"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1751330AbbCRS1T (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Wed, 18 Mar 2015 14:27:19 -0400
Date: Wed, 18 Mar 2015 19:25:22 +0100
From: Oleg Nesterov <oleg@redhat.com>
To: Cyrill Gorcunov <gorcunov@gmail.com>
Cc: Andy Lutomirski <luto@amacapital.net>, Andrey Wagin <avagin@gmail.com>,
        Andy Lutomirski <luto@kernel.org>, Ingo Molnar <mingo@kernel.org>,
        Andi Kleen <andi@firstfloor.org>, "H. Peter Anvin" <hpa@zytor.com>,
        Al Viro <viro@zeniv.linux.org.uk>, X86 ML <x86@kernel.org>,
        LKML <linux-kernel@vger.kernel.org>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        Borislav Petkov <bp@alien8.de>, Pavel Emelyanov <xemul@openvz.org>
Subject: Re: [PATCH v3 1/2] x86_64,signal: Fix SS handling for signals
	delivered to 64-bit programs
Message-ID: <20150318182522.GA1832@redhat.com>
References: <cover.1426193719.git.luto@kernel.org> <405594361340a2ec32f8e2b115c142df0e180d8e.1426193719.git.luto@kernel.org> <CANaxB-yz9BZbU1TLB-kGfR21L_ZUkni9bqL96mK5jgsXAka+KA@mail.gmail.com> <20150318174843.GA32238@redhat.com> <CALCETrVMvD+yAesUPfTPhM9bs2EkeQq3AwXNA2pdkM2w8CwPcg@mail.gmail.com> <20150318181718.GG2255@moon>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20150318181718.GG2255@moon>
User-Agent: Mutt/1.5.18 (2008-05-17)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 03/18, Cyrill Gorcunov wrote:
>
> On Wed, Mar 18, 2015 at 11:06:00AM -0700, Andy Lutomirski wrote:
> > > --- a/arch/x86/crtools.c
> > > +++ b/arch/x86/crtools.c
> > > @@ -475,6 +475,7 @@ int restore_gpregs(struct rt_sigframe *f, UserX86RegsEntry *r)
> > >         CPREG2(rip, ip);
> > >         CPREG2(eflags, flags);
> > >         CPREG1(cs);
> > > +       CPREG1(ss);
> > >         CPREG1(gs);
> > >         CPREG1(fs);
> >
> > Huh?  Is CRIU actually trying to build an entire sigcontext from
> > scratch here?  I don't see how this can reliably work across kernel
> > versions or CPU versions.
>
> Yes we are. And why it can't work reliably? As to CPU -- we're
> testing that cpu features saved in image should match ones
> provided by the kernel runtime, ie on the machine where we're
> restoring.

But, say, __USER_CS can be changed in kernel, and nobody should notice this.

But in this case "restore on another machine" or "restore after kernel
upgrade" can fail.

So probably restore_gpregs() should only change the general-purpose regs,
as its name suggests.

Oleg.