From patchwork Wed Jun 17 20:11:21 2009 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: number9652 X-Patchwork-Id: 28808 Return-Path: X-Original-To: patchwork-incoming@bilbo.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from ozlabs.org (ozlabs.org [203.10.76.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mx.ozlabs.org", Issuer "CA Cert Signing Authority" (verified OK)) by bilbo.ozlabs.org (Postfix) with ESMTPS id 2B92FB7230 for ; Thu, 18 Jun 2009 06:11:26 +1000 (EST) Received: by ozlabs.org (Postfix) id 18979DDDB6; Thu, 18 Jun 2009 06:11:26 +1000 (EST) Delivered-To: patchwork-incoming@ozlabs.org Received: from vger.kernel.org (vger.kernel.org [209.132.176.167]) by ozlabs.org (Postfix) with ESMTP id AA1BBDDDB2 for ; Thu, 18 Jun 2009 06:11:25 +1000 (EST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754461AbZFQULU (ORCPT ); Wed, 17 Jun 2009 16:11:20 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1755414AbZFQULU (ORCPT ); Wed, 17 Jun 2009 16:11:20 -0400 Received: from n69.bullet.mail.sp1.yahoo.com ([98.136.44.41]:38269 "HELO n69.bullet.mail.sp1.yahoo.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1754461AbZFQULU (ORCPT ); Wed, 17 Jun 2009 16:11:20 -0400 Received: from [69.147.84.145] by n69.bullet.mail.sp1.yahoo.com with NNFMP; 17 Jun 2009 20:11:22 -0000 Received: from [69.147.65.154] by t8.bullet.mail.sp1.yahoo.com with NNFMP; 17 Jun 2009 20:11:22 -0000 Received: from [127.0.0.1] by omp402.mail.sp1.yahoo.com with NNFMP; 17 Jun 2009 20:11:22 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 732038.5984.bm@omp402.mail.sp1.yahoo.com Received: (qmail 86231 invoked by uid 60001); 17 Jun 2009 20:11:22 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1245269482; bh=Je8mqljwYZZ3DCBJsGyeuEDQkfECK6EAlW3bR3FwP+s=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type; b=bu9xE34OwqkwytwE1mbV/MDpxcnoAbgsij178gi3P8SNT+CyffXHd5PastXf+FWVs5/ewEpY/JzCT8/+QuQpP4fIxF9wLRnxy+o1WAvHjCXdMdmXIfObyQYH0xgheDvGVx5R9NlKqu3D9uc+25U53AWLiLMtNW62UJ3F5Cq4wZ8= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type; b=XYAO0KwzrY4zfDTCVD/Z5gUQFuY60EQVpNv8VswuoGCHtvWDkJe8MRhTObNSWiYNQrHKiej5YajzB3w7XvlO5fWWB1gkwvRLkf8YDPsuasIMbkgPIlfiacNYsqUeRx2seCfY3rNlK+Ti+X2LLGbGmd511sCzNZ3x2xNtivP6x40=; Message-ID: <494208.86194.qm@web43505.mail.sp1.yahoo.com> X-YMail-OSG: 2agITKYVM1ngus2gzEKtexfE85eGLFngneUrOOuqRh1TYaEi9jyzIR4zIumskMLA9mt8IW97wwDWFlw67DTBy4U0PIURN_AuWGyrKPctprJNkt9lS1UxFZK09HPWLtKI9UB5iigjQlppdogKEGvmRm1cJ6Pr9YK44VNhuyn5w9cIqJEf5ydiDqBhcWgn8fPHmJKwrRrUFz8bF3eNOXAjGpOL_sh8bRco8p1kK7r7WvhfTJLSmaczLxRTy5RT87l.yAN.oOa9pBh8p_WbiA-- Received: from [173.9.226.29] by web43505.mail.sp1.yahoo.com via HTTP; Wed, 17 Jun 2009 13:11:21 PDT X-Mailer: YahooMailClassic/5.4.12 YahooMailWebService/0.7.289.15 Date: Wed, 17 Jun 2009 13:11:21 -0700 (PDT) From: number9652 Subject: Re: [PATCH] libext2fs: write only core inode in update_path() To: Theodore Tso , Eric Sandeen Cc: ext4 development MIME-Version: 1.0 Sender: linux-ext4-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org --- On Wed, 6/17/09, Eric Sandeen wrote: > Theodore Tso wrote: > > Probably it would be better/simpler to replace this > with: > > > > retval = > ext2fs_write_inode(handle->fs, handle->ino, > handle->inode); > - Ted > > > Sure, that makes more sense, revised below: > > libext2fs: write only core inode in update_path() > > The ext2_extent_handle only has a struct ext2_inode > allocated on > it, and the same amount copied into it in that same > function, First, sorry for the original bug. I don't think the above is the right way to fix it, however. I am concerned that I may have basically broken write_inode_full on any inode with extents. For example, there is another call to write_inode_full in extent.c that might exhibit this same problem. I think the right fix would be to return to reading the full inode into memory in the extent_open function. See the patch below for what I am talking about. libext2fs: read the full inode in extent_open2 The inode pointed to in the extent handle structure is expected to have the same size as the on-disk inode so the entire inode can be updated and written to disk, but in extent_open2, only 128 bytes was read into the inode, regardless of the on-disk inode size. Instead, read the entire inode. Signed-off-by: Nic Case --- --- -- 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/e2fsprogs-1.41.6-orig/lib/ext2fs/extent.c b/e2fsprogs-1.41.6/lib/ext2fs/extent.c index b7eb617..aebb9bc 100644 --- a/e2fsprogs-1.41.6-orig/lib/ext2fs/extent.c +++ b/e2fsprogs-1.41.6/lib/ext2fs/extent.c @@ -189,6 +189,7 @@ extern errcode_t ext2fs_extent_open2(ext2_filsys fs, ext2_ino_t ino, { struct ext2_extent_handle *handle; errcode_t retval; + int isize = EXT2_INODE_SIZE(fs->super); int i; struct ext3_extent_header *eh; @@ -203,7 +204,7 @@ extern errcode_t ext2fs_extent_open2(ext2_filsys fs, ext2_ino_t ino, return retval; memset(handle, 0, sizeof(struct ext2_extent_handle)); - retval = ext2fs_get_mem(sizeof(struct ext2_inode), &handle->inode); + retval = ext2fs_get_mem(isize, &handle->inode); if (retval) goto errout; @@ -211,10 +212,10 @@ extern errcode_t ext2fs_extent_open2(ext2_filsys fs, ext2_ino_t ino, handle->fs = fs; if (inode) { - memcpy(handle->inode, inode, sizeof(struct ext2_inode)); + memcpy(handle->inode, inode, isize); } else { - retval = ext2fs_read_inode(fs, ino, handle->inode); + retval = ext2fs_read_inode_full(fs, ino, handle->inode, isize); if (retval) goto errout; }