linux-ext4 - ext4_ext_calc_credits_for_single

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-id: <20090629224133.GF19362@webber.adilger.int>
Date:	Tue, 30 Jun 2009 00:41:33 +0200
From:	Andreas Dilger <adilger@....com>
To:	Aneesh Kumar <aneesh.kumar@...ux.vnet.ibm.com>,
	Mingming Cao <cmm@...ibm.com>
Cc:	linux-ext4@...r.kernel.org
Subject: ext4_ext_calc_credits_for_single_extent() bug?

I was looking at the function ext4_ext_calc_credits_for_insert(), because
it appeared similar to a function we were using in Lustre and I wanted to
remove redundant code from our patches.  On closer inspection, however,
that function is doing something strange that wasn't in our original code.

int ext4_ext_calc_credits_for_single_extent(struct inode *inode, int nrblocks,
                                                struct ext4_ext_path *path)
{
        if (path) {
                int depth = ext_depth(inode);
                int ret = 0;

                /* probably there is space in leaf? */
                if (le16_to_cpu(path[depth].p_hdr->eh_entries)
                                < le16_to_cpu(path[depth].p_hdr->eh_max)) {

                        /*
                         *  There are some space in the leaf tree, no
                         *  need to account for leaf block credit
                         *
                         *  bitmaps and block group descriptor blocks
                         *  and other metadat blocks still need to be
                         *  accounted.
                         */
                        /* 1 bitmap, 1 block group descriptor */
                        ret = 2 + EXT4_META_TRANS_BLOCKS(inode->i_sb);
                }
        }

        return ext4_chunk_trans_blocks(inode, nrblocks);
}

It computes "ret" but doesn't actually use it, and then
ext4_chunk_trans_blocks() does nothing but call ext4_meta_trans_blocks(),
which is doing the bulk of the calculation.

It looks like this was committed by Mingming in "ext4: journal credits
reservation fixes for extent file writepage"
ee12b630687d510f6f4b6d4acdc4e267fd4adeda

Ideally we would use the "path" information to generate an accurate block
count for this extent.  Can we just return "ret" in this case?

Cheers, Andreas
--
Andreas Dilger
Sr. Staff Engineer, Lustre Group
Sun Microsystems of Canada, Inc.

--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html