Received: by 10.223.185.116 with SMTP id b49csp2202882wrg; Thu, 22 Feb 2018 09:43:17 -0800 (PST) X-Google-Smtp-Source: AH8x224wnRHNBFf2jIqDDEd0LD97eBSbtHw6Caf9p0umHLZxVBTBuuFJxCxgbEa9a9x2izhrEhlP X-Received: by 2002:a17:902:5982:: with SMTP id p2-v6mr7028519pli.289.1519321397363; Thu, 22 Feb 2018 09:43:17 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1519321397; cv=none; d=google.com; s=arc-20160816; b=Pfx2izES5w7VC1ClhVcqm1D69/rxKVFWJIxvaTu1ZFZH/J7dG6fRU/yt5qW4r+CKWv yxcC80TqCN30kTeqxOKOLUbxc4DQXy2CKtq13d/b55a0j2EELwglY7nxejD7nMZRicpu 06LtjbrBm212qcOu+yBsr/G8qzFFt3NSnIr9nT+HwFpFsUesyn4Bb3t/e5BEWdDMvc1A C1+RZqXfUDd9ItosEbot5T85KWv0MeHUM8aV8BKt95p+XAdFJHr5b0ZmxIL/DQGc8Iid 1vK8EUMuXhjRl1os7VtCnYX7HHp0vGmIy1iMMnZm0ZoseSFnkecoNwmuyQR1DYlKuVvu rG8w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature:arc-authentication-results; bh=gRcQZaU32I6KJcM0XhzsqiLQc4M9B76laFTBKM4zC8E=; b=HZB9px5lgQaBSq5dJtyetfKIHSgODWo+YZaivdPEGpvD1ECoVd8PlauUW5XE3jdgzx bzv2m9VwH/Bc+2UKnmXHMVkYyNeQbnigotWJpH7N2x/2GTfjWagm/dRQ+3jixUT+9jGr WdZXT0VZ7Ram6hEXNYlKiVcNIny+DQ4mX05CNbn12MRLn4OqZM0GqxFwK99LAu0bnJoB tqRBJlgSa2qGpq20nt4uw15WPFzaeo3q3qeE+s62KKdy6nUldZZIKKkv9t50F6SYyNqD o0zQs+pcmKwC8CGE7iX8+KoAO8Hr0CmLkVP0peQlbKRfvOjqdCDP4R93NDsXRf+4haKc zNZg== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@infradead.org header.s=merlin.20170209 header.b=svrOSMf4; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id t6-v6si374393plj.126.2018.02.22.09.43.03; Thu, 22 Feb 2018 09:43:17 -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=fail header.i=@infradead.org header.s=merlin.20170209 header.b=svrOSMf4; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933584AbeBVRl6 (ORCPT + 99 others); Thu, 22 Feb 2018 12:41:58 -0500 Received: from merlin.infradead.org ([205.233.59.134]:55770 "EHLO merlin.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933427AbeBVRl5 (ORCPT ); Thu, 22 Feb 2018 12:41:57 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=merlin.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=gRcQZaU32I6KJcM0XhzsqiLQc4M9B76laFTBKM4zC8E=; b=svrOSMf4rJfcq5ZK4r1dU1XJ2 7QR4nQzTFttBGFg1Ry2eCGxej7Zbh1u50eIpxK2ekktuEfldMBY3vop+UW/ncDSFu9nCVFEPzcCOq j9QU5ZgiBEo9D0h1aPHVqa/hWUewB66Q49g1aGvRFdQWmk/mLcgdEx71kfP8XIOm84s9eeMWAOpYQ Hmb/tZsnzgLYg9GzTiCKGs+Mt/hKxJsYf9I8FYSzaKbfBTituoM6tLbohSkgx/OE35u648fwZPFkP 2iFUcWDO233cRqQbf8g+x1x80CRBD+A/9x4Y8JQp0GoYZ+xJnYA1nFzW8nem/TD9VSYMenLAnG7vK U4SiPStPA==; Received: from j217100.upc-j.chello.nl ([24.132.217.100] helo=hirez.programming.kicks-ass.net) by merlin.infradead.org with esmtpsa (Exim 4.89 #1 (Red Hat Linux)) id 1eousU-0007xe-V3; Thu, 22 Feb 2018 17:41:55 +0000 Received: by hirez.programming.kicks-ass.net (Postfix, from userid 1000) id 6DD66202A062D; Thu, 22 Feb 2018 18:41:53 +0100 (CET) Date: Thu, 22 Feb 2018 18:41:53 +0100 From: Peter Zijlstra To: Boqun Feng Cc: linux-kernel@vger.kernel.org, Ingo Molnar , Andrea Parri Subject: Re: [RFC tip/locking/lockdep v5 08/17] lockdep: Fix recursive read lock related safe->unsafe detection Message-ID: <20180222174153.GV25201@hirez.programming.kicks-ass.net> References: <20180222070904.548-1-boqun.feng@gmail.com> <20180222070904.548-9-boqun.feng@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180222070904.548-9-boqun.feng@gmail.com> User-Agent: Mutt/1.9.2 (2017-12-15) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Feb 22, 2018 at 03:08:55PM +0800, Boqun Feng wrote: > There are four cases for recursive read lock realted deadlocks: > > (--(X..Y)--> means a strong dependency path starts with a --(X*)--> > dependency and ends with a --(*Y)-- dependency.) > > 1. An irq-safe lock L1 has a dependency --(*..*)--> to an > irq-unsafe lock L2. > > 2. An irq-read-safe lock L1 has a dependency --(N..*)--> to an > irq-unsafe lock L2. > > 3. An irq-safe lock L1 has a dependency --(*..N)--> to an > irq-read-unsafe lock L2. > > 4. An irq-read-safe lock L1 has a dependency --(N..N)--> to an > irq-read-unsafe lock L2. > > The current check_usage() only checks 1) and 2), so this patch adds > checks for 3) and 4) and makes sure when find_usage_{back,for}wards find > an irq-read-{,un}safe lock, the traverse path should ends at a > dependency --(*N)-->. Note when we search backwards, --(*N)--> indicates > a real dependency --(N*)-->. > > Signed-off-by: Boqun Feng > --- > kernel/locking/lockdep.c | 17 ++++++++++++++++- > 1 file changed, 16 insertions(+), 1 deletion(-) > > diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c > index 0b0ad3db78b4..bd3eef664f9d 100644 > --- a/kernel/locking/lockdep.c > +++ b/kernel/locking/lockdep.c > @@ -1504,7 +1504,14 @@ check_redundant(struct lock_list *root, struct held_lock *target, > > static inline int usage_match(struct lock_list *entry, void *bit) > { > - return entry->class->usage_mask & (1 << (enum lock_usage_bit)bit); > + enum lock_usage_bit ub = (enum lock_usage_bit)bit; > + > + > + if (ub & 1) > + return entry->class->usage_mask & (1 << ub) && > + !entry->is_rr; > + else > + return entry->class->usage_mask & (1 << ub); > } The whole is_rr/have_xr thing and backwards hurts my brain. That really wants more than a little 'Note'. Also, the above is unreadable, something like: unsigned long usage_mask = entry->class->usage_mask; enum lock_usage_bit ub = (enum lock_usage_bit)bit; unsigned long mask = 1ULL << ub; if (ub & 1) /* __STATE_RR */ return !entry->have_xr && (usage_mask & mask); return !!(usage_mask & mask); maybe. Also, perhaps we should make __bfs(.match) have a bool return value.