Skip to contentSkip to conversation

SELinux: 0/3-v2 clean up locking and semaphore usage

PATCH New Eric Paris 1 participant 1 message Aug 3, 2006 SELinux security module

lore
Share & tools
lore

Eric Paris

author
#0 lore raw

PATCH 1/1 SELinux: 0/3-v2 clean up locking and semaphore usage

The following patch set attempts to do a little cleanup in SELinux code concerning the usage of semaphores which we init to 1. First off there is nothing wrong with semaphores but with the introduction of simple mutexes a slightly faster interface is available (see Documentation/mutex-design.txt) Since mutexes save time and space I'm going to try to deal with both of the semaphores I see in the selinux code.

The first patch completely eliminates the inode_security_set_security function which was only being called from superblock_doinit. Since there was only 1 caller I rolled it back into superblock_doinit. Also since superblock_doinit is called while mounting, and before the root inode is available to anything else we don't need to worry about locking the isec->sem. So the locking was completely dropped.

The second patch converts the remaining isec->sem into a mutex. The same locking is provided only in the faster smaller mutex rather than slower sem.

The third patch is the most controversial I'm sure. I just completely eliminate the sbsec->sem. This was used to lock the updating of the superblock security struct inside superblock_doinit. superblock_doinit is only called from vfs_kern_mount and from selinux_complete_init. The operation with vfs_kern_mount is protected from races because the &mnt->mnt_sb->s_umount write lock will always be held in the call to security_sb_kern_mount (which works down to superblock_doinit) so the only thing I was really concerned about was selinux_complete_init. It seems to me though that the ss_initialized variable will stop infinite recursion between the two even without locking and that we need not worry about races between vfs_kern_mount and selinux_complete_init since nothing should be able to mount while we are still processing the initial policy load in init. Please though, let me know if I am misunderstanding the race potentials of selinux_complete_init.

-Eric

--
This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to [email protected] with the words "unsubscribe selinux" without quotes as the message.