linux-kernel - Re: [PATCH -v2 00/49] Simplify, reorganize and clean up the x86 text-patching code (alternative.c)

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: <Z_bdxrahsyB5wrg8@gmail.com>
Date: Wed, 9 Apr 2025 22:51:18 +0200
From: Ingo Molnar <mingo@...nel.org>
To: Peter Zijlstra <peterz@...radead.org>
Cc: linux-kernel@...r.kernel.org, Juergen Gross <jgross@...e.com>,
	"H . Peter Anvin" <hpa@...or.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Borislav Petkov <bp@...en8.de>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH -v2 00/49] Simplify, reorganize and clean up the x86
 text-patching code (alternative.c)


* Peter Zijlstra <peterz@...radead.org> wrote:

> On Fri, Mar 28, 2025 at 02:26:15PM +0100, Ingo Molnar wrote:
> > This series has 3 main parts:
> > 
> > (1)
> > 
> > The first part of this series performs a thorough text-patching API namespace
> > cleanup discussed with Linus for the -v1 series:
> > 
> > 	# boot/UP APIs & single-thread helpers:
> > 
> > 						text_poke()
> > 						text_poke_kgdb()
> > 	[ unchanged APIs: ]			text_poke_copy()
> > 						text_poke_copy_locked()
> > 						text_poke_set()
> > 
> > 						text_poke_addr()
> > 
> > 	# SMP API & helpers namespace:
> > 
> > 	text_poke_bp()			=>	smp_text_poke_single()
> > 	text_poke_loc_init()		=>	__smp_text_poke_batch_add()
> > 	text_poke_queue()		=>	smp_text_poke_batch_add()
> > 	text_poke_finish()		=>	smp_text_poke_batch_finish()
> > 
> > 	text_poke_flush()		=>	[removed]
> > 
> > 	text_poke_bp_batch()		=>	smp_text_poke_batch_process()
> > 	poke_int3_handler()		=>	smp_text_poke_int3_trap_handler()
> >         text_poke_sync()		=>	smp_text_poke_sync_each_cpu()
> > 
> 
> Not sure I like that; smp_text_poke_ is a bit of a mouth full, esp. if
> you're then adding even more text.
> 
> Do we really need function names this long?

So they are still shorter than:

    perf_scope_cpu_topology_cpumask()
    perf_swevent_put_recursion_context() 
    perf_event_max_sample_rate_handler() 
    perf_unregister_guest_info_callbacks()

;-)

I think we could trim the longest one via:

  s/smp_text_poke_int3_trap_handler
   /smp_text_poke_int3_handler

Because 'INT3 handler' is more than specific enough?

But in general, function name length is less critical for 'complex', 
non-library APIs that are called in a pretty flat fashion, especially 
if they have no error returns.

Here's how they are used today, after the rename:

	smp_text_poke_sync_each_cpu();
		smp_text_poke_sync_each_cpu();
		smp_text_poke_sync_each_cpu();
		smp_text_poke_batch_finish();
	__smp_text_poke_batch_add(addr, opcode, len, emulate);
	__smp_text_poke_batch_add(addr, opcode, len, emulate);
	smp_text_poke_batch_finish();
	smp_text_poke_batch_finish();
		smp_text_poke_batch_add((void *)ip, new_code, MCOUNT_INSN_SIZE, NULL);
	smp_text_poke_single((void *)ip, new, MCOUNT_INSN_SIZE, NULL);
	smp_text_poke_single((void *)ip, new, MCOUNT_INSN_SIZE, NULL);
		smp_text_poke_batch_add((void *)rec->ip, new, MCOUNT_INSN_SIZE, NULL);
	smp_text_poke_batch_finish();
	smp_text_poke_single((void *)ip, new, MCOUNT_INSN_SIZE, NULL);
	smp_text_poke_single((void *)ip, new, MCOUNT_INSN_SIZE, NULL);
	smp_text_poke_single((void *)jump_entry_code(entry), jlp.code, jlp.size, NULL);
	smp_text_poke_batch_add((void *)jump_entry_code(entry), jlp.code, jlp.size, NULL);
	smp_text_poke_batch_finish();
	smp_text_poke_sync_each_cpu();
	smp_text_poke_sync_each_cpu();
		smp_text_poke_single(op->kp.addr, insn_buff, JMP32_INSN_SIZE, NULL);
	smp_text_poke_sync_each_cpu();
	smp_text_poke_sync_each_cpu();
		smp_text_poke_sync_each_cpu();
	smp_text_poke_single(insn, code, size, emulate);
		smp_text_poke_single(ip, new_insn, X86_PATCH_SIZE, NULL);

Note how there's no error return, no conditionals, just flat calls.

And note how easy it was to do a 'git grep smp_text_poke_' to get such 
an overview. ;-)

Anyway, any other suggestions for shorter names, or can I proceed with 
these plus the above shortening of the trap handler name?

Thanks,

	Ingo