[apparmor] [PATCH 19/43] apparmor: convert profile lists to RCU based locking

John Johansen john.johansen at canonical.com
Wed Feb 27 18:45:37 UTC 2013


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 02/26/2013 04:02 PM, Seth Arnold wrote:
> On Fri, Feb 08, 2013 at 01:00:55PM -0800, John Johansen wrote:
> 
>> @@ -1091,13 +1098,13 @@ ssize_t aa_replace_profiles(void *udata, size_t size, bool noreplace)
> 
> Again, found while reviewing this patch, but not actually changed by
> _this_ patch at all. (Sorry.) My comments are out here: vvvvvvvvvvvv
> 
>         /* released below */
>         error = aa_unpack(udata, size, &lh, &ns_name);
>         if (error)
>                 goto out;				/* no ns yet */
> 
>         /* released below */
>         ns = aa_prepare_namespace(ns_name);
>         if (!ns) {
>                 info = "failed to prepare namespace";
>                 error = -ENOMEM;
>                 name = ns_name;
>                 goto fail;
>         }
> 
> 	/* ... */
> 
> out:
>         aa_put_namespace(ns);				/* but ns is put
> 							   and &lh is
> 							   not cleaned */
> 
>         if (error)
>                 return error;
>         return size;
> 
> fail_lock:
>         mutex_unlock(&ns->lock);
> 
> fail:
>         error = audit_policy(op, GFP_KERNEL, name, info, error);
> 
>         list_for_each_entry_safe(new, tmp, &lh, base.list) {
>                 /* &lh list is private and not rcu based */
>                 list_del_init(&new->base.list);
>                 aa_free_profile(new);
>         }
> 
>         goto out;
> }
> 
> 
> 
> At least one case of aa_unpack (an error in a profile header) can cause
> aa_unpack to leave profiles allocated on the list, so cleaning up after
> it here makes sense. (Or having aa_unpack() tear down on failure. Either
> way.)
> 
yep fixed in the new set
thanks

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iQIcBAEBCgAGBQJRLlRQAAoJEAUvNnAY1cPYe9EP/RwBSh/kvWJeGuO4LgP4bEO/
WNeWgdZCM2gUH4ZNCKNHA2U2be4OJULAFAwyzbt11KTkoTtVwfcV5bkk/adI1E+R
Y0pu3va7sBcOxaKJFVQDoc06Ade6Iw7b3x8qOUTImrqzvORNDBz7Y4gA2/7YJ8CP
r17XHKlUKPXmg079bPCBqrNjLZFFonxJ8CvN6XlfqZ3+nfqx8lk9F6UJxauvRE3E
fk7Z1+TQZnurSy0T+rXlUACDM+FAR5166vSrVGHrraOEAKZIDUx07I/RFpAxgZ74
PXXv6RsvF+9tpB1v6hoTfNDmnF0npYlUlDr6P+gL6XAr7VFm8Tv8Q8A6koR/EGyu
CC+NNJJGUrgPCXdERN01NWdqeSNpAIYjh5OgpaDv1MqfyV9bU+NoJJbv39mFHuMT
7cX/Z/a3TAfnmtFD7/jcbaqciCppCX0poMY0KSpdjONGu2Yeha7yYaDif7jb9M1A
KXVS3TFWCJ06xq7V+kjsb3BfxZ/k5iIQ3+AEC5rB63GIr1SNzp07T29fkt5DgYff
cmBKKkGl6DI/Ui3k/bccaX9Ww5GDaiP5phyoCOEvc2PamNEcktyGT9LGkPcDZk19
Dv9qGp54qu5D4TC7JoRQXfejt4+EC8l7T9rs2ltBTBzBCCA5oTeEWTV4S+JNufqJ
r7+SShMIKmHecVDTu+5I
=0bKm
-----END PGP SIGNATURE-----



More information about the AppArmor mailing list