Messages in this thread | | | Date | Mon, 21 Oct 2019 11:01:04 +0200 | From | Ingo Molnar <> | Subject | Re: [PATCH v4 10/16] x86/alternative: Shrink text_poke_loc |
| |
* Peter Zijlstra <peterz@infradead.org> wrote:
> Employ the fact that all text must be within a s32 displacement of one > another to shrink the text_poke_loc::addr field. Make it relative to > _stext. > > This then shrinks struct text_poke_loc to 16 bytes, and consequently > increases TP_VEC_MAX from 170 to 256. > > Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> > --- > arch/x86/kernel/alternative.c | 23 ++++++++++++++--------- > 1 file changed, 14 insertions(+), 9 deletions(-) > > --- a/arch/x86/kernel/alternative.c > +++ b/arch/x86/kernel/alternative.c > @@ -937,7 +937,7 @@ static void do_sync_core(void *info) > } > > struct text_poke_loc { > - void *addr; > + s32 rel_addr; /* addr := _stext + rel_addr */ > s32 rel32; > u8 opcode; > const u8 text[POKE_MAX_OPCODE_SIZE]; > @@ -948,13 +948,18 @@ static struct bp_patching_desc { > int nr_entries; > } bp_patching; > > +static inline void *text_poke_addr(struct text_poke_loc *tp) > +{ > + return _stext + tp->rel_addr; > +}
So won't this complicate the life of the big-address-space gcc model build patches that for purposes of module randomization are spreading the kernel and modules all across the 64-bit address space, where they might not necessarily end up within a ~2GB window?
Nothing upstream yet, but I remember such patches ...
Thanks,
Ingo
| |