Re: [PATCH] x86/xsave: Robustify and merge macros
From: Quentin Casasnovas
Date: Fri Apr 03 2015 - 16:40:45 EST
On Fri, Apr 03, 2015 at 07:48:24PM +0200, Borislav Petkov wrote:
> On Fri, Apr 03, 2015 at 07:33:06PM +0200, Quentin Casasnovas wrote:
> > > Basically, the idea was:
> > >
> > > .skip len(repl1) - len(orig), 0x90
> > > .skip len(repl2) - len(repl1), 0x90
> > >
> > > BUT!, for some reason I changed it to what's there now and I can't
> > > remember why anymore.
> > I think it would not work in the case where repl1 is smaller or equal than
> > orig_insn (i.e. no padding in the first .skip) but orig_insn is strictly
> > smaller than repl2 (since we're never comparing repl2 with insn in this
> > new-old code).
> .skip 0, 0x90
> .skip 2, 0x90
> I think that still works, only the padding is larger than it needs to
> be. And it is so many bytes larger as len(abs(repl1 - orig_insn)) is.
> In the example above, we'll get two bytes padding while only 1 suffices.
> > Anything wrong with the two different approaches I've suggested in my
> > original mail?
> Right now, I want to have a minimal fix for obvious reasons. We can
> always improve stuff later when there's more time.
If you're happy with the extra padding in such cases then your second
approach looks okay to me. But IMO, even if taking the '.if' directive
approach is certainly bigger LOC-wise, it should be much easier to review
in a rush than some other .skip trickery.
It all depends on your definition of minimal change really, and whether
that extra padding is acceptable or not for you :)
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/