Received: by 10.192.165.148 with SMTP id m20csp4168189imm; Mon, 30 Apr 2018 13:04:32 -0700 (PDT) X-Google-Smtp-Source: AB8JxZrpVToLE2Cs5rUDDOb3CkFtsK9tVnGpmkLZYSN2Z3tXy1wduqArdOs4lKX0Phqe3aKAkeyU X-Received: by 2002:a17:902:8c95:: with SMTP id t21-v6mr9694568plo.306.1525118672742; Mon, 30 Apr 2018 13:04:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1525118672; cv=none; d=google.com; s=arc-20160816; b=CDDcBqmwhdRita1wVyOUoCdOVU3sZjTO2gGbZNfu2w/QeW0tnV4pOn6kuFi/YsYEmT bPVX4b6Z3nPrtngV+otBYDF2M+xhJsS2j9/dKECYPGvnlvpS/uawkwePWhvdCkBvKsm2 h6Hy7m3u5CbQJkdWUVvPmMYurqRHnI4CmmVZbVyeJ3+Dod1v9j1pYvJQEERxYqLxB6l5 oVrrwv0d75wi6gbUiKLlWjK11qc3P8H4M+PM0ouKEhQrdEL3iLjQac+GqVpf4MysxeZK oFb1zWytLlMiTfC6DTMST/IeJMGBnCs9GlDYJG5tUjR4svKfgneONovx5tF2rQf+y2YZ dSow== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :in-reply-to:message-id:date:subject:cc:to:from:dmarc-filter :arc-authentication-results; bh=IYU0uE/XJA30o+SK7W6q/gGwTzZ5nepqL9dFMRdICfg=; b=ez3wWupMB91uxnaCFiVbLKM5Krc8mQwC3KUlHekumo0nvudy9Z+9puoIVB6FR9Vc/W e59sgawR8C2tUnDunC2jrepNANW6ZafBz7/gIsGQ/3vM/hY5KJwcXWWK3DI1Wggh6Sk1 QW+Rjk5e9Uz/F0GPNdp5x6J61lDCgJL7+on2AeBpiqYyd+g8vqK+AJVtS+lDm6bmZJTf qUA8GnBhvWQWV7pUDQmnqZQ+9prgG/1k8CE4JDMLbOGuN11QGkYwcsT+t5xXVQofktiU yweVhldOUKBy+p0THypesZcn5YWPXLtlyoHQ5dJkHzKFv2qwoQS+th4DJXUsCIF9xzEo dHww== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 24si2723022pfp.161.2018.04.30.13.04.18; Mon, 30 Apr 2018 13:04:32 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756098AbeD3UC6 (ORCPT + 99 others); Mon, 30 Apr 2018 16:02:58 -0400 Received: from mail.kernel.org ([198.145.29.99]:34304 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755999AbeD3T1f (ORCPT ); Mon, 30 Apr 2018 15:27:35 -0400 Received: from localhost (unknown [104.132.1.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 5C67E22DCC; Mon, 30 Apr 2018 19:27:35 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 5C67E22DCC Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linuxfoundation.org Authentication-Results: mail.kernel.org; spf=fail smtp.mailfrom=gregkh@linuxfoundation.org From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Ilya Dryomov , Jason Dillaman Subject: [PATCH 4.14 74/91] libceph: reschedule a tick in finish_hunting() Date: Mon, 30 Apr 2018 12:24:56 -0700 Message-Id: <20180430184008.125080894@linuxfoundation.org> X-Mailer: git-send-email 2.17.0 In-Reply-To: <20180430184004.216234025@linuxfoundation.org> References: <20180430184004.216234025@linuxfoundation.org> User-Agent: quilt/0.65 X-stable: review MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 4.14-stable review patch. If anyone has any objections, please let me know. ------------------ From: Ilya Dryomov commit 7b4c443d139f1d2b5570da475f7a9cbcef86740c upstream. If we go without an established session for a while, backoff delay will climb to 30 seconds. The keepalive timeout is also 30 seconds, so it's pretty easily hit after a prolonged hunting for a monitor: we don't get a chance to send out a keepalive in time, which means we never get back a keepalive ack in time, cutting an established session and attempting to connect to a different monitor every 30 seconds: [Sun Apr 1 23:37:05 2018] libceph: mon0 10.80.20.99:6789 session established [Sun Apr 1 23:37:36 2018] libceph: mon0 10.80.20.99:6789 session lost, hunting for new mon [Sun Apr 1 23:37:36 2018] libceph: mon2 10.80.20.103:6789 session established [Sun Apr 1 23:38:07 2018] libceph: mon2 10.80.20.103:6789 session lost, hunting for new mon [Sun Apr 1 23:38:07 2018] libceph: mon1 10.80.20.100:6789 session established [Sun Apr 1 23:38:37 2018] libceph: mon1 10.80.20.100:6789 session lost, hunting for new mon [Sun Apr 1 23:38:37 2018] libceph: mon2 10.80.20.103:6789 session established [Sun Apr 1 23:39:08 2018] libceph: mon2 10.80.20.103:6789 session lost, hunting for new mon The regular keepalive interval is 10 seconds. After ->hunting is cleared in finish_hunting(), call __schedule_delayed() to ensure we send out a keepalive after 10 seconds. Cc: stable@vger.kernel.org # 4.7+ Link: http://tracker.ceph.com/issues/23537 Signed-off-by: Ilya Dryomov Reviewed-by: Jason Dillaman Signed-off-by: Greg Kroah-Hartman --- net/ceph/mon_client.c | 1 + 1 file changed, 1 insertion(+) --- a/net/ceph/mon_client.c +++ b/net/ceph/mon_client.c @@ -1133,6 +1133,7 @@ static void finish_hunting(struct ceph_m monc->hunting = false; monc->had_a_connection = true; un_backoff(monc); + __schedule_delayed(monc); } }