melver wrote: In https://lore.kernel.org/all/CANpmjNPquO=W1JAh1FNQb8pMQjgeZAKCPQUAd7qUg=5pjJ6x=q...@mail.gmail.com/ I wrote:
> 1. Re-entrant acquires: rcu_read_lock(), preempt_disable(), etc. are > all re-entrant locks. My proposal is to introduce an attribute that > can be added to "ACQUIRE(..)" annotated functions to indicate they are > re-entrant. Release-count needs to then match acquire-count to fully > release a capability. But thinking about this more, this is unnecessarily complex and introduces other headaches in the analysis. The simpler option is to just declare the whole capability/lock as reentrant, as done in this PR. My conclusion is that the more complex version would be a case of YAGNI, and in the odd cases where it might need to be more fine-grained, marking the whole capability as reentrant will be traded off against potential false negatives. For user space locking primitives I've never seen this kind of mixed interface -- only in the kernel I could imaging this to be something we could cook up, but I'm happy to take the false negatives for having a simpler-to-use and saner feature in Clang. https://github.com/llvm/llvm-project/pull/137133 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
