Messages in this thread | | | Subject | Re: 2.6.0-test9 and sleeping function called from invalid context | From | Stephen Smalley <> | Date | 27 Oct 2003 08:52:01 -0500 |
| |
On Sun, 2003-10-26 at 01:49, Andrew Morton wrote: > Andrew Morton <akpm@osdl.org> wrote: > > > > but the wider question would be: is the SELinux > > d_instantiate callout allowed to sleep? A quick audit seems to indicate > > that it's OK, but only by luck I think. > > proc_pid_lookup() calls d_add->d_instantiate under task->proc_lock, so > inode_doinit_with_dentry() is called under spinlock on this path as well. > > Manfred, is there any particular reason why proc_pid_lookup()'s d_add is > inside the lock?
This shouldn't be a problem for SELinux, because the /proc/pid inodes are initialized by proc_pid_make_inode via the security_task_to_inode hook (=> selinux_task_to_inode), so inode_doinit_with_dentry will bail immediately on the first test of isec->initialized prior to any blocking calls.
I asked Al Viro about this issue back when the proc locking change was introduced (circa 2.5.70), and he seemed to agree that the SELinux code is safe in this case. He was concerned about the change in behavior for d_instantiate, but d_instantiate seems to be the more general location to perform inode security initialization for the majority of filesystem types; hooking in iget() would only handle a subset of filesystems.
-- Stephen Smalley <sds@epoch.ncsc.mil> National Security Agency
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |