linux-ext4 - Re: Directory unremovable on ext4 no

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]

Date:   Mon, 9 Apr 2018 17:38:37 -0700
From:   "Darrick J. Wong" <darrick.wong@...cle.com>
To:     Jayashree Mohan <jayashree2912@...il.com>
Cc:     linux-ext4@...r.kernel.org, fstests <fstests@...r.kernel.org>,
        Vijaychidambaram Velayudhan Pillai <vijay@...utexas.edu>
Subject: Re: Directory unremovable on ext4 no_journal mode

On Mon, Apr 09, 2018 at 07:08:13PM -0500, Jayashree Mohan wrote:
> Hi,
> 
> We stumbled upon what seems to be a bug that makes a “directory
> unremovable”,  on ext4 when mounted with no_journal option.
> 
> A sequence of operations described below led to the following state :
> “A directory that was renamed, was persisted in both parent and target
> directories, with the same inode number. This also means the rename
> was non-atomic on storage. In addition, the renamed directory becomes
> unremovable on the target with FS-error logged in dmesg.”
> 
> Here are more details of the workload and the corresponding failure.
> 
> Workload :
> 
> mkdir /mnt/test/X and /mnt/test/Y
> mkdir X/Z
> sync()
> rename X/Z   Y/Z
> fsync Y
> —-Crash now—-
> Remount

You're supposed to run e2fsck after a crash to clean up the metadata.
nojournal disables the piece that takes care of that.

--D

> ls X and Y (You will see Z is present in both directories X and Y, and
> has same inode)
> rmdir test_dir/X/Z  (This succeeds)
> rmdir test_dir/Y/Z  (This fails with a FS error logged in dmesg)
> 
> 
> Results:
> 
> rmdir: failed to remove '/mnt/test/Y/Z': Structure needs cleaning
> 
> The corresponding dmesg log has the following error message :
> [66799.504124] EXT4-fs error (device cow_ram_snapshot1_0):
> ext4_lookup:1576: inode #12: comm rmdir: deleted inode referenced: 14
> [66799.504131] EXT4-fs (cow_ram_snapshot1_0): Remounting filesystem read-only
> 
> The sequence of operations listed above is making dir Z unremovable
> from dir Y, which seems like unexpected behavior. Could you provide
> more details on the reason for such behavior? We understand we run
> this on no_journal mode of ext4, but would like you to verify if this
> behavior is acceptable.
> 
> Do let us know if we are missing any detail here.
> 
> Thanks,
> Jayashree Mohan