All of lore.kernel.org
 help / color / mirror / Atom feed
From: "H. Peter Anvin" <hpa@zytor.com>
To: Andi Kleen <andi@firstfloor.org>, x86@kernel.org
Cc: linux-kernel@vger.kernel.org, Andi Kleen <ak@linux.intel.com>,
	Ingo Molnar <mingo@kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [PATCH] Add a text_poke syscall
Date: Mon, 18 Nov 2013 21:23:35 -0800	[thread overview]
Message-ID: <528AF5D7.7000308@zytor.com> (raw)
In-Reply-To: <1384820855-27790-1-git-send-email-andi@firstfloor.org>

On 11/18/2013 04:27 PM, Andi Kleen wrote:
> 
> Proposed man page:
> 
> NAME
> 	text_poke - Safely modify running instructions (x86)
> 
> SYNOPSYS
> 	int text_poke(void *addr, const void *opcode, size_t len,
> 	              void (*handler)(void), int timeout);
> 
> DESCRIPTION
> 	The text_poke system allows to safely modify code that may
> 	be currently executing in parallel on other threads.
> 	Patch the instruction at addr with the new instructions
> 	at opcode of length len. The target instruction will temporarily
> 	be patched with a break point, before it is replaced
> 	with the final replacement instruction. When the break point
> 	hits the code handler will be called in the context
> 	of the thread. The handler does not save any registers
> 	and cannot return. Typically it would consist of the
> 	original instruction and then a jump to after the original
> 	instruction. The handler is only needed during the
> 	patching process and can be overwritten once the syscall
> 	returns. timeout defines an optional timout to indicate
> 	to the kernel how long the patching could be delayed.
> 	Right now it has to be 0.
> 

I think I would prefer an interface which took a list of patch points,
or implemented only the aspects which are impossible to do in user space.

All we really need in the kernel is the IPI broadcasts - the rest can be
done in user space, including intercepting SIGTRAP.  For userspace it is
probably the best to just put a thread to sleep until the patching is
done, which can be done with a futex.

One advantage with doing this in userspace is that the kernel doesn't
have to be responsible avoiding holding a thread due to a slightly
different SIGTRAP -- it will all come out after the signal handler is
restored, anyway.

That being said, the user space code would really need to be librarized.

	-hpa


  parent reply	other threads:[~2013-11-19  5:24 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-19  0:27 [PATCH] Add a text_poke syscall Andi Kleen
2013-11-19  2:32 ` Andy Lutomirski
2013-11-19 20:16   ` Andi Kleen
2013-11-21 10:02     ` Jiri Kosina
2013-11-19  5:23 ` H. Peter Anvin [this message]
2013-11-19 18:49   ` Andi Kleen
2013-11-20 16:42     ` H. Peter Anvin
2013-11-20 17:25       ` Andi Kleen
2013-11-20 18:30         ` H. Peter Anvin
2013-11-20 21:00         ` H. Peter Anvin
2013-11-21 12:49       ` Steven Rostedt
2013-11-19  6:49 ` Ingo Molnar
2013-11-19 19:10   ` Andi Kleen
2013-11-21 13:07     ` Steven Rostedt
2013-11-22  3:26       ` Andi Kleen
2013-11-21 18:26 ` Oleg Nesterov
2013-11-22  3:29   ` Andi Kleen

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=528AF5D7.7000308@zytor.com \
    --to=hpa@zytor.com \
    --cc=ak@linux.intel.com \
    --cc=andi@firstfloor.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.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.