Received: by 2002:ac0:a591:0:0:0:0:0 with SMTP id m17-v6csp1415357imm; Thu, 5 Jul 2018 22:59:45 -0700 (PDT) X-Google-Smtp-Source: AAOMgpfU2yggd2tTBXeevM4DeHaAmGKexSVOC95c2C2EzXrqWdQo22fZbNw7Vm98ChR4e5MMUGvJ X-Received: by 2002:a63:943:: with SMTP id 64-v6mr8087112pgj.368.1530856785362; Thu, 05 Jul 2018 22:59:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1530856785; cv=none; d=google.com; s=arc-20160816; b=a3zT6x65aqbCXVhWHCbxQgkiiY94SPjRQUClD2KF/mLr4vHbTsn4YZ7uSPlplVvtDR 5U7tttRDsxOfDT2SjvwQ0EDP2/oGFsmGnQIvg/OfHod2epAWfb/HX8MIzO9ejQDdcbiP B3t2IWlQyAVrcJDiNhV7EmIK6c6F5AgxC0zY146CWvORkQdNEUKR15PAfUx35dLiKi3H 7jUwqGi9htqiVWSi7+7XdSsO01rvLiijSnyjMVeWW0v1I93pta66oaqTEdouhAszZQK8 bZbYTu0HP8zhbj6r9woAJ1Q0OR8khXW2G9GDl+9QU+i13oEvhU1WYI+Sg7ET9PouIz8o ImWQ== 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 :arc-authentication-results; bh=5uGpctMZpeMcZeX8gQ7kR/8cSL0L3eYmaUvrXy2OkOk=; b=F4BKpygSoHKEC0jnnoTG6S37+e5Vk8l7s+C/jilILEZ988kWd+Bo3Gz43BlIkEjxrd rje6grLmvb4j/N9ioCl/yNRp6oKodsJEQA7veOmvNN9s/xFKoO+asZD81QeCyW/ZWT9V /YXZDRiXLsfSnqR0TjYss1f6zFAESzka4mAl6g7w64gQT81zJNiHSwM2dMrpc1Yr/4f4 dpWgz2P4z9cGQ2cR51l4RpnNURlPS3X1nGWz1yDcBm1WMq70ZTcoaQMJBeYSeDJYTw5E PY9A3FxCScFHkAQVGmzR9/0Y+XKqnFf0xFhRNEDdGCdkoRMxT7w2YXRhE0A4qeRQhM4/ 4zfg== 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 y3-v6si7280699pge.41.2018.07.05.22.59.31; Thu, 05 Jul 2018 22:59:45 -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 S934342AbeGFFvd (ORCPT + 99 others); Fri, 6 Jul 2018 01:51:33 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:33354 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934326AbeGFFva (ORCPT ); Fri, 6 Jul 2018 01:51:30 -0400 Received: from localhost (D57D388D.static.ziggozakelijk.nl [213.125.56.141]) by mail.linuxfoundation.org (Postfix) with ESMTPSA id 0FFF586A; Fri, 6 Jul 2018 05:51:29 +0000 (UTC) From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, NeilBrown , Shaohua Li , Jack Wang Subject: [PATCH 4.14 38/61] md: allow metadata update while suspending. Date: Fri, 6 Jul 2018 07:47:02 +0200 Message-Id: <20180706054713.797576051@linuxfoundation.org> X-Mailer: git-send-email 2.18.0 In-Reply-To: <20180706054712.332416244@linuxfoundation.org> References: <20180706054712.332416244@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: NeilBrown commit 35bfc52187f6df8779d0f1cebdb52b7f797baf4e upstream. There are various deadlocks that can occur when a thread holds reconfig_mutex and calls ->quiesce(mddev, 1). As some write request block waiting for metadata to be updated (e.g. to record device failure), and as the md thread updates the metadata while the reconfig mutex is held, holding the mutex can stop write requests completing, and this prevents ->quiesce(mddev, 1) from completing. ->quiesce() is now usually called from mddev_suspend(), and it is always called with reconfig_mutex held. So at this time it is safe for the thread to update metadata without explicitly taking the lock. So add 2 new flags, one which says the unlocked updates is allowed, and one which ways it is happening. Then allow it while the quiesce completes, and then wait for it to finish. Reported-and-tested-by: Xiao Ni Signed-off-by: NeilBrown Signed-off-by: Shaohua Li Signed-off-by: Jack Wang Signed-off-by: Greg Kroah-Hartman --- drivers/md/md.c | 14 ++++++++++++++ drivers/md/md.h | 6 ++++++ 2 files changed, 20 insertions(+) --- a/drivers/md/md.c +++ b/drivers/md/md.c @@ -364,8 +364,12 @@ void mddev_suspend(struct mddev *mddev) return; synchronize_rcu(); wake_up(&mddev->sb_wait); + set_bit(MD_ALLOW_SB_UPDATE, &mddev->flags); + smp_mb__after_atomic(); wait_event(mddev->sb_wait, atomic_read(&mddev->active_io) == 0); mddev->pers->quiesce(mddev, 1); + clear_bit_unlock(MD_ALLOW_SB_UPDATE, &mddev->flags); + wait_event(mddev->sb_wait, !test_bit(MD_UPDATING_SB, &mddev->flags)); del_timer_sync(&mddev->safemode_timer); } @@ -8882,6 +8886,16 @@ void md_check_recovery(struct mddev *mdd unlock: wake_up(&mddev->sb_wait); mddev_unlock(mddev); + } else if (test_bit(MD_ALLOW_SB_UPDATE, &mddev->flags) && mddev->sb_flags) { + /* Write superblock - thread that called mddev_suspend() + * holds reconfig_mutex for us. + */ + set_bit(MD_UPDATING_SB, &mddev->flags); + smp_mb__after_atomic(); + if (test_bit(MD_ALLOW_SB_UPDATE, &mddev->flags)) + md_update_sb(mddev, 0); + clear_bit_unlock(MD_UPDATING_SB, &mddev->flags); + wake_up(&mddev->sb_wait); } } EXPORT_SYMBOL(md_check_recovery); --- a/drivers/md/md.h +++ b/drivers/md/md.h @@ -237,6 +237,12 @@ enum mddev_flags { */ MD_HAS_PPL, /* The raid array has PPL feature set */ MD_HAS_MULTIPLE_PPLS, /* The raid array has multiple PPLs feature set */ + MD_ALLOW_SB_UPDATE, /* md_check_recovery is allowed to update + * the metadata without taking reconfig_mutex. + */ + MD_UPDATING_SB, /* md_check_recovery is updating the metadata + * without explicitly holding reconfig_mutex. + */ }; enum mddev_sb_flags {