QMI CID leaks

[Aleksander Morgado]

Hey!


> On 14.4.2020 17.55, Teijo Kinnunen wrote:
>
> > Possibly this could also be something in qmi-proxy side. I assume it is
> > expected that even after MM disconnects from it, it's supposed to
> > execute all queued QMI operations. Looking at the code, it seems that if
> > sending the response from device_command_ready() fails for the first of
> > the QMI Release CID operations (which sounds plausible, in case MM has
> > disconnected), untrack_client() gets called and it may close the QMI
> > device, blocking the execution of the remaining QMI commands.
> >
> > I didn't actually debug it yet to find out if this is what really
> > happens, but maybe I can look at it tomorrow.
>
> OK, got it sorted now. What happens between MM and qmi-proxy is as follows:
> - MM sends 6x Release CID to qmi-proxy (using libqmi) and disconnects
>    immediately (qmi_device_close_async).
> - The socket handler in qmi-proxy (connection_readable_cb) receives
>    these messages in two batches. The first batch contains 2...3
>    Release CID messages (which are processed OK) and the second batch
>    contains the remaining ones. The second call has *both* G_IO_IN and
>    G_IO_HUP set. As connection_readable_cb() processes G_IO_HUP first, it
>    will never get to handle the remaining Release CID messages.
>    => This leads to CID leak.
>
> So it looks like this could be fixed most easily in qmi-proxy. I will
> post a patch candidate for review/merging to libqmi project soon...
>

That makes sense, and the patch is likely an easy one :) thanks for
debugging this.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/modemmanager-devel/attachments/20200415/95915991/attachment.htm>