From mboxrd@z Thu Jan  1 00:00:00 1970
From: Dave Hansen <dave.hansen@linux.intel.com>
Subject: Re: [PATCH 05/11] x86/fpu: set PKRU state for kernel threads
Date: Fri, 19 Oct 2018 11:26:19 -0700
Message-ID: <970783e5-0406-b605-6524-43c7e9218f2d@linux.intel.com>
References: <20181004140547.13014-1-bigeasy@linutronix.de>
 <20181004140547.13014-6-bigeasy@linutronix.de>
 <39e0a55f-4920-cfde-9bef-09c51109d211@linux.intel.com>
 <CALCETrUdxsFA5g0M9uRFktfdi=mxK_g3kBfs-VxwDZ0xWqjFAQ@mail.gmail.com>
 <20181018162644.qqjkzoqn2fleyi2b@linutronix.de>
 <CC7B46F7-7A6E-4CAF-A1EB-91271CC7B092@amacapital.net>
 <20181018182538.vgotfpsdy7qxl2tg@linutronix.de>
 <CALCETrVjEOkNhdyAF10PaYi_rnFUWKRqPhLRCq3ZV=gxQFETxg@mail.gmail.com>
 <2fe82232-4e80-8317-757c-d2235c4633d8@redhat.com>
 <9BAD5065-AA1B-4DEF-A9D4-D7FD9B46667E@amacapital.net>
 <9c5ed364-4282-7dd3-f614-4e62632d81aa@linux.intel.com>
 <4CCD6641-4CCC-485A-BDD9-50751C4139B0@amacapital.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Cc: Paolo Bonzini <pbonzini@redhat.com>,
        Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
        Andrew Lutomirski <luto@kernel.org>,
        LKML <linux-kernel@vger.kernel.org>, X86 ML <x86@kernel.org>,
        Radim Krcmar <rkrcmar@redhat.com>,
        kvm list <kvm@vger.kernel.org>,
        "Jason A. Donenfeld" <Jason@zx2c4.com>,
        Rik van Riel <riel@surriel.com>
To: Andy Lutomirski <luto@amacapital.net>
Return-path: <linux-kernel-owner@vger.kernel.org>
In-Reply-To: <4CCD6641-4CCC-485A-BDD9-50751C4139B0@amacapital.net>
Content-Language: en-US
Sender: linux-kernel-owner@vger.kernel.org
List-Id: kvm.vger.kernel.org

On 10/19/2018 10:37 AM, Andy Lutomirski wrote:
>> I think it's much more straightforward to just not enforce pkeys. 
>> Having this "phantom" value could cause a very odd, nearly
>> undebuggable I/O failure.
> But now we have the reverse. The IO can work if it’s truly async but,
> if the kernel decides to synchronously complete IO (with GUP or
> copy_to_user), it’ll fail, right. This isn’t exactly friendly
> either.

Yeah, but a synchronous I/O failure is really straightforward to debug
because you get an immediate error message about it.  This is certainly
not the weirdest behavior or asymmetry that we would see from
synchronous vs. async I/O.