Sigh, it would have been nice to catch this when ext4_new_group_input was first created.
I don't mind fixing the kernel, since this is clearly broken. However, we may as well go ahead and declare a new struct ext4_new_group_input that has the right alignment, rename and deprecate the old one (have resize2fs prefer the new one if available) and take the old one out in a few years. I hate this business of keeping around old cruft like this forever.
struct compat_ext4_new_group_input {
u32 group;
u64 block_bitmap;
u64 inode_bitmap;
u64 inode_table;
u32 blocks_count;
u16 reserved_blocks;
u16 unused;
};
struct ext4_new_group_input {
u64 group;
u64 block_bitmap;
u64 inode_bitmap;
u64 inode_table;
u64 blocks_count;
u32 reserved_blocks;
u32 unused;
};
#define EXT2_IOC_GROUP_ADD _IOW('f', 8,struct ext2_new_group_input)
#define EXT4_IOC_GROUP_ADD_OLD _IOW('f', 8,struct compat_ext4_new_group_input)
#define EXT4_IOC_GROUP_ADD _IOW('f', 8,struct ext4_new_group_input)
The resize/online.c code already has compat support for both 32-bit and 64-bit IOC numbers, so it isn't much effort to have it try a third variant for a couple of years.
Cheers, Andreas
--
Andreas Dilger
Lustre Technical Lead
Oracle Corporation Canada Inc.
--
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