linux-kernel - Re: [PATCH] jump_label,x86: use text_poke_smp

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]

Message-ID: <20110429153739.GB1966@jolsa.brq.redhat.com>
Date:	Fri, 29 Apr 2011 17:37:39 +0200
From:	Jiri Olsa <jolsa@...hat.com>
To:	Jason Baron <jbaron@...hat.com>
Cc:	rostedt@...dmis.org, mingo@...e.hu, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] jump_label,x86: use text_poke_smp_batch for entries
 update

On Fri, Apr 29, 2011 at 11:15:09AM -0400, Jason Baron wrote:
> On Thu, Apr 28, 2011 at 10:52:41PM +0200, Jiri Olsa wrote:
> > Changing the jump label update code to use batch processing
> > for x86 architectures. 
> > 
> > Currently each jump label update calls text_poke_smp for each
> > jump label key entry. Thus one key update ends up calling stop
> > machine multiple times.
> > 
> 
> cool. Batching the updates is a nice idea.
> 
> > This patch is using text_poke_smp_batch, which is called for
> > all the key's entries.  Ensuring the stop machine is called
> > only once.
> > 
> 
> Since we walk the modules list per key (calling __jump_label_update()),
> this is not always the case. I'm wondering then if maybe what we want to do
> is 'queue' each update from the core code. Then, when the queue fills
> up, we flush out the queue. In this way, we cover jump labels that might
> be in both the core kernel and in modules. This also has the side effect
> of moving code such as:
> 
> /*
>  * The entry->code set to 0 invalidates module
>  * init text
>  * sections (see
>  * jump_label_invalidate_module_init).
>  */
> if (!entry->code || !kernel_text_address(entry->code))
>               continue;
> 
> 
> out of the arch code into the generic code, which in my opinion is a bit
> cleaner. thoughts?

nice, we'd safe another few stop machine calls
I'll update the patch

thanks,
jirka
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/