On Sat, 06 Sep 2025, Al Viro wrote: > On Sat, Sep 06, 2025 at 06:50:05AM +0100, Al Viro wrote: > > On Sat, Sep 06, 2025 at 02:57:05PM +1000, NeilBrown wrote: > > > From: NeilBrown <neil@xxxxxxxxxx> > > > > > > proc_setup_self() and proc_setup_thread_self() are only called from > > > proc_fill_super() which is before the filesystem is "live". So there is > > > no need to lock the root directory when adding "self" and "thread-self". > > > > > > The locking rules are expected to change, so this locking will become > > > anachronistic if we don't remove it. > > > > Please, leave that one alone. FWIW, in tree-in-dcache branch (will push > > tomorrow or on Sunday, once I sort the fucking #work.f_path out) there's > > this: Sure, I'm happy to drop this patch. > > PS: you do realize that we have similar things in devpts, binder, functionfs, > etc., right? What's special about procfs? > devpts uses simple_start_creating(). The ->lookup function for for procfs will return -ENOENT for a non-existing name rather than returning NULL and leaving the dentry uninstantiated, so simple_start_creating() will fail. binder uses d_alloc_name() and d_add() without any locking, which is exactly what I was proposing for proc. functionfs seems to do the same. NeilBrown
