watchdog: s3c2410: Fix potential deadlock on &wdt->lock

As &wdt->lock is acquired by hard irq s3c2410wdt_irq(),
other acquisition of the same lock under process context should
disable irq, otherwise deadlock could happen if the
irq preempt the execution while the lock is held in process context
on the same CPU.

[Deadlock Scenario]
s3c2410wdt_suspend()
    -> s3c2410wdt_stop()
    -> spin_lock(&wdt->lock)
        <irq iterrupt>
        -> s3c2410wdt_irq()
        -> s3c2410wdt_keepalive()
        -> spin_lock(&wdt->lock) (deadlock here)

[Deadlock Scenario]
s3c2410wdt_probe()
    -> s3c2410wdt_start()
    -> spin_lock(&wdt->lock)
        <irq iterrupt>
        -> s3c2410wdt_irq()
        -> s3c2410wdt_keepalive()
        -> spin_lock(&wdt->lock) (deadlock here)

[Deadlock Scenario]
s3c2410wdt_keepalive()
    -> spin_lock(&wdt->lock)
        <irq iterrupt>
        -> s3c2410wdt_irq()
        -> s3c2410wdt_keepalive()
        -> spin_lock(&wdt->lock) (deadlock here)

This flaw was found by an experimental static analysis tool I am
developing for irq-related deadlock, which reported the above
warning when analyzing the linux kernel 6.4-rc7 release.

The tentative patch fix the potential deadlock by spin_lock_irqsave()
under process context.

Signed-off-by: Chengfeng Ye <[email protected]>
Reviewed-by: Krzysztof Kozlowski <[email protected]>
Reviewed-by: Guenter Roeck <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Guenter Roeck <[email protected]>
Signed-off-by: Wim Van Sebroeck <[email protected]>

0 files changed, 0 insertions, 0 deletions