Messages in this thread | | | Date | Tue, 9 Nov 2021 20:41:23 +0100 | From | Peter Zijlstra <> | Subject | Re: [RFC PATCH 2/7] static_call: deal with unexported keys without cluttering up the API |
| |
On Tue, Nov 09, 2021 at 07:53:33PM +0100, Ard Biesheuvel wrote: > On Tue, 9 Nov 2021 at 19:49, Peter Zijlstra <peterz@infradead.org> 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.
| |