From patchwork Tue May 13 21:04:41 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Filipe Manana X-Patchwork-Id: 4170411 Return-Path: X-Original-To: patchwork-linux-btrfs@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.19.201]) by patchwork1.web.kernel.org (Postfix) with ESMTP id E16569F1C0 for ; Tue, 13 May 2014 20:05:10 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id BEC1720266 for ; Tue, 13 May 2014 20:05:09 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 88C0C2024D for ; Tue, 13 May 2014 20:05:08 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753185AbaEMUFF (ORCPT ); Tue, 13 May 2014 16:05:05 -0400 Received: from mail-wi0-f174.google.com ([209.85.212.174]:55026 "EHLO mail-wi0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752371AbaEMUFE (ORCPT ); Tue, 13 May 2014 16:05:04 -0400 Received: by mail-wi0-f174.google.com with SMTP id r20so6899468wiv.7 for ; Tue, 13 May 2014 13:05:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:date:message-id; bh=VdfB3OCE3LaSnlbjhX4AmgI38V1FRcq94FeJJ0nGpGo=; b=jQqifnkhYJmSP5PRaIJ66Wcx30ZGSAP1u73GNPZwCKDN1slqakhnu3Rb1++Vt7D1X1 +HX44kA0ZUaa9Alk1+hkxfMdfGCbZ4kJ3vD2+8lBP0xGBVhVGrD6ymN85ArtfNnrOmFI eE13OGwFEliWkLOuJak2TxV3U+QdJy7fIYZnD7gdiIIzg5n9rBFkjFepJyq/ttZgfBCv KKaamYfJJKG/2vvZfwtruEV2P1OiEb8vAI4ys+ntvT9+lQncA36Qu5pFJX3v/KmrouCs 21C4BALe853cGjFJSCvvZYnLJ38o071EK+1Hi8HcC3Zicw/4UKyz/XTUEi5ku7JJ6ayu ae9Q== X-Received: by 10.180.99.40 with SMTP id en8mr7614wib.24.1400011502215; Tue, 13 May 2014 13:05:02 -0700 (PDT) Received: from debian-vm3.lan (bl14-139-83.dsl.telepac.pt. [85.247.139.83]) by mx.google.com with ESMTPSA id nb8sm23620716wic.18.2014.05.13.13.05.00 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 13 May 2014 13:05:01 -0700 (PDT) From: Filipe David Borba Manana To: xfs@oss.sgi.com Cc: linux-btrfs@vger.kernel.org, Filipe David Borba Manana , Josef Bacik Subject: [PATCH] xfstests: btrfs, add regression test for send with extrefs Date: Tue, 13 May 2014 22:04:41 +0100 Message-Id: <1400015081-2192-1-git-send-email-fdmanana@gmail.com> X-Mailer: git-send-email 1.9.1 Sender: linux-btrfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-btrfs@vger.kernel.org X-Spam-Status: No, score=-7.4 required=5.0 tests=BAYES_00, DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED, FREEMAIL_FROM, RCVD_IN_DNSWL_HI, RP_MATCHES_RCVD, 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 Regression for btrfs send when an inode only has extended references associated to it (no regular references present). This used to cause incorrect access to a b+tree leaf, where an extended reference item was accessed as if it were a regular reference item, causing unexpected and unpredictable behaviour such as producing a random/weird path string or a crash. This issue is fixed by the following linux kernel btrfs patch: Btrfs: send, fix incorrect ref access when using extrefs Cc: Josef Bacik Signed-off-by: Filipe David Borba Manana --- tests/btrfs/050 | 109 ++++++++++++++++++++++++++++++++++++++++++++++++++++ tests/btrfs/050.out | 1 + tests/btrfs/group | 1 + 3 files changed, 111 insertions(+) create mode 100755 tests/btrfs/050 create mode 100644 tests/btrfs/050.out diff --git a/tests/btrfs/050 b/tests/btrfs/050 new file mode 100755 index 0000000..6e4bd13 --- /dev/null +++ b/tests/btrfs/050 @@ -0,0 +1,109 @@ +#! /bin/bash +# FS QA Test No. btrfs/050 +# +# Regression for btrfs send when an inode only has extended references +# associated to it (no regular references present). This used to cause +# incorrect access to a b+tree leaf, where an extended reference item +# was accessed as if it were a regular reference item, causing unexpected +# and unpredictable behaviour such as producing a random/weird path string +# or a crash. +# +# This issue is fixed by the following linux kernel btrfs patch: +# +# Btrfs: send, fix incorrect ref access when using extrefs +# +#----------------------------------------------------------------------- +# Copyright (c) 2014 Filipe Manana. All Rights Reserved. +# +# This program is free software; you can redistribute it and/or +# modify it under the terms of the GNU General Public License as +# published by the Free Software Foundation. +# +# This program is distributed in the hope that it would be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program; if not, write the Free Software Foundation, +# Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA +#----------------------------------------------------------------------- +# + +seq=`basename $0` +seqres=$RESULT_DIR/$seq +echo "QA output created by $seq" + +tmp=/tmp/$$ +status=1 # failure is the default! +trap "_cleanup; exit \$status" 0 1 2 3 15 + +_cleanup() +{ + rm -fr $send_files_dir + rm -fr $tmp +} + +# get standard environment, filters and checks +. ./common/rc +. ./common/filter + +# real QA test starts here +_supported_fs btrfs +_supported_os Linux +_require_scratch +_require_fssum +_need_to_be_root + +send_files_dir=$TEST_DIR/btrfs-test-$seq + +rm -f $seqres.full +rm -fr $send_files_dir +mkdir $send_files_dir + +_scratch_mkfs "-O extref" >/dev/null 2>&1 +_scratch_mount + +# 2550 hard links is enough to cause creation of extended references +# even if the leaf/node size is 64Kb (largest possible). +NUM_LINKS=2550 +TEST_PATH=$SCRATCH_MNT/home/john/files/series/qwerty + +mkdir -p $TEST_PATH +touch $TEST_PATH/foobar + +# Create a bunch of hard links for the file, such that at least one +# inode extended reference item is created. +for i in `seq 1 $NUM_LINKS`; do + ln $TEST_PATH/foobar $TEST_PATH/foobar_link_`printf "%04d" $i` +done + +# The only link we'll have alive at the end. +ln $TEST_PATH/foobar $TEST_PATH/final_foobar_name + +# Now delete all previous hard links (except the last one). This will +# remove the regular inode reference item from the b+tree, and will +# leave only an inode extended reference item, which is the condition +# necessary to trigger the bug. +rm -f $TEST_PATH/foobar +for i in `seq 1 $NUM_LINKS`; do + rm -f $TEST_PATH/foobar_link_`printf "%04d" $i` +done + +_run_btrfs_util_prog subvolume snapshot -r $SCRATCH_MNT $SCRATCH_MNT/mysnap1 +run_check $FSSUM_PROG -A -f -w $send_files_dir/1.fssum $SCRATCH_MNT/mysnap1 +_run_btrfs_util_prog send $SCRATCH_MNT/mysnap1 -f $send_files_dir/1.snap + +_scratch_unmount +_check_scratch_fs + +_scratch_mkfs >/dev/null 2>&1 +_scratch_mount + +_run_btrfs_util_prog receive $SCRATCH_MNT -f $send_files_dir/1.snap +run_check $FSSUM_PROG -r $send_files_dir/1.fssum $SCRATCH_MNT/mysnap1 + +_check_scratch_fs + +status=0 +exit diff --git a/tests/btrfs/050.out b/tests/btrfs/050.out new file mode 100644 index 0000000..37f2cbc --- /dev/null +++ b/tests/btrfs/050.out @@ -0,0 +1 @@ +QA output created by 050 diff --git a/tests/btrfs/group b/tests/btrfs/group index 59b0c98..69a80e0 100644 --- a/tests/btrfs/group +++ b/tests/btrfs/group @@ -52,3 +52,4 @@ 047 auto quick 048 auto quick 049 auto quick +050 auto