On Fri, Dec 06, 2024 at 04:06:37PM +0000, Matthew Wilcox wrote: > On Fri, Dec 06, 2024 at 05:03:03PM +0100, Christian Brauner wrote: > > On Fri, Dec 06, 2024 at 03:46:37PM +0000, Matthew Wilcox wrote: > > > On Fri, Dec 06, 2024 at 04:25:13PM +0100, Christian Brauner wrote: > > > > For the pidfs inode maple tree we use an external lock for add and > > > > > > Please don't. We want to get rid of it. That's a hack that only exists > > > for the VMA tree. > > > > Hm, ok. Then I'll stick with idr for now because we can simply use > > pidmap_lock. Otherwise we'd have to introduce more locking. > > Why can you not delete pidmap_lock and use the maple tree lock > everywhere that you currently use pidmap_lock? That's the intended > way to use it. Each pid namespace has it's own idr (as each pid namespace gets its own pid number space) and the whole pid allocation across all pid namespaces idrs is protected by pidname_lock. All pid numbers in all pid namespaces idrs are allocated (acquiring and dropping pidmap_lock) but storing a NULL so that find_pid_ns() isn't able to find a half-initialized struct pid. The pidmap_lock is taken again to publish all pid numbers once its finalized. It also protects each pid namespaces's pid number allocation indicator pid_ns->pid_allocated. So in short, I'm pretty sure that it's possible to port this to the maple tree overall and rely on the maple tree locks but I'm not sure how straightforward it would be and I don't want to tie this work into the pidfs file handle work as a preliminary as well.
