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=-6.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable 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 A8327C4360D for ; Thu, 26 Sep 2019 02:04:50 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 7939E222C3 for ; Thu, 26 Sep 2019 02:04:50 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="NugwTEW4" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2391539AbfIZCEt (ORCPT ); Wed, 25 Sep 2019 22:04:49 -0400 Received: from mail-lj1-f193.google.com ([209.85.208.193]:44466 "EHLO mail-lj1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725768AbfIZCEt (ORCPT ); Wed, 25 Sep 2019 22:04:49 -0400 Received: by mail-lj1-f193.google.com with SMTP id m13so390986ljj.11 for ; Wed, 25 Sep 2019 19:04:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=iqIvO1/cRY3REy92QSmyBb/XxrlUuFl4iRm+RuLwMC8=; b=NugwTEW4rRZD2qAs8X3uEZ9BKyuMoKS5D5w+bks29qqIEOGaOsBREORPdjhVUoUSHS pCY5Zg4EuicvpuihX9HT7PHYEmZC2DqUaNcST/sR6rP1ZnwpB9enQycL0eMF+j8KBnDV AykipfJVrJzJruuXcGTEw+f6u1BdZpk1ya///n1PUDPUqs1XB3ut//E53xuFSyGgrm5F o+p1PLVFby++tHnOE8+sExz5w8i6tzlEmI+Mzht8sgheaKOQOu+NFM9JfKdRfzS8l4b3 66eImMyYdm0krsN9jV0ynhBYhcRldlEqLfcvHi/yfpKkeposa9FPnVT+eeQh+GNTlUzo gf8Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=iqIvO1/cRY3REy92QSmyBb/XxrlUuFl4iRm+RuLwMC8=; b=oHPSI4yGN/zww6Fkh2VQMXnCaB4rUslwbreVDdbQE8ZXediSBJ/8/sf55LveGPXGoO /59v6GudRNYd8/toTsSadg5C8ex9F3RtY9C7LvZQ7jc42qhYxHi5w6XKmiK+VulVgR0J 3ToTBrPx/6AEp1UEY83MYCdMq8hzqqW9Qve7J1LtIpY2dXcwNJ8ZVeF+TapHazfdVMSu p8n6SuOohxoFEt8NJPZB18rRGoXC9v18e4C1VPSrwtogLgXutttjHTM9VJkem3/4DCfp sapGzQq35W8MyUJwNwd4BRd++9Xmqw6cEgAwoh6e83J1IsxK74SiXNlOGn4rxz0mxqvy mltg== X-Gm-Message-State: APjAAAUi3L6ZTqvb7Haq7dzRbhmMQcKmb0Ck0BEDTBG17JV1pNoAI6nc S9mrc1ntLx7GsEkq83+a3241eTuLfIzR/TU4ZmRs3Q== X-Google-Smtp-Source: APXvYqzr4GSxqb6AjtMPnutvvMqRRvOEPmaJrXJguS0rhSU/wUbzDgKSpgPMW4V3/Z8S7tqO6sLkZPfZV/pSy3857wU= X-Received: by 2002:a2e:a0c5:: with SMTP id f5mr795667ljm.114.1569463487576; Wed, 25 Sep 2019 19:04:47 -0700 (PDT) MIME-Version: 1.0 References: <4ac2e84637ceaf5ec67cfc11ad58c489778693a8.1569405445.git.baolin.wang@linaro.org> <87e81724-9f1a-8716-5b4f-f2aac6f25c5a@redhat.com> In-Reply-To: <87e81724-9f1a-8716-5b4f-f2aac6f25c5a@redhat.com> From: Baolin Wang Date: Thu, 26 Sep 2019 10:04:35 +0800 Message-ID: Subject: Re: [BACKPORT 4.14.y v3 1/3] locking/lockdep: Add debug_locks check in __lock_downgrade() To: Waiman Long Cc: "# 3.4.x" , Peter Zijlstra , Ingo Molnar , Arnd Bergmann , Orson Zhai , Vincent Guittot , LKML Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 25 Sep 2019 at 22:05, Waiman Long wrote: > > On 9/25/19 6:01 AM, Baolin Wang wrote: > > From: Waiman Long > > > > [Upstream commit 513e1073d52e55b8024b4f238a48de7587c64ccf] > > > > 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 > > Signed-off-by: Baolin Wang > > --- > > kernel/locking/lockdep.c | 3 +++ > > 1 file changed, 3 insertions(+) > > > > diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c > > index 565005a..5c370c6 100644 > > --- a/kernel/locking/lockdep.c > > +++ b/kernel/locking/lockdep.c > > @@ -3650,6 +3650,9 @@ static int reacquire_held_locks(struct task_struct *curr, unsigned int depth, > > 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, > > Apparently, there are 2 such patches in the upstream kernel - commit > 513e1073d52e55b8024b4f238a48de7587c64ccf and > 71492580571467fb7177aade19c18ce7486267f5. These are probably caused by > the fact that there are 2 places in the code that can match the hunks. > Anyway, this looks like it is applying to the wrong function. It should > be applied to __lock_downgrade. Though it shouldn't harm if it is > applied to the wrong function. Ah, I noticed there are 2 commits with the same commit message, though 513e1073d52e55b8024b4f238a48de7587c64ccf patch did not change the __lock_downgrade(), which is really confusing. This patch (513e1073d52e55b8024b4f238a48de7587c64ccf) did the right thing, and 71492580571467fb7177aade19c18ce7486267f5 patch should be applied to __lock_downgrade. I'll backport commit 71492580571467fb7177aade19c18ce7486267f5 too in future. Thanks. -- Baolin Wang Best Regards