I just looked at some new code submission outside of the VFS. And it's like three new mutexes in there. I haven't added a mutex in such a long time I probably forgot what they look like.

Instead it's all rcu, seqlocks, memory barriers, atomics, and maybe a spinlock to be adventurous.

I don't know where things went wrong.

@brauner yeah rarely see a mutex in mm also

@ljs @brauner slab has one, I maintain a mutex!

@vbabka @brauner vmalloc too haha but I wisely un-R'd myself there

@ljs @brauner actually just week or two ago I've got an off-list question from a kernel newbie about why kmem_cache refcounts are not atomic or kref and what protects the operations on them. Truly forgotten ancient technology this mutex!

I blame @paulmckrcu

@brauner RCU uses many mutexes so that RCU users don't have to? ;-)

@paulmckrcu You know when you sometimes have to refactor a piece of code because you changed one of your exported helpers. For me it inevitably involves opening some file in some subsystem at some point and looking at the code and thinking or muttering "WTAF". Then squinting very very aggressively and just changing the tiny pieces you need. Then closing that file very quickly. Then swapping out the memory. I'm choosing to apply this strategy to your reply. 😛

@brauner @paulmckrcu welcome to the back porting hell!

@brauner Fair enough! But I might nor might not remember that you forgot. ;-)

@brauner I write significantly less kernel code than you or the others on this thread but I feel like I'm constantly dealing with rwsems and mutexes. Which makes me a little concerned about the future of debugging those RCU issues. With rwsems and mutexes, at least we have a chance at determining ownership and which tasks are waiting for resources. RCU and memory barriers are so much more inscrutable for debugging, if you're not an expert in the subsystem 😓