From patchwork Tue Nov 28 17:30:25 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Josef Bacik X-Patchwork-Id: 10080805 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 351DA602DC for ; Tue, 28 Nov 2017 17:30:32 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 20D9429516 for ; Tue, 28 Nov 2017 17:30:32 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 155D52951F; Tue, 28 Nov 2017 17:30:32 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.9 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 9AA5529516 for ; Tue, 28 Nov 2017 17:30:31 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753035AbdK1Ra2 (ORCPT ); Tue, 28 Nov 2017 12:30:28 -0500 Received: from mail-qt0-f195.google.com ([209.85.216.195]:41155 "EHLO mail-qt0-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753263AbdK1Ra1 (ORCPT ); Tue, 28 Nov 2017 12:30:27 -0500 Received: by mail-qt0-f195.google.com with SMTP id i40so817222qti.8 for ; Tue, 28 Nov 2017 09:30:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=toxicpanda-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id; bh=W7dhj6eX0eBFeShHO1oyPsSan6reg5I5oW/kTJhY8hQ=; b=v9VC/820pxGefZ7akhXGhe3EnIHNVWFeg23pkGYfDaNqKizv1yygNiKRSSxnU5Yx1G 1lZLGOWiCh6jx56kWDF4EGi4KhixrlldBzbGE9+V0SHFOpcavPiSHGLaa6bTPWxx8kzJ vIVRltioz3DNAv7M6MuRPWve22wtzE10H2FRcUvHNUpn/jk9BW6Jvit3b3P7M2MkehHI WrZDCpHUv8gFRiGbsdZwUY2hHnaXC8DkvcX/kLJPQEgfYhp5Zq6jlcZAZvtPDtq9L+WL KHwr2qeSprFiqmvpNH8sqIMg9m7H/7m8/EIEQVPEXxSJ6lbC+RnEERPqMu/NX+gaLKHk 7Wlg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=W7dhj6eX0eBFeShHO1oyPsSan6reg5I5oW/kTJhY8hQ=; b=tV67J+SH9SaQt6rzE1m3UrVTymVvmeIi8WI7L1TPXxFlNWEXP4vrWuD+vvysYB0NcE DxPXtVKQcTgJo9kbQZKU4gH0NmPwmFpkQiLDHg6ZCUtmex+Z+bOUuWPrL9o/Ex5L0vxE 6gKAwGpaI3MK3HAlpg1ZiJ94su1If1VXPjpsGhUV3N0g/9TqH09AHSxLzPVZ4gEMT4pU 4g51dgL01ZdsSBdVt98Tk3T7c139hfTPEIOJ4PGQJuKObv5XHRXWFaBKojPywjDV5y+e dsJyS7dO1/LLwaFjao6QhFvX1kCiKSTqDzJHEpM2DOI79IWqIEyZ+d2bOYAHKcpkLiNp BkwA== X-Gm-Message-State: AJaThX5OmK5+dfNkwNd6vYSeDdtT7YD4yllTJZyDkHETVrqzwUbgL9vm rpvqJ7mugow4Af/OG+J49/HE/g== X-Google-Smtp-Source: AGs4zMY/tpMBq9YWTMR4RDtPhl9bY2g4jqoaJOZOt81zkoL0q1Z+6A+hVebg8caR9BoVPHzJ+Xh3Pw== X-Received: by 10.237.37.89 with SMTP id w25mr42992720qtc.160.1511890227319; Tue, 28 Nov 2017 09:30:27 -0800 (PST) Received: from localhost (cpe-2606-A000-4381-1201-225-22FF-FEB3-E51A.dyn6.twc.com. [2606:a000:4381:1201:225:22ff:feb3:e51a]) by smtp.gmail.com with ESMTPSA id 44sm21647516qtq.62.2017.11.28.09.30.26 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 Nov 2017 09:30:26 -0800 (PST) From: Josef Bacik To: snitzer@redhat.com, dm-devel@redhat.com, linux-fsdevel@vger.kernel.org Cc: Josef Bacik Subject: [PATCH] dm-log-writes: invalidate the bdev's for both of our devices Date: Tue, 28 Nov 2017 12:30:25 -0500 Message-Id: <1511890225-16601-1-git-send-email-josef@toxicpanda.com> X-Mailer: git-send-email 2.7.5 Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP From: Josef Bacik Amir noticed that sometimes the xfstests using dm-log-writes would fail randomly but would work fine after trying again manually. This is because dm-log-writes writes directly to the device, but the log replay tools read and write via the block device page cache. Sometimes this resulted in stale data being in the block device's page cache which would result in random failures. To handle this simply invalidate the block device page cache on destruction so any replay of the log device that follows will be forced to read the new real contents. Reported-and-tested-by: Amir Goldstein Signed-off-by: Josef Bacik --- drivers/md/dm-log-writes.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/md/dm-log-writes.c b/drivers/md/dm-log-writes.c index 8b80a9ce9ea9..1c502930af5e 100644 --- a/drivers/md/dm-log-writes.c +++ b/drivers/md/dm-log-writes.c @@ -545,6 +545,8 @@ static void log_writes_dtr(struct dm_target *ti) !atomic_read(&lc->pending_blocks)); kthread_stop(lc->log_kthread); + invalidate_bdev(lc->logdev->bdev); + invalidate_bdev(lc->dev->bdev); WARN_ON(!list_empty(&lc->logging_blocks)); WARN_ON(!list_empty(&lc->unflushed_blocks)); dm_put_device(ti, lc->dev);