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] [day] [month] [year] [list]
Message-ID: <20251025191839.6907-1-qq570070308@gmail.com>
Date: Sun, 26 Oct 2025 03:18:39 +0800
From: Xie Yuanbin <qq570070308@...il.com>
To: riel@...riel.com,
	segher@...nel.crashing.org
Cc: acme@...nel.org,
	adrian.hunter@...el.com,
	agordeev@...ux.ibm.com,
	akpm@...ux-foundation.org,
	alex@...ti.fr,
	alexander.shishkin@...ux.intel.com,
	andreas@...sler.com,
	anna-maria@...utronix.de,
	aou@...s.berkeley.edu,
	borntraeger@...ux.ibm.com,
	bp@...en8.de,
	bsegall@...gle.com,
	dave.hansen@...ux.intel.com,
	davem@...emloft.net,
	david@...hat.com,
	dietmar.eggemann@....com,
	frederic@...nel.org,
	gor@...ux.ibm.com,
	hca@...ux.ibm.com,
	hpa@...or.com,
	irogers@...gle.com,
	jolsa@...nel.org,
	juri.lelli@...hat.com,
	linux-arm-kernel@...ts.infradead.org,
	linux-kernel@...r.kernel.org,
	linux-perf-users@...r.kernel.org,
	linux-riscv@...ts.infradead.org,
	linux-s390@...r.kernel.org,
	linux@...linux.org.uk,
	lorenzo.stoakes@...cle.com,
	luto@...nel.org,
	mark.rutland@....com,
	mathieu.desnoyers@...icios.com,
	max.kellermann@...os.com,
	mgorman@...e.de,
	mingo@...hat.com,
	namhyung@...nel.org,
	nysal@...ux.ibm.com,
	palmer@...belt.com,
	paulmck@...nel.org,
	peterz@...radead.org,
	pjw@...nel.org,
	qq570070308@...il.com,
	rostedt@...dmis.org,
	ryan.roberts@....com,
	sparclinux@...r.kernel.org,
	svens@...ux.ibm.com,
	tglx@...utronix.de,
	thuth@...hat.com,
	urezki@...il.com,
	vincent.guittot@...aro.org,
	vschneid@...hat.com,
	will@...nel.org,
	x86@...nel.org
Subject: Re: [PATCH 2/3] Provide and use an always inline version of finish_task_switch

On Fri, 24 Oct 2025 17:36:06 -0400, Rik van Riel wrote:
> Does that actually work, or does the compiler
> still inline some of those "non-inlined" versions,
> anyway?

For the current code, adding a new finish_task_switch_ainline function
and calling it has the same effect as directly changing the
finish_task_switch function attribute to __always_inline. This is because
there are only two references to the finish_task_switch function in
core.c. When one is inlined, the other becomes the only call point and it
must be inlined (unless the no-inline option/attribute is added or the
static attribute is removed). The uninlined finish_task_switch assembly
code will not exist.

However, if the call point of the finish_task_switch function in core.c is
increased in the future, as long as one point is added, a non inline
function will be generated and codesize revenue will be obtained.

Xie Yuanbin

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ