linux-ext4 - Use of consistent types in e2fsprogs

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]

Date:	Mon, 16 May 2011 15:55:54 -0600
From:	Andreas Dilger <adilger.kernel@...ger.ca>
To:	Theodore Ts'o <tytso@....edu>
Cc:	Ext4 Developers List <linux-ext4@...r.kernel.org>,
	Lukas Czerner <lczerner@...hat.com>
Subject: Use of consistent types in e2fsprogs

While inspecting the qcow2 format code, I was checking whether it was going to correctly support 64-bit filesystems.  It looks like the qcow2 format itself supports 64-bit filesystems, which is good, but I also found inconsistent use of types within libext2fs for block numbers, file offsets, groups, inodes, etc.

There are uses of blk64_t, ext2_off64_t, long long, (unsigned) long, etc. in the libext2fs code.  The currently defined types are:

typedef __u32           blk_t;
typedef __u64           blk64_t;
typedef __u32           dgrp_t;
typedef __u32           ext2_off_t;
typedef __u64           ext2_off64_t;
typedef __s64           e2_blkcnt_t;

It would be nice to get some consistent naming for these types, like ext2_blk_t, ext2_blk64_t (or possibly ext2_fsblk_t to match the kernel), ext2_group_t, and ext2_blkcnt_t (this appears to be negative in some places, so isn't easily replaced with ext2_blk64_t.

For example, io_channel_read_blk64() uses "long long", while both ext2fs_{read,write}_inode_full() _incorrectly_ use "unsigned long".  I guess this wasn't noticed because > 16TB isn't directly usable on 32-bit Linux due to the block device limits, but it doesn't seem right to leave it as-is.

I understand it would be a lot of code churn, but I think it would be valuable to fix up the types used in e2fsprogs in order to clarify usage and remove errors, just like we did with the kernel code.  Is there any interest in accepting patches like this upstream?  Both ext2fs_{read,write}_inode_full() need to be fixed, and I expect even more places will need fixing.

Cheers, Andreas

Cheers, Andreas

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