Re: kernel locking for releasing incore security

From: Hawk Xu (h.xu@private)
Date: Wed Dec 07 2005 - 02:27:33 PST


Hi!

Tony Jones wrote:

>Question: who are the possible concurrent users of this "security information"?
>  
>
In my LSM module:

task_alloc_security allocates the space for the incore security 
information for tasks,  task_free_security frees it,  task_post_setuid 
and inode_permission use(read, or update) it.

inode_alloc_security hook allocates the space for the incore security 
information for inodes,  inode_free_security frees it,  d_instantiate, 
inode_post_setxattr, inode_post_removexattr(I added this hook for 
special need) and inode_permission use(read, or update) it.

Because of lacking of linux kernel knowledge, I'm not sure whether the 
other hooks will use it concurrently when task_free_security and 
inode_free_security are freeing it.

>Hint: *_free_security is being called as the kernel is about to release the 
>object.
>
Do you mean that no locking is needed for *_free_security?

Thanks!

 
Best regards,

Hawk Xu, M.S.C.S.
h.xu `echo "ta"|rev` 163 `echo "tod"|rev` com



This archive was generated by hypermail 2.1.3 : Wed Dec 07 2005 - 02:29:35 PST