lkml.org 
[lkml]   [2018]   [Sep]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [RFC][PATCH 1/8] x86/mm: clarify hardware vs. software "error_code"
    From
    Date


    > On Sep 10, 2018, at 1:07 PM, Dave Hansen <dave.hansen@linux.intel.com> wrote:
    >
    > On 09/07/2018 03:48 PM, Andy Lutomirski wrote:
    >>>
    >>> For part of the page fault handler, "error_code" does exactly
    >>> match PFEC. But, during later parts, it diverges and starts to
    >>> mean something a bit different.
    >>>
    >>> Give it two names for its two jobs.
    >> How hard would it be to just remove sw_error_code instead? It seems
    >> like it adds little value and much confusion.
    >
    > I think it would be really nice to have hw_error_code stand by itself
    > and be limited in scope to just __do_page_fault() and then have
    > FAULT_FLAG_* for everything else.
    >
    > But, I was a little scared off of that. For one, I think we fill in
    > signal info with error_code, which makes it nominally part of the ABI.
    > So, I wanted to muck with it as little as possible in this set.
    >
    > But, if we just said that
    > 1. hw_error_code goes out to userspace, always, and

    Nope, it’s an info leak. If the address is in kernel land (and not vsyscall), we must (and do, I believe) fake it.

    > 2. We drive all kernel behavior off of FAULT_FLAG_*, not error_code,
    > I think we can get away with it.
    >
    >> I’m also unconvinced that the warning is terribly useful. We’re going
    >> to oops when this happens anyway.
    >
    > One thing I wanted to get out of the warning was the contents of
    > hw_error_code before we go screwing with it. I also don't mind a nice,
    > clarifying warning showing up just before an oops. Maybe it could be a
    > pr_warn/err() instead of a full warning?

    Sure.
    \
     
     \ /
      Last update: 2018-09-10 23:18    [W:5.777 / U:0.056 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site