Crash after 'reboot' due to 9be4fd2c7723a

[Russell King - ARM Linux]

On Mon, May 23, 2016 at 05:59:37PM -0300, Fabio Estevam 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.

Read the code again.  There's three states:

1. CONFIG_SMP=n - it always returns false.
2. CONFIG_SMP=y, CONFIG_SMP_ON_UP=n - it always returns true.  Such a
   kernel can _only_ be run on SMP capable systems.
3. CONFIG_SMP=y, CONFIG_SMP_ON_UP=y - it returns depending on whether
   we detect that the CPU is SMP capable.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.