Received: by 2002:ac0:a582:0:0:0:0:0 with SMTP id m2-v6csp3930194imm; Mon, 8 Oct 2018 11:52:20 -0700 (PDT) X-Google-Smtp-Source: ACcGV63Q/B3Ooq1DR8Pm5upHObBD9wntw614ALaxecC9gUp9KTZfPlrKmxrK8F32xapFo4H9758m X-Received: by 2002:a65:5347:: with SMTP id w7-v6mr22671743pgr.17.1539024740815; Mon, 08 Oct 2018 11:52:20 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1539024740; cv=none; d=google.com; s=arc-20160816; b=PH8ougqp0BiG7t2PmgFQcuNWFn8zmVxjngnsTMY8bBh4h0dSK+Cc5xwh6TxgouLJSN HJhWpMZNc5EWmgV2GEXw1jGq6R+ZrynWokRoj7ycMI7cjIAKZccbIWhSkavkfBxdnFUw EKV4nZaGulAQCRd7lPOU1T0o28aPCQaIa9UVg3YWNuSi0XvX5vKOnSKsXhXVoExGznBb QC28peHcnDtBUkchmth5V9W+nFWXjoZFhoeQd62j/3nIgEyCD6rSpbbL1BMmlTJdjh3t qAp87lGTrE7r11rlGjp1jsax4XHcl5YNx2zz0u+2y8/wFzadCNPCdyoewTUaApaAjLHN s02A== 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=PLZKvRfPrI82N33yRhCWsvoxEH3AZ6PzhNTgXgxmdGw=; b=jpe+pyz+kYxOrvOo+RrV+XwRLoYPn6k4xvNYD4HPcorOYTbvs35C/w31UnI5n0XOwW rvSy3bZu6l1x8an2P33f7oBa+e9F9fcRJMoB9K8RonDR6VRpRdnAJ+eoFWitNswbEi3J YpJ/g4ExP9k10qePH0R9/azR5bfZ9Er0NjvGS/4MfN7uSxIZs2DfOALGFUoVH/XE5ua3 DXURolrq5wgjFM0l/akw94m3cj9MDpn48179uUfkcN9B/fqDmJpJ9RuQzSpFzXrPtpMz AxtH3V0cGxti24oDAUoEak7EGZ9EU/fWq84yQaCwnt0q528hS71zUfMaPeVEv7U7S2I2 wmOg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=xao6VgZp; 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 u81-v6si12481754pfi.175.2018.10.08.11.52.05; Mon, 08 Oct 2018 11:52:20 -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=xao6VgZp; 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 S1732180AbeJICDz (ORCPT + 99 others); Mon, 8 Oct 2018 22:03:55 -0400 Received: from mail.kernel.org ([198.145.29.99]:53508 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729987AbeJICDy (ORCPT ); Mon, 8 Oct 2018 22:03:54 -0400 Received: from localhost (ip-213-127-77-176.ip.prioritytelecom.net [213.127.77.176]) (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 219E6214C5; Mon, 8 Oct 2018 18:50:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1539024646; bh=dlWjQA1R4GC5HmTnsSrqcR16un9M789p0ddl7Y3cMbA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=xao6VgZpWuOtcL/pKuM58EXUloZj+Y+LCD02vMBGyBYW+czRkIbjvPrFpYVEtt6MU YzV8IFe3SBS0L/wh4RGuWq6PnJBCrG1Wv122QGlXvDn1f50gr8NlECKnykF5bfJ0V+ rLAUqdigYTvs6sg/TMy7e4N6YcDJitz5WDAEwpK0= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Heinz Mauelshagen , Mike Snitzer , Sasha Levin Subject: [PATCH 4.18 107/168] dm raid: fix reshape race on small devices Date: Mon, 8 Oct 2018 20:31:27 +0200 Message-Id: <20181008175624.118391622@linuxfoundation.org> X-Mailer: git-send-email 2.19.0 In-Reply-To: <20181008175620.043587728@linuxfoundation.org> References: <20181008175620.043587728@linuxfoundation.org> User-Agent: quilt/0.65 X-stable: review 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 4.18-stable review patch. If anyone has any objections, please let me know. ------------------ From: Heinz Mauelshagen [ Upstream commit 38b0bd0cda07d34ad6f145fce675ead74739c44e ] Loading a new mapping table, the dm-raid target's constructor retrieves the volatile reshaping state from the raid superblocks. When the new table is activated in a following resume, the actual reshape position is retrieved. The reshape driven by the previous mapping can already have finished on small and/or fast devices thus updating raid superblocks about the new raid layout. This causes the actual array state (e.g. stripe size reshape finished) to be inconsistent with the one in the new mapping, causing hangs with left behind devices. This race does not occur with usual raid device sizes but with small ones (e.g. those created by the lvm2 test suite). Fix by no longer transferring stale/inconsistent raid_set state during preresume. Signed-off-by: Heinz Mauelshagen Signed-off-by: Mike Snitzer Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman --- drivers/md/dm-raid.c | 48 +----------------------------------------------- 1 file changed, 1 insertion(+), 47 deletions(-) --- a/drivers/md/dm-raid.c +++ b/drivers/md/dm-raid.c @@ -29,9 +29,6 @@ */ #define MIN_RAID456_JOURNAL_SPACE (4*2048) -/* Global list of all raid sets */ -static LIST_HEAD(raid_sets); - static bool devices_handle_discard_safely = false; /* @@ -227,7 +224,6 @@ struct rs_layout { struct raid_set { struct dm_target *ti; - struct list_head list; uint32_t stripe_cache_entries; unsigned long ctr_flags; @@ -273,19 +269,6 @@ static void rs_config_restore(struct rai mddev->new_chunk_sectors = l->new_chunk_sectors; } -/* Find any raid_set in active slot for @rs on global list */ -static struct raid_set *rs_find_active(struct raid_set *rs) -{ - struct raid_set *r; - struct mapped_device *md = dm_table_get_md(rs->ti->table); - - list_for_each_entry(r, &raid_sets, list) - if (r != rs && dm_table_get_md(r->ti->table) == md) - return r; - - return NULL; -} - /* raid10 algorithms (i.e. formats) */ #define ALGORITHM_RAID10_DEFAULT 0 #define ALGORITHM_RAID10_NEAR 1 @@ -764,7 +747,6 @@ static struct raid_set *raid_set_alloc(s mddev_init(&rs->md); - INIT_LIST_HEAD(&rs->list); rs->raid_disks = raid_devs; rs->delta_disks = 0; @@ -782,9 +764,6 @@ static struct raid_set *raid_set_alloc(s for (i = 0; i < raid_devs; i++) md_rdev_init(&rs->dev[i].rdev); - /* Add @rs to global list. */ - list_add(&rs->list, &raid_sets); - /* * Remaining items to be initialized by further RAID params: * rs->md.persistent @@ -797,7 +776,7 @@ static struct raid_set *raid_set_alloc(s return rs; } -/* Free all @rs allocations and remove it from global list. */ +/* Free all @rs allocations */ static void raid_set_free(struct raid_set *rs) { int i; @@ -815,8 +794,6 @@ static void raid_set_free(struct raid_se dm_put_device(rs->ti, rs->dev[i].data_dev); } - list_del(&rs->list); - kfree(rs); } @@ -3947,29 +3924,6 @@ static int raid_preresume(struct dm_targ if (test_and_set_bit(RT_FLAG_RS_PRERESUMED, &rs->runtime_flags)) return 0; - if (!test_bit(__CTR_FLAG_REBUILD, &rs->ctr_flags)) { - struct raid_set *rs_active = rs_find_active(rs); - - if (rs_active) { - /* - * In case no rebuilds have been requested - * and an active table slot exists, copy - * current resynchonization completed and - * reshape position pointers across from - * suspended raid set in the active slot. - * - * This resumes the new mapping at current - * offsets to continue recover/reshape without - * necessarily redoing a raid set partially or - * causing data corruption in case of a reshape. - */ - if (rs_active->md.curr_resync_completed != MaxSector) - mddev->curr_resync_completed = rs_active->md.curr_resync_completed; - if (rs_active->md.reshape_position != MaxSector) - mddev->reshape_position = rs_active->md.reshape_position; - } - } - /* * The superblocks need to be updated on disk if the * array is new or new devices got added (thus zeroed