Hi! Serge E. Hallyn wrote: >You don't want to use these at all. inode->i_lock protects the >inode itself, for instance. By the time you get to inode_free_security, >the inode won't be referenced by anyone else.So you only need to >protect your own data. If inode->i_security points to a shared object, >then you'll need to protect that appropriately. > >To be clear, make sure that you are considering what data to protect >from concurrent access, not which concurrent code to protect. > > > Do you mean that no kernel locking is needed for releasing the incore security information, and even if some kind of locking is needed, my code in the previous post is unable(or use the wrong lock) to protect the incore security infomation? 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:28:23 PST