On Thu, Oct 4, 2018 at 12:33 PM H. Peter Anvin <h...@zytor.com> wrote: > > On 10/04/18 02:16, Ingo Molnar wrote: > > > > * h...@zytor.com <h...@zytor.com> wrote: > > > >> Ingo: I wasn't talking necessarily about the specifics of each bit, but > >> rather the general > >> concept about being able to use macros in inlines... > > > > Ok, agreed about that part - and some of the patches did improve > > readability. > > > > Also, the 275 lines macros.s is a lot nicer than the 4,200 lines macros.S. > > > > Also, I'm not against using workarounds when the benefits are larger than > > the costs, but I am > > against *hiding* the fact that these are workarounds and that for some of > > them there are costs. > > > > Agreed, of course. > > >> I can send you something I have been working on in the background, but > >> have been holding off > >> on because of this, in the morning my time. > > > > BTW., I have applied most of the series to tip:x86/kbuild already, and will > > push them out later > > today after some testing. I didn't apply the final 3 patches as they have > > dependencies, but > > applied the basics and fixed up the changelogs. > > > > So you can rely on this. > > > > Wonderful. > > Here is the horrible code I mentioned yesterday. This is about > implementing the immediate-patching framework that Linus and others have > discussed (it helps both performance and kernel hardening): >
I'm wondering if a production version should look more like: patch_point: mov $whatever, [target] .pushsection ".immediate_patches" .quad .Lpatch_point .popsection and let objtool parse the resulting assembled output and emit an entry in some table mapping patch_point to the actual address and size of the immediate to be patched.
