Messages in this thread | | | Date | Sun, 26 Oct 2003 09:41:57 +0000 | From | viro@parcelfa ... | Subject | Re: 2.6.0-test9 and sleeping function called from invalid context |
| |
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. - 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/
| |