On Mon, Dec 03, 2018 at 09:07:00AM -0800, Bart Van Assche wrote:
> How about adding this as an additional patch before patch 25/27?
Excellent, thanks!
> diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c
> index 9a7cca6dc3d4..ce05b9b419f4 100644
> --- a/kernel/locking/lockdep.c
> ++
On Thu, 2018-11-29 at 11:10 +0100, Peter Zijlstra wrote:
> On Wed, Nov 28, 2018 at 03:43:23PM -0800, Bart Van Assche wrote:
> > +/* hash_entry is used to keep track of dynamically allocated keys. */
> > struct lock_class_key {
> > + struct hlist_node hash_entry;
> > struct lock
On Thu, 2018-11-29 at 13:04 +0100, Peter Zijlstra wrote:
> On Wed, Nov 28, 2018 at 03:43:23PM -0800, Bart Van Assche wrote:
> > A shortcoming of the current lockdep implementation is that it requires
> > lock keys to be allocated statically. That forces certain lock objects
> > to share lock keys.
On Wed, Nov 28, 2018 at 03:43:23PM -0800, Bart Van Assche wrote:
> A shortcoming of the current lockdep implementation is that it requires
> lock keys to be allocated statically. That forces certain lock objects
> to share lock keys. Since lock dependency analysis groups lock objects
> per key shar
On Wed, Nov 28, 2018 at 03:43:23PM -0800, Bart Van Assche wrote:
> +/* hash_entry is used to keep track of dynamically allocated keys. */
> struct lock_class_key {
> + struct hlist_node hash_entry;
> struct lockdep_subclass_key subkeys[MAX_LOCKDEP_SUBCLASSES];
> };
On
A shortcoming of the current lockdep implementation is that it requires
lock keys to be allocated statically. That forces certain lock objects
to share lock keys. Since lock dependency analysis groups lock objects
per key sharing lock keys can cause false positive lockdep reports.
Make it possible
6 matches
Mail list logo
