RE: [External Mail] Re: [PATCH v4 6/7] net: wwan: t9xx: Add AT & MBIM WWAN ports

[Wu. JackBB (GSM)]

Hi Simon,

On ... sashiko wrote:
> > +static int mtk_port_wwan_write(...)
> > +	if (ret < 0)
> > +		return ret;
> > +
> > +	consume_skb(skb);
> > +	return 0;
>
> [Severity: High]
> If mtk_port_common_write() successfully sends the first few fragments
> but fails on subsequent ones ... does this code silently drop the
> remaining data?

This is a design limitation of the WWAN port API:
wwan_port_op_tx returns 0 for success or negative for error —
there is no mechanism to report partial writes back to the WWAN
core. The already-submitted fragments cannot be recalled from
the DMA engine. For the AT/MBIM control ports, messages are
small (typically under 1KB, within a single MTU). The
multi-fragment path is rarely exercised for control plane
traffic.

> > +static int mtk_port_wwan_write_blocking(...)
> > +	if (ret < 0)
> > +		return ret;
> > +
> > +	consume_skb(skb);
> > +	return 0;
>
> [Severity: High]
> Can the same silent drop of partially written SKBs happen here?

Same reasoning as above. The WWAN port API does not support
partial write reporting, and control plane messages are
typically within a single MTU.

> > +static int mtk_port_wwan_enable(...)
> > +	port->w_priv.w_port = wwan_create_port(...);
> > +	if (IS_ERR(port->w_priv.w_port)) {
>
> [Severity: High]
> Can a race condition occur here if wwan_create_port() fails?

mtk_port_wwan_enable() is called from the FSM thread during
the handshake sequence, before the port starts receiving data.
The CLDMA RX queue for this port has not been opened at this
point — RX data only arrives after the modem completes its
handshake. The RX path cannot observe the error pointer.

During teardown, mtk_port_wwan_disable() holds w_lock when
clearing w_port, and mtk_port_wwan_recv() checks w_port under
the same lock, so the RX path is properly synchronized.

Thanks.

Jack Wu