[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <9BAD5065-AA1B-4DEF-A9D4-D7FD9B46667E@amacapital.net>
Date: Fri, 19 Oct 2018 09:59:00 -0700
From: Andy Lutomirski <luto@...capital.net>
To: Paolo Bonzini <pbonzini@...hat.com>
Cc: Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
Andrew Lutomirski <luto@...nel.org>,
Dave Hansen <dave.hansen@...ux.intel.com>,
LKML <linux-kernel@...r.kernel.org>, X86 ML <x86@...nel.org>,
Radim Krcmar <rkrcmar@...hat.com>,
kvm list <kvm@...r.kernel.org>,
"Jason A. Donenfeld" <Jason@...c4.com>,
Rik van Riel <riel@...riel.com>
Subject: Re: [PATCH 05/11] x86/fpu: set PKRU state for kernel threads
> On Oct 19, 2018, at 12:44 AM, Paolo Bonzini <pbonzini@...hat.com> wrote:
>
> On 18/10/2018 22:46, Andy Lutomirski wrote:
>>> [0] drivers/usb/gadget/function/f_fs.c::ffs_user_copy_worker()
>>>
>>> Sebastian
>> I think we need an entirely new API:
>>
>> user_mm_ctx_t ctx = user_mm_ctx_get();
>>
>> ...
>>
>> use_user_mm_ctx(ctx);
>> unuse_user_mm_ctx(ctx);
>>
>> ...
>>
>> user_mm_ctx_put(ctx);
>>
>> and ctx will store a copy of mm and PKRU.
>>
>
> That looks like a good API in general. The ffs_user_copy_worker that
> Sebastian mentioned seems to be used by AIO, in which case of course it
> has to happen in a kernel thread.
>
> But while the API is good, deciding on the desired semantics is
> "interesting". The submitting thread might be changing PKRU between the
> time the I/O operation is submitted and the time it is completed, for
> example.
I think there’s only one sensible answer: capture PKRU at the time of submission.
Powered by blists - more mailing lists