linux-ext4 - Failure with generic/388 test

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

Message-ID: <20180118173946.aug2x2iclhemeij6@quack2.suse.cz>
Date:   Thu, 18 Jan 2018 18:39:46 +0100
From:   Jan Kara <jack@...e.cz>
To:     Ted Tso <tytso@....edu>
Cc:     linux-ext4@...r.kernel.org
Subject: Failure with generic/388 test

Hello,

I've been seeing failures with generic/388 test (with 4.12-based distro
kernel). Now after debugging it for some time it seems it is a problem in
EXT4_GOING_FLAGS_NOLOGFLUSH implementation. What seems to be happening is
that e.g. directory is being created, we set EXT4_FLAGS_SHUTDOWN in the
middle and so the creation fails. We do iput() which should delete the
unused inode but since the filesystem is marked as EXT4_FLAGS_SHUTDOWN,
those changes don't hit the disk. *But* the transaction which has allocated
the inode still manages to commit before we abort the journal (as there is
a window provided by msleep() in EXT4_GOING_FLAGS_NOLOGFLUSH
implementation). So after journal recovery, we have unattached inode and
e2fsck complains.

Now this would not happen if the system just crashed - in such case, either
the allocating transaction won't be able to commit, or iput() would have
finished successfully and logged inode deletion in the same transaction.

So why is journal abort happening after EXT4_FLAGS_SHUTDOWN being set and
why is that window even prolonged by msleep? That would deserve a comment
if nothing else BTW...

								Honza
-- 
Jan Kara <jack@...e.com>
SUSE Labs, CR