linux-ext4 - Re: [PATCH 1/3] e2fsck: update quota when optimizing the extent tree

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

Message-ID: <20170422214802.z4qekigaoaucwffl@thunk.org>
Date:   Sat, 22 Apr 2017 17:48:02 -0400
From:   Theodore Ts'o <tytso@....edu>
To:     Andreas Dilger <adilger@...ger.ca>
Cc:     "Darrick J. Wong" <darrick.wong@...cle.com>,
        Ext4 Developers List <linux-ext4@...r.kernel.org>
Subject: Re: [PATCH 1/3] e2fsck: update quota when optimizing the extent tree

On Fri, Apr 21, 2017 at 03:15:07PM -0600, Andreas Dilger wrote:
> 
> Should this quota_data_sub() call be after ext2fs_iblk_sub_blocks() has
> completed successfully, or are the blocks already freed at this point
> and only the inode->i_blocks counter would be outdated?

The blocks are already freed at this point.

> In theory this could go at the start before any changes are made to the
> inode, and then there wouldn't be the need for the intermediate call to
> quota_data_sub() above?  That avoids a small amount of overhead, and
> also avoids the more complicated issue of the quota file being modified
> even if this operation hits an error and is skipped (i.e. any "goto err"
> case).

We're actually not modifying the quota file at this point; we're just
modifying the in-memory "correct" quota data numbers.

Also, if we fail in the middle, given that the extent tree blocks have
been freed and potentially partially reused, the fact that the quota
file has been modified is the least of our problems.  In theory we
could save the list of old extent tree index blocks, and try to use
new blocks for the new extent tree index blocks as much as possible.
But that's not true today.

    	   				- Ted