linux-ext4 - Re: [PATCH 06/10] e2fsck: Handle s_inodes

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]

Message-ID: <20180619145957.GH6931@thunk.org>
Date:   Tue, 19 Jun 2018 10:59:57 -0400
From:   "Theodore Y. Ts'o" <tytso@....edu>
To:     Jan Kara <jack@...e.cz>
Cc:     Andreas Dilger <adilger@...ger.ca>,
        Ext4 Developers List <linux-ext4@...r.kernel.org>
Subject: Re: [PATCH 06/10] e2fsck: Handle s_inodes_count corruption properly

On Wed, Jun 13, 2018 at 02:11:05PM +0200, Jan Kara wrote:
> 
> Actually currently e2fsck never succeeded in even opening the filesystem
> with corrupted s_inodes_count so it could not fix anything. So my change is
> at least an improvement that it reports what's wrong and fixes the "easily
> fixable" corruptions.
> 
> Reducing number of block groups is doable (although libext2fs code is not
> quite prepared for that so it may need some fixups). I was just a bit
> worried that if the s_inodes_count corruption is not due to resize2fs bug,
> reducing the group count may actually be a wrong thing to do and could
> cause serious damage to the filesystem. What do people think?

The primary principle should be "first, do no harm".  It's probably
going to be easier to get e2undo with resize2fs working well and by
default than trying to figure out how to fix the s_inodes_count
corruption case.  And it will have a better bang for the buck, since
future bugs may not involve s_inodes_count at all.

So that's probably a better investment of developer time, in my view.

       	    	    	    		      - Ted