[PATCHv2 09/11] arm64: entry: fix non-NMI kernel<->kernel transitions

[Mark Rutland]

On Tue, Apr 27, 2021 at 03:15:39PM +0800, Zenghui Yu wrote:
> On 2021/4/26 21:39, Zenghui Yu wrote:
> > Hi Mark,
> > 
> > On 2021/4/26 17:21, Mark Rutland wrote:
> >
> > > diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S
> > > index 6acfc5e6b5e0..7d46c74a8706 100644
> > > --- a/arch/arm64/kernel/entry.S
> > > +++ b/arch/arm64/kernel/entry.S
> > > @@ -292,6 +292,8 @@ alternative_else_nop_endif
> > >  alternative_if ARM64_HAS_IRQ_PRIO_MASKING
> > >  	mrs_s	x20, SYS_ICC_PMR_EL1
> > >  	str	x20, [sp, #S_PMR_SAVE]
> > > +	orr	x20, x20, #GIC_PRIO_PSR_I_SET
> > > +	msr_s	SYS_ICC_PMR_EL1, x20
> > >  alternative_else_nop_endif
> > 
> > While this does fix the lockdep part, it breaks something else. The
> > sleep-in-atomic one stands out (which says, I've seen other splats
> > triggered with this diff), where irqs_disabled() in do_mem_abort() now
> > gets confused by the updated PMR (GIC_PRIO_IRQON | GIC_PRIO_PSR_I_SET).
> 
> Seem that this can be addressed by restoring pt_regs->pmr_save into PMR
> in local_daif_inherit() (before we restore the DAIF bits)?

I think so, yes.

Looking at this some more, I'm not sure whether the entry code should:

* ORR in GIC_PRIO_PSR_I_SET, matching gic_prio_irq_setup

* MOV in (GIC_PRIO_IRQON | GIC_PRIO_PSR_I_SET) matching
  gic_prio_kentry_setup

... as it's not clear to me why the two differ, nor whether we can
follow the same approach in both cases.

I'll dig a bit more through the history and see what I can dredge up,
unless Marc has any ideas.

Thanks,
Mark.