[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190412172730.ru6bukxcepwbiklp@linutronix.de>
Date: Fri, 12 Apr 2019 19:27:30 +0200
From: Sebastian Andrzej Siewior <bigeasy@...utronix.de>
To: Borislav Petkov <bp@...en8.de>
Cc: linux-kernel@...r.kernel.org, x86@...nel.org,
Andy Lutomirski <luto@...nel.org>,
Paolo Bonzini <pbonzini@...hat.com>,
Radim Krčmář <rkrcmar@...hat.com>,
kvm@...r.kernel.org, "Jason A. Donenfeld" <Jason@...c4.com>,
Rik van Riel <riel@...riel.com>,
Dave Hansen <dave.hansen@...ux.intel.com>
Subject: Re: [PATCH 24/27] x86/fpu: Add a fastpath to __fpu__restore_sig()
On 2019-04-12 19:17:59 [+0200], Borislav Petkov wrote:
> > @@ -327,7 +327,19 @@ static int __fpu__restore_sig(void __user *buf, void __user *buf_fx, int size)
> > if (ret)
> > goto err_out;
> > envp = &env;
> > + } else {
>
> I've added here:
I would suggest to add it in the last patch once we have the complete
fast path. The other one extended (in case you want to add a comment
there, too).
> + /*
/**
> + * Attempt to restore the FPU registers directly from user
> + * memory. For that to succeed, the user accesses cannot cause
I would say "user access" because it is always a single instruction.
> + * page faults. If they do, fall back to the slow path below,
> + * going through the kernel buffer.
"with the enabled page fault handler".
> + */
>
> so that it is clear what's happening.
>
> This function is doing gazillion things again ;-\
It is the old code with disabled page fault handler. But I understand.
Sebastian
Powered by blists - more mailing lists