linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Matthew Wilcox <willy@infradead.org>
To: Bart Van Assche <Bart.VanAssche@wdc.com>
Cc: "tglx@linutronix.de" <tglx@linutronix.de>,
	"mingo@kernel.org" <mingo@kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"peterz@infradead.org" <peterz@infradead.org>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	"byungchul.park@lge.com" <byungchul.park@lge.com>,
	"kernel-team@lge.com" <kernel-team@lge.com>
Subject: Re: [PATCH v2 2/3] lockdep: Remove BROKEN flag of LOCKDEP_CROSSRELEASE
Date: Thu, 19 Oct 2017 13:33:13 -0700	[thread overview]
Message-ID: <20171019203313.GA10538@bombadil.infradead.org> (raw)
In-Reply-To: <1508444515.2429.55.camel@wdc.com>

On Thu, Oct 19, 2017 at 08:21:56PM +0000, Bart Van Assche wrote:
> In case it wouldn't be clear, your work and the work of others on lockdep
> and preempt-rt is highly appreciated. Sorry that I missed the discussion
> about the cross-release functionality when it went upstream. I have several
> questions about that functionality:
> * How many lock inversion problems have been found so far thanks to the
>   cross-release checking? How many false positives have the cross-release
>   checks triggered so far? Does the number of real issues that has been
>   found outweigh the effort spent on suppressing false positives?
> * What alternatives have been considered other than enabling cross-release
>   checking for all locking objects that support releasing from the context
>   of another task than the context from which the lock was obtained? Has it
>   e.g. been considered to introduce two versions of the lock objects that
>   support cross-releases - one version for which lock inversion checking is
>   always enabled and another version for which lock inversion checking is
>   always disabled?
> * How much review has the Documentation/locking/crossrelease.txt received
>   before it went upstream? At least to me that document seems much harder
>   to read than other kernel documentation due to weird use of the English
>   grammar.

While interesting, I think this list of questions misses an important one:

 * How many bugs is this going to catch in the future?

For example, the page lock is not annotatable with lockdep -- we return
to userspace with it held, for heaven's sake!  So it is quite easy for
someone not familiar with the MM locking hierarchy to inadvertently
introduce an ABBA deadlock against the page lock.  (ie me.  I did that.)
Right now, that has to be caught by a human reviewer; if cross-release
checking can catch that, then it's worth having.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2017-10-19 20:33 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-19  5:55 [PATCH v2 0/3] crossrelease: make it not unwind by default Byungchul Park
2017-10-19  5:55 ` [PATCH v2 1/3] lockdep: Introduce CROSSRELEASE_STACK_TRACE and make it not unwind as default Byungchul Park
2017-10-19  5:55 ` [PATCH v2 2/3] lockdep: Remove BROKEN flag of LOCKDEP_CROSSRELEASE Byungchul Park
2017-10-19 15:05   ` Bart Van Assche
2017-10-19 15:34     ` Thomas Gleixner
2017-10-19 15:47       ` Bart Van Assche
2017-10-19 19:04         ` Thomas Gleixner
2017-10-19 19:12           ` Thomas Gleixner
2017-10-19 20:21             ` Bart Van Assche
2017-10-19 20:33               ` Matthew Wilcox [this message]
2017-10-19 20:41                 ` Bart Van Assche
2017-10-19 20:53                   ` Thomas Gleixner
2017-10-19 20:49               ` Thomas Gleixner
2017-10-20  7:30                 ` Ingo Molnar
2017-10-20  6:03               ` Byungchul Park
2017-10-19  5:55 ` [PATCH v2 3/3] lockdep: Add a kernel parameter, crossrelease_fullstack Byungchul Park
2017-10-19  7:03 ` [PATCH v2 0/4] Fix false positives by cross-release feature Byungchul Park
2017-10-19  7:03   ` [PATCH v2 1/4] completion: Add support for initializing completion with lockdep_map Byungchul Park
2017-10-19  7:03   ` [PATCH v2 2/4] lockdep: Remove unnecessary acquisitions wrt workqueue flush Byungchul Park
2017-10-19  7:03   ` [PATCH v2 3/4] genhd.h: Remove trailing white space Byungchul Park
2017-10-19  7:03   ` [PATCH v2 4/4] lockdep: Assign a lock_class per gendisk used for wait_for_completion() Byungchul Park
2017-10-20 14:44     ` Christoph Hellwig
2017-10-22 23:53       ` Byungchul Park
2017-10-23  6:36         ` Christoph Hellwig
2017-10-23  7:04           ` Byungchul Park
2017-10-21 19:17     ` kbuild test robot

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=20171019203313.GA10538@bombadil.infradead.org \
    --to=willy@infradead.org \
    --cc=Bart.VanAssche@wdc.com \
    --cc=byungchul.park@lge.com \
    --cc=kernel-team@lge.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mingo@kernel.org \
    --cc=peterz@infradead.org \
    --cc=tglx@linutronix.de \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).