On Tue, Jan 3, 2012 at 10:45 AM, Mimi Zohar <zohar@xxxxxxxxxxxxxxxxxx> wrote:
>
> Just clarifying not all of commit fb88c2b, but only the
> security_old_inode_init_security() hunk.
Is it really sane to have different semantics like that for the
security[_old]_inode_init_security functions?
Look at ocfs2, for example: it does nothing if
ocfs2_init_security_get() returns 0. That does not sound like the
correct thing to do, when the fallback is to do ocfs2_init_acl() under
the lock.
And ocfs2_init_security_get() just calls either
security_inode_init_security() or security_old_inode_init_security()
depending on whether ocfs2_security_xattr_info is NULL or not. So I
really think callers expect the same kind of semantics regardless of
whether it's the "old" or not version. Which would make sense anyway.
Also, the *documentation* in include/linux/security.h very much says
that it returns 0 only if @name and @value have been successfully set.
So my gut feel says that both security_inode_init_security and
security_old_inode_init_security should return -EOPNOTSUPP (although
the "new" version doesn't really have "name/value", so maybe returning
0 is ok)
Anyway, I'd love for (multiple) people who really know the code to
give me a clean agreement on exactly what the correct patch is.
Please?
Linus
--
To unsubscribe from this list: send the line "unsubscribe reiserfs-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
