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

[Naveen N. Rao]

Mahesh Jagannath Salgaonkar wrote:
> On 11/23/2017 12:37 AM, Naveen N. Rao wrote:
>> Mahesh J Salgaonkar wrote:
>>> From: Mahesh Salgaonkar <mahesh at linux.vnet.ibm.com>
>>>
>>> Rebooting into a new kernel with kexec fails in trace_tlbie() which is
>>> called from native_hpte_clear(). This happens if the running kernel has
>>> CONFIG_LOCKDEP enabled. With lockdep enabled, the tracepoints always
>>> execute few RCU checks regardless of whether tracing is on or off.
>>> We are already in the last phase of kexec sequence in real mode with
>>> HILE_BE set. At this point the RCU check ends up in RCU_LOCKDEP_WARN and
>>> causes kexec to fail.
>>>
>>> Fix this by not calling trace_tlbie() from native_hpte_clear().
>>>
>>> Signed-off-by: Mahesh Salgaonkar <mahesh at linux.vnet.ibm.com>
>>> Reported-by: Aneesh Kumar K.V <aneesh.kumar at linux.vnet.ibm.com>
>>> Suggested-by: Michael Ellerman <mpe at ellerman.id.au>
>>> ---
>>>  arch/powerpc/mm/hash_native_64.c |   15 ++++++++++++---
>>>  1 file changed, 12 insertions(+), 3 deletions(-)
>>>

[snip]

>>> @@ -100,7 +101,15 @@ static inline void __tlbie(unsigned long vpn, 
>>> int
>>> psize, int apsize, int ssize)
>>>                   : "memory");
>>>          break;
>>>      }
>>> -    trace_tlbie(0, 0, va, 0, 0, 0, 0);
>> 
>> Does it help if you use the _rcuidle variant instead, to turn off all
>> rcu checks for tracing __tlbie()?
>>     trace_tlbie_rcuidle(0, 0, va, 0, 0, 0, 0);
> 
> It helps if tracepoint is not enabled. But with tracepoint enabled kexec
> still fails. I think we should not have tracepoint in kexec path at all.
> If someone enables it, kexec will definitely fail regardless of
> CONFIG_LOCKDEP.

Ok, thanks for confirming that other tracepoints don't interfere with 
kexec. As Balbir points out, moving to TRACE_EVENT_CONDITION() with a 
global in_kexec variable may be the other option, but is probably 
overkill for a single tracepoint.

Acked-by: Naveen N. Rao <naveen.n.rao at linux.vnet.ibm.com>


Thanks,
Naveen