From: Arjan van de Ven <arjan@infradead.org>
To: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
Cc: "H. Peter Anvin" <hpa@zytor.com>,
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,
mhiramat@redhat.com
Subject: Re: [RFC PATCH 2/8] jump label v4 - x86: Introduce generic jump patching without stop_machine
Date: Sun, 17 Jan 2010 11:16:08 -0800 [thread overview]
Message-ID: <20100117111608.35a98ee2@infradead.org> (raw)
In-Reply-To: <20100117185539.GF9008@Krystal>
On Sun, 17 Jan 2010 13:55:39 -0500
Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca> wrote:
> * H. Peter Anvin (hpa@zytor.com) wrote:
> > On 01/14/2010 07:32 AM, Steven Rostedt wrote:
> > >> +
> > >> + /* Replacing 1 byte can be done atomically. */
> > >> + if (unlikely(len <= 1))
> > >> + return text_poke(addr, opcode, len);
> > >
> > > This part bothers me. The text_poke just writes over the text
> > > directly (using a separate mapping). But if that memory is in the
> > > pipeline of another CPU, I think this could cause a GPF.
> > >
> >
> > Could you clarify why you think that?
>
> Basically, what Steven and I were concerned about in this particular
> patch version is the fact that this code took a "shortcut" for
> single-byte text modification, thus bypassing the int3-bypass scheme
> altogether.
single byte instruction updates are likely 100x safer than any scheme
of multi-byte instruction scheme that I have seen, other than a full
stop_machine().
That does not mean it is safe, it just means it's an order of
complexity less to analyze ;-)
--
Arjan van de Ven Intel Open Source Technology Centre
For development, discussion and tips for power savings,
visit http://www.lesswatts.org
next prev parent reply other threads:[~2010-01-17 19:16 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 [this message]
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
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
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=20100117111608.35a98ee2@infradead.org \
--to=arjan@infradead.org \
--cc=andi@firstfloor.org \
--cc=hpa@zytor.com \
--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
Powered by JetHome