From patchwork Wed Jul 24 15:11:25 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Eric Sandeen X-Patchwork-Id: 261436 Return-Path: X-Original-To: patchwork-incoming@ozlabs.org Delivered-To: patchwork-incoming@ozlabs.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 21E9A2C0085 for ; Thu, 25 Jul 2013 01:11:33 +1000 (EST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752101Ab3GXPLc (ORCPT ); Wed, 24 Jul 2013 11:11:32 -0400 Received: from mx1.redhat.com ([209.132.183.28]:16590 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751645Ab3GXPLb (ORCPT ); Wed, 24 Jul 2013 11:11:31 -0400 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r6OFBQeT029543 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 24 Jul 2013 11:11:27 -0400 Received: from Liberator-563.local (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id r6OFBPPl024101 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 24 Jul 2013 11:11:26 -0400 Message-ID: <51EFEE9D.9070501@redhat.com> Date: Wed, 24 Jul 2013 10:11:25 -0500 From: Eric Sandeen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Robert Yang CC: "Darrick J. Wong" , linux-ext4@vger.kernel.org, "Theodore Ts'o" , Darren Hart Subject: [PATCH] debugfs: properly set up extent header in do_write References: <51EF975E.2090700@windriver.com> In-Reply-To: <51EF975E.2090700@windriver.com> X-Enigmail-Version: 1.5.1 X-Scanned-By: MIMEDefang 2.67 on 10.5.11.12 Sender: linux-ext4-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org do_write doesn't fully set up the first extent header on a new inode, so if we write a 0-length file, and don't write any data to the new file, we end up creating something that looks corrupt to kernelspace: EXT4-fs error (device loop0): ext4_ext_check_inode:464: inode #12: comm ls: bad header/extent: invalid magic - magic 0, entries 0, max 0(0), depth 0(0) Do something similar to ext4_ext_tree_init() here, and fill out the first extent header upon creation to avoid this. Reported-by: Robert Yang Signed-off-by: Eric Sandeen Tested-by: Robert Yang --- -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/debugfs/debugfs.c b/debugfs/debugfs.c index dcf16e2..2660218 100644 --- a/debugfs/debugfs.c +++ b/debugfs/debugfs.c @@ -1677,8 +1677,19 @@ void do_write(int argc, char *argv[]) inode.i_links_count = 1; inode.i_size = statbuf.st_size; if (current_fs->super->s_feature_incompat & - EXT3_FEATURE_INCOMPAT_EXTENTS) + EXT3_FEATURE_INCOMPAT_EXTENTS) { + int i; + struct ext3_extent_header *eh; + + eh = (struct ext3_extent_header *) &inode.i_block[0]; + eh->eh_depth = 0; + eh->eh_entries = 0; + eh->eh_magic = EXT3_EXT_MAGIC; + i = (sizeof(inode.i_block) - sizeof(*eh)) / + sizeof(struct ext3_extent); + eh->eh_max = ext2fs_cpu_to_le16(i); inode.i_flags |= EXT4_EXTENTS_FL; + } if (debugfs_write_new_inode(newfile, &inode, argv[0])) { close(fd); return;