All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Matthew Wilcox <willy@infradead.org>
Cc: Ingo Molnar <mingo@redhat.com>,
	"David S. Miller" <davem@davemloft.net>,
	Matthew Wilcox <mawilcox@microsoft.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	linux-kernel@vger.kernel.org
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: <20180117151414.23686-1-willy@infradead.org>

On Wed, Jan 17, 2018 at 07:14:11AM -0800, Matthew Wilcox wrote:
> From: Matthew Wilcox <mawilcox@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) <peterz@infradead.org>

Ingo can you make that happen?

      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 [PATCH 0/3] lockdep: Allow checking a read-only lock 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 \
    --to=peterz@infradead.org \
    --cc=davem@davemloft.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mawilcox@microsoft.com \
    --cc=mingo@redhat.com \
    --cc=tglx@linutronix.de \
    --cc=willy@infradead.org \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.