Crash after 'reboot' due to 9be4fd2c7723a

[Rafael J. Wysocki]

On Mon, May 23, 2016 at 10:59 PM, Fabio Estevam <festevam at gmail.com> wrote:
> On Mon, May 23, 2016 at 5:23 PM, Rafael J. Wysocki <rafael at kernel.org> wrote:
>
>> 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.
>
> It returns true because the kernel was built with CONFIG_SMP=y.
>
> On ARM we have:
>
> static inline bool arch_irq_work_has_interrupt(void)
> {
>     return is_smp();
> }
>
> and then:
>
> static inline bool is_smp(void)
> {
> #ifndef CONFIG_SMP
>     return false;
> #elif defined(CONFIG_SMP_ON_UP)
>     extern unsigned int smp_on_up;
>     return !!smp_on_up;
> #else
>     return true;
> #endif
> }
>
> So if CONFIG_SMP=y,  is_smp() returns 1.
>
> As I mentioned before, the reboot problem does not happen with CONFIG_SMP=n.

First, why don't the other ARM UP platforms have this problem when SMP
kernels are run on them?

Second, quite evidently, the platform says "I can raise interrupts for
IRQ works", but then it doesn't do that.  That doesn't seem
particularly consistent to me ...