Messages in this thread | | | Date | Tue, 22 Mar 2022 08:54:55 +0100 | From | Peter Zijlstra <> | 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@infradead.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.
| |