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?
--
Matt Fleming, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
