linux-ext4 - Re: ext4: fix metadata checksum calculation for the superblock

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]

Message-ID: <20121101070731.21349.qmail@science.horizon.com>
Date:	1 Nov 2012 03:07:31 -0400
From:	"George Spelvin" <linux@...izon.com>
To:	darrick.wong@...cle.com, linux@...izon.com
Cc:	linux-ext4@...r.kernel.org, tm@....ma, tytso@....edu
Subject: Re: ext4: fix metadata checksum calculation for the superblock

> Yes, it would be useful to know what's going on with this directory file,
> since it seems to fallback to linear scan, yet e2fsck -D doesn't fix it.
> What I was /going/ for was that the kernel would notice a bad directory
> and flag it for fsck on reboot.  Upon reboot, fsck would be run, notice
> the bad dir, and feed it to the directory rebuilder to get it fixed
> for good.  However, there doesn't seem to be any real checksum mismatch,
> so the rebuild doesn't happen.

That's what confuses me.  I had already run e2fsck -D (which I assume
rebuilds all directories, even if unnecessary) before observing the
problem.  The other odd clue is that it's always nfsd that chokes;
other accesses to the directory (ls -U, ls -lU, grep -r) don't produce
the message.

> Also ... refresh my memory -- some files have disappeared as a result of this
> happening?

I haven't observed it, no.  But the nature of the symptoms suggests it
might be happening.
--
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