linux-ext4 - Re: [PATCH] e2fsprogs: fix to use inode i

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-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 30 Dec 2019 11:37:40 -0700
From:   Andreas Dilger <adilger@...ger.ca>
To:     "Theodore Y. Ts'o" <tytso@....edu>
Cc:     Wang Shilong <wangshilong1991@...il.com>,
        Ext4 Developers List <linux-ext4@...r.kernel.org>,
        lixi@....com, dongyangli@....com, Wang Shilong <wshilong@....com>
Subject: Re: [PATCH] e2fsprogs: fix to use inode i_blocks correctly

On Dec 30, 2019, at 8:19 AM, Theodore Y. Ts'o <tytso@....edu> wrote:
> 
> On Mon, Dec 30, 2019 at 08:36:06PM +0900, Wang Shilong wrote:
>> blocks_from_inode() did not return wrong inode blocks, and
>> ext2fs_inode_i_blocks() is not taking EXT4_HUGE_FILE_FL into account
>> at all, while the some callers deal it correctly, some not. This patch
>> try to unify to handle it in ext2fs_inode_i_blocks() to return.
>> blocks(based on 512 bytes)
> 
> I don't really want to change the functionality of
> ext2fs_inode_i_blocks().  First of all, it's in a shared library, so
> if there are any binaries which were expecting the old behavior, that
> could get surprising.  Secondly, its name is confusing and so we're
> better off creating a new function ext2fs_get_stat_i_blocks() which
> makes it clear that we function is using units of 512 byte sectors,
> instead of either the file system block size, or the raw i_blocks
> value from the inode.
> 
> Two other things about your patch.  First of all, the filefrag command
> in debugfs was intended to print the number of file system blocks, so
> it was correct as written.  Secondly, please note the blkcnt_t is a
> signed type (because the block iterator functions use negative values
> to indicate various kinds of metadata blocks), while blk64_t is an
> unsigned type.  So using blkcnt_t as a temporary value and returning
> it in a function which has a return type of blk64_t will (righly)
> trigger compiler warnings.
> 
> Here's the patch I've checked into the maint branch of e2fsprogs to
> address the issue you've identified.

No patch is attached?

Cheers, Andreas






Download attachment "signature.asc" of type "application/pgp-signature" (874 bytes)