@@ -106,15 +106,20 @@ struct ext3_ext_path {
((struct ext3_extent_idx *) (((char *) (__hdr__)) + \
sizeof(struct ext3_extent_header)))
#define EXT_HAS_FREE_INDEX(__path__) \
- ((__path__)->p_hdr->eh_entries < (__path__)->p_hdr->eh_max)
+ (ext2fs_le16_to_cpu((__path__)->p_hdr->eh_entries) < \
+ ext2fs_le16_to_cpu((__path__)->p_hdr->eh_max))
#define EXT_LAST_EXTENT(__hdr__) \
- (EXT_FIRST_EXTENT((__hdr__)) + (__hdr__)->eh_entries - 1)
+ (EXT_FIRST_EXTENT((__hdr__)) + \
+ ext2fs_le16_to_cpu((__hdr__)->eh_entries) - 1)
#define EXT_LAST_INDEX(__hdr__) \
- (EXT_FIRST_INDEX((__hdr__)) + (__hdr__)->eh_entries - 1)
+ (EXT_FIRST_INDEX((__hdr__)) + \
+ ext2fs_le16_to_cpu((__hdr__)->eh_entries) - 1)
#define EXT_MAX_EXTENT(__hdr__) \
- (EXT_FIRST_EXTENT((__hdr__)) + (__hdr__)->eh_max - 1)
+ (EXT_FIRST_EXTENT((__hdr__)) + \
+ ext2fs_le16_to_cpu((__hdr__)->eh_max) - 1)
#define EXT_MAX_INDEX(__hdr__) \
- (EXT_FIRST_INDEX((__hdr__)) + (__hdr__)->eh_max - 1)
+ (EXT_FIRST_INDEX((__hdr__)) + \
+ ext2fs_le16_to_cpu((__hdr__)->eh_max) - 1)
#endif /* _LINUX_EXT3_EXTENTS */
@@ -420,7 +420,7 @@ ext2fs_inline_data_file_expand(ext2_filsys fs, ext2_ino_t ino,
eh = (struct ext3_extent_header *) &inode->i_block[0];
eh->eh_depth = 0;
eh->eh_entries = 0;
- eh->eh_magic = EXT3_EXT_MAGIC;
+ eh->eh_magic = ext2fs_cpu_to_le16(EXT3_EXT_MAGIC);
i = (sizeof(inode->i_block) - sizeof(*eh)) /
sizeof(struct ext3_extent);
eh->eh_max = ext2fs_cpu_to_le16(i);
This turned up when trying to resize a filesystem containing a file with many extents on PPC64. Fix all locations where ext3_extent_header members aren't handled in an endian-safe manner. Signed-off-by: Eric Sandeen <sandeen@redhat.com> --- I only audited ext3_extent_header's members, and found places where they were not properly endian-handled. Is there a reason that disk structures aren't sparse-annotated for endianness? I can't help but wonder if there's a lot more than this lurking. -- 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