From: Andy Lutomirski <luto@amacapital.net>
To: Dave Hansen <dave.hansen@linux.intel.com>
Cc: linux-kernel@vger.kernel.org, sean.j.christopherson@intel.com,
peterz@infradead.org, tglx@linutronix.de, x86@kernel.org,
luto@kernel.org
Subject: Re: [RFC][PATCH 1/8] x86/mm: clarify hardware vs. software "error_code"
Date: Fri, 7 Sep 2018 15:48:18 -0700 [thread overview]
Message-ID: <561334F6-9C13-424A-95ED-D377CE48DA46@amacapital.net> (raw)
In-Reply-To: <20180907194854.74729D71@viggo.jf.intel.com>
> On Sep 7, 2018, at 12:48 PM, Dave Hansen <dave.hansen@linux.intel.com> wrote:
>
>
> From: Dave Hansen <dave.hansen@linux.intel.com>
>
> We pass around a variable called "error_code" all around the page
> fault code. Sounds simple enough, especially since "error_code" looks
> like it exactly matches the values that the hardware gives us on the
> stack to report the page fault error code (PFEC in SDM parlance).
>
> But, that's not how it works.
>
> 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’m also unconvinced that the warning is terribly useful. We’re going to oops when this happens anyway.
I’ll rebase my diagnostic patch on top of this series after it settles.
next prev parent reply other threads:[~2018-09-07 22:48 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-07 19:48 [RFC][PATCH 0/8] x86/mm: page fault handling cleanups Dave Hansen
2018-09-07 19:48 ` [RFC][PATCH 1/8] x86/mm: clarify hardware vs. software "error_code" Dave Hansen
2018-09-07 22:48 ` Andy Lutomirski [this message]
2018-09-10 20:07 ` Dave Hansen
2018-09-10 21:17 ` Andy Lutomirski
2018-09-07 19:48 ` [RFC][PATCH 2/8] x86/mm: break out kernel address space handling Dave Hansen
2018-09-07 21:06 ` Sean Christopherson
2018-09-07 21:51 ` Dave Hansen
2018-09-07 22:21 ` Andy Lutomirski
2018-09-07 22:37 ` Dave Hansen
2018-09-07 19:48 ` [RFC][PATCH 3/8] x86/mm: break out user " Dave Hansen
2018-09-08 9:38 ` Peter Zijlstra
2018-09-10 20:20 ` Dave Hansen
2018-09-07 19:48 ` [RFC][PATCH 4/8] x86/mm: add clarifying comments for user addr space Dave Hansen
2018-09-07 19:49 ` [RFC][PATCH 5/8] x86/mm: fix exception table comments Dave Hansen
2018-09-07 21:04 ` Sean Christopherson
2018-09-07 21:51 ` Dave Hansen
2018-09-10 20:43 ` Sean Christopherson
2018-09-08 0:37 ` Jann Horn
2018-09-07 19:49 ` [RFC][PATCH 6/8] x86/mm: add vsyscall address helper Dave Hansen
2018-09-08 0:46 ` Jann Horn
2018-09-07 19:49 ` [RFC][PATCH 7/8] x86/mm/vsyscall: consider vsyscall page part of user address space Dave Hansen
2018-09-07 22:58 ` Andy Lutomirski
2018-09-08 1:16 ` Jann Horn
2018-09-07 19:49 ` [RFC][PATCH 8/8] x86/mm: remove spurious fault pkey check 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=561334F6-9C13-424A-95ED-D377CE48DA46@amacapital.net \
--to=luto@amacapital.net \
--cc=dave.hansen@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=peterz@infradead.org \
--cc=sean.j.christopherson@intel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).