|
From: Mehmet K. <mka...@li...> - 2017-07-21 13:00:56
|
> On Jul 19, 2017, at 4:09 PM, Magalhaes, Guilherme (Brazil R&D-CL) <gui...@hp...> wrote: > > Hi Mimi, > For all solutions with a single additional tree look up, the namespaced flags tree is placed inside the iint structure. This is what the POC posted by Mehmet does, and this mechanism is also the solution for 'namespacing' the integrity_iint_find() function. See the patch set I posted yesterday [1], that does not place it inside the iint, and creates an rbtree as part of the namespace struct. > However, this option suffers with the costly lock/unlock of hundreds of inodes when a namespace is released to cleanup namespaced flags, what makes this solution not acceptable for upstreaming as you indicated. As a result, the namespace cleanup does not touch inodes or iints. However, we didn't save the inode-->namespace association, so we don't have a way of removing the flags when the inode is removed. But we keep a copy of ino and generation, so if inode matches but ino and generation do not match, we can reset and reuse it. > We are really convinced that the solution #2 below is the best possible solution, which has 2 additional tree look ups for namespaced flags references (2 in addition to the existent iint tree look up, the first look up gets the list of flags for a given namespace and the second lookup get the target flag from the list for a given iint). The extra lookup is the namespace one. We should be able to tell the current namespace without needing an rbtree or a hash table. [1]: https://sourceforge.net/p/linux-ima/mailman/message/35956610/ Mehmet |