On Wed, Jan 17, 2018 at 07:14:11AM -0800, Matthew Wilcox wrote: > From: Matthew Wilcox <mawil...@microsoft.com> > > I am not for one moment suggesting that the concept of a read-only lock > makes sense. You can't sensibly put one in ROM or in read-only mappings. > What does make sense is some APIs want to specify a const pointer to > indicate that they do not modify the object being pointed to. One example > we have of this today is in the networking stack; tcp_md5_do_lookup takes > a const struct sock * argument and wants to ensure that the caller either > took the socket lock or the rcu lock. > > At the moment, tcp_md5_do_lookup() is actually lying to its callers; > lockdep_sock_is_held() casts away the constness of the pointer because > lockdep actually does modify the lock when checking whether it's held > (under rare and unnecessary conditions). > > Fix this situation by (patch 1) only assigning a lock key on registration, > not on check, (patch 2) marking the pointers in the lockdep check path > as const and (patch 3) converting a few of the callers to themselves > be const, removing the nasty hack in lockdep_sock_is_held(). >
Seems OK. Acked-by: Peter Zijlstra (Intel) <pet...@infradead.org> Ingo can you make that happen?