From: Masami Hiramatsu <mhiramat@redhat.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Adrian Bunk <bunk@kernel.org>,
ananth@in.ibm.com, anil.s.keshavamurthy@intel.com,
davem@davemloft.net, bugme-daemon@bugzilla.kernel.org,
jean-marc LACROIX <jeanmarc.lacroix@free.Fr>,
linux-kernel@vger.kernel.org, Ingo Molnar <mingo@elte.hu>,
Arjan van de Ven <arjan@linux.intel.com>
Subject: Re: [Bug 10489] Kprobe smoke test lockdep warning
Date: Tue, 22 Apr 2008 12:23:22 -0400 [thread overview]
Message-ID: <480E10FA.3050401@redhat.com> (raw)
In-Reply-To: <1208880358.7115.285.camel@twins>
Peter Zijlstra wrote:
> On Tue, 2008-04-22 at 11:25 -0400, Masami Hiramatsu wrote:
>> Peter Zijlstra wrote:
>>> On Tue, 2008-04-22 at 15:09 +0200, Peter Zijlstra wrote:
>>>> On Mon, 2008-04-21 at 18:54 -0400, Masami Hiramatsu wrote:
>>>>> Thank you for reporting.
>>>>>
>>>>> Actually, kprobes tries to fixup thread's flags in post_kprobe_handler
>>>>> (which is called from kprobe_exceptions_notify) by
>>>>> trace_hardirqs_fixup_flags(pt_regs->flags). However, even the irq flag
>>>>> is set in pt_regs->flags, true hardirq is still off until returning
>>>>> from do_debug. Thus, lockdep assumes that hardirq is off without annotation.
>>> Ah, can you clarrify? pt_regs->flags will only be set when returning to
>>> the original trap site? in that case we should not need a lockdep
>>> annotation I guess, unless its allowed and exptected for the int3 site
>>> to change IRQ state.
>> As far as I took a look at the lockdep, your suggestion is correct.
>> post_kprobe_handler should not set a lockdep annotation, because
>> processor's IF is not changed yet in that time.
>
> That much was clear; but when _will_ it be changed?
processor's IF bit is changed when an iret(q) is issued.
In other words, when returning from a debug/int3 exception.
--
Masami Hiramatsu
Software Engineer
Hitachi Computer Products (America) Inc.
Software Solutions Division
e-mail: mhiramat@redhat.com
next prev parent reply other threads:[~2008-04-22 16:24 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-04-21 15:06 [Bug 10489] Kprobe smoke test lockdep warning Adrian Bunk
2008-04-21 15:13 ` Vegard Nossum
2008-04-21 22:54 ` Masami Hiramatsu
2008-04-22 13:09 ` Peter Zijlstra
2008-04-22 13:26 ` Peter Zijlstra
2008-04-22 15:25 ` Masami Hiramatsu
2008-04-22 16:05 ` Peter Zijlstra
2008-04-22 16:23 ` Masami Hiramatsu [this message]
2008-04-22 19:51 ` Masami Hiramatsu
2008-04-22 16:18 ` Masami Hiramatsu
2008-07-15 9:19 ` Ingo Molnar
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=480E10FA.3050401@redhat.com \
--to=mhiramat@redhat.com \
--cc=ananth@in.ibm.com \
--cc=anil.s.keshavamurthy@intel.com \
--cc=arjan@linux.intel.com \
--cc=bugme-daemon@bugzilla.kernel.org \
--cc=bunk@kernel.org \
--cc=davem@davemloft.net \
--cc=jeanmarc.lacroix@free.Fr \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=peterz@infradead.org \
/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.