linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Lee Jones <lee.jones@linaro.org>
To: gregkh@google.com
Cc: linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org,
	Mariusz Tkaczyk <mariusz.tkaczyk@intel.com>,
	Song Liu <songliubraving@fb.com>, Sasha Levin <sashal@kernel.org>,
	Lee Jones <lee.jones@linaro.org>
Subject: [PATCH 07/10] md: fix for divide error in status_resync
Date: Thu,  7 Nov 2019 20:16:59 +0000	[thread overview]
Message-ID: <20191107201702.27023-7-lee.jones@linaro.org> (raw)
In-Reply-To: <20191107201702.27023-1-lee.jones@linaro.org>

From: Mariusz Tkaczyk <mariusz.tkaczyk@intel.com>

[ 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 <mariusz.tkaczyk@intel.com>
Signed-off-by: Song Liu <songliubraving@fb.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Change-Id: If2744cff07135d0c1fa5f55bcec36ab2137b841e
---
 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 ba201db6afce..9a84a74747f8 100644
--- a/drivers/md/md.c
+++ b/drivers/md/md.c
@@ -6701,9 +6701,9 @@ static void status_unused(struct seq_file *seq)
 static void 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 (mddev->curr_resync <= 3)
@@ -6759,22 +6759,30 @@ static void 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.24.0


  parent reply	other threads:[~2019-11-07 20:17 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-07 20:16 [PATCH 01/10] ASoC: max98090: remove 24-bit format support if RJ is 0 Lee Jones
2019-11-07 20:16 ` [PATCH 02/10] usb: gadget: udc: lpc32xx: allocate descriptor with GFP_ATOMIC Lee Jones
2019-11-07 20:16 ` [PATCH 03/10] mac80211: mesh: fix RCU warning Lee Jones
2019-11-07 20:16 ` [PATCH 04/10] mwifiex: Abort at too short BSS descriptor element Lee Jones
2019-11-07 20:16 ` [PATCH 05/10] Input: imx_keypad - make sure keyboard can always wake up system Lee Jones
2019-11-07 20:16 ` [PATCH 06/10] ARM: davinci: da850-evm: call regulator_has_full_constraints() Lee Jones
2019-11-07 20:16 ` Lee Jones [this message]
2019-11-07 20:17 ` [PATCH 08/10] bnx2x: Check if transceiver implements DDM before access Lee Jones
2019-11-07 20:17 ` [PATCH 09/10] ARM: davinci: da8xx: specify dma_coherent_mask for lcdc Lee Jones
2019-11-07 20:17 ` [PATCH 10/10] can: mcp251x: add support for mcp25625 Lee Jones
2019-11-08  7:42 ` [PATCH 01/10] ASoC: max98090: remove 24-bit format support if RJ is 0 Lee Jones

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20191107201702.27023-7-lee.jones@linaro.org \
    --to=lee.jones@linaro.org \
    --cc=gregkh@google.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mariusz.tkaczyk@intel.com \
    --cc=sashal@kernel.org \
    --cc=songliubraving@fb.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).