On Fri, 15 Oct 2021 17:12:26 +0800 王贇 <yun.wang@xxxxxxxxxxxxxxxxx> wrote: > Maybe take some example would be easier to understand... > > Currently there are two way of using ftrace_test_recursion_trylock(), > one with TRACE_FTRACE_XXX we mark as A, one with TRACE_LIST_XXX we mark > as B, then: > > A followed by B on same context got bit > 0 > B followed by A on any context got bit 0 > A followed by A on same context got bit > 0 > A followed by A followed by A on same context got bit -1 > B followed by B on same context got bit > 0 > B followed by B followed by B on same context got bit -1 > > If we get rid of the TRACE_TRANSITION_BIT which allowed recursion for > onetime, then it would be: We can't get rid of the transition bit. It's there to fix a bug. Or at least until we finish the "noinst" issue which may be true now? I have to go revisit it. The reason for the transition bit, is because we were dropping function traces, that people relied on being there. The problem is that the recursion protection allows for nested context. That is, it will not detect recursion if we an interrupt triggers during a trace (while the recursion lock is held) and then that interrupt does a trace. It is allowed to call the ftrace_test_recursion_trylock() again. But, what happens if the trace occurs after the interrupt triggers, but before the preempt_count states that we are now in interrupt context? As preempt_count is used by this code to determine what context we are in, if a trace happens in this "transition" state, without the transition bit, a recursion is detected (false positive) and the event is dropped. People are then confused on how an interrupt happened, but the entry of the interrupt never triggered (according to the trace). The transition bit allows one level of recursion to handle this case. The "noinst" work may also remove all locations that can be traced before the context is updated. I need to see if that is now the case, and if it is, we can remove the transition bit. This is not the design issue I mentioned earlier. I'm still working on that one. -- Steve > > A followed by B on same context got bit > 0 > B followed by A on any context got bit 0 > A followed by A on same context got bit -1 > B followed by B on same context got bit -1 > > So as long as no continuously AAA it's safe?
