[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YMikRd/nTEXqGwSd@zn.tnic>
Date: Tue, 15 Jun 2021 14:59:49 +0200
From: Borislav Petkov <bp@...e.de>
To: Thomas Gleixner <tglx@...utronix.de>
Cc: LKML <linux-kernel@...r.kernel.org>,
Andy Lutomirski <luto@...nel.org>,
Dave Hansen <dave.hansen@...ux.intel.com>,
Fenghua Yu <fenghua.yu@...el.com>,
Tony Luck <tony.luck@...el.com>,
Yu-cheng Yu <yu-cheng.yu@...el.com>,
Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
Peter Zijlstra <peterz@...radead.org>,
Kan Liang <kan.liang@...ux.intel.com>
Subject: Re: [patch V2 02/52] x86/fpu: Fix copy_xstate_to_kernel() gap
handling
On Tue, Jun 15, 2021 at 02:47:14PM +0200, Thomas Gleixner wrote:
> I'll never learn that. /me goes to write some elisp.
You could also say, this is a way to keep your reviewers awake. :-P
> Nah. The wonder of membug_write() is that it does not write behind the
membug - Freudian slip, yeah, I know which is the word you've been
writing the most, lately. :-P
> end of the buffer which is designed to allow partial reads w/o checking
> a gazillion times for return values etc.
Yeah, right. I'm just being overly paranoid here, as most of the time.
> The point is that this gives us the proper init.mxcsr value when SSE and
> YMM are not set.
Oh sure - what I mean is, this could be a simple assignment into those
mxcsr and mxcsr_mask things but if you add the whole conditional code
around it, it'll become hard to read too and it will be the only copy
which doesn't call copy_feature() and that would throw off people
looking for the same pattern of calling copy_feature() in that whole
function.
And the destination @to would need casting...
Fget about it. :-)
Thx.
--
Regards/Gruss,
Boris.
SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer, HRB 36809, AG Nürnberg
Powered by blists - more mailing lists