All of lore.kernel.org
 help / color / mirror / Atom feed
From: "H. Peter Anvin" <hpa@zytor.com>
To: Jason Baron <jbaron@redhat.com>
Cc: linux-kernel@vger.kernel.org, mingo@elte.hu,
	mathieu.desnoyers@polymtl.ca, tglx@linutronix.de,
	rostedt@goodmis.org, andi@firstfloor.org, roland@redhat.com,
	rth@redhat.com, mhiramat@redhat.com
Subject: Re: [RFC PATCH 2/6] jump label v3 - x86: Introduce generic jump patching without stop_machine
Date: Fri, 20 Nov 2009 13:54:08 -0800	[thread overview]
Message-ID: <4B071000.9080408@zytor.com> (raw)
In-Reply-To: <37e397b27509c378f93b9a30f1158791d1b99be7.1258580048.git.jbaron@redhat.com>

On 11/18/2009 02:43 PM, Jason Baron wrote:
> Add text_poke_fixup() which takes a fixup address to where a processor
> jumps if it hits the modifying address while code modifying.
> text_poke_fixup() does following steps for this purpose.
> 
>  1. Setup int3 handler for fixup.
>  2. Put a breakpoint (int3) on the first byte of modifying region,
>     and synchronize code on all CPUs.
>  3. Modify other bytes of modifying region, and synchronize code on all CPUs.
>  4. Modify the first byte of modifying region, and synchronize code
>     on all CPUs.
>  5. Clear int3 handler.
> 
> Thus, if some other processor execute modifying address when step2 to step4,
> it will be jumped to fixup code.
> 
> This still has many limitations for modifying multi-instructions at once.
> However, it is enough for 'a 5 bytes nop replacing with a jump' patching,
> because;
>  - Replaced instruction is just one instruction, which is executed atomically.
>  - Replacing instruction is a jump, so we can set fixup address where the jump
>    goes to.
> 

I just had a thought about this... regardless of if this is safe or not
(which still remains to be determined)... I have a bit more of a
fundamental question about it:

This code ends up taking *two* global IPIs for each instruction
modification.  Each of those requires whole-system synchronization.  How
is this better than taking one IPI and having the other CPUs wait until
the modification is complete before returning?

	-hpa

  parent reply	other threads:[~2009-11-20 21:54 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-11-18 22:43 [RFC PATCH 0/6] jump label v3 Jason Baron
2009-11-18 22:43 ` [RFC PATCH 1/6] jump label v3 - kprobes/x86: Cleanup RELATIVEJUMP_INSTRUCTION to RELATIVEJUMP_OPCODE Jason Baron
2009-11-18 22:43 ` [RFC PATCH 2/6] jump label v3 - x86: Introduce generic jump patching without stop_machine Jason Baron
2009-11-19  0:28   ` Mathieu Desnoyers
2009-11-19  0:58     ` Paul E. McKenney
2009-11-19  1:22       ` Steven Rostedt
2009-11-19  1:39         ` Paul E. McKenney
2009-11-19  1:57       ` Mathieu Desnoyers
2009-11-19  4:16         ` Paul E. McKenney
2009-11-19 14:04     ` Masami Hiramatsu
2009-11-19 16:03       ` Mathieu Desnoyers
2009-11-20  1:00         ` Masami Hiramatsu
2009-11-21 15:32           ` Mathieu Desnoyers
2009-11-21  1:11     ` Masami Hiramatsu
2009-11-21 15:38       ` Mathieu Desnoyers
2009-11-20 21:54   ` H. Peter Anvin [this message]
2009-11-21  0:06     ` Masami Hiramatsu
2009-11-21  0:19       ` H. Peter Anvin
2009-11-21 16:21       ` Mathieu Desnoyers
2009-11-21 21:55         ` Masami Hiramatsu
2009-11-22  1:46           ` Mathieu Desnoyers
2009-11-21 16:12     ` Mathieu Desnoyers
2009-11-18 22:43 ` [RFC PATCH 3/6] jump label v3 - move opcode defs Jason Baron
2009-11-18 22:43 ` [RFC PATCH 4/6] jump label v3 - base patch Jason Baron
2009-11-18 23:38   ` [PATCH] notifier atomic call chain notrace Mathieu Desnoyers
2009-11-19  0:02     ` Paul E. McKenney
2009-11-19  3:59     ` Masami Hiramatsu
2009-11-19 16:48     ` Jason Baron
2009-11-18 22:43 ` [RFC PATCH 5/6] jump label v3 - add module support Jason Baron
2009-11-18 22:43 ` [RFC PATCH 6/6] jump label v3 - tracepoint support Jason Baron
2009-11-18 22:51 ` [RFC PATCH 0/6] jump label v3 H. Peter Anvin
2009-11-18 23:07   ` Roland McGrath
2009-11-18 23:18     ` H. Peter Anvin
2009-11-19  3:54 ` Roland McGrath
2009-11-19 21:55   ` Jason Baron

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=4B071000.9080408@zytor.com \
    --to=hpa@zytor.com \
    --cc=andi@firstfloor.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 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.