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

Date:   Tue, 22 Mar 2022 08:54:55 +0100
From:   Peter Zijlstra <peterz@...radead.org>
To:     Steven Rostedt <rostedt@...dmis.org>
Cc:     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>,
        mhiramat@...nel.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 Mon, Mar 21, 2022 at 12:54:19PM -0400, Steven Rostedt wrote:
> On Mon, 21 Mar 2022 17:50:50 +0100
> Peter Zijlstra <peterz@...radead.org> wrote:
> 
> > > This also assumes that we need to trace everything that is marked. I
> > > mentioned in another email, what do we do if we only trace funcA?  
> > 
> > Like I said later on; if we inhibit tail-calls to notrace, this goes
> > away.
> 
> Please no. The number of "notrace" functions is increasing to the point
> that it's starting to make function tracing useless in a lot of
> circumstances. I've already lost my ability to see when user space goes
> into the kernel (which I have to hack up custom coding to enable again).

I really can't follow the argument there, nor on IRC.

Suppose:

notrace func_B()
{
	...
}

func_A()
{
	...
	return func_B();
}

then inhibiting tail calls would end up looking like:

func_A:
	call __fentry__
	...
	call func_B
	call __fexit__
	ret

Then A is fully traced, B is invisible, as per spec. What is the
problem?

The problem you initially had, of doing a tail-call into a notrace, was
that the __fexit__ call went missing, because notrace will obviously not
have that. But that's avoided by inhibiting all tail-calls between
notrace and !notrace functions (note that notrace must also not
tail-call !notrace).

Your worry seems to stem about loosing visiblilty of !notrace functions,
but AFAICT that doesn't happen.