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
| ||
|
Date: Mon, 28 Nov 2011 15:38:52 +0300 From: Alexander Zhavnerchik <alex.vizor@...il.com> To: Ted Ts'o <tytso@....edu> CC: adilger.kernel@...ger.ca, linux-ext4@...r.kernel.org Subject: Re: WARNING: at fs/inode.c:884 unlock_new_inode+0x34/0x59() Hi Ted, Unfortunately my laptop died today and I can't retest this issue. I'll provide more information once and if I repair it. Thanks, Alex On 28.11.2011 00:34, Ted Ts'o wrote: > On Sun, Nov 27, 2011 at 11:24:03PM +0300, Alex wrote: >> BTW, after last resume from disk fs was corrupted but fsck managed >> to fix this error. So I think severity of this issue should be >> raised. > Can you reproduce this reliably? What was running at the time of the s2disk? > > What appears to be going on is that insert_inode_locked() is failing > at fs/ext4/ialloc.c:887, probably because there's another inode with > that inode number already on the superblock's hash list. The error > codepath if insert_inode_locked() fail is incorrect; it's going to > fail_drop, which tries dropping the inode's dquot (but we haven't > calle ddquot_initialize)inode) yet) and calls unlock_new_inode(), but > I_NEW hasn't been set because insert_inode_locked(). > > So the warning is easy to fix; we just need to have it jump to fail > instead of fail_drop. But the bigger issue is why did > insert_inode_locked() failed in the first place. > > Did this error happen *right* after the system resumed, or did some > amount of time pass before the warning triggered? This could have > happened because the in-memory (or possibly on-disk) copy of the inode > allocation bitmap has gotten corrupted, for example. > > What was the nature of the file system corruption which e2fsck decided > that it need to correct? > > Regards, > > - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists