I have a full patch for this.I don't remember the details yet, but lock was not god here, we used semaphore. I pointed to this problem long ago when fixed error path in proc with moduleget.

This patch protects proc_dir_entry tree with a proc_tree_sem semaphore. I suppose lock_kernel() can be removed later after checking that no proc handlers require it.Also this patch remakes de refcounters a bit making it more clear and more similar to dentry scheme - this is required to make sure that everything works correctly.

Patch is against 2.6.15-rcX and was tested for about a week. Also works half a year on 2.6.8 :)

> Steven Rostedt <rostedt@goodmis.org> wrote:>> +static DEFINE_SPINLOCK(remove_proc_lock);>>> > I'll take a closer look at this next week.> > The official way of protecting the contents of a directory from concurrent> lookup or modification is to take its i_sem. But procfs is totally weird> and that approach may well not be practical here. We'd certainly prefer> not to rely upon lock_kernel().> -> 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/> --- ./fs/proc/generic.c.proclk 2005-12-26 13:43:14.000000000 +0300+++ ./fs/proc/generic.c 2005-12-31 11:48:16.000000000 +0300@@ -27,6 +27,8 @@ static ssize_t proc_file_write(struct fi size_t count, loff_t *ppos); static loff_t proc_file_lseek(struct file *, loff_t, int);