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

[Michael Ellerman]

"Naveen N. Rao" <naveen.n.rao at linux.vnet.ibm.com> writes:

> Michael Ellerman wrote:
>> Balbir Singh <bsingharora at gmail.com> writes:
>> 
>>> On Thu, Nov 23, 2017 at 4:32 AM, Mahesh J Salgaonkar
>>> <mahesh at linux.vnet.ibm.com> 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.
>>>>
>>>
>>> Effectively we can't enter the trace point code after we've set
>>> HILE_BE.  Do we need
>>> a fixes tag? Or is this a side-effect of a new generic change?
>> 
>> Yes I added:
>> 
>> Fixes: 0428491cba92 ("powerpc/mm: Trace tlbie(l) instructions")
>> Cc: stable at vger.kernel.org # v4.13+
>> 
>>> 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.  

Yes you're right, I misread that.

So maybe that is an option. But it still makes me nervous :)

cheers