From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-12.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, MENTIONS_GIT_HOSTING,SIGNED_OFF_BY,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A292AC282C4 for ; Mon, 4 Feb 2019 08:57:19 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 7A1D7214DA for ; Mon, 4 Feb 2019 08:57:19 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728739AbfBDI5S (ORCPT ); Mon, 4 Feb 2019 03:57:18 -0500 Received: from terminus.zytor.com ([198.137.202.136]:45813 "EHLO terminus.zytor.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726502AbfBDI5R (ORCPT ); Mon, 4 Feb 2019 03:57:17 -0500 Received: from terminus.zytor.com (localhost [127.0.0.1]) by terminus.zytor.com (8.15.2/8.15.2) with ESMTPS id x148uwtE358127 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Mon, 4 Feb 2019 00:56:58 -0800 Received: (from tipbot@localhost) by terminus.zytor.com (8.15.2/8.15.2/Submit) id x148uwfL358124; Mon, 4 Feb 2019 00:56:58 -0800 Date: Mon, 4 Feb 2019 00:56:58 -0800 X-Authentication-Warning: terminus.zytor.com: tipbot set sender to tipbot@zytor.com using -f From: tip-bot for Waiman Long Message-ID: Cc: mingo@kernel.org, linux-kernel@vger.kernel.org, peterz@infradead.org, hpa@zytor.com, paulmck@linux.vnet.ibm.com, tglx@linutronix.de, penguin-kernel@i-love.sakura.ne.jp, torvalds@linux-foundation.org, longman@redhat.com, akpm@linux-foundation.org, will.deacon@arm.com Reply-To: longman@redhat.com, akpm@linux-foundation.org, linux-kernel@vger.kernel.org, will.deacon@arm.com, peterz@infradead.org, hpa@zytor.com, paulmck@linux.vnet.ibm.com, penguin-kernel@i-love.sakura.ne.jp, tglx@linutronix.de, torvalds@linux-foundation.org, mingo@kernel.org In-Reply-To: <1547093005-26085-1-git-send-email-longman@redhat.com> References: <1547093005-26085-1-git-send-email-longman@redhat.com> To: linux-tip-commits@vger.kernel.org Subject: [tip:locking/core] locking/lockdep: Add debug_locks check in __lock_downgrade() Git-Commit-ID: 513e1073d52e55b8024b4f238a48de7587c64ccf X-Mailer: tip-git-log-daemon Robot-ID: Robot-Unsubscribe: Contact to get blacklisted from these emails MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Content-Disposition: inline Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Commit-ID: 513e1073d52e55b8024b4f238a48de7587c64ccf Gitweb: https://git.kernel.org/tip/513e1073d52e55b8024b4f238a48de7587c64ccf Author: Waiman Long AuthorDate: Wed, 9 Jan 2019 23:03:25 -0500 Committer: Ingo Molnar CommitDate: Mon, 4 Feb 2019 09:03:27 +0100 locking/lockdep: Add debug_locks check in __lock_downgrade() Tetsuo Handa had reported he saw an incorrect "downgrading a read lock" warning right after a previous lockdep warning. It is likely that the previous warning turned off lock debugging causing the lockdep to have inconsistency states leading to the lock downgrade warning. Fix that by add a check for debug_locks at the beginning of __lock_downgrade(). Reported-by: Tetsuo Handa Reported-by: syzbot+53383ae265fb161ef488@syzkaller.appspotmail.com Signed-off-by: Waiman Long Signed-off-by: Peter Zijlstra (Intel) Cc: Andrew Morton Cc: Linus Torvalds Cc: Paul E. McKenney Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: Will Deacon Link: https://lkml.kernel.org/r/1547093005-26085-1-git-send-email-longman@redhat.com Signed-off-by: Ingo Molnar --- kernel/locking/lockdep.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c index 608f74ed8bb9..7f7db23fc002 100644 --- a/kernel/locking/lockdep.c +++ b/kernel/locking/lockdep.c @@ -3479,6 +3479,9 @@ __lock_set_class(struct lockdep_map *lock, const char *name, unsigned int depth; int i; + if (unlikely(!debug_locks)) + return 0; + depth = curr->lockdep_depth; /* * This function is about (re)setting the class of a held lock,