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:	Thu, 1 Nov 2012 00:18:18 -0700
From:	"Darrick J. Wong" <darrick.wong@...cle.com>
To:	George Spelvin <linux@...izon.com>
Cc:	linux-ext4@...r.kernel.org, tm@....ma, tytso@....edu
Subject: Re: ext4: fix metadata checksum calculation for the superblock

On Thu, Nov 01, 2012 at 03:07:31AM -0400, George Spelvin wrote:
> > 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.

Oh, so ... it's just nfsd that causes the linear fallback?  Regular (i.e.
non-nfs) users can see everything in the dir, no error messages?

Now *that* is odd. :)

You know, I was starting to wonder what on earth would even cause the fallback
in the first place.  It even looked like most of the "your dir is corrupt"
exits from that function would spit out an error or be somehow obviously
broken.

> > 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.

Hum.  When linear scan happens on a hashed dir, it's scanning the same blocks
that the hash scan sees.   The htree block looks like a regular directory block
with one huge "unused" dirent that wraps all the htree data.  So, the linear
scan should find the exact same files as a htree scan would.  If it doesn't,
something's wrong.  But you say it isn't, so I imagine it's fine.

<shrug> Another thing for me to ponder tomorrow. :)

--D
--
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

Powered by blists - more mailing lists