netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
To: Phil Sutter <phil@nwl.cc>
Cc: David Miller <davem@davemloft.net>,
	Xin Long <lucien.xin@gmail.com>,
	netdev@vger.kernel.org
Subject: Re: [PATCH 2/3] sctp_diag: export timer value only if it is active
Date: Fri, 29 Jul 2016 17:51:13 -0300	[thread overview]
Message-ID: <20160729205113.GA2954@localhost.localdomain> (raw)
In-Reply-To: <1469811580-32429-3-git-send-email-phil@nwl.cc>

On Fri, Jul 29, 2016 at 06:59:39PM +0200, Phil Sutter wrote:
> Since it is exported as unsigned value, userspace has no way detecting
> whether it is negative or just very large. Therefore do this in kernel
> space where it is a simple comparison.
> 
> Signed-off-by: Phil Sutter <phil@nwl.cc>
> ---
>  net/sctp/sctp_diag.c | 10 ++++++----
>  1 file changed, 6 insertions(+), 4 deletions(-)
> 
> diff --git a/net/sctp/sctp_diag.c b/net/sctp/sctp_diag.c
> index f69edcf219e51..0ad6033a7330c 100644
> --- a/net/sctp/sctp_diag.c
> +++ b/net/sctp/sctp_diag.c
> @@ -40,10 +40,12 @@ static void inet_diag_msg_sctpasoc_fill(struct inet_diag_msg *r,
>  	}
>  
>  	r->idiag_state = asoc->state;
> -	r->idiag_timer = SCTP_EVENT_TIMEOUT_T3_RTX;
> -	r->idiag_retrans = asoc->rtx_data_chunks;
> -	r->idiag_expires = jiffies_to_msecs(
> -		asoc->timeouts[SCTP_EVENT_TIMEOUT_T3_RTX] - jiffies);

I think we have two issues here, prior to your patch, but I noticed
while reviewing it :-)

This array is actually not based on jiffies but on intervals instead, as
per:

sm_sideeffect.c:
                case SCTP_CMD_TIMER_START:                       [1]
                        timer = &asoc->timers[cmd->obj.to];
                        timeout = asoc->timeouts[cmd->obj.to];   <---
                        BUG_ON(!timeout);

                        timer->expires = jiffies + timeout;      <---

But more importantly, this array is actually not used for this timeout
and the timeout is sctp_transport dependant, as per:

/* Schedule retransmission on the given transport */
void sctp_transport_immediate_rtx(struct sctp_transport *t)
{
        /* Stop pending T3_rtx_timer */
        if (del_timer(&t->T3_rtx_timer))
                sctp_transport_put(t);

        sctp_retransmit(&t->asoc->outqueue, t, SCTP_RTXR_T3_RTX);
        if (!timer_pending(&t->T3_rtx_timer)) {
                if (!mod_timer(&t->T3_rtx_timer, jiffies + t->rto))
                                                 ^^^^^^^^^^^^^^^^
                        sctp_transport_hold(t);

Note how on sctp_get_sctp_info() it fetches the RTO (which is T3_RTX)
this way:
	info->sctpi_p_rto = jiffies_to_msecs(prim->rto);
If we want to know how long is left for the timer to expire, we have to
read directly from it.

With git grep -A 1 TIMER_START we can confirm that [1] is never hit for
SCTP_EVENT_TIMEOUT_T3_RTX. Yet, the asoc is allocated with kzalloc(), so
I guess you were just reading -jiffies in there.

Note however that the stats rtx_data_chunks is the accumulated stats,
it's good, and that we may have multiple T3 timers running at once, with
different timeouts.

Xin, ideas on how we can fix this? I'm not sure if we can dump
per-transport info in there. Not as it is now, I guess.

> +	if (asoc->timeouts[SCTP_EVENT_TIMEOUT_T3_RTX] > jiffies) {
> +		r->idiag_timer = SCTP_EVENT_TIMEOUT_T3_RTX;
> +		r->idiag_retrans = asoc->rtx_data_chunks;
> +		r->idiag_expires = jiffies_to_msecs(
> +			asoc->timeouts[SCTP_EVENT_TIMEOUT_T3_RTX] - jiffies);
> +	}
>  }
>  
>  static int inet_diag_msg_sctpladdrs_fill(struct sk_buff *skb,
> -- 
> 2.8.2
> 

  reply	other threads:[~2016-07-29 20:51 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-29 16:59 [PATCH 0/3] sctp_diag: A bunch of fixes for upcoming 'ss' support Phil Sutter
2016-07-29 16:59 ` [PATCH 1/3] sctp: Export struct sctp_info to userspace Phil Sutter
2016-07-31 21:18   ` Stephen Hemminger
2016-08-01 13:36     ` Phil Sutter
2016-07-29 16:59 ` [PATCH 2/3] sctp_diag: export timer value only if it is active Phil Sutter
2016-07-29 20:51   ` Marcelo Ricardo Leitner [this message]
2016-07-30 13:25     ` Xin Long
2016-07-30 13:33       ` Marcelo Ricardo Leitner
2016-07-30 17:59         ` Phil Sutter
2016-07-31 15:57           ` Xin Long
2016-08-03 19:28       ` Phil Sutter
2016-08-03 19:46         ` Marcelo Ricardo Leitner
2016-08-03 20:15           ` Phil Sutter
2016-07-29 16:59 ` [PATCH 3/3] sctp_diag: Respect ss adding TCPF_CLOSE to idiag_states Phil Sutter

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=20160729205113.GA2954@localhost.localdomain \
    --to=marcelo.leitner@gmail.com \
    --cc=davem@davemloft.net \
    --cc=lucien.xin@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=phil@nwl.cc \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).