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
| ||
|
Message-ID: <20170121133049.bsrp55gi4x5x5wcv@thunk.org> Date: Sat, 21 Jan 2017 08:30:49 -0500 From: Theodore Ts'o <tytso@....edu> To: George Spelvin <linux@...encehorizons.net> Cc: jack@...e.cz, linux-ext4@...r.kernel.org Subject: Re: Ext4 deadlock (+lockdep splat) during rsync On Fri, Jan 20, 2017 at 12:57:23PM -0500, George Spelvin wrote: > So I'm guessing the problem is that the required empty system.data > attribute is missing (due to the preceding extra_isize changing mess), > and if I just created it, everything would magically come back to life > > Something like ea_set <inode> system.data "" Well, it would still a corrupted, innconsistent inode, in that there would still be a block attached to the inode, and i_size would be different from the size of the data xattr used by inline_data. So you might as well just clri the inode and rerun fsck, or clri the inode and then unlink the directory entry in lost+found. You might get it to a state where the kernel isn't explicitly complaining any more, but you might end up unmasking other bugs where the kernel is further failing to handle an inconsistent inode relating to inline_data. Which is fine if you want to potentially exposing more problems, but if this is file system with Data You Care about, my suggestsion to run debugfs's clri and then e2fsck -f really is the most conservative advice to give. - Ted
Powered by blists - more mailing lists