Re: free inode security blob

[Chris Wright <chris@wirex.com>]

(sorry, i mean to include the lsm list on the last reply).
tongcd, you may also find useful lsm help on the lsm list.

* Chris Wright (chris@wirex.com) wrote:
> * tongcd (tongcd@21cn.com) wrote:
> > Could anybody give me some hint about the following question?  Thanks
> > 1.  I use linux security module to alloc a security blob to each inode, but when
> >     i want to cleanup the module ,i decide to free these alloced memory from inode struct,i want to travel through inode_in_use ,inode_unused,sb->s_dirty and sb->s_locked_inode ,but these are all static varieble,where is no way to use it in lsm module,could it be other ways to do it?
> 
> lsm attempts to make the minimal changes to the kernel required to
> meet its requirements.  so static lists like you've mentioned have
> not been exported just for lsm.  the proper way to handle this is to
> maintain your own list in your module of the allocations you've made.
> during the module_exit code, you can traverse these lists, and clean up
> after yourself.  see the SELinux module for a good example of how to
> handle this.  honestly, many lsm modules are coded with the intention
> that they will not be removed until the machine is being rebooted, and
> since lsm can control module unloading, this is not necessarily a bogus
> assumption.
> 
> > why dte not do it?
> 
> i'm sure serge would accept patches ;-)
> 
> > 2.   iget4 call find_inode to find establishing inode linked in i_hash,(these inode all in inode_in_used and inode_unused links??)why iget call get_new_inode which use find_inode for a second time? If this question has post before,i am sorry.
> 
> it is possible for an inode to not be in hash.  so the first attempt
> at find_inode in iget4 could fail.  notice find_inode must be called
> with lock, so get_new_inode (which is called after the search failed,
> and the lock is released) must re-obtain the lock and re-check the hash.
> 

-chris
--
Kernelnewbies: Help each other learn about the Linux kernel.
Archive:       http://mail.nl.linux.org/kernelnewbies/
IRC Channel:   irc.openprojects.net / #kernelnewbies
Web Page:      http://www.kernelnewbies.org/