Re: 2.6.0-test9 and sleeping function called from invalid context

[Stephen Smalley]

On Sun, 2003-10-26 at 01:49, Andrew Morton wrote:
> Andrew Morton <akpm@xxxxxxxx> 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@xxxxxxxxxxxxxx>
National Security Agency

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/