[U-Boot] genext2fs fix for supporting filesystems generated by genext2fs

[U-Boot] genext2fs fix for supporting filesystems generated by genext2fs

[FrostyBytes]

I found that the latest U-Boot cannot handle filesystems generated by genext2fs. Attempts to list such a filesystem results in divide by zero.

Using git bisect with a test script, I got:

f798b1dda1c5de818b806189e523d1b75db7e72d is the first bad commit

That commit changes to using fs->gdsize rather than a calculated descriptor size.

The problem is that ext4fs_mount does not set fs->gdsize when revision_level is zero.

The simplest fix seemed to be to plug in the old calculation into the case when revision_level is zero, which made the problem go away. I know next to nothing about the internals ext2/3/4, so this may not be the right thing to do. I'm attaching a patch anyways:

The patch is also available at the following URL if the mailer has mangled it: https://ptpb.pw/KcQI

diff --git a/fs/ext4/ext4_common.c b/fs/ext4/ext4_common.c
index bfebe7e..fa83586 100644
--- a/fs/ext4/ext4_common.c
+++ b/fs/ext4/ext4_common.c
@@ -2334,6 +2334,7 @@ int ext4fs_mount(unsigned part_length)

if (le32_to_cpu(data->sblock.revision_level) == 0) {
fs->inodesz = 128;
+ fs->gdsize = EXT2_BLOCK_SIZE(data) / sizeof(struct ext2_block_group);
} else {
debug("EXT4 features COMPAT: %08x INCOMPAT: %08x RO_COMPAT: %08x\n",
__le32_to_cpu(data->sblock.feature_compatibility),


Sent with [ProtonMail](https://protonmail.com) Secure Email.

[U-Boot] genext2fs fix for supporting filesystems generated by genext2fs

[Tom Rini]

On Sun, Dec 11, 2016 at 07:25:21PM -0500, FrostyBytes wrote:

> I found that the latest U-Boot cannot handle filesystems generated by genext2fs. Attempts to list such a filesystem results in divide by zero.
> 
> Using git bisect with a test script, I got:
> 
> f798b1dda1c5de818b806189e523d1b75db7e72d is the first bad commit
> 
> That commit changes to using fs->gdsize rather than a calculated descriptor size.
> 
> The problem is that ext4fs_mount does not set fs->gdsize when revision_level is zero.
> 
> The simplest fix seemed to be to plug in the old calculation into the case when revision_level is zero, which made the problem go away. I know next to nothing about the internals ext2/3/4, so this may not be the right thing to do. I'm attaching a patch anyways:
> 
> The patch is also available at the following URL if the mailer has mangled it: https://ptpb.pw/KcQI
> 
> diff --git a/fs/ext4/ext4_common.c b/fs/ext4/ext4_common.c
> index bfebe7e..fa83586 100644
> --- a/fs/ext4/ext4_common.c
> +++ b/fs/ext4/ext4_common.c
> @@ -2334,6 +2334,7 @@ int ext4fs_mount(unsigned part_length)
> 
> if (le32_to_cpu(data->sblock.revision_level) == 0) {
> fs->inodesz = 128;
> + fs->gdsize = EXT2_BLOCK_SIZE(data) / sizeof(struct ext2_block_group);
> } else {
> debug("EXT4 features COMPAT: %08x INCOMPAT: %08x RO_COMPAT: %08x\n",
> __le32_to_cpu(data->sblock.feature_compatibility),

Thanks for looking into this and providing the fix as well.  Can you
please reply back with a Signed-off-by and your real name?  Thanks!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20161212/c9ff6d2a/attachment.sig>

[U-Boot] genext2fs fix for supporting filesystems generated by genext2fs

[stefan.bruens at rwth-aachen.de]

On Sonntag, 11. Dezember 2016 19:25:21 CET FrostyBytes wrote:
> I found that the latest U-Boot cannot handle filesystems generated by
> genext2fs. Attempts to list such a filesystem results in divide by zero.
> 
> Using git bisect with a test script, I got:
> 
> f798b1dda1c5de818b806189e523d1b75db7e72d is the first bad commit
> 
> That commit changes to using fs->gdsize rather than a calculated descriptor
> size.
> 
> The problem is that ext4fs_mount does not set fs->gdsize when revision_level
> is zero.
> 
> The simplest fix seemed to be to plug in the old calculation into the case
> when revision_level is zero, which made the problem go away. I know next to
> nothing about the internals ext2/3/4, so this may not be the right thing to
> do. I'm attaching a patch anyways:
> 
> The patch is also available at the following URL if the mailer has mangled
> it: https://ptpb.pw/KcQI
> 
> diff --git a/fs/ext4/ext4_common.c b/fs/ext4/ext4_common.c
> index bfebe7e..fa83586 100644
> --- a/fs/ext4/ext4_common.c
> +++ b/fs/ext4/ext4_common.c
> @@ -2334,6 +2334,7 @@ int ext4fs_mount(unsigned part_length)
> 
> if (le32_to_cpu(data->sblock.revision_level) == 0) {
> fs->inodesz = 128;
> + fs->gdsize = EXT2_BLOCK_SIZE(data) / sizeof(struct ext2_block_group);
> } else {
> debug("EXT4 features COMPAT: %08x INCOMPAT: %08x RO_COMPAT: %08x\n",
> __le32_to_cpu(data->sblock.feature_compatibility),

Although you are correct in that the initialization is missing here, your 
patch is wrong, and may even corrupt the filesystem.

Just make it fs->gdsize = 32;

Kind regards,

Stefan