Re: Why is text_mutex used in jump_label_transform for x86_64

[chengjian (D)]

On 2020/4/6 22:10, Will Deacon wrote:
> 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
>
> .


Hi, Peter and Will

ÂÂÂ I have learned.

ÂÂÂ I truly appreciate your timely help.


ÂÂÂ Thanks a lot.

ÂÂÂ -- Cheng Jian