From: Linus Torvalds <torvalds@linux-foundation.org>
To: Byungchul Park <byungchul.park@lge.com>
Cc: "Theodore Ts'o" <tytso@mit.edu>,
Peter Zijlstra <peterz@infradead.org>,
Thomas Gleixner <tglx@linutronix.de>,
kernel-team@lge.com, linux-block <linux-block@vger.kernel.org>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
Oleg Nesterov <oleg@redhat.com>, Tejun Heo <tj@kernel.org>
Subject: Re: [PATCH] locking/lockdep: Add CONFIG_LOCKDEP_AGGRESSIVE
Date: Tue, 12 Dec 2017 09:00:56 -0800 [thread overview]
Message-ID: <CA+55aFw3kiLObrtMTTiJBJW44gWV=cc=-rZs46XyuLjaTvxcHg@mail.gmail.com> (raw)
In-Reply-To: <c4a4b7be-b3c4-ed56-21a5-d3396b8a4e25@lge.com>
On Mon, Dec 11, 2017 at 9:20 PM, Byungchul Park <byungchul.park@lge.com> wrote:
>
> The *problem* is false positives, since locks and waiters in
> kernel are not classified properly
So the problem is that those false positives apparently end up being a
big deal for the filesystem people.
I personally don't think the code itself has to be removed, but I do
think that it should never have been added on as part of the generic
lock proving, and should always have been a separate config option.
I also feel that you dismiss "false positives" much too easily. A
false positive is a big problem - because it makes people ignore the
real cases (or just disable the functionality entirely).
It's why I am very quick to disable compiler warnings that have false
positives, for example. Just a couple of "harmless" false positive
warnings will poison the real warnings for people because they'll get
used to seeing warnings while building, and no longer actually look at
them.
Linus
next prev parent reply other threads:[~2017-12-12 17:00 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-11 3:50 [PATCH] locking/lockdep: Add CONFIG_LOCKDEP_AGGRESSIVE Theodore Ts'o
2017-12-11 3:57 ` Theodore Ts'o
2017-12-11 21:06 ` Linus Torvalds
2017-12-12 1:56 ` Theodore Ts'o
2017-12-12 5:20 ` Byungchul Park
2017-12-12 13:03 ` Theodore Ts'o
2017-12-12 15:39 ` Matthew Wilcox
2017-12-13 5:33 ` Byungchul Park
2017-12-12 17:00 ` Linus Torvalds [this message]
2017-12-13 5:38 ` Byungchul Park
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='CA+55aFw3kiLObrtMTTiJBJW44gWV=cc=-rZs46XyuLjaTvxcHg@mail.gmail.com' \
--to=torvalds@linux-foundation.org \
--cc=byungchul.park@lge.com \
--cc=kernel-team@lge.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=oleg@redhat.com \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
--cc=tj@kernel.org \
--cc=tytso@mit.edu \
/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).