On Tue, Sep 12, 2023 at 11:03:42AM +0200, Peter Zijlstra wrote: > On Tue, Sep 12, 2023 at 08:29:55AM +1000, Dave Chinner wrote: > > > So, once again, we have mixed messages from the lock maintainers. > > One says "no, it might get abused", another says "I'm fine with > > that", and now we have a maintainer disagreement stalemate. > > I didn't say no, I was trying to see if there's alternatives because the > is_locked pattern has a history of abuse. Yet you haven't suggested or commented on the proposed methods to avoid abuse - you are still arguing that it can be abused. Go back and read what I proposed before continuing to argue about mutex_is_locked().... > If not, then sure we can do this; it's not like I managed to get rid of > muteX_is_locked() -- and I actually tried at some point :/ > > And just now I grepped for it, and look what I find: > > drivers/hid/hid-nintendo.c: if (unlikely(mutex_is_locked(&ctlr->output_mutex))) { > drivers/nvdimm/btt.c: if (mutex_is_locked(&arena->err_lock) > > And there's more :-( .... like this. Seriously: if we put it behind CONFIG_DEBUG_RWSEM, and then turn that on when other subsystem debug code wants the rwsem introspection, why does anyone outside that subsystem even how it gets used? It won't even get used in production kernels, because nobody will turn something on that requires rwsem debug in a production kernel. If you are still concerned that this will happen, then do the same that we've done for trace_printk and other debug only functions: dump a big warning at boot time that rwsem debug is enabled and this is not a supported production kernel configuration. > Also, please just calm down already.. I'm perfectly calm and relaxed. Asking for a definitive decision between co-maintainers who are giving decidedly mixed signals is a very reasonable request to make. Just because you may not like what such a request implies about how the code is being maintained, it doesn't mean I'm the slightest bit upset, hysterical or irrational. -Dave. -- Dave Chinner david@xxxxxxxxxxxxx