linux-ext4 - question about i_dtime being used as an orphan list pointer

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: <AANLkTi=3hK1RLRJ+2Kt0ju=HEr-LdkO9eX_YxLfp0wea@mail.gmail.com>
Date:	Wed, 25 Aug 2010 12:22:22 -0700
From:	Vitali Lovich <vlovich@...il.com>
To:	linux-ext4@...r.kernel.org
Subject: question about i_dtime being used as an orphan list pointer

So I've run into this problem where the clock was reset into the 1970s
on my system, causing e2fsck to get confused & think a file I deleted
actually had an orphan list inode pointer stored in the i_dtime
instead of the deletion time, causing e2fsck to get all confused &
return an error code.

My current idea for a workaround is to clamp the value to midnight
2000 if get_seconds returns that, but I'm not really enamoured with
that idea.

Looking at this further, I made the following observations (please let
me know if I'm completely off base):

Even a value of midnight 2010 corresponds to a limit of only about 1
billion files (1 262 304 000).  Thus it seems if you delete a file on
a partition with more than a billion files, it will make e2fsck think
you've got a corrupt file-system even though you don't.

A slightly related question I have is if anyone knows whether i_dtime
is actually used as a timestamp for anything useful in kernel or
user-space?  Can I just set d_time to 0xffffffff when it's deleted
instead of giving it wall-clock time?

Thanks for any feedback,
Vitali
--
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