All of lore.kernel.org
 help / color / mirror / Atom feed
From: Luca Barbieri <luca@luca-barbieri.com>
To: "H. Peter Anvin" <hpa@zytor.com>
Cc: mingo@elte.hu, a.p.zijlstra@chello.nl, akpm@linux-foundation.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 02/10] x86: add support for relative CALL and JMP in  alternatives
Date: Fri, 19 Feb 2010 00:38:48 +0100	[thread overview]
Message-ID: <ff13bc9a1002181538q7ccc1381x32a2f25bfb6d56cc@mail.gmail.com> (raw)
In-Reply-To: <4B7D97A6.4060900@zytor.com>

> The existing instruction parser is only present if KPROBES is configured
> in... this patch would make it obligatory.  Your patch doesn't reflect
> that.  Furthermore, it is ~16K of code and data which probably will make
> embedded people unhappy... although perhaps isn't out of line.
Didn't notice that.

> A good question, though, is if we actually need support for JMP or CALL
> as anything but the first instruction (usually the *only* instruction),
> which would make it a lot easier...

Probably not.
I think an even better option is to create a CALL if replacementlen is 0xff.
This would save some space for each callsite and make it clear we only
support this usage.

  reply	other threads:[~2010-02-18 23:38 UTC|newest]

Thread overview: 54+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-02-17 11:42 [PATCH 0/10] x86-32: improve atomic64_t functions Luca Barbieri
2010-02-17 11:42 ` [PATCH 01/10] x86: add support for multiple choice alternatives Luca Barbieri
2010-02-17 12:47   ` Avi Kivity
2010-02-18 19:46     ` H. Peter Anvin
2010-02-17 11:42 ` [PATCH 02/10] x86: add support for relative CALL and JMP in alternatives Luca Barbieri
2010-02-18 19:40   ` H. Peter Anvin
2010-02-18 23:38     ` Luca Barbieri [this message]
2010-02-18 23:54       ` H. Peter Anvin
2010-02-19 14:27   ` Masami Hiramatsu
2010-02-17 11:42 ` [PATCH 03/10] x86: add support for lock prefix " Luca Barbieri
2010-02-17 11:42 ` [PATCH 04/10] x86-32: allow UP/SMP lock replacement in cmpxchg64 Luca Barbieri
2010-02-17 11:42 ` [PATCH 05/10] lib: add self-test for atomic64_t Luca Barbieri
2010-02-17 11:42 ` [PATCH 06/10] x86-32: rewrite 32-bit atomic64 functions in assembly Luca Barbieri
2010-02-17 11:42 ` [PATCH 07/10] lib: move generic atomic64 to atomic64-impl.h Luca Barbieri
2010-02-17 11:42 ` [PATCH 08/10] x86-32: support atomic64_t on 386/486 UP/SMP Luca Barbieri
2010-02-18 10:25   ` Peter Zijlstra
2010-02-18 10:58     ` Luca Barbieri
2010-02-18 15:20     ` H. Peter Anvin
2010-02-17 11:42 ` [PATCH 09/10] x86-32: use SSE for atomic64_read/set if available Luca Barbieri
2010-02-17 22:39   ` H. Peter Anvin
2010-02-18  0:41     ` Luca Barbieri
2010-02-18  0:47       ` H. Peter Anvin
2010-02-18  9:56         ` Avi Kivity
2010-02-18 10:07           ` Luca Barbieri
2010-02-18  8:23   ` Andi Kleen
2010-02-18  9:53     ` Luca Barbieri
2010-02-18  9:56       ` Luca Barbieri
2010-02-18 10:11       ` Andi Kleen
2010-02-18 10:27         ` Luca Barbieri
2010-02-18 15:24           ` H. Peter Anvin
2010-02-18 18:14             ` Luca Barbieri
2010-02-18 18:28               ` H. Peter Anvin
2010-02-18 18:42                 ` Luca Barbieri
2010-02-18 19:07                   ` H. Peter Anvin
2010-02-18 20:26               ` Andi Kleen
2010-02-18 16:52           ` H. Peter Anvin
2010-02-18 18:49             ` Luca Barbieri
2010-02-18 19:06               ` H. Peter Anvin
2010-02-18 19:43                 ` Luca Barbieri
2010-02-18 19:45                 ` Yuhong Bao
2010-02-18 10:24       ` Peter Zijlstra
2010-02-18 10:25   ` Peter Zijlstra
2010-02-18 10:50     ` Luca Barbieri
2010-02-18 11:00       ` Peter Zijlstra
2010-02-18 12:29         ` Luca Barbieri
2010-02-18 12:32           ` Peter Zijlstra
2010-02-18 13:45             ` Luca Barbieri
2010-02-17 11:42 ` [PATCH 10/10] x86-32: panic on !CX8 && XMM Luca Barbieri
2010-02-17 22:38   ` H. Peter Anvin
2010-02-17 23:00     ` Yuhong Bao
2010-02-17 23:41       ` H. Peter Anvin
2010-02-18  1:13         ` Yuhong Bao
2010-02-25 20:24           ` Yuhong Bao
2010-02-18  0:46     ` Luca Barbieri

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=ff13bc9a1002181538q7ccc1381x32a2f25bfb6d56cc@mail.gmail.com \
    --to=luca@luca-barbieri.com \
    --cc=a.p.zijlstra@chello.nl \
    --cc=akpm@linux-foundation.org \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    /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.