[PATCH 3/3] ARM: vfp: Use vfp_lock() in vfp_entry().

[Ard Biesheuvel]

On Tue, 27 Jun 2023 at 14:41, Sebastian Andrzej Siewior
<bigeasy at linutronix.de> wrote:
>
> On 2023-06-27 12:22:23 [+0200], Ard Biesheuvel wrote:
> > On Thu, 15 Jun 2023 at 12:17, Sebastian Andrzej Siewior
> > <bigeasy at linutronix.de> wrote:
> > >
> > > vfp_entry() is invoked from exception handler and is fully preemptible.
> > > It uses local_bh_disable() to remain uninterrupted while checking the
> > > VFP state.
> > > This is not working on PREEMPT_RT because local_bh_disable()
> > > synchronizes the relevant section but the context remains fully
> > > preemptible.
> > >
> > > Use vfp_lock() for uninterrupted access.
> > >
> > > VFP_bounce() is invoked from within vfp_entry() and may send a signal.
> > > Sending a signal uses spinlock_t which becomes a sleeping lock
> > > on PREEMPT_RT and must not be acquired within a preempt-disabled
> > > section. Move the vfp_raise_sigfpe() block outside of the
> > > preempt-disabled section.
> > >
> >
> > Isn't the latter a separate issue that predates the softirq changes?
> > If so, it should be fixed separately too, and backported to -stable
> > (unless nobody uses out-of-tree PREEMPT_RT with those kernels)
>
> This only affects the PREEMPT_RT tree and once this is settled I would
> ask to backport the PREEMPT_RT related fixes within the preempt-rt
> stable trees and not bother the official stable trees.
>
> Thanks for noting ;)
>

OK, so would it make sense to split this off into a separate patch,
and combine all the vfp_lock/unlock replacements into a second patch.

Note that Russell didn't pull my VFP work so it won't be landing in v6.5.