Hi Andrew, 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 :) Signed-Off-By: Pavel Emelianov Signed-Off-By: Kirill Korotaev Kirill > Steven Rostedt 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/ >