From patchwork Fri Mar 6 10:01:13 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Omar Sandoval X-Patchwork-Id: 5952031 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 D2B75BF440 for ; Fri, 6 Mar 2015 10:07:41 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id BB2572034E for ; Fri, 6 Mar 2015 10:07:40 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 746A6201F4 for ; Fri, 6 Mar 2015 10:07:39 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933565AbbCFKGs (ORCPT ); Fri, 6 Mar 2015 05:06:48 -0500 Received: from mail-pa0-f52.google.com ([209.85.220.52]:34630 "EHLO mail-pa0-f52.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933309AbbCFKBP (ORCPT ); Fri, 6 Mar 2015 05:01:15 -0500 Received: by paceu11 with SMTP id eu11so36425046pac.1 for ; Fri, 06 Mar 2015 02:01:15 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-type:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=6+SCK4BYy/HWtPjVfgeUP8Hwn0sj2dfKvQGWoe2ikVc=; b=XQpmnVdN5Fg/X/rwfq1eEAG+R0rn6KrlsIamc0zkoIovehgRK0psfKuJPfkyOc95IB /g18pvvuPRVHse1W5XN06nTFZWLi68MWi8j3+qvDRVm7tyuO/sza3gbob/73VCDCtakb yFagUMWjPJovUouRnqLbRlerRlgw1jpSdpFjzlYQnOaTIJwihulrgfEexZ0u4RUhNW10 xYMPAmXJoX0jYl0tJ4tPFzuGCx1UNTsnDMkSdutHQOLl3NDDJ3EyAFz4L6Z2iAoPrxfI fhqW68y9iOj74RD1xrFmpgNAWWKVUWy5F/YjwrBD4Y4XzLFSaokm7p0Z6lf9Gcn2L8lJ /viQ== X-Gm-Message-State: ALoCoQmcFA/k2+u1ldtCxK0EfDXQlSoZ9uPqUlFDSgbcD2F7oaVgLHrIq62uYajVpN8OYgjHK/0s X-Received: by 10.69.20.33 with SMTP id gz1mr24760584pbd.16.1425636075241; Fri, 06 Mar 2015 02:01:15 -0800 (PST) Received: from mew (c-76-104-211-44.hsd1.wa.comcast.net. [76.104.211.44]) by mx.google.com with ESMTPSA id w1sm3056779pdp.25.2015.03.06.02.01.14 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 06 Mar 2015 02:01:14 -0800 (PST) Date: Fri, 6 Mar 2015 02:01:13 -0800 From: Omar Sandoval To: Qu Wenruo , Chris Mason , David Sterba Cc: bo.li.liu@oracle.com, Eryu Guan , linux-btrfs@vger.kernel.org Subject: Re: btrfs oops while mounting fuzzed btrfs image Message-ID: <20150306100113.GA26485@mew> References: <20150305070933.GB17015@dhcp-13-216.nay.redhat.com> <20150305094611.GA4147@localhost.localdomain> <20150305101354.GC17015@dhcp-13-216.nay.redhat.com> <20150305102701.GE4147@localhost.localdomain> <54F90937.70309@cn.fujitsu.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <54F90937.70309@cn.fujitsu.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-btrfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-btrfs@vger.kernel.org X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_HI, T_RP_MATCHES_RCVD, 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 On Fri, Mar 06, 2015 at 09:56:07AM +0800, Qu Wenruo wrote: > > > -------- Original Message -------- > Subject: Re: btrfs oops while mounting fuzzed btrfs image > From: Liu Bo > To: Eryu Guan > Date: 2015?03?05? 18:27 > > >On Thu, Mar 05, 2015 at 06:13:54PM +0800, Eryu Guan wrote: > >>On Thu, Mar 05, 2015 at 05:46:12PM +0800, Liu Bo wrote: > >>>On Thu, Mar 05, 2015 at 03:09:33PM +0800, Eryu Guan wrote: > >>>>Hi, > >>>> > >>>>I was testing btrfs with fsfuzzer and encountered a divide error on > >>>>mount, kernel version 3.19 and 4.0-rc1. > >>>> > >>>>I found a similar bug on kernel bugzilla > >>>> > >>>>https://bugzilla.kernel.org/show_bug.cgi?id=88611 > >>>> > >>>>Please find the fuzzed btrfs image in the buzilla, and the following > >>>>command will reproduce: > >>>> > >>>>mount -o loop btrfs.img /mnt/btrfs > >>> > >>>A divide by 0 oops. > >>> > >>>My printk shows that a raid56 chunk has a negative map->length, so we need to find out > >>>how fsfuzzer made that. Can you share your script so that we can > >>>reproduce the oops? > >> > >>You can download fsfuzzer from here: > >> > >>http://people.redhat.com/sgrubb/files/fsfuzzer-0.7.tar.gz > >> > >>What it does is simply writing random garbage to the first 10% of the > >>fs image. You can take a look at fsfuzz and mangle.c > > > >Will take a look, but I guess writing the first 10% of fs image may mess up fs's super block, > >if it does then we can do nothing about it except throwing a WARNING_ONCE(). > > > >Thanks, > > > >-liubo > I'm using the same tool to do enhance btrfsck, and the tool will skip the > first 1M bytes by default, so superblock is not affected. > > Thanks, > Qu Hi, Qu, I'm not seeing that in the code I'm looking at :( In fsfuzz:447, I see the mangle executable called with an offset starting at 0, which would mean that the superblock isn't safe. (Btw, that line also indicates that we potentially write to the entire file system image, not just the beginning. My understanding from mangle.c is that up to 10% of the file contents are modified, not the first 10% of the file by length. Someone please correct me if I'm wrong!). Indeed, Eryu's dmesg shows: [ 309.384037] BTRFS: super block crcs don't match, older mkfs detected This commit is relevant: ---- commit 667e7d94a1683661cff5fe9a0fa0d7f8fdd2c007 Author: Chris Mason Date: Tue May 7 11:00:13 2013 -0400 Btrfs: allow superblock mismatch from older mkfs We've added new checks to make sure the super block crc is correct during mount. A fresh filesystem from an older mkfs won't have the crc set. This adds a warning when it finds a newly created filesystem but doesn't fail the mount. Signed-off-by: Chris Mason ---- So, it looks like the super block is corrupted, but we ignore it because this is a fresh filesystem. I can easily trigger a related panic with this: ---- while true; do dd if=/dev/urandom of=btrfs.img bs=1M count=16 mkfs.btrfs btrfs.img dd if=/dev/urandom of=btrfs.img bs=1 seek=$((64 * 1024 + 88)) count=8 conv=notrunc mount -o loop btrfs.img /mnt && umount /mnt done ---- I'm not sure that this is exactly what's happening with Eryu's image, but it's definitely an issue. I also don't know whether it's safe to get rid of that special case. It looks like it's needed for btrfs-progs before v3.12 (November 2013). Chris? David? Thanks! diff --git a/fs/btrfs/disk-io.c b/fs/btrfs/disk-io.c index bc423f7e..4e9ebe1 100644 --- a/fs/btrfs/disk-io.c +++ b/fs/btrfs/disk-io.c @@ -383,6 +383,11 @@ static int btrfs_check_super_csum(char *raw_disk_sb) if (memcmp(raw_disk_sb, result, csum_size)) ret = 1; + + if (ret && btrfs_super_generation(disk_sb) < 10) { + printk(KERN_WARNING "btrfs: super block crcs don't match, older mkfs detected\n"); + ret = 0; + } } if (csum_type >= ARRAY_SIZE(btrfs_csum_sizes)) {