[<prev] [next>] [day] [month] [year] [list]
Message-ID: <20070828202915.GY5377@schatzie.adilger.int>
Date: Tue, 28 Aug 2007 14:29:15 -0600
From: Andreas Dilger <adilger@...sterfs.com>
To: linux-ext4@...r.kernel.org
Subject: [RFC] split 32-bit and 64-bit words
There are now several places in the on-disk format that we are accessing
split 64-bit and 32-bit words with helper functions (e.g.
ext4_free_{blocks,inodes}_count()), but there is no easy way to ensure
that we are accessing them correctly.
There were several cases in the recently-ported uninit-groups patch that
were missing these checks, and there may be others already in the code.
I propose that we do something akin to the __le32 and __be32 types to
detect cases where these are improperly accessed.
Something like __ll32 and __lh32 for the low and high parts of the word
(similarly __ll16 and __lh16) that are cast to __le32 and __le16 respectively
in the helper function/macro before being passed to le32_to_cpu() and friends.
The alternative is to rename the "low" parts of the field explicitly, so any
incorrect code gets a compile error instead of silently working for any
filesystem < 16TB in size.
I can find the following split fields in ext4_fs.h:
__le16 l_i_file_acl_high;
__le16 l_i_uid_high; /* these 2 fields */
__le16 l_i_gid_high; /* were reserved2[0] */
#define i_size_high i_dir_acl
__le32 s_blocks_count_hi; /* Blocks count */
__le32 s_r_blocks_count_hi; /* Reserved blocks count */
__le32 s_free_blocks_count_hi; /* Free blocks count */
__le32 bg_block_bitmap_hi; /* Blocks bitmap block MSB */
__le32 bg_inode_bitmap_hi; /* Inodes bitmap block MSB */
__le32 bg_inode_table_hi; /* Inodes table block MSB */
We should just rename i_dir_acl to i_size_high permanently, and allow
directories to use i_size_high as is done for regular files.
Cheers, Andreas
--
Andreas Dilger
Principal Software Engineer
Cluster File Systems, 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
Powered by blists - more mailing lists