Re: [RFC,PATCH] efivarfs: Don't delete efivar_entry structures on unlink

[Jeremy Kerr <jk-mnsaURCQ41sdnm+yROfE0A@public.gmane.org>]

Hi Matt,

> Isn't there a race here? Can't the efivar_entry be deleted and freed
> before we call efivar_get_entry()?
>
> The problem is you need to be able to ensure the validity of
> inode->i_private, but you can't in the open() function if you haven't
> already taken a reference to the variable. A ref count of some
> description needs to be incremented in efivarfs_fill_super() before the
> efivar_entry pointer is stored in the inode, and while we're holding the
> lock.

Yes, the intention is to bump the refcount any time we store the struct 
efivars_entry somewhere it might be referenced later (ie, in 
inode->i_private in this case). I'll add the ref when we create the 
inodes too.

One of my concerns with the current patch is using the empty list as an 
indicator whether the variable is present in firmware. Alternatively, we 
could do this with a new bool 'deleted' in the strut efivars_entry, 
which is set on unlink(). Any preferences?

Cheers,


Jeremy