[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CALOAHbCFWCzV6PQXkB7YyyPuLOZv27yABDADgbwi1F76pOzwVg@mail.gmail.com>
Date: Sun, 16 Apr 2023 10:42:48 +0800
From: Yafang Shao <laoar.shao@...il.com>
To: Steven Rostedt <rostedt@...dmis.org>
Cc: Alexei Starovoitov <ast@...nel.org>,
LKML <linux-kernel@...r.kernel.org>,
Linux trace kernel <linux-trace-kernel@...r.kernel.org>,
Masami Hiramatsu <mhiramat@...nel.org>,
Mark Rutland <mark.rutland@....com>, bpf <bpf@...r.kernel.org>
Subject: Re: [PATCH] tracing: Add generic test_recursion_try_acquire()
On Sat, Apr 15, 2023 at 11:46 PM Steven Rostedt <rostedt@...dmis.org> wrote:
>
> On Sat, 15 Apr 2023 22:33:17 +0800
> Yafang Shao <laoar.shao@...il.com> wrote:
>
> >
> > I don't have a clear idea why TRACE_CTX_TRANSITION must be needed, but
> > it seems we have to do below code for the fentry test case,
>
> The issue is that there's still cases that we can trace when
> preempt_count hasn't been updated to the new context. That is,
> preempt_count is used to determine if we are in softirq, hardirq or NMI
> context. But there's some places that have:
>
> normal context:
> func_a() --> traced
> --> interrupt
> func_b() --> traced
> preempt_count_add(HARDIRQ_OFFSET)
>
> Now we drop the second trace because it is flagged as a recursion when
> in reality it is in a new context, but the preempt_count has not been
> updated yet.
>
> We are currently fixing these locations, but it's not there yet. And
> since there's tools that relies on not dropping these locations, the
> transition bit needs to be there until this situation is dealt with.
>
Got it. Thanks for your explanation.
> Can you change the tests to allow a single recursion?
>
I think one single recursion should be acceptable. I will change it.
--
Regards
Yafang
Powered by blists - more mailing lists