Received: by 10.213.65.68 with SMTP id h4csp577428imn; Fri, 16 Mar 2018 12:02:32 -0700 (PDT) X-Google-Smtp-Source: AG47ELu1L9aHh37AryCYiCkEa17YDHH5HsDJ7OGr9ch5+N0ZlRses9El7tdjgOYiFDR1CGqe6T6a X-Received: by 2002:a17:902:744b:: with SMTP id e11-v6mr3236063plt.351.1521226952472; Fri, 16 Mar 2018 12:02:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1521226952; cv=none; d=google.com; s=arc-20160816; b=mlmmaejPB03IZu0EI97Crj86hn7mLB70cOQEYjGuu0LovR6zJgAIVZPxm8m8STy75h JFJaSP/iKDeLKVduTiwxRHeLRea3DWmLMpv6Icn0s/IXyiMRztlLmUWbGgehVGacYGXr YlCf3m1gr2RCs6r4gzQo2OmcMVZqFeP41nsDP/4LRzNXc2KUCF3qMVx/LhFAgKEvvFtm 2LgnseLiJrmLhUWXSStVqMQrKKOeq0YSofuTTccOVinY3J+bU4YBWpC17r7D2FRVBXPH EdkqHQNaBPfbziaSN4I7Nb9Xgmwpnhm9rq2ZJUqWpyczz61DTtkuTU1kRYgUQ9NBAzHZ 4gnQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:cc:references:to:subject:arc-authentication-results; bh=ObzoZ+ex3LN0CVOq70w5x9sFTZY7+J7KXDNI7zeoqk8=; b=U7E5vhfPUQ2EweB/jwfelMXwF0hhRU5y2n4/wgugrgNv5pipvCc5xtVCfj9EwT8Xe8 vfJ24fyHup9Z8JZTp9pQo6O3VKsmCk1yd8+7/M9zcvkz+XhVoe0rF54zj0wjKMaiDOfS doaFVbPZi75NfNLCtTqFYiqKVWUyHlbPOw0lEv98Nh3T5lQEd+mZ87RWsEqbrowgXoVc rrDCR2QctPpotS2Moq2qP/MYlHQRXFNsnMqHlOLmjgaLd/+IYbYcj1+HQmCw1rGlm7wF gYmLt+PNx1qw+6XxsKj73D9cRkW9gEX35PHjvxWwVsj1ShUkS2mKmsYXaTVZuUaVN+rk +46Q== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id x190si5404896pgx.378.2018.03.16.12.02.17; Fri, 16 Mar 2018 12:02:32 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753129AbeCPTAm (ORCPT + 99 others); Fri, 16 Mar 2018 15:00:42 -0400 Received: from mga04.intel.com ([192.55.52.120]:29291 "EHLO mga04.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752966AbeCPTAY (ORCPT ); Fri, 16 Mar 2018 15:00:24 -0400 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga007.jf.intel.com ([10.7.209.58]) by fmsmga104.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Mar 2018 12:00:24 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.48,317,1517904000"; d="scan'208";a="25330856" Received: from ray.jf.intel.com (HELO [10.7.201.16]) ([10.7.201.16]) by orsmga007.jf.intel.com with ESMTP; 16 Mar 2018 12:00:23 -0700 Subject: Re: [PATCH 13/22] signal: Move addr_lsb into the _sigfault union for clarity To: "Eric W. Biederman" , linux-kernel@vger.kernel.org References: <87k1wimybi.fsf_-_@xmission.com> <20180116004009.31036-13-ebiederm@xmission.com> Cc: Al Viro , Oleg Nesterov , linux-arch@vger.kernel.org From: Dave Hansen Message-ID: <29eb3438-0891-36ee-e5f6-36e26ccf2b89@intel.com> Date: Fri, 16 Mar 2018 12:00:16 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <20180116004009.31036-13-ebiederm@xmission.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 01/15/2018 04:40 PM, Eric W. Biederman wrote: > The addr_lsb fields is only valid and available when the > signal is SIGBUS and the si_code is BUS_MCEERR_AR or BUS_MCEERR_AO. > Document this with a comment and place the field in the _sigfault union > to make this clear. > > All of the fields stay in the same physical location so both the old > and new definitions of struct siginfo will continue to work. This breaks the ABI and breaks protection keys. The physical locations *DO* change. Before this patch: #define si_pkey _sifields._sigfault._pkey (gdb) print &((siginfo_t *)0)->_sifields._sigfault._pkey $1 = (__u32 *) 0x20 and after: +#define si_pkey _sifields._sigfault._addr_pkey._pkey (gdb) print &((siginfo_t *)0)->_sifields._sigfault._addr_pkey._pkey $1 = (__u32 *) 0x1c Can we revert this, please?