summaryrefslogtreecommitdiffstats
path: root/tools/perf/scripts/python/flamegraph.py
diff options
context:
space:
mode:
authorErwan Le Ray <erwan.leray@foss.st.com>2021-03-04 17:23:00 +0100
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>2021-03-10 09:34:10 +0100
commitad7676812437a00a4c6be155fc17926069f99084 (patch)
treedf710b54335c0cd32877ce3e47b0352ea47f47e6 /tools/perf/scripts/python/flamegraph.py
parent25a8e7611da5513b388165661b17173c26e12c04 (diff)
downloadlinux-ad7676812437a00a4c6be155fc17926069f99084.tar.gz
linux-ad7676812437a00a4c6be155fc17926069f99084.zip
serial: stm32: fix a deadlock condition with wakeup event
Deadlock issue is seen when enabling CONFIG_PROVE_LOCKING=Y, and uart console as wakeup source. Deadlock occurs when resuming from low power mode if system is waked up via usart console. The deadlock is triggered 100% when also disabling console suspend prior to go to suspend. Simplified call stack, deadlock condition: - stm32_console_write <-- spin_lock already held - print_circular_bug - pm_wakeup_dev_event <-- triggers lockdep as seen above - stm32_receive_chars - stm32_interrupt <-- wakeup via uart console, takes the lock So, revisit spin_lock in stm32-usart driver: - there is no need to hold the lock to access ICR (atomic clear of status flags) - only hold the lock inside stm32_receive_chars() routine (no need to call pm_wakeup_dev_event with lock held) - keep stm32_transmit_chars() routine called with lock held Fixes: 48a6092fb41f ("serial: stm32-usart: Add STM32 USART Driver") Signed-off-by: Erwan Le Ray <erwan.leray@foss.st.com> Signed-off-by: Fabrice Gasnier <fabrice.gasnier@foss.st.com> Link: https://lore.kernel.org/r/20210304162308.8984-6-erwan.leray@foss.st.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Diffstat (limited to 'tools/perf/scripts/python/flamegraph.py')
0 files changed, 0 insertions, 0 deletions