Re: [PATCH 1/1] tty: n_gsm: fix missing modem controls after DLCI open in convergence layer type 2

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:

Pre-existing issues:
- [High] Threads waiting in `gsm_control_wait` may hang forever in `TASK_UNINTERRUPTIBLE` if the GSM mux is concurrently shut down, also leading to a memory leak of the control object.
- [High] Lockless read-modify-write of `dlci->modem_tx` leading to lost virtual V.24 control signals and broken hardware flow control.
--

commit 94af07ea4775d3698d9b5b43641a19696873abc0
Author: Daniel Starke <daniel.starke@siemens.com>

tty: n_gsm: fix missing modem controls after DLCI open in convergence layer type 2

This commit updates virtual V.24 control signals by transmitting an empty data
frame in advanced option mode with convergence layer type 2. It introduces a
wait flag to gsm_modem_update() and gsm_modem_upd_via_msc() to control waiting
for the MSC command response. The obsolete gsm_modem_send_initial_msc() is
also removed.

> diff --git a/drivers/tty/n_gsm.c b/drivers/tty/n_gsm.c
> --- a/drivers/tty/n_gsm.c
> +++ b/drivers/tty/n_gsm.c

[ ... ]

> @@ -4155,41 +4155,22 @@ static int gsm_modem_upd_via_msc(struct gsm_dlci *dlci, u8 brk)
>  		modembits[2] = (brk << 4) | 2 | EA; /* Length, Break, EA */
>  		len++;
>  	}
> +	if (!wait)
> +		return gsm_control_command(dlci->gsm, CMD_MSC, modembits, len);
>  	ctrl = gsm_control_send(dlci->gsm, CMD_MSC, modembits, len);
>  	if (ctrl == NULL)
>  		return -ENOMEM;
>  	return gsm_control_wait(dlci->gsm, ctrl);
>  }

[Severity: High]
This isn't a bug introduced by this patch, but can threads waiting in
gsm_control_wait() hang forever?

If a thread queues a control command here and blocks in gsm_control_wait(),
and the physical serial port is closed concurrently, gsmld_close() will call
gsm_cleanup_mux().

gsm_cleanup_mux() calls timer_delete_sync(&gsm->t2_timer), which cancels the
retransmit timer without aborting the pending command. Does this mean the wake
condition for wait_event(gsm->event, control->done == 1) will never be met,
leading to an unkillable TASK_UNINTERRUPTIBLE task and leaking the control
object?

[ ... ]

> @@ -4265,7 +4246,7 @@ static void gsm_dtr_rts(struct tty_port *port, bool active)
>  		modem_tx &= ~(TIOCM_DTR | TIOCM_RTS);
>  	if (modem_tx != dlci->modem_tx) {
>  		dlci->modem_tx = modem_tx;
> -		gsm_modem_update(dlci, 0);
> +		gsm_modem_update(dlci, 0, true);
>  	}
>  }

[Severity: High]
This is a pre-existing issue, but does this lockless read-modify-write of
dlci->modem_tx risk losing virtual V.24 control signals?

If gsmtty_throttle() is called (often from softirq context when receive buffers
fill up) to clear TIOCM_RTS, it updates dlci->modem_tx locklessly.

Concurrently, if a userspace ioctl calls gsmtty_tiocmset(), it also performs
a lockless read-modify-write on dlci->modem_tx.

If these updates overlap, could the throttle state change be overwritten and
lost? This might cause the local system to believe it has throttled the peer,
while the RTS bit remains set, leading to receive buffer overflows.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260826063026.2472-1-daniel.starke@siemens.com?part=1