Re: Dumb question: BKL on reboot ?

[Andrea Arcangeli]

On Thu, Aug 21, 2003 at 10:05:20AM +0200, Hannes Reinecke wrote:
> Dave Hansen wrote:
> [ .. ]
> >
> >Or, are you saying that a CPU could have the BKL, and have
> >stop_this_cpu() called on it?  I guess we could add
> >release_kernel_lock() to stop_this_cpu().
> Exactly what happened here. CPU#1 entered sys_reboot, got BKL and 
> prepared to stop. It will never release BKL, leaving a nice big window 
> for CPU#0 to deadlock.

if that was really the case it shouldn't deadlock, because CPU0
shouldn't depend on a big kernel lock to be able to re-enable the irqs,
and to receive the IPI. Nor any IPI handler could ever be allowed to
take the big kernel lock.

Unless you can demonstrate a dependency on the big kernel lock for CPU0
to re-enable the irqs eventually, I can't see how the above could
deadlock.

The only clear deadlock prone thing I can see from the code is the IPI
handler looping forever w/o allowing the stopped cpu to release all its
underlying spinlocks. Not sure exactly how this generates the deadlock
in practice, but you only need to hit one of the held spinlocks
(including possibly the BKL) in the context of the reboot "cpu" to hang
forever during reboot. Looping forever and giving the OK to reboot the
machine from the context of a kernel thread instead of an IPI will fix
it as far as I can tell.

Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/