linux-ext4 - Re: e2fsck bogus error report on orphan-list

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:	Fri, 20 Jul 2007 08:20:26 +0900
From:	Ryoichi KATO <Ryoichi.Kato@...sony.com>
To:	tytso@....edu
Cc:	linux-ext4@...r.kernel.org, sct@...hat.com,
	akpm@...ux-foundation.org, adilger@...sterfs.com,
	tim.bird@...sony.com
Subject: Re: e2fsck bogus error report on orphan-list

At Thu, 19 Jul 2007 12:55:10 -0400,
Theodore Tso wrote:
> On Fri, Jul 20, 2007 at 12:39:19AM +0900, Ryoichi.Kato@...sony.com wrote:
> > Hi,
> > I hit a problem of ext3/e2fsck on orphan-list handling.
> 
> Wow, I'm rather impressed that this was sufficient for a presentation
> at a conference.  You could have just sent me e-mail.  :-)

I know it's a rare case for most of the people and not sure
it is a 'bug',  but I thought it might happen more offten for CE people.
So, I asked for opinions of CE people in a lighting session of
"CELF Technical Jamboree."

> >    1. Delete a file in an ext3 filesystem in early 1970
> 
> Dare I ask *why* the system clock was set in the 1970's?  Umm... don't
> do that.

As Tim pointed out, embedded devices offten omit RTC battery.

> >    2. Set RTC to 2007, and then mount/write the filesystem.
> 
> There is code that detects when the time is set back in the 1970's
> (normally due to a bad clock battery) and thus disables this
> particular check.  So it only triggers when the clock was previously
> bad, and is now good.

Actually, it's a *real* problem happend for my car navigation product.
Until GPS signal is available, it's clock was 1970.
And for servers and PCs, it's possible that RTC backup battery run out,
then clock get set correctly afterward by, say, NTP.

> The net is that the check is basically a sanity check to make any bugs
> in the orphaned list handling would be discovered, although it can
> also trigger if there is block device corruption where part of the
> inode table is corrupted.  I had added hueristics that for most people
> meant that it never triggered, so I'm surprised that it actually did
> in your environment.  Still, if it did, the easist thing to do is to
> just turn it off.

Now, after things behind the problem turned out, it's easy.
But let me point out that,

 * It is very difficult to relate RTC to the problem.
   No clue without digging into e2fsck source code.

 * -p (preen) option of e2fsck doen't fix it automatically.
   Though I'm not sure but, maybe it's safe to correct the
   problem automatically?

Actually, it took me for several weeks to solve, because it is rare.
My system only reset RTC for hardware reset or when main battery run out
but not for software reset. But it can happen.

Thank you.
--
Ryoichi KATO <Ryoichi.Kato@...sony.com>
    System Design Dept. No4
    Audio Development & Engineering Div.
    Sony Corporation Audio Business Group
    Tel +81-3-3599-3862 / Fax +81-3-3599-3859
-
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