From: Peter Zijlstra <peterz@infradead•org>
To: "chengjian (D)" <cj.chengjian@huawei•com>
Cc: jakub.kicinski@netronome•com, Kees Cook <keescook@chromium•org>,
"Xiexiuqi \(Xie XiuQi\)" <xiexiuqi@huawei•com>,
"x86@kernel•org" <x86@kernel•org>,
"linux-kernel@vger•kernel.org" <linux-kernel@vger•kernel.org>,
bobo.shaobowang@huawei•com, Li Bin <huawei.libin@huawei•com>,
andrew.murray@arm•com, bristot@redhat•com,
linux-arm-kernel@lists•infradead.org
Subject: Re: Why is text_mutex used in jump_label_transform for x86_64
Date: Fri, 20 Mar 2020 11:27:09 +0100 [thread overview]
Message-ID: <20200320102709.GC20696@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <f7f686f2-4f28-1763-dd19-43eff6a5a8f2@huawei.com>
On Thu, Mar 19, 2020 at 09:49:04PM +0800, chengjian (D) wrote:
> Hi，everyone
>
> I'm sorry to disturb you. I have a problem about jump_label, and a bit
> confused about the code
>
> I noticed that text_mutex is used in this function under x86_64
> architecture,
> but other architectures do not.
>
> in arch/x86/kernel/jump_label.c
> static void __ref jump_label_transform(struct jump_entry *entry,
> enum jump_label_type type,
> int init)
> {
> mutex_lock(&text_mutex);
> __jump_label_transform(entry, type, init);
> mutex_unlock(&text_mutex);
>
> in arch/arm64/kernel/jump_label.c
>
> void arch_jump_label_transform(struct jump_entry *entry,
> enum jump_label_type type)
> {
> void *addr = (void *)jump_entry_code(entry);
> u32 insn;
>
> if (type == JUMP_LABEL_JMP) {
> insn =
> aarch64_insn_gen_branch_imm(jump_entry_code(entry),
> jump_entry_target(entry),
> AARCH64_INSN_BRANCH_NOLINK);
> } else {
> insn = aarch64_insn_gen_nop();
> }
>
> aarch64_insn_patch_text_nosync(addr, insn);
> }
>
>
> Is there anything wrong with x86
>
> or
>
> is this missing for other architectures?
It depends on the architecture details of how self-modifying code works.
In particular, x86 is a variable instruction length architecture and
needs extreme care -- it's implementation requires there only be a
single text modifier at any one time, hence the use of text_mutex.
ARM64 OTOH is, like most RISC based architectures, a fixed width
instruction architecture. And in particular it can re-write certain
(branch) instructions with impunity (see their
aarch64_insn_patch_text_nosync()). Which is why they don't need
additional serialization.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists•infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2020-03-20 10:27 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-19 13:49 Why is text_mutex used in jump_label_transform for x86_64 chengjian (D)
2020-03-20 10:27 ` Peter Zijlstra [this message]
2020-04-06 8:39 ` chengjian (D)
2020-04-06 9:15 ` Peter Zijlstra
2020-04-06 14:10 ` Will Deacon
2020-04-08 1:17 ` chengjian (D)
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=20200320102709.GC20696@hirez.programming.kicks-ass.net \
--to=peterz@infradead$(echo .)org \
--cc=andrew.murray@arm$(echo .)com \
--cc=bobo.shaobowang@huawei$(echo .)com \
--cc=bristot@redhat$(echo .)com \
--cc=cj.chengjian@huawei$(echo .)com \
--cc=huawei.libin@huawei$(echo .)com \
--cc=jakub.kicinski@netronome$(echo .)com \
--cc=keescook@chromium$(echo .)org \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
--cc=linux-kernel@vger$(echo .)kernel.org \
--cc=x86@kernel$(echo .)org \
--cc=xiexiuqi@huawei$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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