linux-kernel - Re: [PATCH v6 15/17] static

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 14 Jul 2020 10:16:36 -0400
From:   Steven Rostedt <rostedt@...dmis.org>
To:     Peter Zijlstra <peterz@...radead.org>
Cc:     x86@...nel.org, linux-kernel@...r.kernel.org, mhiramat@...nel.org,
        bristot@...hat.com, jbaron@...mai.com,
        torvalds@...ux-foundation.org, tglx@...utronix.de,
        mingo@...nel.org, namit@...are.com, hpa@...or.com, luto@...nel.org,
        ard.biesheuvel@...aro.org, jpoimboe@...hat.com,
        pbonzini@...hat.com, mathieu.desnoyers@...icios.com,
        linux@...musvillemoes.dk
Subject: Re: [PATCH v6 15/17] static_call: Allow early init

On Tue, 14 Jul 2020 11:51:17 +0200
Peter Zijlstra <peterz@...radead.org> wrote:

> On Mon, Jul 13, 2020 at 04:24:19PM -0400, Steven Rostedt wrote:
> > On Sat, 11 Jul 2020 07:08:31 +0200
> > Peter Zijlstra <peterz@...radead.org> wrote:
> >   
> > > On Fri, Jul 10, 2020 at 09:14:26PM -0400, Steven Rostedt wrote:  
> > > > On Fri, 10 Jul 2020 15:38:46 +0200
> > > > Peter Zijlstra <peterz@...radead.org> wrote:
> > > >     
> > > > > In order to use static_call() to wire up x86_pmu, we need to
> > > > > initialize earlier; copy some of the tricks from jump_label to enable
> > > > > this.
> > > > > 
> > > > > Primarily we overload key->next to store a sites pointer when there
> > > > > are no modules, this avoids having to use kmalloc() to initialize the
> > > > > sites and allows us to run much earlier.
> > > > >     
> > > > 
> > > > I'm confused. What was the need to have key->next store site pointers
> > > > in order to move it up earlier?    
> > > 
> > > The critical part was to not need an allocation.  
> > 
> > Why is an allocation needed? What's different about calling it early
> > that we need an allocation or this trick?
> > 
> > The two paragraphs above seem totally disconnected.
> > 
> > "In order to use static_call() to wire up x86_pmu, we need to
> > initialize earlier; copy some of the tricks from jump_label to enable
> > this."
> > 
> > What tricks were copied?
> > 
> > "Primarily we overload key->next to store a sites pointer when there  
> 
> ^^ this trick...
> 
> +	union {
> +		/* bit 0: 0 = mods, 1 = sites */
> +		unsigned long type;
> +		struct static_call_mod *mods;
> +		struct static_call_site *sites;
> +	};
> 
> If that isn't a trick, I don't know ;-)

Ah, that makes more sense. The way it was worded didn't quite put 2 and
2 together like that.

> 
> > are no modules, this avoids having to use kmalloc() to initialize the
> > sites and allows us to run much earlier."
> > 
> > Why is kmalloc() (or this trick) needed to initialize the sites?  
> 
> That's just how the code was; it treated vmlinux as the NULL module, and
> as such needed a static_call_mod allocated to host the static_call_sites
> pointer.
> 
> That is, the static_call_key has a single linked list pointer to
> static_call_mod, and every module has an entry on that list with a
> pointer to their sites. Very simple and straight forward.
> 
> Except it requires an allocation to set up, which is a pain is you want
> it initialized very early.

OK, I'm still missing something, but having a hard time explaining
exactly what that is. ;-)

I guess that is, why did moving the initialization early require an
allocation where initializing it later did not? What allocation are we
avoiding?

I'm not seeing why this trick is needed when we moved the init early as
compared to doing the same thing later on.

Is it this?

> @@ -192,16 +222,35 @@ static int __static_call_init(struct mod
>                 if (key != prev_key) {
>                         prev_key = key;
>  
> +                       if (!mod) {
> +                               key->sites = site;
> +                               key->type |= 1;
> +                               goto do_transform;
> +                       }
> +

We want to avoid calling kzalloc() early?

If so, this should have a comment here stating so and why.

>                         site_mod = kzalloc(sizeof(*site_mod), GFP_KERNEL);
>                         if (!site_mod)
>                                 return -ENOMEM;

-- Steve