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 for Android: free password hash cracker in your pocket

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

Message-ID: <20110429151509.GA2545@redhat.com>
Date:	Fri, 29 Apr 2011 11:15:09 -0400
From:	Jason Baron <jbaron@...hat.com>
To:	Jiri Olsa <jolsa@...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 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?

Thanks,

-Jason
--
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/