linux-ext4 - Re: [PATCH 15/15][e2fsprogs] 64-bit mke2fs cleanup

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-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20080716110242.7cffffa5@ichigo>
Date:	Wed, 16 Jul 2008 11:02:42 -0500
From:	"Jose R. Santos" <jrs@...ibm.com>
To:	Goswin von Brederlow <goswin-v-b@....de>
Cc:	Goswin von Brederlow <goswin-v-b@....de>,
	"Theodore Ts'o" <tytso@....edu>, linux-ext4@...r.kernel.org
Subject: Re: [PATCH 15/15][e2fsprogs] 64-bit mke2fs cleanup

On Wed, 16 Jul 2008 17:23:45 +0200
Goswin von Brederlow <goswin-v-b@....de> wrote:

> "Jose R. Santos" <jrs@...ibm.com> writes:
> 
> > On Wed, 16 Jul 2008 15:52:01 +0200
> > Goswin von Brederlow <goswin-v-b@....de> wrote:
> >> My test device is exactly 32 TiB large and gives the following:
> >> 
> >> root@...-13:~# LD_LIBRARY_PATH=/tmpa/ext4 /tmpa/ext4/mke2fs -T ext4dev
> >> -j -m0 /dev/mapper/ext4
> >> mke2fs 1.41.0 (10-Jul-2008)
> >> mke2fs: inode_size (256) * inodes_count (0) too big for a
> >>         filesystem with 0 blocks, specify higher inode_ratio (-i)
> >>         or lower inode count (-N).
> >
> > hehe, I put a FIXME-64 around this since I knew it was going to be a
> > problem.  I just wasn't sure what was the right approach for fixing.
> > You'll have to specify an inode count for now.
> >
> > The "filesystem with 0 blocks" surprise me though.  Looks like I missed
> > something somewhere.
> 
> /*
>  * Set the fs block count
>  */
> void ext2fs_blocks_count_set(struct ext2_super_block *super, blk64_t blk)
> {
>         super->s_blocks_count = blk;
>         if (super->s_feature_incompat & EXT4_FEATURE_INCOMPAT_64BIT)
>            super->s_blocks_count_hi = (__u64) blk >> 32;
> }
> 
> EXT4_FEATURE_INCOMPAT_64BIT is not set so the upper bits just get
> ignored.
> 
> MfG
>         Goswin
> 
> PS: Should functions that chop off upper bits like that make sure they
> are 0?

I think this is something that need to be cheched at fsck since having
these be non-zero on a non-64-bit FS should be pointing to file system
corruption.  Not sure if its something that need to be done every time
we set a value on the lower bit only though.

We could add error code here but that means that the users of the
routine need to handle the error code.  Determining now if we need to
return errcode_t here now would avoid the need to change the API later.

Ted.  Any comment on this one?

-JRS
--
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