Re: [PATCH 4/6] xfs_db: fix metadump name obfuscation for ascii-ci filesystems

["Darrick J. Wong" <djwong@kernel.org>]

On Mon, Apr 10, 2023 at 09:58:46PM -0700, Christoph Hellwig wrote:
> On Wed, Apr 05, 2023 at 05:09:55PM -0700, Darrick J. Wong wrote:
> > From: Darrick J. Wong <djwong@kernel.org>
> > 
> > Now that we've stabilized the dirent hash function for ascii-ci
> > filesystems, adapt the metadump name obfuscation code to detect when
> > it's obfuscating a directory entry name on an ascii-ci filesystem and
> > spit out names that actually have the same hash.
> 
> Between the alloc use, the goto jumping back and the failure to
> obsfucate some names this really seems horribly ugly.  I could
> come up with ideas to fix some of that, but they'd be fairly invasive.

Given that it's rol7 and xoring, I'd love it if someone came up with a
gentler obfuscate_name() that at least tried to generate obfuscated
names that weren't full of control characters and other junk that make
ls output horrible.

Buuuut doing that requires a deep understanding of how the math works.
I think I've almost grokked it, but applied math has never been my
specialty.  Mark Adler's crc spoof looked promising if we ever follow
through on Dave's suggestion to change the dahash to crc32c, but that's
a whole different discussion.

> Is there any reason we need to support obsfucatation for ascii-ci,
> or could we just say we require "-o" to metadump ascii-ci file systems
> and not deal with this at all given that it never actually worked?

That would be simpler for metadump, yes.

I'm going to introduce a followup series that adds a new xfs_db command
to generate obfuscated filenames/attrs to exercise the dabtree hash
collision resolution code.  I should probably do that now, since I
already sent xfs/861 that uses it.

It wouldn't be the end of the world if hashcoll didn't work on asciici
filesystems, but that /would/ be a testing gap.

--D