From patchwork Thu Aug 11 21:13:41 2011 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Darrick J. Wong" X-Patchwork-Id: 109686 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 A5C33B6F7F for ; Fri, 12 Aug 2011 07:15:02 +1000 (EST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753935Ab1HKVPA (ORCPT ); Thu, 11 Aug 2011 17:15:00 -0400 Received: from e9.ny.us.ibm.com ([32.97.182.139]:56822 "EHLO e9.ny.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753840Ab1HKVO7 (ORCPT ); Thu, 11 Aug 2011 17:14:59 -0400 Received: from d01relay06.pok.ibm.com (d01relay06.pok.ibm.com [9.56.227.116]) by e9.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id p7BKfi19029661; Thu, 11 Aug 2011 16:41:44 -0400 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay06.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p7BLDg3m3227680; Thu, 11 Aug 2011 17:13:42 -0400 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p7BLDfYH021623; Thu, 11 Aug 2011 17:13:41 -0400 Received: from tux1.beaverton.ibm.com ([9.47.67.50]) by d01av01.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p7BLDfAk021615; Thu, 11 Aug 2011 17:13:41 -0400 Received: by tux1.beaverton.ibm.com (Postfix, from userid 501) id 6A1C413E7B5; Thu, 11 Aug 2011 14:13:41 -0700 (PDT) Date: Thu, 11 Aug 2011 14:13:41 -0700 From: "Darrick J. Wong" To: "Theodore Ts'o" Cc: linux-kernel , linux-ext4 Subject: [PATCH] ext4: Always verify extent tree blocks Message-ID: <20110811211348.GK20655@tux1.beaverton.ibm.com> Reply-To: djwong@us.ibm.com MIME-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.5.17+20080114 (2008-01-14) Sender: linux-ext4-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org It turns out that ext4_ext_check only verifies the validity of the extent block it's processing if the block has to be read in from the disk. Unfortunately, this means that the check is NOT done if the block is already in memory, which means that if a file has a corrupted extent block, then the first IO peformed on the file will find the corrupt block and fail, but a second IO will see that the extent block is in memory, bypass the corruption check, and use garbage data as if they were extent data. A simple testcase is to allocate a file with enough extents to overflow the inode i_block, umount, overwrite the extent block magic with garbage, then mount the filesystem and try to access the file. The first access causes the kernel to spit out an error, but subsequent accesses seem to succeed. Signed-off-by: Darrick J. Wong --- fs/ext4/extents.c | 6 +----- 1 files changed, 1 insertions(+), 5 deletions(-) -- 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/fs/ext4/extents.c b/fs/ext4/extents.c index ee4b391..bb07b79 100644 --- a/fs/ext4/extents.c +++ b/fs/ext4/extents.c @@ -744,8 +744,6 @@ ext4_ext_find_extent(struct inode *inode, ext4_lblk_t block, i = depth; /* walk through the tree */ while (i) { - int need_to_validate = 0; - ext_debug("depth %d: num %d, max %d\n", ppos, le16_to_cpu(eh->eh_entries), le16_to_cpu(eh->eh_max)); @@ -764,8 +762,6 @@ ext4_ext_find_extent(struct inode *inode, ext4_lblk_t block, put_bh(bh); goto err; } - /* validate the extent entries */ - need_to_validate = 1; } eh = ext_block_hdr(bh); ppos++; @@ -779,7 +775,7 @@ ext4_ext_find_extent(struct inode *inode, ext4_lblk_t block, path[ppos].p_hdr = eh; i--; - if (need_to_validate && ext4_ext_check(inode, eh, i)) + if (ext4_ext_check(inode, eh, i)) goto err; }