From patchwork Sun Feb 21 15:36:04 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Alex Lyakas X-Patchwork-Id: 8368541 Return-Path: X-Original-To: patchwork-linux-btrfs@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork2.web.kernel.org (Postfix) with ESMTP id 152BFC0553 for ; Sun, 21 Feb 2016 17:31:12 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 2BA7D2041C for ; Sun, 21 Feb 2016 17:31:11 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id BC1AE2040F for ; Sun, 21 Feb 2016 17:31:09 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752148AbcBUR3K (ORCPT ); Sun, 21 Feb 2016 12:29:10 -0500 Received: from mail-wm0-f52.google.com ([74.125.82.52]:38815 "EHLO mail-wm0-f52.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751645AbcBUR3H (ORCPT ); Sun, 21 Feb 2016 12:29:07 -0500 Received: by mail-wm0-f52.google.com with SMTP id a4so133460089wme.1 for ; Sun, 21 Feb 2016 09:29:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zadarastorage-com.20150623.gappssmtp.com; s=20150623; h=message-id:from:to:subject:date:mime-version:content-type :content-transfer-encoding:importance; bh=IlYdXEu3ZMUL7r46TPGPSV5x0tlGjg2BMJIsldkyEXs=; b=09Wst9hH76ctM6d3bmktySaljRjqDWrEPcVcK8TyxU/dr+2v/kHxlWbdAh/dRpHxzc 7dy2Nqn5lzq5sqGUA5o6uWKSBI9BTrHbgKQS4wro5m8DBRam/0V2ySJa5O5VxpVUwnrA XnNWysalSXPAN0yQ9BlKRcSv2Rxl1b+iENj4TkJ8IAmXkY8BmBhKFmw8HKIBbJXZsPw/ Ti2BzM6HKdIl81ZxrEM+uF/rpo2mzrB7VLA86ZXhcaFQbVJ1gdJLsE5ekVGLh6ih7Eg/ x1eMd4qcOvXKzXZFRs8Ge2RAR15HVAJoqRjxeQJ/oS1Sm1kIYM8nx+J+QDm0cWc4+3Ds D0KQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:from:to:subject:date:mime-version :content-type:content-transfer-encoding:importance; bh=IlYdXEu3ZMUL7r46TPGPSV5x0tlGjg2BMJIsldkyEXs=; b=WJ4rNW0Q7px4r10QOuPeucPoadKWxrbtXeZCYmgQTIldvqr47ohMbJv3ZojmhUbvtC 9pSm73ohjQLapkMYTHtVsQN12JTnFXlmXj2FndaBqqpgGaAbJ76Sj+qNdk2ynF6UH1rj yymOv+eTM/b/sR03AFH+SCf4mlb6cHuM1PBSYQzTuTkwgXH4PKyXoWNCVcbP6tBLWOTC NLAKB/Uhn78lh0iY1AzcDO1qVYtRzQRw9wFqgtNnSBBeWDSZ8P9n8OCMz3Hq+7DPVsw7 8Mkp1lzWvXmHq9Rs+jAibzyFx2KjwQtWMn4tCmB0WVfO/HeS2TCN6SiAyjIv9O5X7+w2 giiA== X-Gm-Message-State: AG10YOTkjwY8ndCMT3TO7ZfhNDH3oX4lZ93HgtC9CGO876jFHlM0w0ZppEqoeAIlJSCrWA== X-Received: by 10.194.2.202 with SMTP id 10mr26374521wjw.94.1456068966955; Sun, 21 Feb 2016 07:36:06 -0800 (PST) Received: from alyakaslap (bzq-169-168-31-234.red.bezeqint.net. [31.168.169.234]) by smtp.gmail.com with ESMTPSA id k8sm9139152wjr.38.2016.02.21.07.36.05 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 21 Feb 2016 07:36:06 -0800 (PST) Message-ID: <286C424321A6496789A866288933406A@alyakaslap> From: "Alex Lyakas" To: , , Subject: [RFC - PATCH] btrfs: do not write corrupted metadata blocks to disk Date: Sun, 21 Feb 2016 17:36:04 +0200 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 15.4.3555.308 X-MimeOLE: Produced By Microsoft MimeOLE V15.4.3555.308 Sender: linux-btrfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-btrfs@vger.kernel.org X-Spam-Status: No, score=-4.6 required=5.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_HI,RP_MATCHES_RCVD,STOX_REPLY_TYPE, STOX_REPLY_TYPE_WITHOUT_QUOTES, T_DKIM_INVALID, UNPARSEABLE_RELAY autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP csum_dirty_buffer was issuing a warning in case the extent buffer did not look alright, but was still returning success. Let's return error in this case, and also add two additional sanity checks on the extent buffer header. We had btrfs metadata corruption, and after looking at the logs we saw that WARN_ON(found_start != start) has been triggered. We are still investigating which component trashed the cache page which belonged to btrfs. But btrfs only issued a warning, and as a result, the corrupted metadata block went to disk. I think we should return an error in such case that the extent buffer doesn't look alright. The caller up the chain may BUG_ON on this, for example flush_epd_write_bio will, but it is better than to have a silent metadata corruption on disk. Note: this patch has been properly tested on 3.18 kernel only. Signed-off-by: Alex Lyakas --- fs/btrfs/disk-io.c | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-) diff --git a/fs/btrfs/disk-io.c b/fs/btrfs/disk-io.c index 4545e2e..701e706 100644 --- a/fs/btrfs/disk-io.c +++ b/fs/btrfs/disk-io.c @@ -508,22 +508,32 @@ static int csum_dirty_buffer(struct btrfs_fs_info *fs_info, struct page *page) { u64 start = page_offset(page); u64 found_start; struct extent_buffer *eb; eb = (struct extent_buffer *)page->private; if (page != eb->pages[0]) return 0; found_start = btrfs_header_bytenr(eb); if (WARN_ON(found_start != start || !PageUptodate(page))) - return 0; - csum_tree_block(fs_info, eb, 0); + return -EUCLEAN; +#ifdef CONFIG_BTRFS_ASSERT + if (WARN_ON(memcmp_extent_buffer(eb, fs_info->fsid, + (unsigned long)btrfs_header_fsid(), BTRFS_FSID_SIZE))) + return -EUCLEAN; + if (WARN_ON(memcmp_extent_buffer(eb, fs_info->fsid, + (unsigned long)btrfs_header_chunk_tree_uuid(eb), + BTRFS_FSID_SIZE))) + return -EUCLEAN; +#endif + if (csum_tree_block(fs_info, eb, 0)) + return -EUCLEAN; return 0; } static int check_tree_block_fsid(struct btrfs_fs_info *fs_info, struct extent_buffer *eb) { struct btrfs_fs_devices *fs_devices = fs_info->fs_devices; u8 fsid[BTRFS_UUID_SIZE]; int ret = 1;