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

[viro@parcelfarce.linux.theplanet.co.uk]

On Sun, Oct 26, 2003 at 01:41:53AM -0700, Andrew Morton wrote:

> > 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.

Yes, we do.  At least we used to - the other side of that code assumes
that holding the spinlock is enough to keep ->proc_dentry unchanged.
And no, I hadn't done the analysis of changes that had come with the
"task" ugliness.

> 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??

For proc_pid_lookup() they are the same.