Quoting Hawk Xu (h.xu@private):
> 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,
Right, within reason.
1. In
inode_free_security(struct inode *my_inode) {
}
you don't need to lock my_inode, because it won't be accessed by
anyone else at that point.
2. However, if you have pointed
my_inode->security
to a structure which is shared with other inodes, then you'll
need to do appropriate locking
3. And if you need to do anything with current->security, for
example, then you'll obviously need to lock it.
> 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?
Correct.
-serge
This archive was generated by hypermail 2.1.3 : Wed Dec 07 2005 - 06:56:04 PST