All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Naveen N. Rao" <naveen.n.rao@linux.vnet.ibm.com>
To: Frederic Weisbecker <fweisbec@gmail.com>
Cc: paulus@samba.org, a.p.zijlstra@chello.nl,
	linux-kernel@vger.kernel.org, mingo@redhat.com,
	emachado@linux.vnet.ibm.com, acme@ghostprotocols.net,
	prasad.krishnan@gmail.com
Subject: Re: [PATCH v2 RESEND] Hardware breakpoints: Invoke __perf_event_disable() if interrupts are already disabled
Date: Wed, 25 Jul 2012 17:02:56 +0530	[thread overview]
Message-ID: <500FD968.6000407@linux.vnet.ibm.com> (raw)
In-Reply-To: <5007EC8C.7060200@linux.vnet.ibm.com>

On 07/19/2012 04:46 PM, Naveen N. Rao wrote:
> On 07/18/2012 05:27 PM, Frederic Weisbecker wrote:
>> On Wed, Jul 18, 2012 at 04:00:46PM +0530, Naveen N. Rao wrote:
>>> Please find v2 of the patch from Prasad, based on Peter Zijlstra's
>>> feedback. This applies on top of v3.5-rc7. This has been tested and
>>> found to work fine by Edjunior.
>>>
>>> Regards,
>>> Naveen
>>> ______
>>>
>>> From: K.Prasad <Prasad.Krishnan@gmail.com>
>>>
>>> While debugging a warning message on PowerPC while using hardware
>>> breakpoints, it was discovered that when perf_event_disable is invoked
>>> through hw_breakpoint_handler function with interrupts disabled, a
>>> subsequent IPI in the code path would trigger a WARN_ON_ONCE message in
>>> smp_call_function_single function.
>>>
>>> This patch calls __perf_event_disable() when interrupts are already
>>> disabled, instead of perf_event_disable().
>>>
>>> Reported-by: Edjunior Barbosa Machado <emachado@linux.vnet.ibm.com>
>>> Signed-off-by: K.Prasad <Prasad.Krishnan@gmail.com>
>>> Signed-off-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
>>> ---
>>>   include/linux/perf_event.h    |    2 ++
>>>   kernel/events/core.c          |    2 +-
>>>   kernel/events/hw_breakpoint.c |   10 +++++++++-
>>>   3 files changed, 12 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
>>> index 45db49f..c289ba0 100644
>>> --- a/include/linux/perf_event.h
>>> +++ b/include/linux/perf_event.h
>>> @@ -1292,6 +1292,7 @@ extern int
>>> perf_swevent_get_recursion_context(void);
>>>   extern void perf_swevent_put_recursion_context(int rctx);
>>>   extern void perf_event_enable(struct perf_event *event);
>>>   extern void perf_event_disable(struct perf_event *event);
>>> +extern int __perf_event_disable(void *info);
>>>   extern void perf_event_task_tick(void);
>>>   #else
>>>   static inline void
>>> @@ -1330,6 +1331,7 @@ static inline int
>>> perf_swevent_get_recursion_context(void)        { return -1; }
>>>   static inline void perf_swevent_put_recursion_context(int
>>> rctx)        { }
>>>   static inline void perf_event_enable(struct perf_event
>>> *event)        { }
>>>   static inline void perf_event_disable(struct perf_event
>>> *event)        { }
>>> +static inline int __perf_event_disable(void *info)            { }
>>>   static inline void perf_event_task_tick(void)                { }
>>>   #endif
>>>
>>> diff --git a/kernel/events/core.c b/kernel/events/core.c
>>> index d7d71d6..0ad0fc9 100644
>>> --- a/kernel/events/core.c
>>> +++ b/kernel/events/core.c
>>> @@ -1253,7 +1253,7 @@ retry:
>>>   /*
>>>    * Cross CPU call to disable a performance event
>>>    */
>>> -static int __perf_event_disable(void *info)
>>> +int __perf_event_disable(void *info)
>>>   {
>>>       struct perf_event *event = info;
>>>       struct perf_event_context *ctx = event->ctx;
>>> diff --git a/kernel/events/hw_breakpoint.c
>>> b/kernel/events/hw_breakpoint.c
>>> index bb38c4d..483f14a 100644
>>> --- a/kernel/events/hw_breakpoint.c
>>> +++ b/kernel/events/hw_breakpoint.c
>>> @@ -453,7 +453,15 @@ int modify_user_hw_breakpoint(struct perf_event
>>> *bp, struct perf_event_attr *att
>>>       int old_type = bp->attr.bp_type;
>>>       int err = 0;
>>>
>>> -    perf_event_disable(bp);
>>> +    /*
>>> +     * modify_user_hw_breakpoint can be invoked with IRQs disabled
>>> and hence it
>>> +     * will not be possible to raise IPIs that invoke
>>> __perf_event_disable.
>>> +     * So call the function directly.
>>> +     */
>>> +    if (irqs_disabled())
>>> +        __perf_event_disable(bp);
>>> +    else
>>> +        perf_event_disable(bp);
>>
>> This only works if we are sure the bp is on the current CPU. Do we
>> have that guarantee?
>
> Yes. This is being hit during bp exception processing and is specific to
> ppc where we disable interrupts:
> hw_breakpoint_handler->perf_bp_event->ptrace_triggered->modify_user_hw_breakpoint()

Frederick,
Is this acceptable, or do you have other scenarios where this won't 
work? I can add a check to ensure we call __perf_event_disable only if 
the task is on the current CPU, but the above scenario is the only one 
where we're seeing this issue.

Thanks,
Naveen


  reply	other threads:[~2012-07-25 11:33 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-11  6:02 [Patch][perf] Invoke __perf_event_disable without an IPI K.Prasad
2012-06-11 11:13 ` Peter Zijlstra
2012-06-12  6:06   ` K.Prasad
2012-06-12  9:12     ` Peter Zijlstra
2012-07-06  9:52       ` [PATCH v2] Hardware breakpoints: Invoke __perf_event_disable() if interrupts are already disabled Naveen N. Rao
2012-07-06 10:18         ` Naveen N. Rao
2012-07-18 10:30           ` [PATCH v2 RESEND] " Naveen N. Rao
2012-07-18 11:57             ` Frederic Weisbecker
2012-07-19 11:16               ` Naveen N. Rao
2012-07-25 11:32                 ` Naveen N. Rao [this message]
2012-07-31 13:41                   ` Frederic Weisbecker
2012-08-02  8:16                     ` [PATCH v3] " Naveen N. Rao
2012-08-15 17:37                       ` Naveen N. Rao
2012-08-15 18:42                         ` Frederic Weisbecker
2012-08-16  8:16                           ` Peter Zijlstra
2012-08-29  2:45                             ` Naveen N. Rao
2012-09-04 18:53                       ` [tip:perf/urgent] perf/hwpb: " tip-bot for K.Prasad

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=500FD968.6000407@linux.vnet.ibm.com \
    --to=naveen.n.rao@linux.vnet.ibm.com \
    --cc=a.p.zijlstra@chello.nl \
    --cc=acme@ghostprotocols.net \
    --cc=emachado@linux.vnet.ibm.com \
    --cc=fweisbec@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=paulus@samba.org \
    --cc=prasad.krishnan@gmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.