Received: by 10.223.185.116 with SMTP id b49csp1596832wrg; Wed, 21 Feb 2018 23:11:58 -0800 (PST) X-Google-Smtp-Source: AH8x225oZiNh8m7QUPPCMx78TfKopku+KGAv8UuqfB26LDvoQUOBRobFPFF5XvTPnWZQ/ozhTLw6 X-Received: by 10.99.116.25 with SMTP id p25mr4908059pgc.109.1519283518047; Wed, 21 Feb 2018 23:11:58 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1519283517; cv=none; d=google.com; s=arc-20160816; b=Mbw/WtK50hVGGc5b8upKwkKfS1OEKBlPLii+V+qCsylmoT/9FtLjV7LLWldMwAqQ0o YaD8mjZ3KRVhNd4CzNEHG3SZVWFRoj8B+XzdZLVcCIOflen1KKEiNwvDuQt/fuV02Yh5 aB93Q9e/Q/6P9rFz5rikGSDciPg457awBRlhANmiubOnwAaSja0ZFyXTiU/38xCYSOw3 j8V20AnIoR9zU64wSN0IOThmnQoJ8UrtG8SDX2LtNWwpHthspnOwf8sBbzcRaRJtW85w q1qgX8rizYiuXELpTubLxx6QB7b2o71tHx++z/aNMz/M9S+ZGMr1iXD3fCMVAbod45ZW /55Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:references:in-reply-to:message-id:date :subject:cc:to:from:dkim-signature:arc-authentication-results; bh=Zyahf+OH8rXXWTwxuPaGrU683yZE9bhVyh2lUVqgn7c=; b=vYCwieC/m2rzRyRY8B0Erw8OB5obyfIAPdeP4bqrSgXZ+C5ZQsIDWllwQJtoO2XCzR uXqFwF2E211dDtNAgkSg/skcTmR9YakQx7skgZ12bRgH9kmnU1kc8u4fjvWiLIOD34y+ iZHx75ewBygUvYK4feSsHIGjgLf5wgcQcwu3op3xLnQoXQbgmGZ2MAu+0ah8M42nB5F9 eih0S6cslDtvrXRav4IzvaYWeQilMbMA0k3zWCxZNy85EGK4ixEV5KZRQPPy8hfD8mEG ef7sWQCvgYdh7nR8EnUgQ6Ep5h7GVSUiPYJNNzLiKLVw7MZoLaOb3LGosF0n1J0ZGgy0 PYNw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=i9ALL94v; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id z11-v6si10466169plo.811.2018.02.21.23.11.43; Wed, 21 Feb 2018 23:11:57 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=i9ALL94v; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752754AbeBVHJo (ORCPT + 99 others); Thu, 22 Feb 2018 02:09:44 -0500 Received: from mail-wm0-f68.google.com ([74.125.82.68]:54995 "EHLO mail-wm0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751454AbeBVHF6 (ORCPT ); Thu, 22 Feb 2018 02:05:58 -0500 Received: by mail-wm0-f68.google.com with SMTP id z81so1822712wmb.4 for ; Wed, 21 Feb 2018 23:05:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=Zyahf+OH8rXXWTwxuPaGrU683yZE9bhVyh2lUVqgn7c=; b=i9ALL94vyaWJnlRt5h8P7nsarhljgB7QjuBRL48YV1tRNaMBC0GCxE7Id6rXa/DQrz P4H/4fy6CqYWDhZHMdYEwVYHw81Uhn3AiFndL8GL3mK7Zj9vvuUk4QXo2mvj79f/nM/f 2bmt3eGHqovJcASITOeBztMNjzG9BkIZLr/xUArad++d1cOWBggP5JTZzPGHqmq5utFA Mi7TNNnbF7xOR+e4PUzNGTGHd6dqY0V0148TbaPGj3gpfsEBkE4uEwYZ4uzHXa6WoCmU JuztQxVPgFZZEls11SuPkzA4in+lcfXrvaRfnKwLmFEjDdgzbx9nA1EAXyuc1xHTyKnK SP2A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references; bh=Zyahf+OH8rXXWTwxuPaGrU683yZE9bhVyh2lUVqgn7c=; b=A55Q85Y9PxjTAGNj64LlO6uPu2xkBsgZiv37YcdRpn3EleuI7cnepbpLqtQY3TfI8G sr471WOngQXHdQp1BouNm4ALamBDUxYBLPidXcmvo4JVm0yXxz4gqSo1BJaQkvtl1UOm k7coCtHuavRDXN5KiE/hXbtsQWfjjmpOvnn9KxBcRERYayj11pbuOutNX42UFCKRL9k3 1kC+XJwB+UMRqBai/0Ff15ji7bnbsAJhXeQetRdwLyQiK5lBeIkRyCXc/rXb0lumWo+H dCa4T3vfw6mw8TvoPhRUedkPF1EGXFTDIouLynVLxqNDXmQerRM514jW9hdRuNqB0lah DNfw== X-Gm-Message-State: APf1xPACedSSamAgdaIwWQ5gSTxEgtQEgJZvaeqJHEL6JFo1b5JM/cq2 4k1sNqhUXMIW6ZyA9H1dwh3183uy X-Received: by 10.80.183.214 with SMTP id i22mr8055328ede.15.1519283156777; Wed, 21 Feb 2018 23:05:56 -0800 (PST) Received: from auth1-smtp.messagingengine.com (auth1-smtp.messagingengine.com. [66.111.4.227]) by smtp.gmail.com with ESMTPSA id a14sm18411934edn.93.2018.02.21.23.05.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 21 Feb 2018 23:05:55 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailauth.nyi.internal (Postfix) with ESMTP id 2DE9720784; Thu, 22 Feb 2018 02:05:54 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute7.internal (MEProxy); Thu, 22 Feb 2018 02:05:54 -0500 X-ME-Sender: Received: from localhost (unknown [45.32.128.109]) by mail.messagingengine.com (Postfix) with ESMTPA id 953402463E; Thu, 22 Feb 2018 02:05:53 -0500 (EST) From: Boqun Feng To: linux-kernel@vger.kernel.org Cc: Peter Zijlstra , Ingo Molnar , Andrea Parri , Boqun Feng Subject: [RFC tip/locking/lockdep v5 02/17] lockdep: Make __bfs() visit every dependency until a match Date: Thu, 22 Feb 2018 15:08:49 +0800 Message-Id: <20180222070904.548-3-boqun.feng@gmail.com> X-Mailer: git-send-email 2.16.1 In-Reply-To: <20180222070904.548-1-boqun.feng@gmail.com> References: <20180222070904.548-1-boqun.feng@gmail.com> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Currently, __bfs() will do a breadth-first search in the dependency graph and visit each lock class in the graph exactly once, so for example, in the following graph: A ---------> B | ^ | | +----------> C a __bfs() call starts at A, will visit B through dependency A -> B and visit C through dependency A -> C and that's it, IOW, __bfs() will not visit dependency C -> B. This is OK for now, as we only have strong dependencies in the dependency graph, so whenever there is a traverse path from A to B in __bfs(), it means A has strong dependency to B(IOW, B depends on A strongly). So no need to visit all dependencies in the graph. However, as we are going to add recursive-read lock into the dependency graph, afterwards, not all the paths mean strong dependencies, in the same example above, dependency A -> B may be a weak dependency and traverse A -> C -> B may be a strong dependency path. And with the old way of __bfs()(i.e. visiting every lock class exactly once), we will miss the strong dependency path, which will result into failing to find a deadlock. To cure this for the future, we need to find a way for __bfs() to visit each dependency, rather than each class, exactly once in the search until we find a match. The solution is simple: We used to mark lock_class::lockdep_dependency_gen_id to indicate a class has been visited in __bfs(), now we change the semantics a little bit: we now mark lock_class::lockdep_dependency_gen_id to indicate _all the dependencies_ in its lock_{after,before} have been visited in the __bfs()(note we only take one direction in a __bfs() search). In this way, every dependency is guaranteed to be visited until we find a match. Signed-off-by: Boqun Feng --- kernel/locking/lockdep.c | 61 +++++++++++++++++++++++++++--------------------- 1 file changed, 34 insertions(+), 27 deletions(-) diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c index 9b2e318bcc81..c80f8276ceaa 100644 --- a/kernel/locking/lockdep.c +++ b/kernel/locking/lockdep.c @@ -948,24 +948,20 @@ static inline unsigned int __cq_get_elem_count(struct circular_queue *cq) return (cq->rear - cq->front) & CQ_MASK; } -static inline void mark_lock_accessed(struct lock_list *lock, - struct lock_list *parent) +static inline void mark_lock_list_accessed(struct lock_class *class) { - unsigned long nr; + class->dep_gen_id = lockdep_dependency_gen_id; +} - nr = lock - list_entries; - WARN_ON(nr >= nr_list_entries); /* Out-of-bounds, input fail */ +static inline void visit_lock_entry(struct lock_list *lock, + struct lock_list *parent) +{ lock->parent = parent; - lock->class->dep_gen_id = lockdep_dependency_gen_id; } -static inline unsigned long lock_accessed(struct lock_list *lock) +static inline unsigned long lock_list_accessed(struct lock_class *class) { - unsigned long nr; - - nr = lock - list_entries; - WARN_ON(nr >= nr_list_entries); /* Out-of-bounds, input fail */ - return lock->class->dep_gen_id == lockdep_dependency_gen_id; + return class->dep_gen_id == lockdep_dependency_gen_id; } static inline struct lock_list *get_lock_parent(struct lock_list *child) @@ -1054,6 +1050,18 @@ static enum bfs_result __bfs(struct lock_list *source_entry, goto exit; } + /* + * If we have visited all the dependencies from this @lock to + * others(iow, if we have visited all lock_list entries in + * @lock->class->locks_{after,before}, we skip, otherwise go + * and visit all the dependencies in the list and mark this + * list accessed. + */ + if (lock_list_accessed(lock->class)) + continue; + else + mark_lock_list_accessed(lock->class); + if (forward) head = &lock->class->locks_after; else @@ -1062,23 +1070,22 @@ static enum bfs_result __bfs(struct lock_list *source_entry, DEBUG_LOCKS_WARN_ON(!irqs_disabled()); list_for_each_entry_rcu(entry, head, entry) { - if (!lock_accessed(entry)) { - unsigned int cq_depth; - mark_lock_accessed(entry, lock); - if (match(entry, data)) { - *target_entry = entry; - ret = BFS_RMATCH; - goto exit; - } + unsigned int cq_depth; - if (__cq_enqueue(cq, (unsigned long)entry)) { - ret = BFS_EQUEUEFULL; - goto exit; - } - cq_depth = __cq_get_elem_count(cq); - if (max_bfs_queue_depth < cq_depth) - max_bfs_queue_depth = cq_depth; + visit_lock_entry(entry, lock); + if (match(entry, data)) { + *target_entry = entry; + ret = BFS_RMATCH; + goto exit; + } + + if (__cq_enqueue(cq, (unsigned long)entry)) { + ret = BFS_EQUEUEFULL; + goto exit; } + cq_depth = __cq_get_elem_count(cq); + if (max_bfs_queue_depth < cq_depth) + max_bfs_queue_depth = cq_depth; } } exit: -- 2.16.1