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
