From: Masami Hiramatsu <mhiramat@redhat.com>
To: Arjan van de Ven <arjan@infradead.org>
Cc: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>,
"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
Subject: Re: [RFC PATCH 2/8] jump label v4 - x86: Introduce generic jump patching without stop_machine
Date: Mon, 18 Jan 2010 10:59:30 -0500 [thread overview]
Message-ID: <4B548562.6030008@redhat.com> (raw)
In-Reply-To: <20100117111608.35a98ee2@infradead.org>
Arjan van de Ven wrote:
> 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 ;-)
Yeah, so in the latest patch, I updated it to use int3 even if
len == 1. :-)
Thank you,
--
Masami Hiramatsu
Software Engineer
Hitachi Computer Products (America), Inc.
Software Solutions Division
e-mail: mhiramat@redhat.com
next prev parent reply other threads:[~2010-01-18 16:00 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 [this message]
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
-- 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=4B548562.6030008@redhat.com \
--to=mhiramat@redhat.com \
--cc=andi@firstfloor.org \
--cc=arjan@infradead.org \
--cc=hpa@zytor.com \
--cc=jbaron@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mathieu.desnoyers@polymtl.ca \
--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 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.