linux-ext4 - Re: [PATCH] ext4: fix FS_IOC

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20241028035922.GC3842351@mit.edu>
Date: Sun, 27 Oct 2024 20:59:22 -0700
From: "Theodore Ts'o" <tytso@....edu>
To: Zhang Yi <yi.zhang@...wei.com>
Cc: "Darrick J. Wong" <djwong@...nel.org>,
        Ext4 Developers List <linux-ext4@...r.kernel.org>
Subject: Re: [PATCH] ext4: fix FS_IOC_GETFSMAP handling

On Mon, Oct 28, 2024 at 09:47:46AM +0800, Zhang Yi wrote:
> 
> IIRC, at the moment, fixed metadata does not appear in the middle of
> the block group.

The mke2fs from e2fsprogs will not create a file system like that
normally, no.  *However* it is possible for fixed metadata to be in
the middle of the block group:

   * If resize2fs does an off-line file system growth without a resize inode
     or the reserved blocks in the resize inode has been exhausted
   * If e2fsck needs to reallocate some fixed metadata blocks as part of
     repairing a (very badly) corrupted file system.
   * If there are blocks reported to mke2fs when the file system is created
   * If a non-standard mkfs.ext4 is used by some other operating system which
     reimplemented mke2fs for some reason (for example, because they wanted
     to avoid using GPL'ed code).

So while these cases are quite uncommon, they *can* happen in the
wild, and we want GETFSMAP to be able to handle these file systems
correctly.

Cheers,

					- Ted