Message ID | 75465785f8ee5df2fb3acdca9b8fafdc18984098.1696172660.git.lucien.xin@gmail.com (mailing list archive) |
---|---|
State | Accepted |
Commit | 1f4e803cd9c9166eb8b6c8b0b8e4124f7499fc07 |
Delegated to: | Netdev Maintainers |
Headers | show |
Series | [net] sctp: update hb timer immediately after users change hb_interval | expand |
On Sun, Oct 01, 2023 at 11:04:20AM -0400, Xin Long wrote: > Currently, when hb_interval is changed by users, it won't take effect > until the next expiry of hb timer. As the default value is 30s, users > have to wait up to 30s to wait its hb_interval update to work. > > This becomes pretty bad in containers where a much smaller value is > usually set on hb_interval. This patch improves it by resetting the > hb timer immediately once the value of hb_interval is updated by users. > > Note that we don't address the already existing 'problem' when sending > a heartbeat 'on demand' if one hb has just been sent(from the timer) > mentioned in: > > https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg590224.html Hi Xin Long, I wonder if this warrants a fixes tag, and if so, perhaps: Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") > Signed-off-by: Xin Long <lucien.xin@gmail.com> Reviewed-by: Simon Horman <horms@kernel.org>
Hello: This patch was applied to netdev/net.git (main) by Jakub Kicinski <kuba@kernel.org>: On Sun, 1 Oct 2023 11:04:20 -0400 you wrote: > Currently, when hb_interval is changed by users, it won't take effect > until the next expiry of hb timer. As the default value is 30s, users > have to wait up to 30s to wait its hb_interval update to work. > > This becomes pretty bad in containers where a much smaller value is > usually set on hb_interval. This patch improves it by resetting the > hb timer immediately once the value of hb_interval is updated by users. > > [...] Here is the summary with links: - [net] sctp: update hb timer immediately after users change hb_interval https://git.kernel.org/netdev/net/c/1f4e803cd9c9 You are awesome, thank you!
diff --git a/net/sctp/socket.c b/net/sctp/socket.c index ab943e8fb1db..7f89e43154c0 100644 --- a/net/sctp/socket.c +++ b/net/sctp/socket.c @@ -2450,6 +2450,7 @@ static int sctp_apply_peer_addr_params(struct sctp_paddrparams *params, if (trans) { trans->hbinterval = msecs_to_jiffies(params->spp_hbinterval); + sctp_transport_reset_hb_timer(trans); } else if (asoc) { asoc->hbinterval = msecs_to_jiffies(params->spp_hbinterval);
Currently, when hb_interval is changed by users, it won't take effect until the next expiry of hb timer. As the default value is 30s, users have to wait up to 30s to wait its hb_interval update to work. This becomes pretty bad in containers where a much smaller value is usually set on hb_interval. This patch improves it by resetting the hb timer immediately once the value of hb_interval is updated by users. Note that we don't address the already existing 'problem' when sending a heartbeat 'on demand' if one hb has just been sent(from the timer) mentioned in: https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg590224.html Signed-off-by: Xin Long <lucien.xin@gmail.com> --- net/sctp/socket.c | 1 + 1 file changed, 1 insertion(+)