Crash after 'reboot' due to 9be4fd2c7723a

[Rafael J. Wysocki]

On Mon, May 23, 2016 at 10:16 PM, Rafael J. Wysocki <rafael at kernel.org> wrote:
> On Mon, May 23, 2016 at 8:28 PM, Russell King - ARM Linux
> <linux at armlinux.org.uk> wrote:
>> On Sat, May 21, 2016 at 02:56:20AM +0200, Rafael J. Wysocki wrote:
>>> The root of the problem seems to be arch_irq_work_raise() and specifically
>>> the __smp_cross_call function that appears to have problems.
>>
>> We've been through this before.  The bottom line is that on ARM, there
>> is major wide-spread understanding that we want to be able to run a
>> kernel compiled for SMP on uniprocessor hardware.
>>
>> This is something that's been going for years, and has worked fine for
>> years.
>>
>> Now, someone has introduced this irq work stuff.  Great.  But they
>> haven't considered that people want to be able to run a SMP kernel
>> on UP hardware which _may_ have no hardware present which is capable
>> of raising IPIs.
>>
>> I don't know what the situation is with the platform concerned here,
>> I don't know whether it uses the GIC (presumably, because it doesn't
>> NULL-pointer ref on calling smp_cross_call(), it is using the GIC.)
>> If so, the GIC isn't delivering the IPI because the IPI hardware is
>> missing.
>>
>> Now, whether we could detect whether the GIC is IPI capable, I've
>> no idea, I don't have such a platform I could run tests on.  People
>> don't give me hardware anymore now that arm-soc is split off from
>> core ARM maintanence - it all goes into Linaro build farms.  So I'm
>> powerless to help here.
>>
>> My attitude towards this is that it's a core kernel problem: the
>> core kernel is assuming that it can raise IPIs even on non-SMP
>> capable hardware.  Much non-SMP hardware doesn't have that ability.
>> While folk can try to push it into arch code, my feeling is that it
>> really needs to have a generic solution, even if it's some generic
>> solution that architectures in this situation can plug into.
>
> Well, this particular case isn't about IPIs at all.
>
> irq_work_queue() can work without IPIs and it works like that on other
> ARM platforms where SMP kernels are run on UP hardware (without IPI
> support).
>
> Something seems to be missing in kernel config or similar here, but I
> can't really say what it is right away.

For one, if that platform is not capable of raising interrupts for IRQ
works, I'm not sure why arch_irq_work_has_interrupt() returns true on
it.