Message ID | 1680095250-21032-1-git-send-email-quic_srichara@quicinc.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:b0ea:0:b0:3b6:4342:cba0 with SMTP id b10csp401037vqo; Wed, 29 Mar 2023 06:10:44 -0700 (PDT) X-Google-Smtp-Source: AKy350brgOUQY1jB9fHNmt7JKmhkz/aZ5Du80LVpL+tLauK1117QxK0EqLdovvoWSc5HHWZMzjOg X-Received: by 2002:a17:907:20ee:b0:930:6e31:3c11 with SMTP id rh14-20020a17090720ee00b009306e313c11mr20578417ejb.70.1680095444105; Wed, 29 Mar 2023 06:10:44 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1680095444; cv=none; d=google.com; s=arc-20160816; b=zhmGrnOQ64LSWybb2t5Mcd4nZJhMKhwnGtjQEAWLKKxxSSvwznwGqhezL1qgJEgEUB 0YNWmb0VSyRQlZnLfTXCuY9Eq/gXD1RU+C+NuwkN8xaTJ8noH8rM6SRoh32yNaBfbo+/ V0O3RGvaxrbfzlHfVxbCIPQuJRSau6bodWtR/jlhwy/u4QJfuraOQ+WUT1Sr7zvgbIj7 sufZDlpH8HcsmgyR6DCDVKUwcNrg5srJqyBecZ8AaJBp5cbQO1MWQvra/G7GhwxgBqK8 fDSizeg3X2KIeB0meE9U343T6GS4SNoQ5QCAJizHwppabSsTYuBuUAW4u9ofdv5NWoMR weCQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:message-id:date:subject:to:from :dkim-signature; bh=ukV2puvT6Yb9ovva4Gb5MV+nAbKsW5aWmpTLdH48Cqs=; b=T58fVWxt/Zm2WugwF18jwMcXS2EPbrb2A0xpzm80QfQUyPu3hvPMsOIJ2OX+UoYkS6 L/xQd2E2njZ15+vcvNAetLhYfMnLJe4spVtqTK0E6jLEb3iuZKGEo9GxLPPR7GTBEfxK aMBuG+sAI4s/z9kenW7FI5ncME16gj78JFwReITDh7wDSXhM2MDnK1U8bRts/ZEzyc1G jkWQt01XZvMONVNa60cxqvsUHgcMC4ho3uJGA+xC+DgBVHXQ/vGGEb+XYCNtcbiVCJJ0 C0DvWqvf/g9WIr6Y7aMe0uNXNM3TvBGqcmPjWoes28iIafU4H8EF2CmxeLOeloNu1Yzz JhPA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@quicinc.com header.s=qcppdkim1 header.b=d9Toxc4o; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=quicinc.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id i15-20020a1709061ccf00b0092b97d144d0si34958160ejh.157.2023.03.29.06.10.20; Wed, 29 Mar 2023 06:10:44 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@quicinc.com header.s=qcppdkim1 header.b=d9Toxc4o; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=quicinc.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229720AbjC2NIJ (ORCPT <rfc822;rua109.linux@gmail.com> + 99 others); Wed, 29 Mar 2023 09:08:09 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56010 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230095AbjC2NID (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Wed, 29 Mar 2023 09:08:03 -0400 Received: from mx0b-0031df01.pphosted.com (mx0b-0031df01.pphosted.com [205.220.180.131]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6F14DD2; Wed, 29 Mar 2023 06:07:53 -0700 (PDT) Received: from pps.filterd (m0279869.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 32TCf6lM030891; Wed, 29 Mar 2023 13:07:44 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quicinc.com; h=from : to : subject : date : message-id : mime-version : content-type; s=qcppdkim1; bh=ukV2puvT6Yb9ovva4Gb5MV+nAbKsW5aWmpTLdH48Cqs=; b=d9Toxc4oMkQthJt0ZHb4DdRIokLJyIOeloP8/zLa1eMM84Ae9GsZmRHMbFrQbJDPF8bI mnbceBeZ+F9nPa/H9bU/pguFOlLWwGMp0ojgticSwOYSShwRutH2pXe29p7de/nrFpkg 2X6sTqcXQ2b8D1NYMcYe/QQXEHvXOPBDONQXMg7t8jkZDS2X0bpfYzB3Y5K/5o1EsbMv 3mdOBu0uq14H/o6gtq1N8bgksUDW/2eOkjdgccMeTU8mhylW3hJJl8xWlGO4bWh8qhRs okFrKJhClz450Lrm6oehabpdw7+o4Kz6oG4Ssr+Usjn67R3laEtqoPSgY8nsmEYRlHew vw== Received: from nalasppmta04.qualcomm.com (Global_NAT1.qualcomm.com [129.46.96.20]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 3pkx4tbha9-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 29 Mar 2023 13:07:44 +0000 Received: from nalasex01c.na.qualcomm.com (nalasex01c.na.qualcomm.com [10.47.97.35]) by NALASPPMTA04.qualcomm.com (8.17.1.5/8.17.1.5) with ESMTPS id 32TD7hUN014868 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 29 Mar 2023 13:07:43 GMT Received: from srichara-linux.qualcomm.com (10.80.80.8) by nalasex01c.na.qualcomm.com (10.47.97.35) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.42; Wed, 29 Mar 2023 06:07:39 -0700 From: Sricharan R <quic_srichara@quicinc.com> To: <mani@kernel.org>, <manivannan.sadhasivam@linaro.org>, <davem@davemloft.net>, <edumazet@google.com>, <kuba@kernel.org>, <pabeni@redhat.com>, <linux-arm-msm@vger.kernel.org>, <netdev@vger.kernel.org>, <linux-kernel@vger.kernel.org> Subject: [PATCH] net: qrtr: Do not do DEL_SERVER broadcast after DEL_CLIENT Date: Wed, 29 Mar 2023 18:37:30 +0530 Message-ID: <1680095250-21032-1-git-send-email-quic_srichara@quicinc.com> X-Mailer: git-send-email 2.7.4 MIME-Version: 1.0 Content-Type: text/plain X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: nasanex01a.na.qualcomm.com (10.52.223.231) To nalasex01c.na.qualcomm.com (10.47.97.35) X-QCInternal: smtphost X-Proofpoint-Virus-Version: vendor=nai engine=6200 definitions=5800 signatures=585085 X-Proofpoint-GUID: ---nnJxp7NfEzLz4spvnc47KXR4gg8Zd X-Proofpoint-ORIG-GUID: ---nnJxp7NfEzLz4spvnc47KXR4gg8Zd X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.254,Aquarius:18.0.942,Hydra:6.0.573,FMLib:17.11.170.22 definitions=2023-03-29_06,2023-03-28_02,2023-02-09_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 clxscore=1011 malwarescore=0 spamscore=0 bulkscore=0 phishscore=0 suspectscore=0 impostorscore=0 mlxlogscore=999 lowpriorityscore=0 priorityscore=1501 mlxscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2303200000 definitions=main-2303290105 X-Spam-Status: No, score=-0.2 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1761707760387714939?= X-GMAIL-MSGID: =?utf-8?q?1761707760387714939?= |
Series |
net: qrtr: Do not do DEL_SERVER broadcast after DEL_CLIENT
|
|
Commit Message
Sricharan Ramabadhran
March 29, 2023, 1:07 p.m. UTC
When the qrtr socket is released, qrtr_port_remove gets called, which broadcasts a DEL_CLIENT. After this DEL_SERVER is also additionally broadcasted, which becomes NOP, but triggers the below error msg. "failed while handling packet from 2:-2", since remote node already acted upon on receiving the DEL_CLIENT, once again when it receives the DEL_SERVER, it returns -ENOENT. Fixing it by not sending a 'DEL_SERVER' to remote when a 'DEL_CLIENT' was sent for that port. Signed-off-by: Ram Kumar D <quic_ramd@quicinc.com> Signed-off-by: Sricharan R <quic_srichara@quicinc.com> --- Note: Functionally tested on 5.4 kernel and compile tested on 6.3 TOT net/qrtr/ns.c | 16 ++++++++++------ 1 file changed, 10 insertions(+), 6 deletions(-)
Comments
On Wed, 29 Mar 2023 18:37:30 +0530 Sricharan R wrote: > When the qrtr socket is released, qrtr_port_remove gets called, which > broadcasts a DEL_CLIENT. After this DEL_SERVER is also additionally > broadcasted, which becomes NOP, but triggers the below error msg. > > "failed while handling packet from 2:-2", since remote node already > acted upon on receiving the DEL_CLIENT, once again when it receives > the DEL_SERVER, it returns -ENOENT. > > Fixing it by not sending a 'DEL_SERVER' to remote when a 'DEL_CLIENT' > was sent for that port. You use the word "fix" so please add a Fixes tag. > Signed-off-by: Ram Kumar D <quic_ramd@quicinc.com> > Signed-off-by: Sricharan R <quic_srichara@quicinc.com> Spell out full names, please.
On Wed, Mar 29, 2023 at 06:37:30PM +0530, Sricharan R wrote: > When the qrtr socket is released, qrtr_port_remove gets called, which > broadcasts a DEL_CLIENT. After this DEL_SERVER is also additionally > broadcasted, which becomes NOP, but triggers the below error msg. > > "failed while handling packet from 2:-2", since remote node already > acted upon on receiving the DEL_CLIENT, once again when it receives > the DEL_SERVER, it returns -ENOENT. > > Fixing it by not sending a 'DEL_SERVER' to remote when a 'DEL_CLIENT' > was sent for that port. > Can you share the qrtr trace when this happens to help me understand the flow? - Mani > Signed-off-by: Ram Kumar D <quic_ramd@quicinc.com> > Signed-off-by: Sricharan R <quic_srichara@quicinc.com> > --- > Note: Functionally tested on 5.4 kernel and compile tested on 6.3 TOT > > net/qrtr/ns.c | 16 ++++++++++------ > 1 file changed, 10 insertions(+), 6 deletions(-) > > diff --git a/net/qrtr/ns.c b/net/qrtr/ns.c > index 722936f..6fbb195 100644 > --- a/net/qrtr/ns.c > +++ b/net/qrtr/ns.c > @@ -274,7 +274,7 @@ static struct qrtr_server *server_add(unsigned int service, > return NULL; > } > > -static int server_del(struct qrtr_node *node, unsigned int port) > +static int server_del(struct qrtr_node *node, unsigned int port, bool del_server) > { > struct qrtr_lookup *lookup; > struct qrtr_server *srv; > @@ -287,7 +287,7 @@ static int server_del(struct qrtr_node *node, unsigned int port) > radix_tree_delete(&node->servers, port); > > /* Broadcast the removal of local servers */ > - if (srv->node == qrtr_ns.local_node) > + if (srv->node == qrtr_ns.local_node && del_server) > service_announce_del(&qrtr_ns.bcast_sq, srv); > > /* Announce the service's disappearance to observers */ > @@ -373,7 +373,7 @@ static int ctrl_cmd_bye(struct sockaddr_qrtr *from) > } > slot = radix_tree_iter_resume(slot, &iter); > rcu_read_unlock(); > - server_del(node, srv->port); > + server_del(node, srv->port, true); > rcu_read_lock(); > } > rcu_read_unlock(); > @@ -459,10 +459,14 @@ static int ctrl_cmd_del_client(struct sockaddr_qrtr *from, > kfree(lookup); > } > > - /* Remove the server belonging to this port */ > + /* Remove the server belonging to this port > + * Given that DEL_CLIENT is already broadcasted > + * by port_remove, no need to send DEL_SERVER for > + * the same port to remote > + */ > node = node_get(node_id); > if (node) > - server_del(node, port); > + server_del(node, port, false); > > /* Advertise the removal of this client to all local servers */ > local_node = node_get(qrtr_ns.local_node); > @@ -567,7 +571,7 @@ static int ctrl_cmd_del_server(struct sockaddr_qrtr *from, > if (!node) > return -ENOENT; > > - return server_del(node, port); > + return server_del(node, port, true); > } > > static int ctrl_cmd_new_lookup(struct sockaddr_qrtr *from, > -- > 2.7.4 >
On 3/30/2023 11:54 AM, Manivannan Sadhasivam wrote: > On Wed, Mar 29, 2023 at 06:37:30PM +0530, Sricharan R wrote: >> When the qrtr socket is released, qrtr_port_remove gets called, which >> broadcasts a DEL_CLIENT. After this DEL_SERVER is also additionally >> broadcasted, which becomes NOP, but triggers the below error msg. >> >> "failed while handling packet from 2:-2", since remote node already >> acted upon on receiving the DEL_CLIENT, once again when it receives >> the DEL_SERVER, it returns -ENOENT. >> >> Fixing it by not sending a 'DEL_SERVER' to remote when a 'DEL_CLIENT' >> was sent for that port. >> > > Can you share the qrtr trace when this happens to help me understand the flow? Flow is like this. IPQ SDX --- ---- qrtr_release qrtr_port_remove qrtr_send_del_client | | | | RX CTRL: cmd:0x6 addr[0x2:0x40d4]<-----------| (qrtr_send_client broadcasts it to | the remote, | IPQ cleans up the port) | | ctrl_cmd_del_client (send_del_client also forwards the DEL_CLIENT to internal ns.c. Which then again sends DEL_server to same port to remote) | | RX CTRL: cmd:0x5 SVC[0x1389:0x1] | addr[0x2:0x40d4] <-------------------- ---| (IPQ on receiving the DEL_SERVER on same port throws the message "failed while handling packet from 2:-2") Regards, Sricharan
On 3/30/2023 10:02 AM, Jakub Kicinski wrote: > On Wed, 29 Mar 2023 18:37:30 +0530 Sricharan R wrote: >> When the qrtr socket is released, qrtr_port_remove gets called, which >> broadcasts a DEL_CLIENT. After this DEL_SERVER is also additionally >> broadcasted, which becomes NOP, but triggers the below error msg. >> >> "failed while handling packet from 2:-2", since remote node already >> acted upon on receiving the DEL_CLIENT, once again when it receives >> the DEL_SERVER, it returns -ENOENT. >> >> Fixing it by not sending a 'DEL_SERVER' to remote when a 'DEL_CLIENT' >> was sent for that port. > > You use the word "fix" so please add a Fixes tag. > ok >> Signed-off-by: Ram Kumar D <quic_ramd@quicinc.com> >> Signed-off-by: Sricharan R <quic_srichara@quicinc.com> > > Spell out full names, please. ok Regards, Sricharan
On Wed, Mar 29, 2023 at 06:37:30PM +0530, Sricharan R wrote: > When the qrtr socket is released, qrtr_port_remove gets called, which > broadcasts a DEL_CLIENT. After this DEL_SERVER is also additionally > broadcasted, which becomes NOP, but triggers the below error msg. > > "failed while handling packet from 2:-2", since remote node already > acted upon on receiving the DEL_CLIENT, once again when it receives > the DEL_SERVER, it returns -ENOENT. > > Fixing it by not sending a 'DEL_SERVER' to remote when a 'DEL_CLIENT' > was sent for that port. > How about: "On the remote side, when QRTR socket is removed, af_qrtr will call qrtr_port_remove() which broadcasts the DEL_CLIENT packet to all neighbours including local NS. NS upon receiving the DEL_CLIENT packet, will remove the lookups associated with the node:port and broadcasts the DEL_SERVER packet. But on the host side, due to the arrival of the DEL_CLIENT packet, the NS would've already deleted the server belonging to that port. So when the remote's NS again broadcasts the DEL_SERVER for that port, it throws below error message on the host: "failed while handling packet from 2:-2" So fix this error by not broadcasting the DEL_SERVER packet when the DEL_CLIENT packet gets processed." > Signed-off-by: Ram Kumar D <quic_ramd@quicinc.com> > Signed-off-by: Sricharan R <quic_srichara@quicinc.com> > --- > Note: Functionally tested on 5.4 kernel and compile tested on 6.3 TOT > > net/qrtr/ns.c | 16 ++++++++++------ > 1 file changed, 10 insertions(+), 6 deletions(-) > > diff --git a/net/qrtr/ns.c b/net/qrtr/ns.c > index 722936f..6fbb195 100644 > --- a/net/qrtr/ns.c > +++ b/net/qrtr/ns.c > @@ -274,7 +274,7 @@ static struct qrtr_server *server_add(unsigned int service, > return NULL; > } > > -static int server_del(struct qrtr_node *node, unsigned int port) > +static int server_del(struct qrtr_node *node, unsigned int port, bool del_server) s/bool del_server/bool bcast/g > { > struct qrtr_lookup *lookup; > struct qrtr_server *srv; > @@ -287,7 +287,7 @@ static int server_del(struct qrtr_node *node, unsigned int port) > radix_tree_delete(&node->servers, port); > > /* Broadcast the removal of local servers */ > - if (srv->node == qrtr_ns.local_node) > + if (srv->node == qrtr_ns.local_node && del_server) > service_announce_del(&qrtr_ns.bcast_sq, srv); > > /* Announce the service's disappearance to observers */ > @@ -373,7 +373,7 @@ static int ctrl_cmd_bye(struct sockaddr_qrtr *from) > } > slot = radix_tree_iter_resume(slot, &iter); > rcu_read_unlock(); > - server_del(node, srv->port); > + server_del(node, srv->port, true); > rcu_read_lock(); > } > rcu_read_unlock(); > @@ -459,10 +459,14 @@ static int ctrl_cmd_del_client(struct sockaddr_qrtr *from, > kfree(lookup); > } > > - /* Remove the server belonging to this port */ > + /* Remove the server belonging to this port > + * Given that DEL_CLIENT is already broadcasted > + * by port_remove, no need to send DEL_SERVER for > + * the same port to remote > + */ /* * Remove the server belonging to this port but don't broadcast * DEL_SERVER. Neighbours would've already removed the server belonging * to this port due to the DEL_CLIENT broadcast from qrtr_port_remove(). */ - Mani > node = node_get(node_id); > if (node) > - server_del(node, port); > + server_del(node, port, false); > > /* Advertise the removal of this client to all local servers */ > local_node = node_get(qrtr_ns.local_node); > @@ -567,7 +571,7 @@ static int ctrl_cmd_del_server(struct sockaddr_qrtr *from, > if (!node) > return -ENOENT; > > - return server_del(node, port); > + return server_del(node, port, true); > } > > static int ctrl_cmd_new_lookup(struct sockaddr_qrtr *from, > -- > 2.7.4 >
On 3/30/2023 6:09 PM, Manivannan Sadhasivam wrote: > On Wed, Mar 29, 2023 at 06:37:30PM +0530, Sricharan R wrote: >> When the qrtr socket is released, qrtr_port_remove gets called, which >> broadcasts a DEL_CLIENT. After this DEL_SERVER is also additionally >> broadcasted, which becomes NOP, but triggers the below error msg. >> >> "failed while handling packet from 2:-2", since remote node already >> acted upon on receiving the DEL_CLIENT, once again when it receives >> the DEL_SERVER, it returns -ENOENT. >> >> Fixing it by not sending a 'DEL_SERVER' to remote when a 'DEL_CLIENT' >> was sent for that port. >> > > How about: > > "On the remote side, when QRTR socket is removed, af_qrtr will call > qrtr_port_remove() which broadcasts the DEL_CLIENT packet to all neighbours > including local NS. NS upon receiving the DEL_CLIENT packet, will remove > the lookups associated with the node:port and broadcasts the DEL_SERVER > packet. > > But on the host side, due to the arrival of the DEL_CLIENT packet, the NS > would've already deleted the server belonging to that port. So when the > remote's NS again broadcasts the DEL_SERVER for that port, it throws below > error message on the host: > > "failed while handling packet from 2:-2" > > So fix this error by not broadcasting the DEL_SERVER packet when the > DEL_CLIENT packet gets processed." > Sure, sounds good. Will change this up and send V2. >> Signed-off-by: Ram Kumar D <quic_ramd@quicinc.com> >> Signed-off-by: Sricharan R <quic_srichara@quicinc.com> >> --- >> Note: Functionally tested on 5.4 kernel and compile tested on 6.3 TOT >> <...> >> >> - /* Remove the server belonging to this port */ >> + /* Remove the server belonging to this port >> + * Given that DEL_CLIENT is already broadcasted >> + * by port_remove, no need to send DEL_SERVER for >> + * the same port to remote >> + */ > > /* > * Remove the server belonging to this port but don't broadcast > * DEL_SERVER. Neighbours would've already removed the server belonging > * to this port due to the DEL_CLIENT broadcast from qrtr_port_remove(). > */ Sure, would reword it like above in V2. Thanks. Regards, Sricharan
diff --git a/net/qrtr/ns.c b/net/qrtr/ns.c index 722936f..6fbb195 100644 --- a/net/qrtr/ns.c +++ b/net/qrtr/ns.c @@ -274,7 +274,7 @@ static struct qrtr_server *server_add(unsigned int service, return NULL; } -static int server_del(struct qrtr_node *node, unsigned int port) +static int server_del(struct qrtr_node *node, unsigned int port, bool del_server) { struct qrtr_lookup *lookup; struct qrtr_server *srv; @@ -287,7 +287,7 @@ static int server_del(struct qrtr_node *node, unsigned int port) radix_tree_delete(&node->servers, port); /* Broadcast the removal of local servers */ - if (srv->node == qrtr_ns.local_node) + if (srv->node == qrtr_ns.local_node && del_server) service_announce_del(&qrtr_ns.bcast_sq, srv); /* Announce the service's disappearance to observers */ @@ -373,7 +373,7 @@ static int ctrl_cmd_bye(struct sockaddr_qrtr *from) } slot = radix_tree_iter_resume(slot, &iter); rcu_read_unlock(); - server_del(node, srv->port); + server_del(node, srv->port, true); rcu_read_lock(); } rcu_read_unlock(); @@ -459,10 +459,14 @@ static int ctrl_cmd_del_client(struct sockaddr_qrtr *from, kfree(lookup); } - /* Remove the server belonging to this port */ + /* Remove the server belonging to this port + * Given that DEL_CLIENT is already broadcasted + * by port_remove, no need to send DEL_SERVER for + * the same port to remote + */ node = node_get(node_id); if (node) - server_del(node, port); + server_del(node, port, false); /* Advertise the removal of this client to all local servers */ local_node = node_get(qrtr_ns.local_node); @@ -567,7 +571,7 @@ static int ctrl_cmd_del_server(struct sockaddr_qrtr *from, if (!node) return -ENOENT; - return server_del(node, port); + return server_del(node, port, true); } static int ctrl_cmd_new_lookup(struct sockaddr_qrtr *from,