linux-kernel - [PATCHv2 0/2] jump_label,x86: make batch update of jump

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:	Wed,  4 May 2011 11:41:41 +0200
From:	Jiri Olsa <jolsa@...hat.com>
To:	jbaron@...hat.com, rostedt@...dmis.org, mingo@...e.hu
Cc:	linux-kernel@...r.kernel.org
Subject: [PATCHv2 0/2] jump_label,x86: make batch update of jump_label entries

hi,

I'm 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.

This patch is using text_poke_smp_batch, which is called for
all the key's entries. Thus ensuring the stop machine is called
only once per jump_label key.

attached patches:
1/2 - jump_label,x86: use text_poke_smp_batch for entries update
	- added jump_label_update_end function which is paired with
	the key's entries update
	- jump_label_update_end calls arch_jump_label_update_end which
	is overloaded by x86 arch and makes the batch update of all the
	entries queued by arch_jump_label_transform function.

2/2 - jump_label,x86: using static arrays before dynamic allocation is needed
	- in the first patch, the queue array, which stores jump_label
	entries is allocated/resized dynamically.
	- due to the fact that many jump_label entries have low number
	of callers, it seems appropriate to use static sized array
	when the update starts and if needed (in case of high number
	of jump_label entries) allocate/use the dynamic array


Patch 2/2 and could be ommited if the benefit/complexity ratio
would seem too low.. ;)

I tested this on x86 and s390 archs.

v2 changes:
 - queueing all entries for single key and process them
   all at one time

wrb,
jirka
---
 arch/x86/kernel/jump_label.c |  177 +++++++++++++++++++++++++++++++++++++++--
 include/linux/jump_label.h   |    1 +
 kernel/jump_label.c          |   16 ++++-
 3 files changed, 183 insertions(+), 11 deletions(-)
--
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/