lkml.org 
[lkml]   [2003]   [Oct]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 2.6.0-test9 and sleeping function called from invalid context
viro@parcelfarce.linux.theplanet.co.uk wrote:
>
> On Sat, Oct 25, 2003 at 10:49:50PM -0700, 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?
>
> AFAICS, we can move d_add() right before taking the spinlock. It's there
> to protect the ->proc_dentry assignment.

In which case we don't need to take the lock at all. Two instances.

What protects against concurrent execution of proc_pid_lookup() and
proc_task_lookup()? I think nothing, because one is at /proc/42 and the
other is at /proc/41/42; the parent dir inodes are different. hmm.

> *However*, I would like to point out that we are holding ->i_sem on the
> procfs root at that point, so any blocking code in d_instantiate() would
> better be careful to avoid deadlocks if it wants to play with procfs itself -
> we are not in a locking-neutral situation here, spinlock or not.

"procfs root", or parent dir??
-
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/

\
 
 \ /
  Last update: 2005-03-22 13:58    [W:0.067 / U:0.080 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site