Received: by 2002:a25:824b:0:0:0:0:0 with SMTP id d11csp6990579ybn; Mon, 30 Sep 2019 07:03:54 -0700 (PDT) X-Google-Smtp-Source: APXvYqzanT6i5h/qX3qccq3M9LIraKk273u6YBvTEGGAf4IKPdQOBI8lESSnESYv6E37iBqxjl0n X-Received: by 2002:a1c:9a46:: with SMTP id c67mr17368595wme.115.1569852234695; Mon, 30 Sep 2019 07:03:54 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1569852234; cv=none; d=google.com; s=arc-20160816; b=W8NdsEobZkdr0T0bqFuGLLBzsqgnSFF3as3m+A/hudx6qPQWEp9LUPCivhh32C6xH4 FTcEpUCGiAPJma/vDUkkhvg1Nt/nNsf+MAwtOk6oCX2mYG1isqGqxgkyAgPfFupJo3Zq J+nMyP8jSVNniSco0pLh6HyNJlgWkGklv1gKZCRN1LH7AB2ULEmCxG5EPJsveuGy3PHW Q9N0gLepj2Td3uSxj1XchyEIC6yGFq9aQIR8lWYJ8OTNT7QzB8innCjNCIPeetQYnsmt 9fd34iRSKsUfum/z5MqpS3dH6KTV3W3YwgHbVoWcvHVhzu5+HroDrg5W+P589KQOvcDk qNGA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-language :content-transfer-encoding:in-reply-to:mime-version:user-agent:date :message-id:organization:from:references:cc:to:subject; bh=wyl26C7uv9q6Iwrm522708jkIbfA0vde6CU89WXD2CU=; b=l8ZRxD2QV0dtoPnBqCVuydQ0GLYgoXdPxhm+xTJzCmJRrjBudW71VwLnZZoKD4ctvP Vb3a0PP6vw1RMTm10/yccCm2kBjZvpiVeZ3A0+8Xd3sea7Nu5ni22VVCS9uO8p0riX3J gjdehf0+HmUkvanjYIxxUlZ7d9exCRnEnlBxYTeA5Bo6HhamJuNJH7OW9b8tBF8jnJyA 5bv+UowZbNIfmIhxO8lqp2HG3VLvKTWpeYk8mDiuPcTLG4lYiofzhCTmeckCLDceYZnt uJyi/dGSlDbVtaHJkR6aRL837+yaxJnnonbWq1LS16T5g9CndDVciIRv9ngHvlEDH0lE yObg== ARC-Authentication-Results: i=1; mx.google.com; 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=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id h2si7033410edb.346.2019.09.30.07.03.28; Mon, 30 Sep 2019 07:03:54 -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; 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=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731318AbfI3OAi (ORCPT + 99 others); Mon, 30 Sep 2019 10:00:38 -0400 Received: from mx1.redhat.com ([209.132.183.28]:48778 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726314AbfI3OAi (ORCPT ); Mon, 30 Sep 2019 10:00:38 -0400 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 8122C3086262; Mon, 30 Sep 2019 14:00:37 +0000 (UTC) Received: from llong.remote.csb (ovpn-122-104.rdu2.redhat.com [10.10.122.104]) by smtp.corp.redhat.com (Postfix) with ESMTP id F3D9860C63; Mon, 30 Sep 2019 14:00:35 +0000 (UTC) Subject: Re: [PATCH 4.19 36/63] locking/lockdep: Add debug_locks check in __lock_downgrade() To: Tetsuo Handa , Sasha Levin Cc: Greg Kroah-Hartman , linux-kernel@vger.kernel.org, stable@vger.kernel.org, syzbot+53383ae265fb161ef488@syzkaller.appspotmail.com, "Peter Zijlstra (Intel)" , Andrew Morton , Linus Torvalds , "Paul E. McKenney" , Thomas Gleixner , Will Deacon , Ingo Molnar References: <20190929135031.382429403@linuxfoundation.org> <20190929135038.482721804@linuxfoundation.org> <801c81d2-ce72-8eb3-a18b-1b0943270fc4@i-love.sakura.ne.jp> <20190930002828.GQ8171@sasha-vm> From: Waiman Long Organization: Red Hat Message-ID: Date: Mon, 30 Sep 2019 10:00:35 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.49]); Mon, 30 Sep 2019 14:00:37 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 9/29/19 9:46 PM, Tetsuo Handa wrote: > On 2019/09/30 9:28, Sasha Levin wrote: >> On Sun, Sep 29, 2019 at 11:43:38PM +0900, Tetsuo Handa wrote: >>> On 2019/09/29 22:54, Greg Kroah-Hartman 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(). >>> Please drop "[PATCH 4.19 36/63] locking/lockdep: Add debug_locks check in __lock_downgrade()". >>> We had a revert patch shown below in the past. >> We had a revert in the stable trees, but that revert was incorrect. >> >> Take a look at commit 513e1073d52e55 upstream, it patches >> __lock_set_class() (even though the subject line says >> __lock_downgrade()). So this is not a backporting error as the revert >> said it is, but is rather the intended location to be patched. >> >> If this is actually wrong, then it should be addressed upstream first. >> > Hmm, upstream has two commits with same author, same date, same subject, different hash, different content. > I couldn't find from https://lkml.kernel.org/r/1547093005-26085-1-git-send-email-longman@redhat.com that > we want to patch both __lock_set_class() and __lock_downgrade(), but I found that the tip-bot has patched > __lock_downgrade() on "2019-01-21 11:29" and __lock_set_class() on "2019-02-04 8:56". > Seems that we by error patched both functions, though patching both functions should be harmless... > > 64aa348ed kernel/lockdep.c (Peter Zijlstra 2008-08-11 09:30:21 +0200 4115) static int > 00ef9f734 kernel/lockdep.c (Peter Zijlstra 2008-12-04 09:00:17 +0100 4116) __lock_set_class(struct lockdep_map *lock, const char *name, > 00ef9f734 kernel/lockdep.c (Peter Zijlstra 2008-12-04 09:00:17 +0100 4117) struct lock_class_key *key, unsigned int subclass, > 00ef9f734 kernel/lockdep.c (Peter Zijlstra 2008-12-04 09:00:17 +0100 4118) unsigned long ip) > 64aa348ed kernel/lockdep.c (Peter Zijlstra 2008-08-11 09:30:21 +0200 4119) { > 64aa348ed kernel/lockdep.c (Peter Zijlstra 2008-08-11 09:30:21 +0200 4120) struct task_struct *curr = current; > 8c8889d8e kernel/locking/lockdep.c (Imre Deak 2019-05-24 23:15:08 +0300 4121) unsigned int depth, merged = 0; > 41c2c5b86 kernel/locking/lockdep.c (J. R. Okajima 2017-02-03 01:38:15 +0900 4122) struct held_lock *hlock; > 64aa348ed kernel/lockdep.c (Peter Zijlstra 2008-08-11 09:30:21 +0200 4123) struct lock_class *class; > 64aa348ed kernel/lockdep.c (Peter Zijlstra 2008-08-11 09:30:21 +0200 4124) int i; > 64aa348ed kernel/lockdep.c (Peter Zijlstra 2008-08-11 09:30:21 +0200 4125) > 513e1073d kernel/locking/lockdep.c (Waiman Long 2019-01-09 23:03:25 -0500 4126) if (unlikely(!debug_locks)) > 513e1073d kernel/locking/lockdep.c (Waiman Long 2019-01-09 23:03:25 -0500 4127) return 0; > 513e1073d kernel/locking/lockdep.c (Waiman Long 2019-01-09 23:03:25 -0500 4128) > > 6419c4af7 kernel/locking/lockdep.c (J. R. Okajima 2017-02-03 01:38:17 +0900 4162) static int __lock_downgrade(struct lockdep_map *lock, unsigned long ip) > 6419c4af7 kernel/locking/lockdep.c (J. R. Okajima 2017-02-03 01:38:17 +0900 4163) { > 6419c4af7 kernel/locking/lockdep.c (J. R. Okajima 2017-02-03 01:38:17 +0900 4164) struct task_struct *curr = current; > 8c8889d8e kernel/locking/lockdep.c (Imre Deak 2019-05-24 23:15:08 +0300 4165) unsigned int depth, merged = 0; > 6419c4af7 kernel/locking/lockdep.c (J. R. Okajima 2017-02-03 01:38:17 +0900 4166) struct held_lock *hlock; > 6419c4af7 kernel/locking/lockdep.c (J. R. Okajima 2017-02-03 01:38:17 +0900 4167) int i; > 6419c4af7 kernel/locking/lockdep.c (J. R. Okajima 2017-02-03 01:38:17 +0900 4168) > 714925805 kernel/locking/lockdep.c (Waiman Long 2019-01-09 23:03:25 -0500 4169) if (unlikely(!debug_locks)) > 714925805 kernel/locking/lockdep.c (Waiman Long 2019-01-09 23:03:25 -0500 4170) return 0; > 714925805 kernel/locking/lockdep.c (Waiman Long 2019-01-09 23:03:25 -0500 4171) > > commit 513e1073d52e55b8024b4f238a48de7587c64ccf > Author: Waiman Long > Date: Wed Jan 9 23:03:25 2019 -0500 > > locking/lockdep: Add debug_locks check in __lock_downgrade() > > commit 71492580571467fb7177aade19c18ce7486267f5 > Author: Waiman Long > Date: Wed Jan 9 23:03:25 2019 -0500 > > locking/lockdep: Add debug_locks check in __lock_downgrade() > As I had said before, it looks like the git-apply mixed up the location due to the fact that the hunks are exactly the same for both locations. So if the patch to be applied does not have the right line number, it will get applied to the wrong location first. Cheers, Longman