netdev - RE: [PATCH] sctp: avoid refreshing heartbeat timer too often

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <063D6719AE5E284EB5DD2968C1650D6D54DBFFCD@AcuExch.aculab.com>
Date:	Wed, 30 Mar 2016 09:37:24 +0000
From:	David Laight <David.Laight@...LAB.COM>
To:	'Marcelo Ricardo Leitner' <marcelo.leitner@...il.com>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>
CC:	Neil Horman <nhorman@...driver.com>,
	Vlad Yasevich <vyasevich@...il.com>,
	"linux-sctp@...r.kernel.org" <linux-sctp@...r.kernel.org>
Subject: RE: [PATCH] sctp: avoid refreshing heartbeat timer too often

From: Marcelo Ricardo Leitner
> Sent: 29 March 2016 14:42
>
> Currently on high rate SCTP streams the heartbeat timer refresh can
> consume quite a lot of resources as timer updates are costly and it
> contains a random factor, which a) is also costly and b) invalidates
> mod_timer() optimization for not editing a timer to the same value.
> It may even cause the timer to be slightly advanced, for no good reason.

Interesting thoughts:
1) Is it necessary to use a different 'random factor' until the timer actually
   expires?
2) It might be better to allow the heartbeat timer to expire, on expiry work
   out the new interval based on when the last 'refresh' was done.

	David