Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp9101790pxu; Mon, 28 Dec 2020 06:41:02 -0800 (PST) X-Google-Smtp-Source: ABdhPJxiB5b4oMZa3MzxGWTXp1j9TmONBpfxJmaaIfqtYOP5rweP6lHPBiQbzMCt0gUeJaAvpLsb X-Received: by 2002:a50:8e19:: with SMTP id 25mr40459312edw.263.1609166462434; Mon, 28 Dec 2020 06:41:02 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1609166462; cv=none; d=google.com; s=arc-20160816; b=WwURFbtERhCZiKSe0YB0Woir/L+btgBFXp2e4VU5Q9d9JEI8luhkuf6n+2hQdgwH5k Serr+GqeOKRpMwEbo2hu0gC5RHzxbgkCNgIbp7WjFFAsoJOJRFoGh2Tx5P9QtTdZya1i uSiOlASwbihkIcQpBntZHa31DV0YfPUoMn0B9SpLDJ6Rd0RSJNH6hRzVlAXKEVLLA/l1 CnU2MQXLHXOVHom0fHsUSen+UJMRDpjQY91rVPM7xiRe9oYYGWAAY7kyj6HkP+pF7VbG S7jhe4MtV/LvABFmBewZXDcgfnGJB80aCoYB5iEmj/MERnEKTe6AaOKMaLffraTbu0/7 CBbA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=7QKVMqUfKAuEXGr3cE6trX8sTtmxYH9Fc8cUZcGtr28=; b=bNmTJv1Cc+1vtsRsEOl45DfTvZQdnsuurvz4AEF9rKEDU6VhH7hvZ+X49OAuYomvjx o+6Y4/tk5cpcDgvJcF49ln355j6AyQsRgq551+qMp6ql0+JhDb4OY1zWYeOKaiAYDo7I 0QMiYP8PlD/N+Bvo29m6pnrwpSHI4wB64zY+G+spRiuKUCDT8aMnRx5hACa6E7gFfHYe XaakKw0mamNMT2HbNnN59fPnCZS+R+g+qZyaejuYk7ugUL9oDImuV7wLTwDlkalGweHt V+uAqwHideKkQyc/2m5QMaQuO83e/WZpf5WSGylx11nz7DYhbJGErGhdTGl8sl0ntwnQ 1STw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=UTmozqiz; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id gn22si17919560ejc.749.2020.12.28.06.40.39; Mon, 28 Dec 2020 06:41:02 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=UTmozqiz; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2392307AbgL1Oid (ORCPT + 99 others); Mon, 28 Dec 2020 09:38:33 -0500 Received: from mail.kernel.org ([198.145.29.99]:40036 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2392104AbgL1Obw (ORCPT ); Mon, 28 Dec 2020 09:31:52 -0500 Received: by mail.kernel.org (Postfix) with ESMTPSA id 48265208B6; Mon, 28 Dec 2020 14:31:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1609165871; bh=LexJaubKRqw9/e7RraBeH1d8mwhQ4ISOtgxqE82OAfk=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=UTmozqizrGg8HElfkh9u/sf6U0UC+IgiT85QQD95GjxBiHHD5h4S5vC0xTaHF5Zde NMFABsmAnX/biP9upkmEtyb7JFShen0G5JsljZMsEryeDXrMpJjTi7JyhFxcWzjFO/ iE6bBpqfl5rpALhoXko8VCugebMiBnFnKQdXR5wg= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Zhao Heming , Song Liu Subject: [PATCH 5.10 685/717] md/cluster: block reshape with remote resync job Date: Mon, 28 Dec 2020 13:51:23 +0100 Message-Id: <20201228125053.804239720@linuxfoundation.org> X-Mailer: git-send-email 2.29.2 In-Reply-To: <20201228125020.963311703@linuxfoundation.org> References: <20201228125020.963311703@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Zhao Heming commit a8da01f79c89755fad55ed0ea96e8d2103242a72 upstream. Reshape request should be blocked with ongoing resync job. In cluster env, a node can start resync job even if the resync cmd isn't executed on it, e.g., user executes "mdadm --grow" on node A, sometimes node B will start resync job. However, current update_raid_disks() only check local recovery status, which is incomplete. As a result, we see user will execute "mdadm --grow" successfully on local, while the remote node deny to do reshape job when it doing resync job. The inconsistent handling cause array enter unexpected status. If user doesn't observe this issue and continue executing mdadm cmd, the array doesn't work at last. Fix this issue by blocking reshape request. When node executes "--grow" and detects ongoing resync, it should stop and report error to user. The following script reproduces the issue with ~100% probability. (two nodes share 3 iSCSI luns: sdg/sdh/sdi. Each lun size is 1GB) ``` # on node1, node2 is the remote node. ssh root@node2 "mdadm -S --scan" mdadm -S --scan for i in {g,h,i};do dd if=/dev/zero of=/dev/sd$i oflag=direct bs=1M \ count=20; done mdadm -C /dev/md0 -b clustered -e 1.2 -n 2 -l mirror /dev/sdg /dev/sdh ssh root@node2 "mdadm -A /dev/md0 /dev/sdg /dev/sdh" sleep 5 mdadm --manage --add /dev/md0 /dev/sdi mdadm --wait /dev/md0 mdadm --grow --raid-devices=3 /dev/md0 mdadm /dev/md0 --fail /dev/sdg mdadm /dev/md0 --remove /dev/sdg mdadm --grow --raid-devices=2 /dev/md0 ``` Cc: stable@vger.kernel.org Signed-off-by: Zhao Heming Signed-off-by: Song Liu Signed-off-by: Greg Kroah-Hartman --- drivers/md/md.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) --- a/drivers/md/md.c +++ b/drivers/md/md.c @@ -7278,6 +7278,7 @@ static int update_raid_disks(struct mdde return -EINVAL; if (mddev->sync_thread || test_bit(MD_RECOVERY_RUNNING, &mddev->recovery) || + test_bit(MD_RESYNCING_REMOTE, &mddev->recovery) || mddev->reshape_position != MaxSector) return -EBUSY; @@ -9645,8 +9646,11 @@ static void check_sb_changes(struct mdde } } - if (mddev->raid_disks != le32_to_cpu(sb->raid_disks)) - update_raid_disks(mddev, le32_to_cpu(sb->raid_disks)); + if (mddev->raid_disks != le32_to_cpu(sb->raid_disks)) { + ret = update_raid_disks(mddev, le32_to_cpu(sb->raid_disks)); + if (ret) + pr_warn("md: updating array disks failed. %d\n", ret); + } /* * Since mddev->delta_disks has already updated in update_raid_disks,