Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1041069AbdDUOaO (ORCPT ); Fri, 21 Apr 2017 10:30:14 -0400 Received: from mga11.intel.com ([192.55.52.93]:10312 "EHLO mga11.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1040934AbdDUOaL (ORCPT ); Fri, 21 Apr 2017 10:30:11 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.37,230,1488873600"; d="scan'208";a="79565705" Subject: Re: [PATCH] x86/mpx: Correctly report do_mpx_bt_fault() failures to user-space To: Joerg Roedel References: <1491488362-27198-1-git-send-email-joro@8bytes.org> <0d387d7f-208e-75aa-55ea-0157412aa4d4@linux.intel.com> <20170420120801.GH5077@suse.de> <61c36474-63a5-d080-77d8-874e8c01c626@linux.intel.com> <20170421121901.GJ5077@suse.de> Cc: Joerg Roedel , Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , x86@kernel.org, linux-kernel@vger.kernel.org From: Dave Hansen Message-ID: <879ab29e-963f-4054-2767-74276fd1a3db@linux.intel.com> Date: Fri, 21 Apr 2017 07:30:09 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <20170421121901.GJ5077@suse.de> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 815 Lines: 18 On 04/21/2017 05:19 AM, Joerg Roedel wrote: > On Thu, Apr 20, 2017 at 08:45:28AM -0700, Dave Hansen wrote: >> How about doing X86_TRAP_PF? That would at least be consistent with >> SIGBUS, which is probably the closest thing to a generic error code that >> we have. > Correct me if I am wrong, but for SIGBUS this only happens in the > page-fault path, right? And this path is indeed entered on a #PF > exception. It can happen to programs for tons of reasons. It definitely happens outside page faults. > I see no reason to lie to user-space about the trap_nr that caused the > SIGSEGV, especially since user-space software needs to be modified to > make use of MPX, including the signal handler. So there is no risk of > introducing any incompatibility or regression, no? I think it's pretty safe to change.