QMI CID leaks

[Teijo Kinnunen]

Hi again,

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...

BR,

- Teijo