linux-kernel - [heads up] microblaze ftrace breakage since 60b1f578b578 "ftrace: Get the true parent ip for function tracer"

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>] [day] [month] [year] [list]

Message-ID: <20241204044342.GQ3387508@ZenIV>
Date: Wed, 4 Dec 2024 04:43:42 +0000
From: Al Viro <viro@...iv.linux.org.uk>
To: Steven Rostedt <rostedt@...dmis.org>
Cc: linux-trace-kernel@...r.kernel.org, Michal Simek <monstr@...str.eu>,
	linux-kernel@...r.kernel.org
Subject: [heads up] microblaze ftrace breakage since 60b1f578b578 "ftrace:
 Get the true parent ip for function tracer"

	For one thing, microblaze does *not* have kernel_stack_pointer(),
so defaults would not work there.  That leads to build breakage in
kernel/trace/trace_function.c since the commit in question.  Breakage is
trivial to reproduce - just enable FUNCTION_GRAPH_TRACER and try to
build the kernel...

	Moreover, unless I'm misreading their mcount.S, the registers saved
there are *NOT* in their pt_regs layout - the stored data is
	r15 (return address of _mcount())
	r2..r14
	r16..r31
and all of that is at r1 - 120, where r1 is the kernel stack pointer at the
time of _mcount() call.  So those defaults would be all wrong anyway.

	The last time I touched microblaze assembler had been a dozen years
ago, so I'd rather avoid trying to patch the things up there - not with
live microblaze maintainers around, TYVM...