From: "H. Peter Anvin" <hpa@zytor.com>
To: Masami Hiramatsu <mhiramat@redhat.com>
Cc: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>,
Arjan van de Ven <arjan@infradead.org>,
rostedt@goodmis.org, Jason Baron <jbaron@redhat.com>,
linux-kernel@vger.kernel.org, mingo@elte.hu, tglx@linutronix.de,
andi@firstfloor.org, roland@redhat.com, rth@redhat.com
Subject: Re: [RFC PATCH 2/8] jump label v4 - x86: Introduce generic jump patching without stop_machine
Date: Mon, 18 Jan 2010 13:18:20 -0800 [thread overview]
Message-ID: <4B54D01C.1070505@zytor.com> (raw)
In-Reply-To: <4B54CA2F.1050604@redhat.com>
On 01/18/2010 12:53 PM, Masami Hiramatsu wrote:
>>
>> This is utter and complete nonsense. You seem to think that everything
>> is guaranteed to hit the breakpoint, which is obviously false.
>> Furthermore, until you have done the serialization, you're not
>> guaranteed the *breakpoint* is seen, so you have the same condition.
>
> In that time frame, I guess that the processor sees non-modified
> instruction and executes it. Since we'll wait until serializing on
> each processor, I think it is OK for int3-bypass method.
>
> (Of course, this can depend on chip, it is possible that there is a chip
> which causes a fault when it has a cache-discarding signal on current-
> instruction decoding slot. That's also why we are asking this method
> is OK for x86 processors.)
>
Yes, it is possible, however, if that was the case, then int3 wouldn't
work either. As I said, to the best of our knowledge, at least Intel
processors are okay for a single-byte update (I will wait to try to
state the full general rule until it has been officially approved or
killed.)
-hpa
next prev parent reply other threads:[~2010-01-18 21:22 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-01-12 16:26 [RFC PATCH 0/8] jump label v4 Jason Baron
2010-01-12 16:26 ` [RFC PATCH 1/8] jump label v4 - kprobes/x86: Cleanup RELATIVEJUMP_INSTRUCTION to RELATIVEJUMP_OPCODE Jason Baron
2010-01-12 16:26 ` [RFC PATCH 2/8] jump label v4 - x86: Introduce generic jump patching without stop_machine Jason Baron
2010-01-12 23:16 ` H. Peter Anvin
2010-01-13 2:06 ` Mathieu Desnoyers
2010-01-13 4:55 ` H. Peter Anvin
2010-01-13 14:30 ` Mathieu Desnoyers
2010-01-14 6:57 ` Masami Hiramatsu
2010-01-14 18:45 ` Masami Hiramatsu
2010-04-13 17:16 ` Mathieu Desnoyers
2010-01-13 5:38 ` Masami Hiramatsu
2010-01-14 15:32 ` Steven Rostedt
2010-01-14 15:36 ` H. Peter Anvin
2010-01-17 18:55 ` Mathieu Desnoyers
2010-01-17 19:16 ` Arjan van de Ven
2010-01-18 15:59 ` Masami Hiramatsu
2010-01-18 16:23 ` H. Peter Anvin
2010-01-18 16:52 ` Mathieu Desnoyers
2010-01-18 18:50 ` H. Peter Anvin
2010-01-18 20:53 ` Masami Hiramatsu
2010-01-18 21:18 ` H. Peter Anvin [this message]
2010-01-18 21:32 ` Mathieu Desnoyers
2010-01-18 16:31 ` Arjan van de Ven
2010-01-18 16:54 ` Mathieu Desnoyers
2010-01-18 18:21 ` Masami Hiramatsu
2010-01-18 18:33 ` Mathieu Desnoyers
2010-01-14 15:39 ` Mathieu Desnoyers
2010-01-14 16:23 ` Masami Hiramatsu
2010-01-14 16:42 ` Jason Baron
2010-01-12 16:26 ` [RFC PATCH 3/8] jump label v4 - move opcode definitions Jason Baron
2010-01-12 16:26 ` [RFC PATCH 4/8] jump label v4 - notifier atomic call chain notrace Jason Baron
2010-01-12 16:26 ` [RFC PATCH 5/8] jump label v4 - base patch Jason Baron
2010-01-12 16:26 ` [RFC PATCH 6/8] jump label v4 - x86 support Jason Baron
2010-01-12 16:26 ` [RFC PATCH 7/8] jump label v4 - tracepoint support Jason Baron
2010-01-12 16:26 ` [RFC PATCH 8/8] jump label v4 - add module support Jason Baron
-- strict thread matches above, loose matches on Subject: below --
2010-01-17 22:56 [RFC PATCH 2/8] jump label v4 - x86: Introduce generic jump patching without stop_machine H. Peter Anvin
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=4B54D01C.1070505@zytor.com \
--to=hpa@zytor.com \
--cc=andi@firstfloor.org \
--cc=arjan@infradead.org \
--cc=jbaron@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mathieu.desnoyers@polymtl.ca \
--cc=mhiramat@redhat.com \
--cc=mingo@elte.hu \
--cc=roland@redhat.com \
--cc=rostedt@goodmis.org \
--cc=rth@redhat.com \
--cc=tglx@linutronix.de \
/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