[prev in list] [next in list] [prev in thread] [next in thread] 

List:       selinux
Subject:    [PATCH] SELinux: 0/3 clean up locking and semaphore usage
From:       Eric Paris <eparis () parisplace ! org>
Date:       2006-07-27 17:29:23
Message-ID: 1154021363.5028.44.camel () localhost ! localdomain
[Download RAW message or body]

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 semaphore 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 majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
[prev in list] [next in list] [prev in thread] [next in thread]