Quoting Hawk Xu (h.xu@private): > Hi! > > What kind of kernel locking should I use when releasing the incore > security information of inodes and tasks in the inode_free_security and > task_free_security hook call? > > For inodes: > spin_lock(&inode->i_lock); > ...; > spin_unlock(&inode->i_lock); > > For tasks: > spin_lock(&task->alloc_lock); > ...; > spin_unlock(&task->alloc_lock); > > Is the above code OK? Or the above code may be called in > non-user-context so we have to use spin_lock_irqsave() and > spin_lock_irqrestore()? 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. -serge
This archive was generated by hypermail 2.1.3 : Tue Dec 06 2005 - 20:16:51 PST