summaryrefslogtreecommitdiff
path: root/sound/spi/Makefile
diff options
context:
space:
mode:
authordaniel.starke@siemens.com <daniel.starke@siemens.com>2022-02-18 10:31:23 +0300
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>2022-03-02 13:48:09 +0300
commit92cab57ea6d7b24da33ea5979ce9acfe43077a02 (patch)
tree22400d39fedc6c038772027665b47e915ed6e927 /sound/spi/Makefile
parent06bce5327b760726bd82c65d96ed4aa9704f31a7 (diff)
downloadlinux-92cab57ea6d7b24da33ea5979ce9acfe43077a02.tar.xz
tty: n_gsm: fix deadlock in gsmtty_open()
commit a2ab75b8e76e455af7867e3835fd9cdf386b508f upstream. In the current implementation the user may open a virtual tty which then could fail to establish the underlying DLCI. The function gsmtty_open() gets stuck in tty_port_block_til_ready() while waiting for a carrier rise. This happens if the remote side fails to acknowledge the link establishment request in time or completely. At some point gsm_dlci_close() is called to abort the link establishment attempt. The function tries to inform the associated virtual tty by performing a hangup. But the blocking loop within tty_port_block_til_ready() is not informed about this event. The patch proposed here fixes this by resetting the initialization state of the virtual tty to ensure the loop exits and triggering it to make tty_port_block_til_ready() return. Fixes: e1eaea46bb40 ("tty: n_gsm line discipline") Cc: stable@vger.kernel.org Signed-off-by: Daniel Starke <daniel.starke@siemens.com> Link: https://lore.kernel.org/r/20220218073123.2121-7-daniel.starke@siemens.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Diffstat (limited to 'sound/spi/Makefile')
0 files changed, 0 insertions, 0 deletions