From: Peter Zijlstra <peterz@infradead.org>
To: Waiman Long <longman@redhat.com>
Cc: Ingo Molnar <mingo@redhat.com>, Will Deacon <will.deacon@arm.com>,
Thomas Gleixner <tglx@linutronix.de>,
linux-kernel@vger.kernel.org, kasan-dev@googlegroups.com,
linux-mm@kvack.org, Petr Mladek <pmladek@suse.com>,
Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
Andrey Ryabinin <aryabinin@virtuozzo.com>,
Tejun Heo <tj@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [RFC PATCH 01/12] locking/lockdep: Rework lockdep_set_novalidate_class()
Date: Sun, 11 Nov 2018 02:28:23 +0100 [thread overview]
Message-ID: <20181111012823.GB12766@worktop.psav.com> (raw)
In-Reply-To: <bc8ef8ae-c673-f4ae-fab1-3fe1bc884087@redhat.com>
On Sat, Nov 10, 2018 at 07:26:51PM -0500, Waiman Long wrote:
> On 11/10/2018 09:14 AM, Peter Zijlstra wrote:
> > On Thu, Nov 08, 2018 at 03:34:17PM -0500, Waiman Long wrote:
> >> The current lockdep_set_novalidate_class() implementation is like
> >> a hack. It assigns a special class key for that lock and calls
> >> lockdep_init_map() twice.
> > Ideally it would go away.. it is not thing that should be used.
>
> Yes, I agree. Right now, lockdep_set_novalidate_class() is used in
>
> drivers/base/core.c: lockdep_set_novalidate_class(&dev->mutex);
> drivers/md/bcache/btree.c: lockdep_set_novalidate_class(&b->lock);
> drivers/md/bcache/btree.c:
> lockdep_set_novalidate_class(&b->write_lock);
>
> Do you know the history behind making them novalidate?
Only of the driver/base/core.c one; there the locking order depends on
the hardware and we never quite found a way to annotate that sanely. I
forgot most details though.
The other stuff I only 'recently' found out about :-( And ideally would
have never made it into the tree, but alas.
WARNING: multiple messages have this Message-ID (diff)
From: Peter Zijlstra <peterz@infradead.org>
To: Waiman Long <longman@redhat.com>
Cc: Ingo Molnar <mingo@redhat.com>, Will Deacon <will.deacon@arm.com>,
Thomas Gleixner <tglx@linutronix.de>,
linux-kernel@vger.kernel.org, kasan-dev@googlegroups.com,
linux-mm@kvack.org, Petr Mladek <pmladek@suse.com>,
Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
Andrey Ryabinin <aryabinin@virtuozzo.com>,
Tejun Heo <tj@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [RFC PATCH 01/12] locking/lockdep: Rework lockdep_set_novalidate_class()
Date: Sun, 11 Nov 2018 02:28:23 +0100 [thread overview]
Message-ID: <20181111012823.GB12766@worktop.psav.com> (raw)
In-Reply-To: <bc8ef8ae-c673-f4ae-fab1-3fe1bc884087@redhat.com>
On Sat, Nov 10, 2018 at 07:26:51PM -0500, Waiman Long wrote:
> On 11/10/2018 09:14 AM, Peter Zijlstra wrote:
> > On Thu, Nov 08, 2018 at 03:34:17PM -0500, Waiman Long wrote:
> >> The current lockdep_set_novalidate_class() implementation is like
> >> a hack. It assigns a special class key for that lock and calls
> >> lockdep_init_map() twice.
> > Ideally it would go away.. it is not thing that should be used.
>
> Yes, I agree. Right now, lockdep_set_novalidate_class() is used in
>
> drivers/base/core.c: lockdep_set_novalidate_class(&dev->mutex);
> drivers/md/bcache/btree.c: lockdep_set_novalidate_class(&b->lock);
> drivers/md/bcache/btree.c:
> lockdep_set_novalidate_class(&b->write_lock);
>
> Do you know the history behind making them novalidate?
Only of the driver/base/core.c one; there the locking order depends on
the hardware and we never quite found a way to annotate that sanely. I
forgot most details though.
The other stuff I only 'recently' found out about :-( And ideally would
have never made it into the tree, but alas.
next prev parent reply other threads:[~2018-11-11 1:28 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-08 20:34 [RFC PATCH 00/12] locking/lockdep: Add a new class of terminal locks Waiman Long
2018-11-08 20:34 ` [RFC PATCH 01/12] locking/lockdep: Rework lockdep_set_novalidate_class() Waiman Long
2018-11-10 14:14 ` Peter Zijlstra
2018-11-11 0:26 ` Waiman Long
2018-11-11 1:28 ` Peter Zijlstra [this message]
2018-11-11 1:28 ` Peter Zijlstra
2018-11-08 20:34 ` [RFC PATCH 02/12] locking/lockdep: Add a new terminal lock type Waiman Long
2018-11-10 14:17 ` Peter Zijlstra
2018-11-11 0:28 ` Waiman Long
2018-11-08 20:34 ` [RFC PATCH 03/12] locking/lockdep: Add DEFINE_TERMINAL_SPINLOCK() and related macros Waiman Long
2018-11-08 20:34 ` [RFC PATCH 04/12] printk: Make logbuf_lock a terminal lock Waiman Long
2018-11-08 20:34 ` [RFC PATCH 05/12] debugobjects: Mark pool_lock as " Waiman Long
2018-11-08 20:34 ` [RFC PATCH 06/12] debugobjects: Move printk out of db lock critical sections Waiman Long
2018-11-08 20:34 ` [RFC PATCH 07/12] locking/lockdep: Add support for nested terminal locks Waiman Long
2018-11-10 14:20 ` Peter Zijlstra
2018-11-11 0:30 ` Waiman Long
2018-11-11 1:30 ` Peter Zijlstra
2018-11-08 20:34 ` [RFC PATCH 08/12] debugobjects: Make object hash locks " Waiman Long
2018-11-08 20:34 ` [RFC PATCH 09/12] lib/stackdepot: Make depot_lock a terminal spinlock Waiman Long
2018-11-08 20:34 ` [RFC PATCH 10/12] locking/rwsem: Mark rwsem.wait_lock as a terminal lock Waiman Long
2018-11-08 20:34 ` [RFC PATCH 11/12] cgroup: Mark the rstat percpu lock as terminal Waiman Long
2018-11-08 20:34 ` [RFC PATCH 12/12] mm/kasan: Make quarantine_lock a terminal lock Waiman Long
2018-11-09 8:04 ` [RFC PATCH 00/12] locking/lockdep: Add a new class of terminal locks Ingo Molnar
2018-11-09 15:48 ` Waiman Long
2018-11-12 5:15 ` Ingo Molnar
2018-11-10 14:10 ` Peter Zijlstra
2018-11-10 23:35 ` Waiman Long
2018-11-12 5:10 ` Ingo Molnar
2018-11-12 5:53 ` Josh Poimboeuf
2018-11-12 6:30 ` Ingo Molnar
2018-11-12 22:22 ` Josh Poimboeuf
2018-11-12 22:56 ` Waiman Long
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=20181111012823.GB12766@worktop.psav.com \
--to=peterz@infradead.org \
--cc=akpm@linux-foundation.org \
--cc=aryabinin@virtuozzo.com \
--cc=kasan-dev@googlegroups.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=longman@redhat.com \
--cc=mingo@redhat.com \
--cc=pmladek@suse.com \
--cc=sergey.senozhatsky@gmail.com \
--cc=tglx@linutronix.de \
--cc=tj@kernel.org \
--cc=will.deacon@arm.com \
/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.