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 S1753397AbbCJQod (ORCPT <rfc822;w@1wt.eu>);
	Tue, 10 Mar 2015 12:44:33 -0400
Received: from mx1.redhat.com ([209.132.183.28]:41831 "EHLO mx1.redhat.com"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1752616AbbCJQoa (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Tue, 10 Mar 2015 12:44:30 -0400
Date: Tue, 10 Mar 2015 17:42:11 +0100
From: Oleg Nesterov <oleg@redhat.com>
To: Andy Lutomirski <luto@amacapital.net>
Cc: 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>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        Borislav Petkov <bp@alien8.de>
Subject: Re: [PATCH v2 1/2] x86_64,signal: Fix SS handling for signals
	delivered to 64-bit programs
Message-ID: <20150310164211.GA8642@redhat.com>
References: <cover.1425995824.git.luto@amacapital.net> <ee0df6e0b7a4bd5283fa29f0d4fd11a4d39f45d1.1425995824.git.luto@amacapital.net> <CALCETrU++JjyPFBMxGsDS9_xzK9bGZB0U0QOZ9LEySOYO5maEw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CALCETrU++JjyPFBMxGsDS9_xzK9bGZB0U0QOZ9LEySOYO5maEw@mail.gmail.com>
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

Well, the patch looks "obviously fine" to me, but this is all I can say.

I mean, I simply can't understand this __pad0/ifdef(CONFIG_X86_32), it
looks as if ->ss was specially excluded for unknown reason from the very
beginning.

On 03/10, Andy Lutomirski wrote:
>
> > --- a/arch/x86/include/uapi/asm/sigcontext.h
> > +++ b/arch/x86/include/uapi/asm/sigcontext.h
> > @@ -179,7 +179,7 @@ struct sigcontext {
> >         __u16 cs;
> >         __u16 gs;
> >         __u16 fs;
> > -       __u16 __pad0;
> > +       __u16 ss;

I do not know the rules for include/uapi/ ...

OK, nobody should ever use __pad0, so probably it is safe to rename it.
OTOH, an application can (say) try to print all members for debugging
purposes, it won't compile after this change.

Oleg.