From: Theodore Ts'o <tytso@mit.edu>
To: Byungchul Park <byungchul.park@lge.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
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 08:03:43 -0500 [thread overview]
Message-ID: <20171212130343.6nwxip3i4ua24dwr@thunk.org> (raw)
In-Reply-To: <c4a4b7be-b3c4-ed56-21a5-d3396b8a4e25@lge.com>
On Tue, Dec 12, 2017 at 02:20:32PM +0900, Byungchul Park wrote:
>
> The *problem* is false positives, since locks and waiters in
> kernel are not classified properly, at the moment, which is just
> a fact that is not related to cross-release stuff at all. IOW,
> that would be useful once all locks and waiters are classified
> correctly. It might take time but the classifying is a must-do
> we have to keep doing.
This is the wrong attitude. The reason why LOCKDEP was so powerful
was because it automatically classified locks, instead of requiring
developers to document the locking hierarchy. Requiring developers to
have to document and classified locks --- especially when the d*mned
mechanisms for doign so are so primitive and not even documented ---
is a complete non-strarter.
So, ***NO***, WE do not have to do anything. We can just disable
Lockdep instead. You can not and must not transfer responsibility for
documenting locks to the subsystem maintainers, as if it is some sort
of bug that the locks are not "classified correctly". The fact that
your new technique requires clasification is a BUG, and goes against
the original design principle of LOCKDEP in the first place.
> I admit to make it optional for now, but I don't see why you
> want to remove it entierly.
So are you willing to take my patch? Or give me permission to keep in
the ext4 tree?
- Ted
next prev parent reply other threads:[~2017-12-12 13:03 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 [this message]
2017-12-12 15:39 ` Matthew Wilcox
2017-12-13 5:33 ` Byungchul Park
2017-12-12 17:00 ` Linus Torvalds
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=20171212130343.6nwxip3i4ua24dwr@thunk.org \
--to=tytso@mit.edu \
--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=torvalds@linux-foundation.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox