[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160803192813.GE17974@orbyte.nwl.cc>
Date: Wed, 3 Aug 2016 21:28:13 +0200
From: Phil Sutter <phil@....cc>
To: Xin Long <lucien.xin@...il.com>
Cc: Marcelo Ricardo Leitner <marcelo.leitner@...il.com>,
David Miller <davem@...emloft.net>,
network dev <netdev@...r.kernel.org>
Subject: Re: [PATCH 2/3] sctp_diag: export timer value only if it is active
Hi,
On Sat, Jul 30, 2016 at 09:25:42PM +0800, Xin Long wrote:
[...]
> Now for the transport's info, we only choose primary_path to dump.
> It means we should fix this by getting the left time to expire from
> primary transport t->T3_rtx_timer. like:
>
> r->idiag_expires = jiffies_to_msecs(
> - asoc->timeouts[SCTP_EVENT_TIMEOUT_T3_RTX] - jiffies);
> + asoc->peer.primary_path->T3_rtx_timer.expires - jiffies);
>
> but yes, need to check with timer_pending firstly.
I have changed the code to this:
| struct timer_list *t3_rtx = &asoc->peer.primary_path->T3_rtx_timer;
|
| [...]
|
| if (timer_pending(t3_rtx)) {
| r->idiag_timer = SCTP_EVENT_TIMEOUT_T3_RTX;
| r->idiag_retrans = asoc->rtx_data_chunks;
| r->idiag_expires = jiffies_to_msecs(t3_rtx->expires - jiffies);
| }
And I'm still getting what appears to be negative values sometimes. Here
are some of the common values in hex when busy looping sctp_diag
requests:
0
7530
1000000
3000000
6000000
14000000
94000000
ed690000
ffffea00
While I wonder a bit about the zero, the last two seem to be unsigned
underruns. Do I still have to check for 't3_rtx->expires > jiffies' or
am I missing something?
Thanks, Phil
Powered by blists - more mailing lists