All of lore.kernel.org
 help / color / mirror / Atom feed
From: Joerg Roedel <jroedel@suse.de>
To: Dave Hansen <dave.hansen@linux.intel.com>
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 14:08:01 +0200	[thread overview]
Message-ID: <20170420120801.GH5077@suse.de> (raw)
In-Reply-To: <0d387d7f-208e-75aa-55ea-0157412aa4d4@linux.intel.com>

Hi Dave,

On Mon, Apr 17, 2017 at 08:38:03AM -0700, Dave Hansen wrote:
> Just to be clear, the thing you're calling "correct" is this do_trap(),
> right?
> 
>         do_trap(X86_TRAP_BR, SIGSEGV, "bounds", regs, error_code, NULL);

Yes, because it signals the right trap_nr and error_code to user-space.

> 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.

I don't know whether user-space (with this patch) already gets enough
information from do_trap() to handle all of the above cases, but it is a
step in the right direction.


	Joerg

  reply	other threads:[~2017-04-20 12:08 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 [this message]
2017-04-20 15:45     ` Dave Hansen
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=20170420120801.GH5077@suse.de \
    --to=jroedel@suse.de \
    --cc=dave.hansen@linux.intel.com \
    --cc=hpa@zytor.com \
    --cc=joro@8bytes.org \
    --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.