From: Will Deacon <will@kernel.org>
To: Peter Zijlstra <peterz@infradead.org>
Cc: "chengjian (D)" <cj.chengjian@huawei.com>,
andrew.murray@arm.com, bristot@redhat.com,
jakub.kicinski@netronome.com, Kees Cook <keescook@chromium.org>,
"x86@kernel.org" <x86@kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
linux-arm-kernel@lists.infradead.org,
"Xiexiuqi (Xie XiuQi)" <xiexiuqi@huawei.com>,
Li Bin <huawei.libin@huawei.com>,
bobo.shaobowang@huawei.com
Subject: Re: Why is text_mutex used in jump_label_transform for x86_64
Date: Mon, 6 Apr 2020 15:10:20 +0100 [thread overview]
Message-ID: <20200406141020.GB3178@willie-the-truck> (raw)
In-Reply-To: <20200406091551.GG20730@hirez.programming.kicks-ass.net>
On Mon, Apr 06, 2020 at 11:15:51AM +0200, Peter Zijlstra wrote:
> On Mon, Apr 06, 2020 at 04:39:11PM +0800, chengjian (D) wrote:
> >
> > On 2020/3/20 18:27, Peter Zijlstra wrote:
> > > 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.
> >
> > Hi, Peter
> >
> > Thank you very much for your reply.
> >
> > X86 is a variable-length instruction, only one byte modification of the
> > instruction
> > can be regarded as atomic. so we must be very careful when modifying
> > instructions
> > concurrently.
>
> Close enough.
>
> > For other architectures such as ARM64, the modification of some instructions
> > can be
> > considered atomic, (Eg. nop -> jmp/b). The set of instructions that can be
> > executed
> > by one thread of execution as they are being modified by another thread of
> > execution
> > without requiring explicit synchronization.
> >
> > In ARM64 Architecture Reference Manual, I find that:
> > Concurrent modification and execution of instructions can lead to the
> > resulting instruction performing any behavior
> > that can be achieved by executing any sequence of instructions that can
> > be executed from the same Exception level,
> > except where each of the instruction before modification and the
> > instruction after modification is one of a B, BL, BRK,
> > HVC, ISB, NOP, SMC, or SVC instruction.
> > For the B, BL, BRK, HVC, ISB, NOP, SMC, and SVC instructions the
> > architecture guarantees that, after modification of the
> > instruction, behavior is consistent with execution of either:
> > • The instruction originally fetched.
> > • A fetch of the modified instruction
> >
> > So we can safely modify jump_label for ARM64(from NOP to b or form b to
> > NOP).
> >
> > Is my understanding correct?
>
> I think so; but I'm really not much of an ARM64 person. FWIW I think I
> remember Will saying the same is true of ARM (32bit) and they could
> implement the same optimization, but so far nobody has bothered doing
> so. But please, ask an ARM64 maintainer and don't take my word for this.
On 32-bit there are complications with Thumb-2 instructions where you can
have a mixture of 16-bit and 32-bit encodings, so you have to be pretty
careful there.
For arm64, we have aarch64_insn_patch_text_nosync() which we use to toggle
jump labels.
Will
next prev parent reply other threads:[~2020-04-06 14:10 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
2020-04-06 8:39 ` chengjian (D)
2020-04-06 9:15 ` Peter Zijlstra
2020-04-06 14:10 ` Will Deacon [this message]
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=20200406141020.GB3178@willie-the-truck \
--to=will@kernel.org \
--cc=andrew.murray@arm.com \
--cc=bobo.shaobowang@huawei.com \
--cc=bristot@redhat.com \
--cc=cj.chengjian@huawei.com \
--cc=huawei.libin@huawei.com \
--cc=jakub.kicinski@netronome.com \
--cc=keescook@chromium.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=peterz@infradead.org \
--cc=x86@kernel.org \
--cc=xiexiuqi@huawei.com \
/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).