From: Dave Hansen <dave.hansen@linux.intel.com>
To: Joerg Roedel <jroedel@suse.de>
Cc: Joerg Roedel <joro@8bytes.org>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
x86@kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] x86/mpx: Correctly report do_mpx_bt_fault() failures to user-space
Date: Thu, 20 Apr 2017 08:45:28 -0700 [thread overview]
Message-ID: <61c36474-63a5-d080-77d8-874e8c01c626@linux.intel.com> (raw)
In-Reply-To: <20170420120801.GH5077@suse.de>
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.
next prev parent reply other threads:[~2017-04-20 15:45 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-06 14:19 [PATCH] x86/mpx: Correctly report do_mpx_bt_fault() failures to user-space Joerg Roedel
2017-04-12 7:30 ` [tip:x86/mm] " tip-bot for Joerg Roedel
2017-04-17 15:38 ` [PATCH] " Dave Hansen
2017-04-20 12:08 ` Joerg Roedel
2017-04-20 15:45 ` Dave Hansen [this message]
2017-04-21 12:19 ` Joerg Roedel
2017-04-21 14:30 ` Dave Hansen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=61c36474-63a5-d080-77d8-874e8c01c626@linux.intel.com \
--to=dave.hansen@linux.intel.com \
--cc=hpa@zytor.com \
--cc=joro@8bytes.org \
--cc=jroedel@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.