All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <gregkh@linuxfoundation.org>
To: "D. Starke" <daniel.starke@siemens.com>
Cc: linux-serial@vger.kernel.org, jirislaby@kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 1/9] tty: n_gsm: fix user open not possible at responder until initiator open
Date: Thu, 19 May 2022 18:17:26 +0200	[thread overview]
Message-ID: <YoZtlq3RkNU56xFx@kroah.com> (raw)
In-Reply-To: <20220519070757.2096-1-daniel.starke@siemens.com>

On Thu, May 19, 2022 at 09:07:49AM +0200, D. Starke wrote:
> From: Daniel Starke <daniel.starke@siemens.com>
> 
> 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")
> Cc: stable@vger.kernel.org
> Signed-off-by: Daniel Starke <daniel.starke@siemens.com>
> ---
>  drivers/tty/n_gsm.c | 31 +++++++++++++++++++++++++++++--
>  1 file changed, 29 insertions(+), 2 deletions(-)
> 
> This commit was not changed as there have been no comments on it in v1.
> 
> Link: https://lore.kernel.org/all/20220506144725.1946-1-daniel.starke@siemens.com/
> 
> diff --git a/drivers/tty/n_gsm.c b/drivers/tty/n_gsm.c
> index fd8b86dde525..08fea3e7674d 100644
> --- a/drivers/tty/n_gsm.c
> +++ b/drivers/tty/n_gsm.c
> @@ -1493,6 +1493,8 @@ static void gsm_dlci_close(struct gsm_dlci *dlci)
>  	if (debug & 8)
>  		pr_debug("DLCI %d goes closed.\n", dlci->addr);
>  	dlci->state = DLCI_CLOSED;
> +	/* Prevent us from sending data before the link is up again */
> +	dlci->constipated = true;
>  	if (dlci->addr != 0) {
>  		tty_port_tty_hangup(&dlci->port, false);
>  		spin_lock_irqsave(&dlci->lock, flags);
> @@ -1522,6 +1524,7 @@ static void gsm_dlci_open(struct gsm_dlci *dlci)
>  	del_timer(&dlci->t1);
>  	/* This will let a tty open continue */
>  	dlci->state = DLCI_OPEN;
> +	dlci->constipated = false;
>  	if (debug & 8)
>  		pr_debug("DLCI %d goes open.\n", dlci->addr);
>  	/* Send current modem state */
> @@ -1602,6 +1605,25 @@ static void gsm_dlci_begin_open(struct gsm_dlci *dlci)
>  	mod_timer(&dlci->t1, jiffies + gsm->t1 * HZ / 100);
>  }
>  
> +/**
> + *	gsm_dlci_wait_open	-	wait for channel open procedure
> + *	@dlci: DLCI to open
> + *
> + *	Wait for a DLCI opening from the other side. Asynchronously wait until
> + *	we get a SABM and set off timers and the responses.
> + */
> +static void gsm_dlci_wait_open(struct gsm_dlci *dlci)
> +{
> +	switch (dlci->state) {
> +	case DLCI_CLOSED:
> +	case DLCI_CLOSING:
> +		dlci->state = DLCI_OPENING;
> +		break;
> +	default:
> +		break;
> +	}
> +}

The documentation for this function is odd, you are not waiting for
anything.  You are just changing the state.  This makes no sense as-is,
sorry.

greg k-h

  parent reply	other threads:[~2022-05-19 16:17 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-19  7:07 [PATCH v2 1/9] tty: n_gsm: fix user open not possible at responder until initiator open D. Starke
2022-05-19  7:07 ` [PATCH v2 2/9] tty: n_gsm: fix tty registration before control channel open D. Starke
2022-05-19  7:07 ` [PATCH v2 3/9] tty: n_gsm: fix wrong queuing behavior in gsm_dlci_data_output() D. Starke
2022-05-19  7:07 ` [PATCH v2 4/9] tty: n_gsm: fix missing timer to handle stalled links D. Starke
2022-05-23 11:49   ` Jiri Slaby
2022-05-19  7:07 ` [PATCH v2 5/9] tty: n_gsm: fix non flow control frames during mux flow off D. Starke
2022-05-19  7:07 ` [PATCH v2 6/9] tty: n_gsm: fix deadlock and link starvation in outgoing data path D. Starke
2022-05-19  7:07 ` [PATCH v2 7/9] tty: n_gsm: fix packet re-transmission without open control channel D. Starke
2022-05-19  7:07 ` [PATCH v2 8/9] tty: n_gsm: fix resource allocation order in gsm_activate_mux() D. Starke
2022-05-19  7:07 ` [PATCH v2 9/9] tty: n_gsm: fix race condition in gsmld_write() D. Starke
2022-05-19 16:17 ` Greg KH [this message]
2022-05-23  8:45 [PATCH v2 1/9] tty: n_gsm: fix user open not possible at responder until initiator open Starke, Daniel
2022-05-23 12:09 ` Greg KH

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=YoZtlq3RkNU56xFx@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=daniel.starke@siemens.com \
    --cc=jirislaby@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-serial@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.