Re: [PATCH V2 net-next 1/2] net: qrtr: Prevent stale ports from sending

From: Bjorn Andersson
Date: Wed Sep 20 2023 - 08:44:11 EST


On Wed, Sep 20, 2023 at 11:03:16AM +0530, Sricharan Ramabadhran wrote:
> From: Chris Lew <quic_clew@xxxxxxxxxxx>
>
> If some client tries to initialize a QRTR socket during QRTR
> init, the socket will become stale after the ns(namespace server)
> binds to the QRTR control port. The client should close and reopen
> the QRTR socket once ENETRESET is posted to the stale socket.
>
> There is a possibility that a client tries to send to the NS before
> processing the ENETRESET. In the case of a NEW_SERVER control message,
> the control message will reach the NS and be forwarded to the firmware.
> The client will then process the ENETRESET closing and re-opening the
> socket which triggers a DEL_SERVER and then a second NEW_SERVER.
> This scenario will give an unnecessary disconnect to the clients on the
> firmware who were able to initialize on the first NEW_SERVER.
>
> This was seen when qrtr-ns was a separate application, but there is
> still a potential gap between AF_QIPCRTR socket register and when
> qrtr_ns_init binds to the socket where this issue can still occur.
>
> Signed-off-by: Chris Lew <quic_clew@xxxxxxxxxxx>
> Signed-off-by: Vignesh Viswanathan <quic_viswanat@xxxxxxxxxxx>
> Signed-off-by: Sricharan Ramabadhran <quic_srichara@xxxxxxxxxxx>

Reviewed-by: Bjorn Andersson <andersson@xxxxxxxxxx>

Regards,
Bjorn