Re: [RFC PATCH 2/7] static_call: deal with unexported keys without cluttering up the API

[Peter Zijlstra]

On Tue, Nov 09, 2021 at 07:53:33PM +0100, Ard Biesheuvel wrote:
> On Tue, 9 Nov 2021 at 19:49, Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote:
> >
> > On Tue, Nov 09, 2021 at 05:45:44PM +0100, Ard Biesheuvel wrote:
> >
> > > diff --git a/include/linux/static_call_types.h b/include/linux/static_call_types.h
> > > index 5a00b8b2cf9f..0bb36294cce7 100644
> > > --- a/include/linux/static_call_types.h
> > > +++ b/include/linux/static_call_types.h
> > > @@ -32,15 +32,20 @@
> > >  struct static_call_site {
> > >       s32 addr;
> > >       s32 key;
> > > +     s32 tramp;
> > >  };
> >
> > I can't say I'm thrilled at growing this thing, but the cleanup is nice.
> > Perhaps we can increase alignment on struct static_call_key and instead
> > frob it in .key still?
> >
> 
> This is already a place-relative field, and one points into the data
> section and the other into text. So I don't see how we can squeeze
> enough bits out of it to make this fit.

Well, the actual address will be:

	((unsigned long)&site->key + site->key)

either way around, right? Now, if we align struct static_call_key to 8,
that means the low 3 bits of that address will be 0 and free for us to
muck about with.

That is, we already use the low 2 bits of that (because natural
alignment etc.).

If we got 3 bits, we could shift the existing two bits one up and free
up bit0, then say that if bit0 is set, it's a trampoline address. The
only additional requirement would be that trampolines are (at least)
aligned 2 (they're at 4 currently).

Except.... it would be the linker having to create that field, and
there's no way that thing is smart like that :-( Ooh well.