[PATCH net] sctp: fix double EPs display in sctp_diag

[PATCH net] sctp: fix double EPs display in sctp_diag

[Xin Long]

We have this situation: that EP hash table, contains only the EPs
that are listening, while the transports one, has the opposite.
We have to traverse both to dump all.

But when we traverse the transports one we will also get EPs that are
in the EP hash if they are listening. In this case, the EP is dumped
twice.

We will fix it by checking if the endpoint that is in the endpoint
hash table contains any ep->asoc in there, as it means we will also
find it via transport hash, and thus we can/should skip it, depending
on the filters used, like 'ss -l'.

Still, we should NOT skip it if the user is listing only listening
endpoints, because then we are not traversing the transport hash.
so we have to check idiag_states there also.

Signed-off-by: Xin Long <lucien.xin@gmail.com>
---
 net/sctp/sctp_diag.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/net/sctp/sctp_diag.c b/net/sctp/sctp_diag.c
index 8e3e769..1ce724b 100644
--- a/net/sctp/sctp_diag.c
+++ b/net/sctp/sctp_diag.c
@@ -356,6 +356,9 @@ static int sctp_ep_dump(struct sctp_endpoint *ep, void *p)
 	if (cb->args[4] < cb->args[1])
 		goto next;
 
+	if ((r->idiag_states & ~TCPF_LISTEN) && !list_empty(&ep->asocs))
+		goto next;
+
 	if (r->sdiag_family != AF_UNSPEC &&
 	    sk->sk_family != r->sdiag_family)
 		goto next;
-- 
2.1.0

Re: [PATCH net] sctp: fix double EPs display in sctp_diag

[Marcelo Ricardo Leitner]

On Thu, May 26, 2016 at 03:09:23AM +0800, Xin Long wrote:
> We have this situation: that EP hash table, contains only the EPs
> that are listening, while the transports one, has the opposite.
> We have to traverse both to dump all.
> 
> But when we traverse the transports one we will also get EPs that are
> in the EP hash if they are listening. In this case, the EP is dumped
> twice.
> 
> We will fix it by checking if the endpoint that is in the endpoint
> hash table contains any ep->asoc in there, as it means we will also
> find it via transport hash, and thus we can/should skip it, depending
> on the filters used, like 'ss -l'.
> 
> Still, we should NOT skip it if the user is listing only listening
> endpoints, because then we are not traversing the transport hash.
> so we have to check idiag_states there also.
> 
> Signed-off-by: Xin Long <lucien.xin@gmail.com>

Acked-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>

> ---
>  net/sctp/sctp_diag.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/net/sctp/sctp_diag.c b/net/sctp/sctp_diag.c
> index 8e3e769..1ce724b 100644
> --- a/net/sctp/sctp_diag.c
> +++ b/net/sctp/sctp_diag.c
> @@ -356,6 +356,9 @@ static int sctp_ep_dump(struct sctp_endpoint *ep, void *p)
>  	if (cb->args[4] < cb->args[1])
>  		goto next;
>  
> +	if ((r->idiag_states & ~TCPF_LISTEN) && !list_empty(&ep->asocs))
> +		goto next;
> +
>  	if (r->sdiag_family != AF_UNSPEC &&
>  	    sk->sk_family != r->sdiag_family)
>  		goto next;
> -- 
> 2.1.0
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sctp" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: [PATCH net] sctp: fix double EPs display in sctp_diag

[David Miller]

From: Xin Long <lucien.xin@gmail.com>
Date: Thu, 26 May 2016 03:09:23 +0800

> We have this situation: that EP hash table, contains only the EPs
> that are listening, while the transports one, has the opposite.
> We have to traverse both to dump all.
> 
> But when we traverse the transports one we will also get EPs that are
> in the EP hash if they are listening. In this case, the EP is dumped
> twice.
> 
> We will fix it by checking if the endpoint that is in the endpoint
> hash table contains any ep->asoc in there, as it means we will also
> find it via transport hash, and thus we can/should skip it, depending
> on the filters used, like 'ss -l'.
> 
> Still, we should NOT skip it if the user is listing only listening
> endpoints, because then we are not traversing the transport hash.
> so we have to check idiag_states there also.
> 
> Signed-off-by: Xin Long <lucien.xin@gmail.com>

Applied.