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