From: Peter Zijlstra <email@example.com> To: Matthew Wilcox <firstname.lastname@example.org> Cc: Ingo Molnar <email@example.com>, "David S. Miller" <firstname.lastname@example.org>, Matthew Wilcox <email@example.com>, Thomas Gleixner <firstname.lastname@example.org>, email@example.com Subject: Re: [PATCH 0/3] lockdep: Allow checking a read-only lock Date: Wed, 17 Jan 2018 17:33:10 +0100 [thread overview] Message-ID: <20180117163310.GB2249@hirez.programming.kicks-ass.net> (raw) In-Reply-To: <firstname.lastname@example.org> On Wed, Jan 17, 2018 at 07:14:11AM -0800, Matthew Wilcox wrote: > From: Matthew Wilcox <email@example.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) <firstname.lastname@example.org> Ingo can you make that happen?
prev parent reply other threads:[~2018-01-17 16:33 UTC|newest] Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-01-17 15:14 Matthew Wilcox 2018-01-17 15:14 ` [PATCH 1/3] lockdep: Assign lock keys on registration Matthew Wilcox 2018-01-18 11:00 ` [tip:locking/core] " tip-bot for Matthew Wilcox 2018-01-17 15:14 ` [PATCH 2/3] lockdep: Make lockdep checking constant Matthew Wilcox 2018-01-18 11:01 ` [tip:locking/core] " tip-bot for Matthew Wilcox 2018-01-17 15:14 ` [PATCH 3/3] lockdep: Convert some users to const Matthew Wilcox 2018-01-18 11:01 ` [tip:locking/core] " tip-bot for Matthew Wilcox 2018-01-17 16:33 ` Peter Zijlstra [this message]
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20180117163310.GB2249@hirez.programming.kicks-ass.net \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --subject='Re: [PATCH 0/3] lockdep: Allow checking a read-only lock' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.