linux-kernel - Re: linux-next: build warnings after merge of the tip tree

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

Message-Id: <20220323152840.cb6295ec547f50d3ec34f02a@kernel.org>
Date:   Wed, 23 Mar 2022 15:28:40 +0900
From:   Masami Hiramatsu <mhiramat@...nel.org>
To:     Steven Rostedt <rostedt@...dmis.org>
Cc:     Peter Zijlstra <peterz@...radead.org>,
        Stephen Rothwell <sfr@...b.auug.org.au>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>,
        "H. Peter Anvin" <hpa@...or.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Linux Next Mailing List <linux-next@...r.kernel.org>,
        ast@...nel.org, hjl.tools@...il.com, rick.p.edgecombe@...el.com,
        rppt@...nel.org, linux-toolchains@...r.kernel.org,
        Andrew.Cooper3@...rix.com, ndesaulniers@...gle.com
Subject: Re: linux-next: build warnings after merge of the tip tree

On Tue, 22 Mar 2022 22:42:36 -0400
Steven Rostedt <rostedt@...dmis.org> wrote:

> On Wed, 23 Mar 2022 11:23:23 +0900
> Masami Hiramatsu <mhiramat@...nel.org> wrote:
> 
> > I see the __fexit__ is needed, but why __ftail__ is needed? I guess because
> > func_B is notrace, in that case the __fexit__ will not be in the func_B.
> > Am I correct?
> 
> I believe Peter and I agreed that the "best" solution so far, that has the
> least amount of regressions (doesn't remove anything currently being
> function graph traced, nor removes current tail calls) is:
> 
> > At that point giving us something like:
> > 
> > 1:
> > 	pushsection __ftail_loc
> > 	.long	1b - .
> > 	popsection
> > 
> > 	jmp.d32	func_B
> > 	call	__fexit__
> > 	ret
> 
> 
> Functions with a tail call will not have a __fexit__ and we can not rely on
> the function that is the tail call to do the __fexit__ for the parent
> function. Thus, the compromise is to add a label where the jmp to the
> tail-call function is, and when we want to trace the return of that
> function, we first have to patch the jmp into a call, which will then
> return back to the call to __fexit__.

Got it. So the tail call "jump" will be replaced with a normal call when
we trace it.

That's a good idea :) 


> 
> -- Steve


-- 
Masami Hiramatsu <mhiramat@...nel.org>