Received: by 2002:a25:ad19:0:0:0:0:0 with SMTP id y25csp841406ybi; Fri, 12 Jul 2019 05:32:44 -0700 (PDT) X-Google-Smtp-Source: APXvYqwre58dOObXqElVn+4IduXb8X5TCMIYdZ5vuvl1Uwtr5HD2xckakvStuGkZmUKA9Amc0eKv X-Received: by 2002:a17:90a:2706:: with SMTP id o6mr11770872pje.62.1562934764501; Fri, 12 Jul 2019 05:32:44 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1562934764; cv=none; d=google.com; s=arc-20160816; b=aw5IY0TvfPMA7CPbYdypdzVUuxuE39l1rIPHDrDlwJLowBYrLNszgYTcx8eYxG/ejy c5IyQ1+aO8hxB3H9w9RodX/+DrlMGwa+IL5xy1L8Ob5P7pQE6xr+rNIJnZxvyyuGo30/ 8o/v3AC8LG4P8cSf8a4jZ+9E3RGqc48zYbVg8EpAhr6zqlyRG38K7oVZJRNoM38pex/M rV+K8lNUpPjGidB0o0+Ihs6MbpZZBPxo7orRYT3X2XBFG8pdlFb3WxKVnY/+aDUH8cmv BN2rC/2tWtI7EWTIos94szU1ZYOH71VPPJU4xeohMo5rzG4J1m+tBXDdp/8KkcUQOHUd 7S+A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=qp/OK2cmkE+XXSOK3b0Ri8W03aWJhz1hYaP5HP2byQ0=; b=sz1/jur1kb38KE4jYIgPCCPHyY4vYFNz/1n11aKrN+sMb5G8zDxNc9ZPcxyC2mLpS8 A2jctbhHLH0uuutF9Jwc7req3SOKqv0FRM79UgN+hjGGlHKy36KIIuHJwH8QW5axUc4j q0Dobrsw82dM7sL+NjqGoIIcl2r17H0jc37aMETuup8M/zmoMk4Lb1SnimIjq2GxSWhb Nxy+PrLzkzRPUC7efq/wgzcvuOc5SoR1tK35hkM0uxsvrCNfkhCoDS62xjokwZQzlEpV sjn43KFSRRs86RzwJwb5LVFKyXN/L/2tgKq/tscOZKlR4nfScZHePTbbwO4d3vG7ef2n uZIw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=rQohUkZv; 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 k33si7761858pld.359.2019.07.12.05.32.28; Fri, 12 Jul 2019 05:32:44 -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; dkim=pass header.i=@kernel.org header.s=default header.b=rQohUkZv; 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 S1729215AbfGLMaX (ORCPT + 99 others); Fri, 12 Jul 2019 08:30:23 -0400 Received: from mail.kernel.org ([198.145.29.99]:45928 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729195AbfGLMaS (ORCPT ); Fri, 12 Jul 2019 08:30:18 -0400 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (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 43CAA208E4; Fri, 12 Jul 2019 12:30:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1562934617; bh=5meU9hHpgYxCdNPIwICjkp/CtbL+UAFXdcXK6MeI6IY=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=rQohUkZv1ofnSZyLSPCfIonAIAFisXslZEroDQJkNKg/iLfdwYFAjmiyKSdZZK/Xq s/xfJjGjq+IgVr3LHxg7eJekd59aIZGrx5LpIbF5nxA4mjsfDE4stlhcFhYtUvyGRO ULhVeaTJ/k7q0PJdXY+nV1IbaHfrRrkVjqFOfHEE= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Mariusz Tkaczyk , Song Liu , Sasha Levin Subject: [PATCH 5.1 077/138] md: fix for divide error in status_resync Date: Fri, 12 Jul 2019 14:19:01 +0200 Message-Id: <20190712121631.665080137@linuxfoundation.org> X-Mailer: git-send-email 2.22.0 In-Reply-To: <20190712121628.731888964@linuxfoundation.org> References: <20190712121628.731888964@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org [ Upstream commit 9642fa73d073527b0cbc337cc17a47d545d82cd2 ] Stopping external metadata arrays during resync/recovery causes retries, loop of interrupting and starting reconstruction, until it hit at good moment to stop completely. While these retries curr_mark_cnt can be small- especially on HDD drives, so subtraction result can be smaller than 0. However it is casted to uint without checking. As a result of it the status bar in /proc/mdstat while stopping is strange (it jumps between 0% and 99%). The real problem occurs here after commit 72deb455b5ec ("block: remove CONFIG_LBDAF"). Sector_div() macro has been changed, now the divisor is casted to uint32. For db = -8 the divisior(db/32-1) becomes 0. Check if db value can be really counted and replace these macro by div64_u64() inline. Signed-off-by: Mariusz Tkaczyk Signed-off-by: Song Liu Signed-off-by: Sasha Levin --- drivers/md/md.c | 36 ++++++++++++++++++++++-------------- 1 file changed, 22 insertions(+), 14 deletions(-) diff --git a/drivers/md/md.c b/drivers/md/md.c index 295ff09cff4c..84aec3647994 100644 --- a/drivers/md/md.c +++ b/drivers/md/md.c @@ -7617,9 +7617,9 @@ static void status_unused(struct seq_file *seq) static int status_resync(struct seq_file *seq, struct mddev *mddev) { sector_t max_sectors, resync, res; - unsigned long dt, db; - sector_t rt; - int scale; + unsigned long dt, db = 0; + sector_t rt, curr_mark_cnt, resync_mark_cnt; + int scale, recovery_active; unsigned int per_milli; if (test_bit(MD_RECOVERY_SYNC, &mddev->recovery) || @@ -7708,22 +7708,30 @@ static int status_resync(struct seq_file *seq, struct mddev *mddev) * db: blocks written from mark until now * rt: remaining time * - * rt is a sector_t, so could be 32bit or 64bit. - * So we divide before multiply in case it is 32bit and close - * to the limit. - * We scale the divisor (db) by 32 to avoid losing precision - * near the end of resync when the number of remaining sectors - * is close to 'db'. - * We then divide rt by 32 after multiplying by db to compensate. - * The '+1' avoids division by zero if db is very small. + * rt is a sector_t, which is always 64bit now. We are keeping + * the original algorithm, but it is not really necessary. + * + * Original algorithm: + * So we divide before multiply in case it is 32bit and close + * to the limit. + * We scale the divisor (db) by 32 to avoid losing precision + * near the end of resync when the number of remaining sectors + * is close to 'db'. + * We then divide rt by 32 after multiplying by db to compensate. + * The '+1' avoids division by zero if db is very small. */ dt = ((jiffies - mddev->resync_mark) / HZ); if (!dt) dt++; - db = (mddev->curr_mark_cnt - atomic_read(&mddev->recovery_active)) - - mddev->resync_mark_cnt; + + curr_mark_cnt = mddev->curr_mark_cnt; + recovery_active = atomic_read(&mddev->recovery_active); + resync_mark_cnt = mddev->resync_mark_cnt; + + if (curr_mark_cnt >= (recovery_active + resync_mark_cnt)) + db = curr_mark_cnt - (recovery_active + resync_mark_cnt); rt = max_sectors - resync; /* number of remaining sectors */ - sector_div(rt, db/32+1); + rt = div64_u64(rt, db/32+1); rt *= dt; rt >>= 5; -- 2.20.1