linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Balbir Singh <bsingharora@gmail.com>
To: "Naveen N. Rao" <naveen.n.rao@linux.vnet.ibm.com>
Cc: Mahesh J Salgaonkar <mahesh@linux.vnet.ibm.com>,
	Michael Ellerman <mpe@ellerman.id.au>,
	"Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>,
	linuxppc-dev <linuxppc-dev@ozlabs.org>
Subject: Re: [PATCH] powernv: Avoid calling trace tlbie in kexec path.
Date: Fri, 24 Nov 2017 15:13:11 +1100	[thread overview]
Message-ID: <CAKTCnz=yeLLFWzpVr6ZzRiSe7ggPJabA6Od6msXL2PP-+48GiA@mail.gmail.com> (raw)
In-Reply-To: <1511442295.rqmndvaowx.naveen@linux.ibm.com>

On Fri, Nov 24, 2017 at 12:11 AM, Naveen N. Rao
<naveen.n.rao@linux.vnet.ibm.com> wrote:
> Michael Ellerman wrote:
>>
>> Balbir Singh <bsingharora@gmail.com> writes:
>>
>>> On Thu, Nov 23, 2017 at 4:32 AM, Mahesh J Salgaonkar
>>> <mahesh@linux.vnet.ibm.com> wrote:
>>>>
>>>> From: Mahesh Salgaonkar <mahesh@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@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.  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?

Balbir Singh.

  reply	other threads:[~2017-11-24  4:13 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-22 17:32 [PATCH] powernv: Avoid calling trace tlbie in kexec path Mahesh J Salgaonkar
2017-11-22 19:07 ` Naveen N. Rao
2017-11-23  9:38   ` Mahesh Jagannath Salgaonkar
2017-11-23 10:02     ` Naveen N. Rao
2017-11-22 22:56 ` Balbir Singh
2017-11-23 11:18   ` Mahesh Jagannath Salgaonkar
2017-11-23 12:15   ` Michael Ellerman
2017-11-23 13:11     ` Naveen N. Rao
2017-11-24  4:13       ` Balbir Singh [this message]
2017-11-24  6:10         ` Michael Ellerman
2017-11-24  6:10       ` Michael Ellerman
2017-11-24  9:46 ` Michael Ellerman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAKTCnz=yeLLFWzpVr6ZzRiSe7ggPJabA6Od6msXL2PP-+48GiA@mail.gmail.com' \
    --to=bsingharora@gmail.com \
    --cc=aneesh.kumar@linux.vnet.ibm.com \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=mahesh@linux.vnet.ibm.com \
    --cc=mpe@ellerman.id.au \
    --cc=naveen.n.rao@linux.vnet.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).