Re: [RFC] x86/watchdog: Always disable watchdog before console_force_unlock()

[Andrew Cooper <andrew.cooper3@citrix.com>]

On 12/08/13 09:50, Jan Beulich wrote:
>>>> On 09.08.13 at 23:17, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>> Depending on the state of the conring and serial_tx_buffer,
>> console_force_unlock() can be a long running operation, usually because of
>> serial_start_sync()
>>
>> XenServer testing has found a reliable case where console_force_unlock() on
>> one PCPU takes long enough for another PCPU to timeout due to the watchdog
>> (such as waiting for a tlb flush callin).
>>
>> The watchdog timeout causes the second PCPU to repeat the
>> console_force_unlock(), at which point the first PCPU typically fails an
>> assertion in spin_unlock_irqrestore(&port->tx_lock) (because the tx_lock has
>> been unlocked behind itself).
>>
>> console_force_unlock() is only on emergency paths, so one way or another the
>> host is going down.  Disable the watchdog before forcing the console lock to
>> help prevent having pcpus completing with each other to bring the host down.
> So perhaps rather than calling watchdog_disable() before calling
> console_force_unlock(), would we not better call the former first
> thing from the latter?
>
> Jan
>

That was indeed my first attempt, but console_force_unlock() is common
while watchdog_* is x86.

I could convert the watchdog to arch specific.  I suppose it is
possible/likely that the Arm folk might want to implement and use
watchdogs ?

~Andrew