linux-kernel - Re: [PATCH v5 01/13] lockdep: Refactor lookup_chain

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20170119091627.GG15084@tardis.cn.ibm.com>
Date:   Thu, 19 Jan 2017 17:16:27 +0800
From:   Boqun Feng <boqun.feng@...il.com>
To:     Byungchul Park <byungchul.park@....com>
Cc:     peterz@...radead.org, mingo@...nel.org, tglx@...utronix.de,
        walken@...gle.com, kirill@...temov.name,
        linux-kernel@...r.kernel.org, linux-mm@...ck.org,
        iamjoonsoo.kim@....com, akpm@...ux-foundation.org,
        npiggin@...il.com
Subject: Re: [PATCH v5 01/13] lockdep: Refactor lookup_chain_cache()

On Wed, Jan 18, 2017 at 10:17:27PM +0900, Byungchul Park wrote:
> Currently, lookup_chain_cache() provides both 'lookup' and 'add'
> functionalities in a function. However, each is useful. So this
> patch makes lookup_chain_cache() only do 'lookup' functionality and
> makes add_chain_cahce() only do 'add' functionality. And it's more
> readable than before.
> 
> Signed-off-by: Byungchul Park <byungchul.park@....com>
> ---
>  kernel/locking/lockdep.c | 129 +++++++++++++++++++++++++++++------------------
>  1 file changed, 81 insertions(+), 48 deletions(-)
> 
> diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c
> index 4d7ffc0..f37156f 100644
> --- a/kernel/locking/lockdep.c
> +++ b/kernel/locking/lockdep.c
> @@ -2109,15 +2109,9 @@ static int check_no_collision(struct task_struct *curr,
>  	return 1;
>  }
>  
> -/*
> - * Look up a dependency chain. If the key is not present yet then
> - * add it and return 1 - in this case the new dependency chain is
> - * validated. If the key is already hashed, return 0.
> - * (On return with 1 graph_lock is held.)
> - */

I think you'd better put some comments here for the behavior of
add_chain_cache(), something like:

/*
 * Add a dependency chain into chain hashtable.
 * 
 * Must be called with graph_lock held.
 * Return 0 if fail to add the chain, and graph_lock is released.
 * Return 1 with graph_lock held if succeed.
 */

Regards,
Boqun

> -static inline int lookup_chain_cache(struct task_struct *curr,
> -				     struct held_lock *hlock,
> -				     u64 chain_key)
> +static inline int add_chain_cache(struct task_struct *curr,
> +				  struct held_lock *hlock,
> +				  u64 chain_key)
>  {
>  	struct lock_class *class = hlock_class(hlock);
>  	struct hlist_head *hash_head = chainhashentry(chain_key);
> @@ -2125,49 +2119,18 @@ static inline int lookup_chain_cache(struct task_struct *curr,
>  	int i, j;
>  
>  	/*
> +	 * Allocate a new chain entry from the static array, and add
> +	 * it to the hash:
> +	 */
> +
> +	/*
>  	 * We might need to take the graph lock, ensure we've got IRQs
>  	 * disabled to make this an IRQ-safe lock.. for recursion reasons
>  	 * lockdep won't complain about its own locking errors.
>  	 */
>  	if (DEBUG_LOCKS_WARN_ON(!irqs_disabled()))
>  		return 0;
[...]

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)