Messages in this thread | | | Subject | Re: [RFC 1/3] softirq: Use preempt_latency_stop/start to trace preemption | From | Daniel Bristot de Oliveira <> | Date | Tue, 4 Jun 2019 12:39:03 +0200 |
| |
On 29/05/2019 14:22, Steven Rostedt wrote: > On Wed, 29 May 2019 05:30:56 -0400 > Joel Fernandes <joel@joelfernandes.org> wrote: > >> Yes, I think so. Also this patch changes CALLER_ADDR0 passed to the >> tracepoint because there's one more level of a non-inlined function call >> in the call chain right? Very least the changelog should document this >> change in functional behavior, IMO.
In practice I am seeing no change in the values printed, but there is another problem with this regard: there are cases in which both caller and parent have the same address.
I am quite sure it has to do with the in_lock_function() behavior. Anyway, I was already planing to propose a cleanup in the in_lock_function/in_sched_function. I will investigate it more.
> This sounds more like a break in behavior not a functional change. I > guess moving it to a header and making it a static __always_inline > should be fine though.
Steve, which header should I use?
Thanks!
-- Daniel
> -- Steve >
| |