From: takahiro.akashi@linaro.org (AKASHI Takahiro)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v5 2/7] arm64: introduce interfaces to hotpatch kernel and module code
Date: Fri, 29 Nov 2013 07:39:27 +0900 [thread overview]
Message-ID: <5297C61F.8000801@linaro.org> (raw)
In-Reply-To: <527671E9.8040704@gmail.com>
On 11/04/2013 12:55 AM, Jiang Liu wrote:
> On 10/30/2013 08:12 AM, Will Deacon wrote:
>> Hi Jinag Liu,
>>
>>> +static __always_inline u32 aarch64_insn_read(void *addr)
>>> +{
>>> + return le32_to_cpu(*(u32 *)addr);
>>> +}
>>>
>>> +static __always_inline void aarch64_insn_write(void *addr, u32 insn)
>>> +{
>>> + *(u32 *)addr = cpu_to_le32(insn);
>>> +}
>>
>> I wouldn't bother with these helpers. You should probably be using
>> probe_kernel_address or similar, then doing the endianness swabbing on the
>> return value in-line.
> How about keeping and refining aarch64_insn_read/write interfaces
> by using probe_kernel_address()? I think they may be used in other
> places when supporting big endian ARM64 kernel.
I prefer it (using probe_kernel_read/write) for my ftrace patch.
I would be able to replace some portion of my own function (ftrace_modify_code)
to aarch64_insn_patch_text_nosync().
See my comment here:
http://lists.infradead.org/pipermail/linux-arm-kernel/2013-October/207001.html
([PATCH 2/6])
Current implementation assumes stop_machine (via arch_ftrace_update_code()
in generic ftrace), and, given the discussion btw you and Will, I wonder
that it might be relaxed because ftrace on arm64 modifies only a single branch
or nop instruction at any time.
-Takahiro AKASHI
WARNING: multiple messages have this Message-ID (diff)
From: AKASHI Takahiro <takahiro.akashi@linaro.org>
To: Jiang Liu <liuj97@gmail.com>, Will Deacon <will.deacon@arm.com>
Cc: Sandeepa Prabhu <sandeepa.prabhu@linaro.org>,
Catalin Marinas <Catalin.Marinas@arm.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Steven Rostedt <rostedt@goodmis.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH v5 2/7] arm64: introduce interfaces to hotpatch kernel and module code
Date: Fri, 29 Nov 2013 07:39:27 +0900 [thread overview]
Message-ID: <5297C61F.8000801@linaro.org> (raw)
In-Reply-To: <527671E9.8040704@gmail.com>
On 11/04/2013 12:55 AM, Jiang Liu wrote:
> On 10/30/2013 08:12 AM, Will Deacon wrote:
>> Hi Jinag Liu,
>>
>>> +static __always_inline u32 aarch64_insn_read(void *addr)
>>> +{
>>> + return le32_to_cpu(*(u32 *)addr);
>>> +}
>>>
>>> +static __always_inline void aarch64_insn_write(void *addr, u32 insn)
>>> +{
>>> + *(u32 *)addr = cpu_to_le32(insn);
>>> +}
>>
>> I wouldn't bother with these helpers. You should probably be using
>> probe_kernel_address or similar, then doing the endianness swabbing on the
>> return value in-line.
> How about keeping and refining aarch64_insn_read/write interfaces
> by using probe_kernel_address()? I think they may be used in other
> places when supporting big endian ARM64 kernel.
I prefer it (using probe_kernel_read/write) for my ftrace patch.
I would be able to replace some portion of my own function (ftrace_modify_code)
to aarch64_insn_patch_text_nosync().
See my comment here:
http://lists.infradead.org/pipermail/linux-arm-kernel/2013-October/207001.html
([PATCH 2/6])
Current implementation assumes stop_machine (via arch_ftrace_update_code()
in generic ftrace), and, given the discussion btw you and Will, I wonder
that it might be relaxed because ftrace on arm64 modifies only a single branch
or nop instruction at any time.
-Takahiro AKASHI
next prev parent reply other threads:[~2013-11-28 22:39 UTC|newest]
Thread overview: 54+ 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 ` Jiang Liu
2013-10-18 15:19 ` [PATCH v5 1/7] arm64: introduce basic aarch64 instruction decoding helpers Jiang Liu
2013-10-18 15:19 ` Jiang Liu
2013-10-31 17:39 ` Catalin Marinas
2013-10-31 17:39 ` Catalin Marinas
2013-11-06 15:10 ` Jiang Liu
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-18 15:19 ` Jiang Liu
2013-10-30 0:12 ` Will Deacon
2013-10-30 0:12 ` Will Deacon
2013-11-03 15:55 ` Jiang Liu
2013-11-03 15:55 ` Jiang Liu
2013-11-04 15:12 ` Sandeepa Prabhu
2013-11-04 15:12 ` Sandeepa Prabhu
2013-11-06 10:41 ` Will Deacon
2013-11-06 10:41 ` Will Deacon
2013-11-06 16:12 ` Jiang Liu
2013-11-06 16:12 ` Jiang Liu
2013-11-06 18:09 ` Will Deacon
2013-11-06 18:09 ` Will Deacon
2013-11-27 12:20 ` Will Deacon
2013-11-27 12:20 ` Will Deacon
2013-11-27 15:40 ` Jiang Liu
2013-11-27 15:40 ` Jiang Liu
2013-11-28 22:39 ` AKASHI Takahiro [this message]
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 ` 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-18 15:19 ` Jiang Liu
2013-10-30 0:48 ` Will Deacon
2013-10-30 0:48 ` Will Deacon
2013-11-06 16:31 ` Jiang Liu
2013-11-06 16:31 ` Jiang Liu
2013-11-06 16:45 ` Steven Rostedt
2013-11-06 16:45 ` Steven Rostedt
2013-11-06 18:02 ` Will Deacon
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-18 15:19 ` Jiang Liu
2013-10-30 0:49 ` Will Deacon
2013-10-30 0:49 ` Will Deacon
2013-11-06 16:32 ` Jiang Liu
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-18 15:20 ` Jiang Liu
2013-10-30 0:55 ` Will Deacon
2013-10-30 0:55 ` Will Deacon
2013-11-06 16:38 ` Jiang Liu
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
2013-10-18 15:20 ` 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=5297C61F.8000801@linaro.org \
--to=takahiro.akashi@linaro.org \
--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 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.