* Linus Torvalds <torva...@linux-foundation.org> wrote:
> On Sun, Nov 20, 2016 at 11:13 PM, Ingo Molnar <mi...@kernel.org> wrote:
> >
> > So I have applied your fix that addresses the worst fallout directly:
> >
> > fc0e81b2bea0 x86/traps: Ignore high word of regs->cs in
> > early_fixup_exception()
> >
> > ... but otherwise we might be better off zeroing out the high bits of
> > segment
> > registers stored on the stack, in all entry code pathways
>
> Ugh.
>
> I'd much rather we go back to just making the "cs" entry explicitly
> 16-bit, and have a separate padding entry, the way we used to long
> long ago.
>
> Or just rename it to something that you're not supposed to access
> directly, and a helper accessor function that masks off the high bits.
>
> The entry code-paths are *much* more critical than any of the few user
> codepaths.
Absolutely, no arguments about that!
> [...] Let's not add complexity to entry. Make the structure actually reflect
> reality instead.
So I have no problems at all with your suggestion either.
I am still trying to semi-defend my suggestion as well, because if we do what I
suggested:
> > [...] so that the function call is patched out on modern CPUs.
then it's essentially an opt-in quirk for really old CPUs and won't impact new
CPUs, other than a single NOP for the patched out bits - and not even that on
kernel builds with M686 or later or so ...
I.e. the quirk essentially implements what new CPUs do (in C), and then all
remaining code can just assume that all data is properly initialized/zeroed
like
on new CPUs and the effects of the quirk does not spread to data structures and
code that handles and copies around those data structures - unless I'm missing
something.
Thanks,
Ingo
