From: Manivannan Sadhasivam <mani@kernel.org>
To: Sricharan Ramabadhran <quic_srichara@quicinc.com>
Cc: 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: Re: [PATCH V2] net: qrtr: Do not do DEL_SERVER broadcast after DEL_CLIENT
Date: Sat, 1 Apr 2023 00:00:39 +0530 [thread overview]
Message-ID: <20230331183039.GC6352@thinkpad> (raw)
In-Reply-To: <1680248937-16617-1-git-send-email-quic_srichara@quicinc.com>
On Fri, Mar 31, 2023 at 01:18:57PM +0530, Sricharan Ramabadhran wrote:
> 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."
>
> Fixes: 0c2204a4ad71 ("net: qrtr: Migrate nameservice to kernel from userspace")
> Signed-off-by: Sricharan Ramabadhran <quic_srichara@quicinc.com>
> Signed-off-by: Ram Kumar Dharuman <quic_ramd@quicinc.com>
Sender's Signed-off-by should come last. With that fixed,
Reviewed-by: Manivannan Sadhasivam <mani@kernel.org>
- Mani
> ---
> [v2] Fixed comments from Manivannan and Jakub Kicinski
> Note: Functionally tested on 5.4 and compile tested on 6.3 TOT
>
> net/qrtr/ns.c | 15 +++++++++------
> 1 file changed, 9 insertions(+), 6 deletions(-)
>
> diff --git a/net/qrtr/ns.c b/net/qrtr/ns.c
> index 722936f..0f25a38 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 bcast)
> {
> 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 && bcast)
> 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,13 @@ 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 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().
> + */
> 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 +570,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
>
--
மணிவண்ணன் சதாசிவம்
prev parent reply other threads:[~2023-03-31 18:30 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-31 7:48 [PATCH V2] net: qrtr: Do not do DEL_SERVER broadcast after DEL_CLIENT Sricharan Ramabadhran
2023-03-31 8:02 ` Manivannan Sadhasivam
2023-03-31 8:32 ` Sricharan Ramabadhran
2023-03-31 18:29 ` Manivannan Sadhasivam
2023-03-31 19:46 ` Simon Horman
2023-03-31 18:30 ` Manivannan Sadhasivam [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20230331183039.GC6352@thinkpad \
--to=mani@kernel.org \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=kuba@kernel.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=manivannan.sadhasivam@linaro.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=quic_srichara@quicinc.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.