From: liuj97@gmail.com (Jiang Liu)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v5 2/7] arm64: introduce interfaces to hotpatch kernel and module code
Date: Thu, 07 Nov 2013 00:12:13 +0800 [thread overview]
Message-ID: <527A6A5D.2050206@gmail.com> (raw)
In-Reply-To: <20131106104110.GC21074@mudshark.cambridge.arm.com>
On 11/06/2013 06:41 PM, Will Deacon wrote:
> On Mon, Nov 04, 2013 at 03:12:56PM +0000, Sandeepa Prabhu wrote:
>> On 3 November 2013 23:55, Jiang Liu <liuj97@gmail.com> wrote:
>>> On 10/30/2013 08:12 AM, Will Deacon wrote:
>>>> On Fri, Oct 18, 2013 at 04:19:56PM +0100, Jiang Liu wrote:
>>>>> + atomic_set(&text_patch_id, smp_processor_id());
>>>>> + ret = stop_machine(aarch64_insn_patch_text_cb, &patch, cpu_online_mask);
>>>>
>>>> Instead of doing this, why not instead call aarch64_insn_patch_text_nosync
>>>> inline, then call kick_all_cpus_sync immediately afterwards, without the
>>>> need to stop_machine.
>>> Sandeepa, who is working on kprobe for ARM64, needs the stop_machine()
>>> mechanism to synchronize all online CPUs, so it's a preparation for
>>> kprobe.
>>
>> I had published kprobes patches for ARM64:
>> http://lwn.net/Articles/570648/ and using your patcset (v3) for
>> patching support, it works so far.
>> I CCed you on my RFC but unfortunately to your huawei email not the gmail.
>>
>> I can give a try with kick_all_cpus_sync but wanted to understand this
>> a bit detail on hows different from stop_machine and how this work.
>
> My point was just that for nosync patching, the update to the instruction
> stream is atomic with respect to instruction fetch, so stop_machine seems a
> bit overkill. kick_all_cpus can be used to ensure visibility of the new
> instruction.
>
> Jiang Liu seemed to imply that this isn't suitable for kprobes, but I would
> like to know if/why that is the case.
>
> Will
>
Hi Will and Sandeepa,
Seems some misunderstanding here. We provide three interfaces
here.
1) aarch64_insn_patch_text_nosync(), which patches kernel/module text
without explicitly synchronization. It may be used in cases of
1.a) There's only one CPU running during early boot stage
1.b) All other CPU has been put into safe state in kgdb.
1.c) The instructions before and after patching are both hot-patch safe.
2) aarch64_insn_patch_text_sync(), which patches kernel/module text
with explicitly synchronization by stop_machine() mechanism. It may
be used to support kprobe because kprobe may patch multiple and/or
non-hotpatch safe instructions at runtime, so we need stop_machine()
for synchronization.
3) aarch64_insn_patch_text() intelligently choose
aarch64_insn_patch_text_nosync() or aarch64_insn_patch_text_sync().
So for kprobe, I think need to use stop_machine() for synchronization.
Thanks!
Gerry
next prev parent reply other threads:[~2013-11-06 16:12 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-18 15:19 [PATCH v5 0/7] Optimize jump label implementation for ARM64 Jiang Liu
2013-10-18 15:19 ` [PATCH v5 1/7] arm64: introduce basic aarch64 instruction decoding helpers Jiang Liu
2013-10-31 17:39 ` Catalin Marinas
2013-11-06 15:10 ` Jiang Liu
2013-10-18 15:19 ` [PATCH v5 2/7] arm64: introduce interfaces to hotpatch kernel and module code Jiang Liu
2013-10-30 0:12 ` Will Deacon
2013-11-03 15:55 ` Jiang Liu
2013-11-04 15:12 ` Sandeepa Prabhu
2013-11-06 10:41 ` Will Deacon
2013-11-06 16:12 ` Jiang Liu [this message]
2013-11-06 18:09 ` Will Deacon
2013-11-27 12:20 ` Will Deacon
2013-11-27 15:40 ` Jiang Liu
2013-11-28 22:39 ` AKASHI Takahiro
2013-10-18 15:19 ` [PATCH v5 3/7] arm64: move encode_insn_immediate() from module.c to insn.c Jiang Liu
2013-10-18 15:19 ` [PATCH v5 4/7] arm64: introduce aarch64_insn_gen_{nop|branch_imm}() helper functions Jiang Liu
2013-10-30 0:48 ` Will Deacon
2013-11-06 16:31 ` Jiang Liu
2013-11-06 16:45 ` Steven Rostedt
2013-11-06 18:02 ` Will Deacon
2013-10-18 15:19 ` [PATCH v5 5/7] arm64, jump label: detect %c support for ARM64 Jiang Liu
2013-10-30 0:49 ` Will Deacon
2013-11-06 16:32 ` Jiang Liu
2013-10-18 15:20 ` [PATCH v5 6/7] arm64, jump label: optimize jump label implementation Jiang Liu
2013-10-30 0:55 ` Will Deacon
2013-11-06 16:38 ` Jiang Liu
2013-10-18 15:20 ` [PATCH v5 7/7] jump_label: use defined macros instead of hard-coding for better readability Jiang Liu
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=527A6A5D.2050206@gmail.com \
--to=liuj97@gmail.com \
--cc=linux-arm-kernel@lists.infradead.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).