* Peter Zijlstra <[email protected]> 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) <[email protected]> > --- > 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
