tty: n_gsm: fix user open not possible at responder until initiator open
authorDaniel Starke <daniel.starke@siemens.com>
Fri, 1 Jul 2022 06:16:44 +0000 (08:16 +0200)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Wed, 17 Aug 2022 12:24:04 +0000 (14:24 +0200)
commit3c8d5fdca88120b7d4193eee444375b86262cc65
treef5a1e2eabb92f98ab7fdc0360451439098ea00c5
parent794604fbd71651ad318e8ce11eebf22da7e87cea
tty: n_gsm: fix user open not possible at responder until initiator open

[ Upstream commit ac77f0077c3265197d378158c85a55eee6d21508 ]

After setting up the control channel on both sides the responder side may
want to open a virtual tty to listen on until the initiator starts an
application on a user channel. The current implementation allows the
open() but no other operation, like termios. These fail with EINVAL.
The responder sided application has no means to detect an open by the
initiator sided application this way. And the initiator sided applications
usually expect the responder sided application to listen on the user
channel upon open.
Set the user channel into half-open state on responder side once a user
application opens the virtual tty to allow IO operations on it.
Furthermore, keep the user channel constipated until the initiator side
opens it to give the responder sided application the chance to detect the
new connection and to avoid data loss if the responder sided application
starts sending before the user channel is open.

Fixes: e1eaea46bb40 ("tty: n_gsm line discipline")
Signed-off-by: Daniel Starke <daniel.starke@siemens.com>
Link: https://lore.kernel.org/r/20220701061652.39604-1-daniel.starke@siemens.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
drivers/tty/n_gsm.c