linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Leo Yan <leo.yan@linaro.org>
Cc: Will Deacon <will@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Mike Leach <mike.leach@linaro.org>,
	Adrian Hunter <adrian.hunter@intel.com>,
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
	"H . Peter Anvin" <hpa@zytor.com>,
	x86@kernel.org,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	Mathieu Poirier <mathieu.poirier@linaro.org>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	Jiri Olsa <jolsa@redhat.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH RFC 1/6] perf/x86: Add perf text poke event
Date: Mon, 11 Nov 2019 15:46:42 +0100	[thread overview]
Message-ID: <20191111144642.GM4114@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <20191108150530.GA7721@leoy-ThinkPad-X240s>

On Fri, Nov 08, 2019 at 11:05:30PM +0800, Leo Yan wrote:

> I will update some status for prototype (the code has been uploaded into
> git server [1]) and found some issues for text poke perf event on arm64.
> These issues are mainly related with arch64 architecture.
> 
> - The first issue is for the nosync instruction emulation.  On arm64,
>   some instructions need to be single stepped and some instructions
>   is emulated.  Especially, after I read the code for kprobe
>   implementation on Arm64.  So the main idea for prototyping is to use
>   the almos same method with kprobe for nosync instruction.

This makes no sense to me what so ever. What actual instructions are
patched with _nosync() ? ftrace/jump_label only use 'NOP/JMP/CALL'

For NOP you can advance regs->ip, for JMP you can adjust regs->ip, for
CALL you adjust regs->ip and regs->r14 (IIUC you do something like:
regs->r14 = regs->ip+4; regs->ip = func;)

(FWIW emulating CALL on x86 is fun because we get to PUSH something on
the stack, let me know if you want to see the patches that were required
to make that happen :-)

> - The second issue is race condition between the CPU alters
>   instructions and other CPUs hit the altered instructions (and
>   breakpointed).
> 
>   Peter's suggestion uses global variables 'nosync_insn' and
>   'nosync_addr' to record the altered instruction.  But from the
>   testing I found for single static key, usually it will change for
>   multiple address at once.
> 
>   So this might cause the issue is: CPU(a) will loop to alter
>   instructions for different address (sometimes the opcode also is
>   different for different address), at the meantime, CPU(b) hits an
>   altered instruction and handle exception for the breakpoint, if
>   CPU(a) is continuing to alter instruction for the next address, thne
>   CPU(a) might wrongly to use the value from 'nosync_insn' and
>   'nosync_addr'.
> 
>   Simply to say, we cannot only support single nosync instruction but
>   need to support multiple nosync instructions in the loop.

On x86 all actual text poking is serialized by text_mutex.

> - The third issue is might be nested issue.  E.g. for the injected
>   break instruction, we have no method to pass perf event for this
>   instruction; and if we connect with the first issue, if the
>   instruction is single stepped with slot (the slot is allocated with
>   get_insn_slot()), we cannot to allow the perf user space to know
>   the instructions which are executed in the slots.
> 
>   I am not sure if I think too complex here.  But seems to me, we
>   inject more instructions for poke text event, and if these injected
>   instructions are executed but the userspace decoder has no way to
>   pass the related info.

That's a misunderstanding, the text_poke event is a side-band event and
as such delivered to all events that expressed interest in it. You don't
need any exception to event mapping yourself.

> Just clarify, I am fine for merging this patch set, but we might
> consider more what's the best way on Arm64.  Welcome any public
> comments and suggestions; I will sync internally for how to follow up
> this functionality.

Thanks!

  reply	other threads:[~2019-11-11 14:47 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-25 12:59 [PATCH RFC 0/6] perf/x86: Add perf text poke event Adrian Hunter
2019-10-25 12:59 ` [PATCH RFC 1/6] " Adrian Hunter
2019-10-30 10:47   ` Leo Yan
2019-10-30 12:46     ` Peter Zijlstra
2019-10-30 14:19       ` Leo Yan
2019-10-30 15:00         ` Mike Leach
2019-10-30 16:23         ` Peter Zijlstra
2019-10-31  7:31           ` Leo Yan
2019-11-01 10:04             ` Peter Zijlstra
2019-11-01 10:09               ` Peter Zijlstra
2019-11-04  2:23               ` Leo Yan
2019-11-08 15:05                 ` Leo Yan
2019-11-11 14:46                   ` Peter Zijlstra [this message]
2019-11-11 15:39                     ` Will Deacon
2019-11-11 16:05                       ` Peter Zijlstra
2019-11-11 17:29                         ` Will Deacon
2019-11-11 20:32                           ` Peter Zijlstra
     [not found]             ` <CAJ9a7VgZH7g=rFDpKf=FzEcyBVLS_WjqbrqtRnjOi7WOY4st+w@mail.gmail.com>
2019-11-01 10:06               ` Peter Zijlstra
2019-11-04 10:40   ` Peter Zijlstra
2019-11-04 12:32     ` Adrian Hunter
2019-10-25 12:59 ` [PATCH RFC 2/6] perf dso: Refactor dso_cache__read() Adrian Hunter
2019-10-25 14:54   ` Arnaldo Carvalho de Melo
2019-10-28 15:39   ` Jiri Olsa
2019-10-29  9:19     ` Adrian Hunter
2019-11-12 11:18   ` [tip: perf/core] " tip-bot2 for Adrian Hunter
2019-10-25 12:59 ` [PATCH RFC 3/6] perf dso: Add dso__data_write_cache_addr() Adrian Hunter
2019-10-28 15:45   ` Jiri Olsa
2019-10-29  9:20     ` Adrian Hunter
2019-11-12 11:18   ` [tip: perf/core] " tip-bot2 for Adrian Hunter
2019-10-25 12:59 ` [PATCH RFC 4/6] perf tools: Add support for PERF_RECORD_TEXT_POKE Adrian Hunter
2019-10-25 12:59 ` [PATCH RFC 5/6] perf auxtrace: Add auxtrace_cache__remove() Adrian Hunter
2019-10-25 14:48   ` Arnaldo Carvalho de Melo
2019-11-12 11:18   ` [tip: perf/core] " tip-bot2 for Adrian Hunter
2019-10-25 13:00 ` [PATCH RFC 6/6] perf intel-pt: Add support for text poke events Adrian Hunter

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=20191111144642.GM4114@hirez.programming.kicks-ass.net \
    --to=peterz@infradead.org \
    --cc=acme@kernel.org \
    --cc=adrian.hunter@intel.com \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=bp@alien8.de \
    --cc=hpa@zytor.com \
    --cc=jolsa@redhat.com \
    --cc=leo.yan@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=mathieu.poirier@linaro.org \
    --cc=mike.leach@linaro.org \
    --cc=mingo@redhat.com \
    --cc=will@kernel.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).