From: Alan Cox <gnomes@lxorguk.ukuu.org.uk>
To: Sascha Hauer <s.hauer@pengutronix.de>
Cc: linux-kernel@vger.kernel.org, kernel@pengutronix.de,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Jiri Slaby <jslaby@suse.com>
Subject: Re: tty: closing n_gsm line discipline always times out
Date: Wed, 17 May 2017 16:23:58 +0100 [thread overview]
Message-ID: <20170517162358.14c0b011@alans-desktop> (raw)
In-Reply-To: <20170517134456.hx2dp6zszv6wyr6y@pengutronix.de>
On Wed, 17 May 2017 15:44:56 +0200
Sascha Hauer <s.hauer@pengutronix.de> wrote:
> Hi All,
>
> When the n_gsm line discipline is closed it wants to shutdown the line
> discipline properly and asks the link partner to end the mux protocol. This is
> done in gsm_cleanup_mux() around line 2050 in n_gsm.c:
>
> if (dlci) {
> gc = gsm_control_send(gsm, CMD_CLD, NULL, 0);
> if (gc)
> gsm_control_wait(gsm, gc);
> }
>
> The call stack is like this:
>
> (struct tty_ldisc_ops).close
> -> gsmld_close
> -> gsmld_detach_gsm
> -> gsm_cleanup_mux
>
> (struct tty_ldisc_ops).close is called at tty_release time or when the line
> discipline is changed. At tty_release time the tty is already shutdown, so we
> cannot send anything anymore. In this case our link partner never closes the
> mux protocol, which means we can never re-open it again. When instead the line
> discipline is changed back to N_TTY to close the protocol, gsm_control_send
> works fine, but the tty_ldisc is locked and thus the chars received by the UART
> never make it to the line discipline and gsm_control_wait times out.
>
> There's obviously something wrong here. Any ideas how to fix that? When we are
> not allowed to send/receive at tty_release time, do we need a new n_gsm specific
> ioctl to shutdown the mux?
Probably - it used to work fine but other changes in the core tty code
broke it, and I think because 99% of the users of that code are Android
they've not yet caught up with this decade 8)
The other option would be to just remove the CLD sending and have the
caller do whatever cleanup handling it wants in N_TTY ldisc. You can just
write() the frame rather than having an ioctl.
That said there are power management cases where being able to turn it
on/off without ldisc changing might be useful. However you've then got to
deal with all the locking of active sessions against being in down state.
So I think just having the caller use a write() in N_TTY would be simpler
since we'd have to change user space anyway.
Alan
next prev parent reply other threads:[~2017-05-17 15:24 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-17 13:44 tty: closing n_gsm line discipline always times out Sascha Hauer
2017-05-17 15:23 ` Alan Cox [this message]
2017-05-18 6:50 ` Sascha Hauer
2017-05-19 12:58 ` Alan Cox
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170517162358.14c0b011@alans-desktop \
--to=gnomes@lxorguk.ukuu.org.uk \
--cc=gregkh@linuxfoundation.org \
--cc=jslaby@suse.com \
--cc=kernel@pengutronix.de \
--cc=linux-kernel@vger.kernel.org \
--cc=s.hauer@pengutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox