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