On 03/01/2013 05:57 PM, Seth Arnold wrote:
>> @@ -546,17 +534,40 @@ static void __ns_list_release(struct list_head *head);
>> */
>> static void destroy_namespace(struct aa_namespace *ns)
>> {
>> + struct aa_profile *unconfined;
>> +
>> if (!ns)
>> return;
>>
>> - write_lock(&ns->lock);
>> + mutex_lock(&ns->lock);
>> /* release all profiles in this namespace */
>> __profile_list_release(&ns->base.profiles);
>>
>> /* release all sub namespaces */
>> __ns_list_release(&ns->sub_ns);
>>
>> - write_unlock(&ns->lock);
>> + unconfined = ns->unconfined;
>> + /*
>> + * break the ns, unconfined profile cyclic reference and forward
>> + * all new unconfined profiles requests to the parent namespace
>> + * This will result in all confined tasks that have a profile
>> + * being removed, inheriting the parent->unconfined profile.
>> + */
>> + if (ns->parent)
>> + ns->unconfined = aa_get_profile(ns->parent->unconfined);
>
> Incidentally, the comment in alloc_namespace() is incorrect now that
> this code block have moved functions:
>
> /*
> * released by free_namespace, however __remove_namespace breaks
> * the cyclic references (ns->unconfined, and unconfined->ns) and
> * replaces with refs to parent namespace unconfined
> */
>
just roll with it as its changed in a subsequent patch
>
> It might not actually matter much that the name has changed, since
> __remove_namespace() calls destroy_namespace().. but it does bug me a
> touch that the outer function has double-leading-underscore and the inner
> function doesn't have the double-leading-underscore. Do the names need
> some cleanup? (I'd love to see the split removed entirely, but removing
> the root namespace is a special-case operation...)
>
nope, another convention
the double underscore indicates it needs to be called within locking or
something else special.
destroy_namespace() doesn't technically need that as long as the ns is not
in a list.
__remove_namespace() is all about pulling the ns from the list and so needs
it.
Also just roll with it, as things get changed here as well in a subsequent
patch.
--
AppArmor mailing list
AppArmor@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/apparmor
