linux-ext4 - Re: [v4 1/6] Always read full inode structure

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:	Sat, 5 Mar 2016 23:27:25 -0700
From:	Andreas Dilger <adilger@...ger.ca>
To:	Theodore Ts'o <tytso@....edu>
Cc:	Li Xi <pkuelelixi@...il.com>, linux-ext4@...r.kernel.org
Subject: Re: [v4 1/6] Always read full inode structure

> On Mar 5, 2016, at 10:46 PM, Theodore Ts'o <tytso@....edu> wrote:
> 
> On Sun, Mar 06, 2016 at 01:14:51PM +0900, Li Xi wrote:
>> Project quota need use some extra field of inode for computing quota
>> accounting, this patch tries to use ext2fs_get_next_inode_full()
>> everywhere to read full inode into memeory.
>> 
>> It also fixes a bug that only copy small inode in the function.
>> 
>> Signed-off-by: Wang Shilong <wshilong@....com>
> 
> Um, no.  Most of the places where we are currently using
> ext2fs_get_next_inode() is because they **don't** need the full inode.
> For example, consider debugfs's icheck command.  Why would it need the
> project quota id?  Answer: it doesn't.
> 
> If you think there is a bug, or some place where we should be using
> the large inode, fine.  Let's take a look at it.  But doing a whole
> sale conversion of ext2fs_get_next_inode() to
> ext2fs_get_next_inode_full() makes e2fsprogs much less efficient, and
> for no good purpose.

Do you think it really makes e2fsprogs less efficient?  The disk IO has
already happened, and definitely included the whole inode even if only
the small inode data was requested.  The ext2fs block cache will still
cache the whole inode block, so fetching the whole inode is no overhead.

In contrast, several places in the code are doing extra work to fetch
the large inode data after having fetched the small inode data.  It is
also fairly confusing in different parts of the code which "know" that
the inode pointer is pointing to a full inode buffer, so it is a lot
cleaner if we just always read the full inode data everywhere.

Even better would be if the API explicitly just passed ext4_inode_large
everywhere, which wouldn't break the ABI, but it might cause problems
for anything that encodes the argument types (e.g. C++).  At least if
the e2fsprogs internal functions are reading the full inode the code is
easier to understand.

Cheers, Andreas

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