Messages in this thread | | | Subject | Re: [RFC][PATCH 1/8] x86/mm: clarify hardware vs. software "error_code" | From | Andy Lutomirski <> | Date | Mon, 10 Sep 2018 14:17:56 -0700 |
| |
> 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.
| |