summaryrefslogtreecommitdiff
path: root/scripts/gdb/linux/proc.py
diff options
context:
space:
mode:
authorUwe Kleine-König <u.kleine-koenig@pengutronix.de>2022-02-15 19:02:36 +0300
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>2022-02-26 12:03:21 +0300
commitdedab69fd650ea74710b2e626e63fd35584ef773 (patch)
tree99b91ad73e326e39b40d2aa826fde68b78a4c40d /scripts/gdb/linux/proc.py
parent5427c352a993748846263262e70652216e75b2a5 (diff)
downloadlinux-dedab69fd650ea74710b2e626e63fd35584ef773.tar.xz
serial: 8250: Fix race condition in RTS-after-send handling
Set em485->active_timer = NULL isn't always enough to take out the stop timer. While there is a check that it acts in the right state (i.e. waiting for RTS-after-send to pass after sending some chars) but the following might happen: - CPU1: some chars send, shifter becomes empty, stop tx timer armed - CPU0: more chars send before RTS-after-send expired - CPU0: shifter empty irq, port lock taken - CPU1: tx timer triggers, waits for port lock - CPU0: em485->active_timer = &em485->stop_tx_timer, hrtimer_start(), releases lock() - CPU1: get lock, see em485->active_timer == &em485->stop_tx_timer, tear down RTS too early This fix bases on research done by Steffen Trumtrar. Fixes: b86f86e8e7c5 ("serial: 8250: fix potential deadlock in rs485-mode") Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20220215160236.344236-1-u.kleine-koenig@pengutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Diffstat (limited to 'scripts/gdb/linux/proc.py')
0 files changed, 0 insertions, 0 deletions