Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp2236314yba; Thu, 25 Apr 2019 12:57:06 -0700 (PDT) X-Google-Smtp-Source: APXvYqxX7Lpld1nwMRIxUN3IWXrWMSFvwLBhr1MuIW+KxZt9vYwV5iVXQs89VASxUpZY572F6XMp X-Received: by 2002:a65:51c9:: with SMTP id i9mr39685059pgq.187.1556222226248; Thu, 25 Apr 2019 12:57:06 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1556222226; cv=none; d=google.com; s=arc-20160816; b=MyxjkwNZs1B+7Vyk2CH7y887jMVjr87LawT9XjT6zkuxf9SSKsZTPiTHPC4fKN9Ex6 jajVby/LERYgsi44AnKXrCKv3QNyAJqpLujwxAiKIM1CEfRkoBNxWMmyMsIkAQDTX2qk gTp04z0czCI74dhEv6wj+wgz4nnRz8iaR7IsLBrO1y5y1RwquuWshsOhc5WZYL+b/01s vpygrQRXPeOFJ+LmutbY1h57IokHRDBSOgY/2CXRgbz2ScyWGHj9zCAB9QbHeKBRr5eS xAud628bMJC90xfZHhifB3U3LhXxts4CxNv8Wl7J04sSKFa8DhuxHEyZhdpWK1+CdmK3 YhLw== 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; bh=VOZ0OpoJ76M1yqdpvv8yJsTY4zgs8X+CEIvxpLsiyZw=; b=o1f5dqvrgAe07TeMsYz6PISMFE5dviGUgCoHoCx+hfQ7RorvD2alIQ9AAht8/Csa7k AsbwYZqi8O/OJKUQQv1vdj6hSeS9wxFhiVDCiEjhSOkTRFfK4gRvhXj/56kAR8aCj8jv s7vRAr8MrYtJHZfMJ/D/IY6fIUY1SzqoZn1GIkrhQFSvisTpi8ajf4V30SQF3LTDmQS0 /oCtDp7lVuz8pcOyMj8GuKXGriz+PAY+MJwR0S2tpWx2jDuuUGt3iOA/7C6D+I8aoatz gwp6pc15BrV7mNT/s5wFhFcKFeffpV6rrnXVdjHwTTjcfzXOYWFMOyIf0tBUPfjQdQOP gWEQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@infradead.org header.s=bombadil.20170209 header.b=jDYZJv2M; 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 r12si22957205pgl.108.2019.04.25.12.56.51; Thu, 25 Apr 2019 12:57:06 -0700 (PDT) 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=bombadil.20170209 header.b=jDYZJv2M; 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 S2387940AbfDYTzY (ORCPT + 99 others); Thu, 25 Apr 2019 15:55:24 -0400 Received: from bombadil.infradead.org ([198.137.202.133]:44824 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2387538AbfDYTzX (ORCPT ); Thu, 25 Apr 2019 15:55:23 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.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=VOZ0OpoJ76M1yqdpvv8yJsTY4zgs8X+CEIvxpLsiyZw=; b=jDYZJv2MuyVq0uDtRxHjNnk8S NaRI/nO6b2o8Kcb6+X+ibBTCbGIIE+WXxVtVr02NBSTJv1jQeNyRRiI3Pu8iYNtn67e6sr7n4GB7t 6cgcyQaGVcToDPlhVM13g3PlgO+975scbyDlFmP7GdJP7RtSogv88yVQNwAQcXa4CWS2AJxz1x9Ir tVAQrFVz02VzxjlbnlH+1DUwAZoUZ5ELshIQ3aCK+gC3qOCetC+Gm2lKd5dFUeWSS0qo0juyv3F15 JTkNlmPZUEAjKkWShjZu1dWPNsryC0OTt7mLrtBoowNhmLik7jGGnpdbEKE6cwxbLzk4CZLNs/r2S EHis7BZAA==; Received: from j217100.upc-j.chello.nl ([24.132.217.100] helo=hirez.programming.kicks-ass.net) by bombadil.infradead.org with esmtpsa (Exim 4.90_1 #2 (Red Hat Linux)) id 1hJkSj-0003L3-5L; Thu, 25 Apr 2019 19:55:17 +0000 Received: by hirez.programming.kicks-ass.net (Postfix, from userid 1000) id 9948920288CFF; Thu, 25 Apr 2019 21:55:15 +0200 (CEST) Date: Thu, 25 Apr 2019 21:55:15 +0200 From: Peter Zijlstra To: Yuyang Du Cc: will.deacon@arm.com, mingo@kernel.org, bvanassche@acm.org, ming.lei@redhat.com, frederic@kernel.org, tglx@linutronix.de, linux-kernel@vger.kernel.org Subject: Re: [PATCH 23/28] locking/lockdep: Update irqsafe lock bitmaps Message-ID: <20190425195515.GX12232@hirez.programming.kicks-ass.net> References: <20190424101934.51535-1-duyuyang@gmail.com> <20190424101934.51535-24-duyuyang@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190424101934.51535-24-duyuyang@gmail.com> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Apr 24, 2019 at 06:19:29PM +0800, Yuyang Du wrote: > The bitmaps keep track of which locks are irqsafe. Update the bitmaps > when there is new irqsafe usage and when an irqsafe lock is zapped. > > Signed-off-by: Yuyang Du > --- > kernel/locking/lockdep.c | 39 ++++++++++++++++++++++++++++++++++++++- > 1 file changed, 38 insertions(+), 1 deletion(-) > > diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c > index 291cc9c..1b78216 100644 > --- a/kernel/locking/lockdep.c > +++ b/kernel/locking/lockdep.c > @@ -3107,6 +3107,7 @@ typedef int (*check_usage_f)(struct task_struct *, struct held_lock *, > int excl_bit = exclusive_bit(new_bit); > int read = new_bit & LOCK_USAGE_READ_MASK; > int dir = new_bit & LOCK_USAGE_DIR_MASK; > + struct lock_class *lock = hlock_class(this); > > /* > * mark USED_IN has to look forwards -- to ensure no dependency > @@ -3119,6 +3120,25 @@ typedef int (*check_usage_f)(struct task_struct *, struct held_lock *, > check_usage_backwards : check_usage_forwards; > > /* > + * The bit is already marked so that we update the bitmaps > + * before validation. > + */ > + if (!dir) { > + unsigned long *bitmaps[4] = { > + lock_classes_hardirq_safe, > + lock_classes_hardirq_safe_read, > + lock_classes_softirq_safe, > + lock_classes_softirq_safe_read That again should be something CPP magic using lockdep_states.h. Also, that array can be static const, right? It's just an index into the static bitmaps. > + }; > + int index = (new_bit >> 2) << 1; > + > + if (read) > + index += 1; > + > + __set_bit(lock - lock_classes, bitmaps[index]); > + } > + > + /* > * Validate that this particular lock does not have conflicting > * usage states. > */ > @@ -3146,7 +3166,7 @@ typedef int (*check_usage_f)(struct task_struct *, struct held_lock *, > return 0; > } > > - if (state_verbose(new_bit, hlock_class(this))) > + if (state_verbose(new_bit, lock)) > return 2; > > return 1; > @@ -4650,6 +4670,22 @@ static void remove_class_from_lock_chains(struct pending_free *pf, > } > } > > +static inline void remove_irqsafe_lock_bitmap(struct lock_class *class) > +{ > +#if defined(CONFIG_TRACE_IRQFLAGS) && defined(CONFIG_PROVE_LOCKING) > + unsigned long usage = class->usage_mask; > + > + if (usage & LOCKF_USED_IN_HARDIRQ) > + __clear_bit(class - lock_classes, lock_classes_hardirq_safe); > + if (usage & LOCKF_USED_IN_HARDIRQ_READ) > + __clear_bit(class - lock_classes, lock_classes_hardirq_safe_read); > + if (usage & LOCKF_USED_IN_SOFTIRQ) > + __clear_bit(class - lock_classes, lock_classes_softirq_safe); > + if (usage & LOCKF_USED_IN_SOFTIRQ_READ) > + __clear_bit(class - lock_classes, lock_classes_softirq_safe_read); More CPP foo required here. Also, do we really need to test, we could just unconditionally clear the bits. > +#endif > +}