From patchwork Mon Dec 2 20:47:36 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Kit Westneat X-Patchwork-Id: 296009 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 2DEF52C009A for ; Tue, 3 Dec 2013 07:47:45 +1100 (EST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758481Ab3LBUrm (ORCPT ); Mon, 2 Dec 2013 15:47:42 -0500 Received: from legacy.ddn.com ([64.47.133.206]:34478 "EHLO legacy.ddn.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756979Ab3LBUrk (ORCPT ); Mon, 2 Dec 2013 15:47:40 -0500 Received: from [172.16.0.165] (66.234.239.197) by mail.datadirectnet.com (10.8.16.38) with Microsoft SMTP Server (TLS) id 8.3.297.1; Mon, 2 Dec 2013 12:47:37 -0800 Message-ID: <529CF1E8.3010003@ddn.com> Date: Mon, 2 Dec 2013 15:47:36 -0500 From: Kit Westneat User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Theodore Ts'o CC: "linux-ext4@vger.kernel.org" , "Dilger, Andreas" Subject: [PATCH] e2fsck: blk64_t to blk_t truncation References: <529CF0D2.2010707@ddn.com> In-Reply-To: <529CF0D2.2010707@ddn.com> Sender: linux-ext4-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org Hello, We recently ran into an issue where e2fsck was claiming to clear deleted/unused inodes, but was not actually doing it. We tracked it down to a bad blk64_t to blk_t conversion in pass2 where ext2fs_write_dir_block is being called instead of ext2fs_write_dir_block3. There is another similar call in allocate_dir_block. These appear to be fixed in master as part of the move to adding checksums to the end of directory leaf nodes, but it's still an issue on maint. I ran gcc with -Wconversion and found a number of other places that have blk64_t to blk_t truncations, but I'm not sure how many of them are actually problems. For example in block_iterate_ind, block_nr is blk_t but it seems to be a specific choice, since there is also the blk64 variable. Another instance is with the EA refcounting, which is all 32-bit. In expand_dir_proc in pass3.c, it uses the 32-bit ext2fs_write_dir_block. Against 1.42.7, gcc reports 103 blk64_t to blk_t conversions, so this is just a small sample. I'm sure most of these are not problems, but I thought I'd raise the issue since we did run into problems with deleted/unused inodes. Signed-off-by: Kit Westneat Reviewed-by: Darrick J. Wong --- Kit Westneat L3 Lustre Support, DDN -- 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/e2fsck/pass2.c b/e2fsck/pass2.c index 78740c0..e8d0b47 100644 --- a/e2fsck/pass2.c +++ b/e2fsck/pass2.c @@ -1216,7 +1216,7 @@ out_htree: } } if (dir_modified) { - cd->pctx.errcode = ext2fs_write_dir_block(fs, block_nr, buf); + cd->pctx.errcode = ext2fs_write_dir_block3(fs, block_nr, buf, 0); if (cd->pctx.errcode) { if (!fix_problem(ctx, PR_2_WRITE_DIRBLOCK, &cd->pctx)) @@ -1595,7 +1595,7 @@ static int allocate_dir_block(e2fsck_t ctx, return 1; } - pctx->errcode = ext2fs_write_dir_block(fs, blk, block); + pctx->errcode = ext2fs_write_dir_block3(fs, blk, block, 0); ext2fs_free_mem(&block); if (pctx->errcode) { pctx->str = "ext2fs_write_dir_block";