[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200821174132.GR3982@worktop.programming.kicks-ass.net>
Date: Fri, 21 Aug 2020 19:41:32 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Boqun Feng <boqun.feng@...il.com>
Cc: linux-kernel@...r.kernel.org, linux-doc@...r.kernel.org,
Ingo Molnar <mingo@...hat.com>, Will Deacon <will@...nel.org>,
Jonathan Corbet <corbet@....net>,
Waiman Long <longman@...hat.com>
Subject: Re: [RFC v7 14/19] lockdep: Take read/write status in consideration
when generate chainkey
So far so good, excellent work.
On Fri, Aug 07, 2020 at 03:42:33PM +0800, Boqun Feng wrote:
> @@ -371,6 +371,21 @@ static struct hlist_head classhash_table[CLASSHASH_SIZE];
>
> static struct hlist_head chainhash_table[CHAINHASH_SIZE];
>
> +/*
> + * the id of held_lock
> + */
> +static inline u16 hlock_id(struct held_lock *hlock)
> +{
> + BUILD_BUG_ON(MAX_LOCKDEP_KEYS_BITS + 2 > 16);
> +
> + return (hlock->class_idx | (hlock->read << MAX_LOCKDEP_KEYS_BITS));
> +}
> +
> +static inline unsigned int chain_hlock_class_idx(u16 hlock_id)
> +{
> + return hlock_id & MAX_LOCKDEP_KEYS;
But did that want to be:
return hlock_id & (MAX_LOCKDEP_KEYS-1);
?
> +}
Powered by blists - more mailing lists