On Fri, 20 Feb 2009 17:16:59 -0500
Mimi Zohar <zohar@xxxxxxxxxxxxxxxxxx> wrote:
> integrity: ima iint radix_tree_lookup locking fix
>
> Based on Andrew Morton's comments:
> - add missing locks around radix_tree_lookup in ima_iint_insert()
>
> Signed-off-by: Mimi Zohar <zohar@xxxxxxxxxx>
>
> Index: security-testing-2.6/security/integrity/ima/ima_iint.c
> ===================================================================
> --- security-testing-2.6.orig/security/integrity/ima/ima_iint.c
> +++ security-testing-2.6/security/integrity/ima/ima_iint.c
> @@ -73,8 +73,10 @@ out:
> if (rc < 0) {
> kmem_cache_free(iint_cache, iint);
> if (rc == -EEXIST) {
> + spin_lock(&ima_iint_lock);
> iint = radix_tree_lookup(&ima_iint_store,
> (unsigned long)inode);
> + spin_unlock(&ima_iint_lock);
> } else
> iint = NULL;
> }
Can the -EEXIST ever actually happen?
On the inode_init_always() path (at least), I don't think that any
other thread of control can have access to this inode*, so there is no
way in which a race can result in someone else adding this inode
first?
Also, idle question: why does the radix tree exist at all? Would it
have been possible to just add a `struct ima_iint_cache *' field to the
inode instead?
--
To unsubscribe from this list: send the line "unsubscribe linux-next" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
