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

Peter Zijlstra peterz at infradead.org
Thu Oct 29 07:54:19 EDT 2020


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).




More information about the linux-arm-kernel mailing list