From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S970869AbdDTPpd (ORCPT ); Thu, 20 Apr 2017 11:45:33 -0400 Received: from mga01.intel.com ([192.55.52.88]:37442 "EHLO mga01.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S970809AbdDTPpb (ORCPT ); Thu, 20 Apr 2017 11:45:31 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.37,225,1488873600"; d="scan'208";a="90242655" 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> Cc: Joerg Roedel , Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , x86@kernel.org, linux-kernel@vger.kernel.org From: Dave Hansen Message-ID: <61c36474-63a5-d080-77d8-874e8c01c626@linux.intel.com> Date: Thu, 20 Apr 2017 08:45:28 -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: <20170420120801.GH5077@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 On 04/20/2017 05:08 AM, Joerg Roedel wrote: >> do_mpx_bt_fault() can fail for a bunch of reasons: >> * unexpected or invalid value in BNDCSR >> * out of memory (physical or virtual) >> * unresolvable fault walking/filling bounds tables >> * !valid and non-empty bad entry in the bounds tables >> >> This will end up sending a signal that *looks* like a X86_TRAP_BR for >> all of those, including those that are not really bounds-related, like >> unresolvable faults. We also don't populate enough information in the >> siginfo that gets delivered for userspace to resolve the fault. >> >> I'm not sure this patch is the right thing. > > The problem is, without this patch the trap_nr reported to user-space is > 0, which maps to divide-by-zero. I think this is wrong, and since all > failure cases from do_mpx_bt_fault() can only happen in the #BR > exception handler, I think that reporting X86_TRAP_BR for all failure > cases is the right thing to do. Urg, that does sound bogus. 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.