Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp525382pxb; Wed, 3 Mar 2021 08:53:18 -0800 (PST) X-Google-Smtp-Source: ABdhPJzpq8l4Lengvwi4r0QcPDrH6QHHGDFS4UGkejohwuCDQl5Igwd9rjt9FIUeMVspLsoCI4Rt X-Received: by 2002:a17:906:1ecc:: with SMTP id m12mr26669477ejj.4.1614790397748; Wed, 03 Mar 2021 08:53:17 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1614790397; cv=none; d=google.com; s=arc-20160816; b=icnInKmLCqy5ZiHZwEzNDNEDK3/a+wT2iYWczYFK+GFvpTvxpM58qs/Qq7ZcJ7Q4Qk 8SX2JQHb0JNlpcHKu1V3YFDawTjwVPG0muoOHHdkhUdzjgUGtfwyCvkaSVCXYrVtUZ56 rHp3gWYJqKSCu2CXseWwalYpowc7PY3QE6ONiMIN3pncMs/KO5MWIiuw9mn019j6i9vH dwCPrLzECet+YTdQ91tkbxrxrQ6w0twQ02dTtNQYavNU/JFxR/EiBt3fp04bzWLcRfY9 ocAprZjYUjCyA4JC+h+Lk+3isX4OykDX87L3I8A5TUeSDZ860C6xeuvj3wDmdBI6O/+0 Wv5Q== 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=5pUcAAch6g8ZAIsECJkqarQYgH9STQ3u/RchUwoo4mk=; b=kPXZn6L7cljOlsUC0UD9OQLE+T0VowgV65rTpk0T55yCJw/Q/gsJomVTU9n64U+yPH 0hxCqqIukqFXGcmV8sOFWm+xu9R9xovzS4TcInshj1WUSggL0te1zEMKON1YCWEjk7x1 m+nhZfj8EWhqB1l1z65hN1rcOB/spiV8quydKz62xeuVnCr1M8vmq9vkAkkRrnLixR0N 4iP5D2mwd13ws9QaPiP0do3K2n1Pw87JK0UavE/bVfUdcjMETVWwXzl04c0dMp8kbfIm eRLvqznHVn0hXVKPqA5QGOwM9+Rb0/C4WhG6vJI9jxe3GWvluWkeMQ7xDjTLwkTuG+MI V2bg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=Kg93kPtr; 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 f16si1467214edy.392.2021.03.03.08.52.28; Wed, 03 Mar 2021 08:53:17 -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=Kg93kPtr; 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 S242981AbhCBA1I (ORCPT + 99 others); Mon, 1 Mar 2021 19:27:08 -0500 Received: from mail.kernel.org ([198.145.29.99]:41704 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S239999AbhCAS2Q (ORCPT ); Mon, 1 Mar 2021 13:28:16 -0500 Received: by mail.kernel.org (Postfix) with ESMTPSA id 2A94F652A8; Mon, 1 Mar 2021 17:33:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1614620014; bh=QOhJceIL0u1BL/LPk2HuUcDdu1yh6F7Xpxzv3g4PCtE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Kg93kPtrmTZllm4d4tY4O3QaMH+/5BXQw/4p+kLW3TsJYlFFkoDSsVEuRq+YhSnNO 5id03h6ZYfZ0Ct/aDtB3M0wyggOPT7vEG29EsqeAai6wfNhpz3qWQIkuK1REk4z3Z+ U/AAzOUvkf1OUohvBWcsJQFZctuyLch7KVsUToa8= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Nikos Tsironis , Mike Snitzer Subject: [PATCH 5.10 654/663] dm era: only resize metadata in preresume Date: Mon, 1 Mar 2021 17:15:02 +0100 Message-Id: <20210301161214.208425271@linuxfoundation.org> X-Mailer: git-send-email 2.30.1 In-Reply-To: <20210301161141.760350206@linuxfoundation.org> References: <20210301161141.760350206@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: Nikos Tsironis commit cca2c6aebe86f68103a8615074b3578e854b5016 upstream. Metadata resize shouldn't happen in the ctr. The ctr loads a temporary (inactive) table that will only become active upon resume. That is why resize should always be done in terms of resume. Otherwise a load (ctr) whose inactive table never becomes active will incorrectly resize the metadata. Also, perform the resize directly in preresume, instead of using the worker to do it. The worker might run other metadata operations, e.g., it could start digestion, before resizing the metadata. These operations will end up using the old size. This could lead to errors, like: device-mapper: era: metadata_digest_transcribe_writeset: dm_array_set_value failed device-mapper: era: process_old_eras: digest step failed, stopping digestion The reason of the above error is that the worker started the digestion of the archived writeset using the old, larger size. As a result, metadata_digest_transcribe_writeset tried to write beyond the end of the era array. Fixes: eec40579d84873 ("dm: add era target") Cc: stable@vger.kernel.org # v3.15+ Signed-off-by: Nikos Tsironis Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman --- drivers/md/dm-era-target.c | 21 ++++++++++----------- 1 file changed, 10 insertions(+), 11 deletions(-) --- a/drivers/md/dm-era-target.c +++ b/drivers/md/dm-era-target.c @@ -1501,15 +1501,6 @@ static int era_ctr(struct dm_target *ti, } era->md = md; - era->nr_blocks = calc_nr_blocks(era); - - r = metadata_resize(era->md, &era->nr_blocks); - if (r) { - ti->error = "couldn't resize metadata"; - era_destroy(era); - return -ENOMEM; - } - era->wq = alloc_ordered_workqueue("dm-" DM_MSG_PREFIX, WQ_MEM_RECLAIM); if (!era->wq) { ti->error = "could not create workqueue for metadata object"; @@ -1584,9 +1575,17 @@ static int era_preresume(struct dm_targe dm_block_t new_size = calc_nr_blocks(era); if (era->nr_blocks != new_size) { - r = in_worker1(era, metadata_resize, &new_size); - if (r) + r = metadata_resize(era->md, &new_size); + if (r) { + DMERR("%s: metadata_resize failed", __func__); + return r; + } + + r = metadata_commit(era->md); + if (r) { + DMERR("%s: metadata_commit failed", __func__); return r; + } era->nr_blocks = new_size; }