Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Content-Type: text/plain;
        charset=utf-8
Mime-Version: 1.0 (1.0)
Subject: Re: [RFC][PATCH 1/8] x86/mm: clarify hardware vs. software "error_code"
From:   Andy Lutomirski <luto@amacapital.net>
In-Reply-To: <6f75823d-ce8b-d483-6046-4efbe20d0410@linux.intel.com>
Date:   Mon, 10 Sep 2018 14:17:56 -0700
Cc:     linux-kernel@vger.kernel.org, sean.j.christopherson@intel.com,
        peterz@infradead.org, tglx@linutronix.de, x86@kernel.org,
        luto@kernel.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <E480E807-701D-43C6-A0AF-DF7829A701BC@amacapital.net>
References: <20180907194852.3C351B82@viggo.jf.intel.com> <20180907194854.74729D71@viggo.jf.intel.com> <561334F6-9C13-424A-95ED-D377CE48DA46@amacapital.net> <6f75823d-ce8b-d483-6046-4efbe20d0410@linux.intel.com>
To:     Dave Hansen <dave.hansen@linux.intel.com>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk


> On Sep 10, 2018, at 1:07 PM, Dave Hansen <dave.hansen@linux.intel.com> wro=
te:
>=20
> On 09/07/2018 03:48 PM, Andy Lutomirski wrote:
>>>=20
>>> 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.
>>>=20
>>> 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.
>=20
> 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.
>=20
> 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.
>=20
> But, if we just said that
> 1. hw_error_code goes out to userspace, always, and

Nope, it=E2=80=99s an info leak. If the address is in kernel land (and not v=
syscall), 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.
>=20
>> I=E2=80=99m also unconvinced that the warning is terribly useful. We=E2=80=
=99re going
>> to oops when this happens anyway.
>=20
> 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.=