[PATCH] powernv: Avoid calling trace tlbie in kexec path.

Michael Ellerman mpe at ellerman.id.au
Fri Nov 24 17:10:09 AEDT 2017


Balbir Singh <bsingharora at gmail.com> writes:
> On Fri, Nov 24, 2017 at 12:11 AM, Naveen N. Rao
> <naveen.n.rao at linux.vnet.ibm.com> wrote:
>> Michael Ellerman wrote:
>>> Balbir Singh <bsingharora at gmail.com> writes:
...
>>>
>>>> I think the right thing in the longer run might be to do a
>>>> TRACE_EVENT_CONDITION
>>>> and have the condition do the right thing, but what you have for now is
>>>> good.
>>>
>>>
>>> No I think the right thing is to not call trace points from kexec code,
>>> it's too fragile. TRACE_EVENT_CONDITION wouldn't have saved us from this
>>> RCU breakage.
>>
>> I agree on the fragile part, though it appears to me that a
>> TRACE_EVENT_CONDITION() with a check for is_kexec (that needs to be added)
>> will prevent breakage since both the LOCKDEP block as well as the tracepoint
>> itself are guarded by the condition. So, none of the rcu code should be
>> executed as long as we set is_kexec at the right time.  However, since there
>> are all of 1 tracepoint(s) affecting kexec, it is probably not worth the
>> effort at the moment.
>
> +1, I am good with this change for now. I agree that we should not
> call trace points
> from kexec code, the tracepoint was for other paths, but we should
> definitely avoid
> this path.
>
> Mahesh, is this path specific to hash or do we have similar issues in radix?

The radix code will trigger the tracepoints, so we should fix that. It
may not actually crash but that's secondary.

See:
  mmu_cleanup_all()
  -> radix__mmu_cleanup_all()
     -> radix__flush_tlb_all()
        -> trace_tlbie()

cheers


More information about the Linuxppc-dev mailing list