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] [day] [month] [year] [list]

Message-ID: <20121102000558.GH19576@blackbox.djwong.org>
Date:	Thu, 1 Nov 2012 17:05:58 -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:28:47AM -0400, George Spelvin wrote:
> > 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?
> 
> Yup.  After it survived one e2fsck -D, I poked at the directory a bit
> to see if I could cause the error.  No success from local access.
> 
> It's also probably an NFSv2 client.  I wonder if it's doing something
> odd with directory seeks that's causing problems; perhaps htree and the
> 32-bit seek cookie limit are not friends?

<shrug> I'm not nfs-wise, sadly.  I _am_ wondering if an ftrace of this might
be useful... or a gigantic glut of data that I'll never finish processing.

Just from a quick read of ext4_find_entry() it looks like the only thing that
results in fallback mode without a kernel message is ext4_bread() failing in
dx_probe()?

> >> 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.
> 
> Maybe I was wrong.  I was worried that it was aborting the directory
> scan due to the error and thus files would disappear.  If that doesn't
> happen, no worries.

Oh well, it'll run slowly but at least it won't be throwing up errors.

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