From patchwork Fri Feb 22 08:45:26 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: kwiecienmaciek@gmail.com X-Patchwork-Id: 1046667 X-Patchwork-Delegate: davem@davemloft.net Return-Path: X-Original-To: patchwork-incoming-netdev@ozlabs.org Delivered-To: patchwork-incoming-netdev@ozlabs.org Authentication-Results: ozlabs.org; spf=none (mailfrom) smtp.mailfrom=vger.kernel.org (client-ip=209.132.180.67; helo=vger.kernel.org; envelope-from=netdev-owner@vger.kernel.org; receiver=) Authentication-Results: ozlabs.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="YWt7rMsk"; dkim-atps=neutral Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 445Q124Ct7z9s8m for ; Fri, 22 Feb 2019 19:46:14 +1100 (AEDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725860AbfBVIqN (ORCPT ); Fri, 22 Feb 2019 03:46:13 -0500 Received: from mail-lj1-f194.google.com ([209.85.208.194]:38597 "EHLO mail-lj1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725927AbfBVIqM (ORCPT ); Fri, 22 Feb 2019 03:46:12 -0500 Received: by mail-lj1-f194.google.com with SMTP id j19so1061036ljg.5; Fri, 22 Feb 2019 00:46:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id; bh=2lzIBFDXbQSe0Af23FcP9imDzMaiPQ9NKJJbdILHcYk=; b=YWt7rMskC8vYasEnunom+RWG+Woe49WbrvIL53SJWIo/UXC4Qo0cIo9gYKgfMdV6Yk WN5DEiVel04k2GQmtJv7rlZMeQ+nxiKnH+fPO0INpLYPs9kDYAkvKdWgJjHg6Y1fLOnO kBnh0kqB5fTAm6Md3r3PGrg9kYV4S2ukeU7qQdZvNV7kND6Yx3YiA5JcQ89CIEDvl4W5 vu/vp4ej+2fg8g2M54Whikd42TJZ29n5RU9YIjK0/ZNxIHE/wf2wPzn9jEqRokjzAX0h PYTgis1rvIv/+2Ox3xVNf9UQkGputM8jO28X4eghGL0cgYPe+LkvAz8PflEW3B/ibMNL XHTw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=2lzIBFDXbQSe0Af23FcP9imDzMaiPQ9NKJJbdILHcYk=; b=CPF1z6RVBfr158pHnluu86TFPIpmUEwsy0C5B7ltnzWKtlhYX4jM7R1y0eNMM5A3Xr mnEmdh+CmOZ4XL6XsHulF78PXQ+32GlGk5DMXxxagIEFxkhWWIBiArlwpTeIs/hMn7vl xoaFjqvbJELuiUicy5VnrC+xwHNQq33VuyyyOaWPndRdAgrKGZbMGCSud6QR/CEJdjaS Aay4rDtbQnhyR7MJugeoTHMCkrZoIVzMboIMFGpBgQPyc7BURHrjatcx3pYONdJhKbLM urKt/4SSKWQyEPVKfC5YWgtIfrGM12Cv0jD387IsmfDYC7/F3n0Yk8JNXnzwoMtAt0d9 hSeA== X-Gm-Message-State: AHQUAuZQW8O1DXjLnnxrFz6KJ1rZMtZBlF/1n09DrgKhw0SbqWXHw1Vl 1qCfLL5hfpNNZU9wn8YaIlSuhYCLpgGhVg== X-Google-Smtp-Source: AHgI3IZtz+fpHV7W51B28gmf5SFCftz6j43hrjHBfIOTATI/v/VU67DFfYZ7uwRpYW2Xx20i+e7szw== X-Received: by 2002:a2e:8084:: with SMTP id i4mr1664566ljg.44.1550825170047; Fri, 22 Feb 2019 00:46:10 -0800 (PST) Received: from localhost.localdomain (user-94-254-206-98.play-internet.pl. [94.254.206.98]) by smtp.gmail.com with ESMTPSA id b191sm318876lfd.56.2019.02.22.00.46.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 22 Feb 2019 00:46:09 -0800 (PST) From: kwiecienmaciek@gmail.com X-Google-Original-From: maciej.kwiecien@nokia.com To: linux-sctp@vger.kernel.org Cc: netdev@vger.kernel.org, alexander.sverdlin@nokia.com, Maciej Kwiecien Subject: [PATCH] sctp: don't compare hb_timer expire date before starting it Date: Fri, 22 Feb 2019 09:45:26 +0100 Message-Id: <20190222084526.8214-1-maciej.kwiecien@nokia.com> X-Mailer: git-send-email 2.14.1 Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org From: Maciej Kwiecien hb_timer might not start at all for a particular transport because its start is conditional. In a result a node is not sending heartbeats. Function sctp_transport_reset_hb_timer has two roles: - initial start of hb_timer for a given transport, - update expire date of hb_timer for a given transport. The function is optimized to update timer's expire only if it is before a new calculated one but this comparison is invalid for a timer which has not yet started. Such a timer has expire == 0 and if a new expire value is bigger than (MAX_JIFFIES / 2 + 2) then "time_before" macro will fail and timer will not start resulting in no heartbeat packets send by the node. This was found when association was initialized within first 5 mins after system boot due to jiffies init value which is near to MAX_JIFFIES. Test kernel version: 4.9.154 (ARCH=arm) hb_timer.expire = 0; //initialized, not started timer new_expire = MAX_JIFFIES / 2 + 2; //or more time_before(hb_timer.expire, new_expire) == false Fixes: ba6f5e33bdbb ("sctp: avoid refreshing heartbeat timer too often") Reported-by: Marcin Stojek Tested-by: Marcin Stojek Signed-off-by: Maciej Kwiecien Reviewed-by: Alexander Sverdlin Acked-by: Marcelo Ricardo Leitner --- net/sctp/transport.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/net/sctp/transport.c b/net/sctp/transport.c index 033696e6f74f..ad158d311ffa 100644 --- a/net/sctp/transport.c +++ b/net/sctp/transport.c @@ -207,7 +207,8 @@ void sctp_transport_reset_hb_timer(struct sctp_transport *transport) /* When a data chunk is sent, reset the heartbeat interval. */ expires = jiffies + sctp_transport_timeout(transport); - if (time_before(transport->hb_timer.expires, expires) && + if ((time_before(transport->hb_timer.expires, expires) || + !timer_pending(&transport->hb_timer)) && !mod_timer(&transport->hb_timer, expires + prandom_u32_max(transport->rto))) sctp_transport_hold(transport);