Re: [PATCH 2/2 v2] efivarfs: guid part of filenames are case-insensitive

[Al Viro <viro-3bDd1+5oDREiFSDQTTA3OLVCufUGDwFn@public.gmane.org>]

On Thu, Feb 14, 2013 at 05:11:16PM +0000, Matt Fleming wrote:
> On Thu, 2013-02-14 at 16:04 +0000, Al Viro wrote:
> > On Tue, Feb 12, 2013 at 12:39:34PM +0000, Matt Fleming wrote:
> > 
> > > +static struct dentry *efivarfs_alloc_dentry(struct dentry *parent, char *name)
> > > +{
> > > +	struct qstr q;
> > > +
> > > +	q.name = name;
> > > +	q.len = strlen(name);
> > > +
> > > +	if (efivarfs_d_hash(NULL, NULL, &q))
> > > +		return NULL;
> > > +
> > > +	return d_alloc(parent, &q);
> > > +}
> > 
> > > @@ -1098,7 +1177,7 @@ static int efivarfs_fill_super(struct super_block *sb, void *data, int silent)
> > >  		if (!inode)
> > >  			goto fail_name;
> > >  
> > > -		dentry = d_alloc_name(root, name);
> > > +		dentry = efivarfs_alloc_dentry(root, name);
> > >  		if (!dentry)
> > >  			goto fail_inode;
> > 
> > Umm...  That name has just been built by efivarfs_fill_super() itself, and
> > AFAICS there's no way for its GUID part to be _not_ lowercase
> > hex and with proper locations of dashes.  So
> > 	a) hash value will be exactly full_name_hash(name), unless
> > efivarfs_valid_name() manages to fail.
> 
> In my testing calling full_name_hash() and doing the partial_name_hash()
> loop returned different results. This is on x86, with
> CONFIG_DCACHE_WORD_ACCESS=y. I assumed they weren't compatible because
> most (all?) file systems that do fs-specific hashing also fill out the
> hash member using their fs-specific function, whereas efivarfs was
> previously using d_alloc_name().
> 
> Is this mismatch indicative of a bug in efivarfs hashing?

No, just me forgetting about DCACHE_WORD_ACCESS.  Nevermind...