[PATCH v2] arm64: implement support for static call trampolines

Ard Biesheuvel ardb at kernel.org
Thu Oct 29 08:14:05 EDT 2020


On Thu, 29 Oct 2020 at 12:54, Peter Zijlstra <peterz at infradead.org> wrote:
>
> On Thu, Oct 29, 2020 at 12:49:52PM +0100, Ard Biesheuvel wrote:
> > On Thu, 29 Oct 2020 at 12:46, Peter Zijlstra <peterz at infradead.org> wrote:
> > >
> > > On Thu, Oct 29, 2020 at 11:58:52AM +0100, Ard Biesheuvel wrote:
> > > > On Thu, 29 Oct 2020 at 11:40, Peter Zijlstra <peterz at infradead.org> wrote:
> > >
> > > > > Would it make things easier if your trampoline consisted of two complete
> > > > > slots, between which you can flip?
> > > > >
> > > > > Something like:
> > > > >
> > > > >         0x00    B 0x24 / NOP
> > > > >         0x04    < slot 1 >
> > > > >                 ....
> > > > >         0x20
> > > > >         0x24    < slot 2 >
> > > > >                 ....
> > > > >         0x40
> > > > >
> > > > > Then each (20 byte) slot can contain any of the variants above and you
> > > > > can write the unused slot without stop-machine. Then, when the unused
> > > > > slot is populated, flip the initial instruction (like a static-branch),
> > > > > issue synchronize_rcu_tasks() and flip to using the other slot for next
> > > > > time.
> > > > >
> > > >
> > > > Once we've populated a slot and activated it, we have to assume that
> > > > it is live and we can no longer modify it freely.
> > >
> > > Urhm how so? Once you pass through synchronize_rcu_tasks() nobody should
> > > still be using the old one.
> >
> > But doesn't that require some RCU foo in the static call wrapper itself?
>
> Nope, synchronize_rcu_tasks() ensures that every task will pass a safe
> point (aka. voluntary schedule()) before returning. This then guarantees
> that, no matter where they were preempted, they'll have left (and will
> observe the new state).
>

Ah, wonderful. Yes, that does simplify things substantially.



More information about the linux-arm-kernel mailing list