Received: by 2002:a05:6a10:f3d0:0:0:0:0 with SMTP id a16csp4027865pxv; Mon, 28 Jun 2021 19:54:49 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzD5T1bO0WHyBby4jsJMc3SjMeoJcKH0cqwLBpup61jEDm6KzvDnUS6bpwBhz3Sy91KFi1H X-Received: by 2002:a17:906:8a72:: with SMTP id hy18mr26712358ejc.393.1624935289616; Mon, 28 Jun 2021 19:54:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1624935289; cv=none; d=google.com; s=arc-20160816; b=vQe6SMwQW20DZsJt5BLUKT2qqsMv2PZSXmjSqZvOF3J9giU1H97u7GaLgL6VRlLQZr VpyCh0alF2xWBrJC+NcQM8dGBn4mEbeM+eCIzz6eY1NgRWWi7LjYZxF6W32O6AbtO4LD 4+ScTisgHRYSrXZ1b4psMzq4hmb5xOeze4uZ3hSjKo5bttmjPP6T0ILnvp5vM0ACvHOg eXm0vRsIjOPmhPP9VZjZZFhw5RnfYY6G0cSFKf9gGfBSjZFEeMqFmHv6z9UDGwepGcxi b559sJ6t6C1NoopZ4Y9SbdV7wqsC537VTxlm3rATpWhIRa0pg7NOmCMjUQL50MpIMc7l N4sw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=DajkdBeCCFmMhMvtFbnjwTvzKMnsz2v7ADpzRrerOtM=; b=ccnLTF2XME5ryBVDBFO/6e/78xOOiTIY1tSaIiKwF44ogQmffCG9mr/uF3XYFduPkw 1hNS2N2aEnaFE1R4fDs9F5fmzBIV6+tUxjKWqm6Eroj4gM+VR0AJdIGas04H2kjJ1Tgo PMHfQyS+4JGVhfn4eThVqq+sebCnof39OCP1lNTv961cEKHObrs8OAlNuxDEUlq26u37 AXJlGJ2qOLNV0gPQno8o5PJSIr3ivMCb10Mp3jC8QmUrdESL57YqpwmqvD/0U2pYb3t5 N8wfE0Q+NsOZabunThc7i3/ZM/lUUf4Qo5/lBuctkmDMd42FHSpMhVUrVjGxAlZucusH NPiQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=ndstumrC; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id jy12si9109595ejc.519.2021.06.28.19.54.26; Mon, 28 Jun 2021 19:54:49 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=ndstumrC; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231700AbhF2Czh (ORCPT + 99 others); Mon, 28 Jun 2021 22:55:37 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60504 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231398AbhF2Czg (ORCPT ); Mon, 28 Jun 2021 22:55:36 -0400 Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com [IPv6:2a00:1450:4864:20::12f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E7B59C061574 for ; Mon, 28 Jun 2021 19:53:08 -0700 (PDT) Received: by mail-lf1-x12f.google.com with SMTP id h15so36525858lfv.12 for ; Mon, 28 Jun 2021 19:53:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=DajkdBeCCFmMhMvtFbnjwTvzKMnsz2v7ADpzRrerOtM=; b=ndstumrC5KGEt7B0fAJrPB1fe6lOayRoOqQGOTkwZWPghPGs1HW2kouAeJ582FGjF9 4Ls10gfp33aJe54qjVsU0lyLb0E5jqWN8Yr/ua/ZEZeIij2COjKsEch/Etm8ajCwod/L ikL1oqzl9C1fvwr6H6kc1JvISov1h0jYmp5q52lmKw5kb35jLwO8T3voydJSDWXDTinQ FH95yw8pm4pOxChdf1XXEi3atw0zmKd4LMTKcy3YrIcKTnC5QLEDwp/X7xlDUCxdFpeP GQTWAyRZEK+50vFoyJRjtSB5Lo4scf+/ZS+R7JFf21tZLVsEgxPDmnUDx+89Y2sZ3oC6 USSA== 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=DajkdBeCCFmMhMvtFbnjwTvzKMnsz2v7ADpzRrerOtM=; b=AzqYLL8Rh1M8xgkFwX92FoeZupja0NFjRCGl2OizhJ+lE6cDL4v1vQmAveydKPTI9D FZaw/ZzCZHFvO3IEVWrsIeDpaNsL1hSpRk0zNdkcrFmMYszPHBjwiWsD3EuuhyNfxlLj 5isuBcJ0Ttuil1IyuCm31/X/DXmJblS/x5uV8UX8rusM/6eMr8iBR0a7boD4N45Kqgp0 j3UZ8g9v01C6q8CRjc4iHaoSP+QXrCEFCY0JO8NaaynztW1LK+xCTnJjSpfgSj7NCnG8 rrGv2y8RLQTP8fmE+HojmaLukId1XXQMjbQkWPwGPq6lZ70ItyH5JIBe6DspMuywRYKS ImLw== X-Gm-Message-State: AOAM53048sD54nkMWPgXsXJk0JJ7y6GDKwHUXGdR4/T+8RMsgZoAsnag RbLAaJ57NiGgEJtzTHJBhm7nn5oL6zsWmFKHovw= X-Received: by 2002:a05:6512:1683:: with SMTP id bu3mr22348002lfb.520.1624935187230; Mon, 28 Jun 2021 19:53:07 -0700 (PDT) MIME-Version: 1.0 References: <20210628151708.138524-1-sxwjean@me.com> <8fc00823-9d42-2178-784a-af33cc34b168@redhat.com> In-Reply-To: <8fc00823-9d42-2178-784a-af33cc34b168@redhat.com> From: Xiongwei Song Date: Tue, 29 Jun 2021 10:52:41 +0800 Message-ID: Subject: Re: [PATCH v2] locking/lockdep: Fix meaningless usages output of lock classes To: Waiman Long Cc: Xiongwei Song , peterz@infradead.org, mingo@redhat.com, will@kernel.org, Boqun Feng , Linux Kernel Mailing List Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jun 29, 2021 at 5:17 AM Waiman Long wrote: > > On 6/28/21 11:17 AM, Xiongwei Song wrote: > > From: Xiongwei Song > > > > When enabling CONFIG_LOCK_STAT, then CONFIG_LOCKDEP is forcedly enabled. > > We can get output from /proc/lockdep, which currently includes usages of > > lock classes. But the usages are meaningless, see the output below: > > > > / # cat /proc/lockdep > > all lock classes: > > ffffffff9af63350 ....: cgroup_mutex > > > > ffffffff9af54eb8 ....: (console_sem).lock > > > > ffffffff9af54e60 ....: console_lock > > > > ffffffff9ae74c38 ....: console_owner_lock > > > > ffffffff9ae74c80 ....: console_owner > > > > ffffffff9ae66e60 ....: cpu_hotplug_lock > > > > Only one usage context for each lock, this is because each usage is only > > changed in mark_lock() that is in CONFIG_PROVE_LOCKING defined section, > > however in the test situation, it's not. > > > > The fix is to move the usages reading and seq_print from > > CONFIG_PROVE_LOCKING undefined setcion to its defined section. Also, > > locks_after list of lock_class is empty when CONFIG_PROVE_LOCKING > > undefined, so do the same thing as what have done for usages of lock > > classes. > With this patch, CONFIG_LOCKDEP without CONFIG_PROVE_LOCKING will make > /proc/lockdep displays just the list of lock classes with their > associated lock keys. I think it is worth explicitly saying that in the > commit log. Make sense. Will update. > > Signed-off-by: Xiongwei Song > > --- > > kernel/locking/lockdep_proc.c | 24 +++++++++++++----------- > > 1 file changed, 13 insertions(+), 11 deletions(-) > > > > diff --git a/kernel/locking/lockdep_proc.c b/kernel/locking/lockdep_proc.c > > index 806978314496..a1ec2652d492 100644 > > --- a/kernel/locking/lockdep_proc.c > > +++ b/kernel/locking/lockdep_proc.c > > @@ -70,23 +70,25 @@ static int l_show(struct seq_file *m, void *v) > > #ifdef CONFIG_DEBUG_LOCKDEP > > seq_printf(m, " OPS:%8ld", debug_class_ops_read(class)); > > #endif > > -#ifdef CONFIG_PROVE_LOCKING > > - seq_printf(m, " FD:%5ld", lockdep_count_forward_deps(class)); > > - seq_printf(m, " BD:%5ld", lockdep_count_backward_deps(class)); > > -#endif > > + if (IS_ENABLED(CONFIG_PROVE_LOCKING)) { > > + seq_printf(m, " FD:%5ld", lockdep_count_forward_deps(class)); > > + seq_printf(m, " BD:%5ld", lockdep_count_backward_deps(class)); > > > > - get_usage_chars(class, usage); > > - seq_printf(m, " %s", usage); > > + get_usage_chars(class, usage); > > + seq_printf(m, " %s", usage); > > + } > > > > seq_printf(m, ": "); > > print_name(m, class); > > seq_puts(m, "\n"); > > > > - list_for_each_entry(entry, &class->locks_after, entry) { > > - if (entry->distance == 1) { > > - seq_printf(m, " -> [%p] ", entry->class->key); > > - print_name(m, entry->class); > > - seq_puts(m, "\n"); > > + if (IS_ENABLED(CONFIG_PROVE_LOCKING)) { > > + list_for_each_entry(entry, &class->locks_after, entry) { > > + if (entry->distance == 1) { > > + seq_printf(m, " -> [%p] ", entry->class->key); > > + print_name(m, entry->class); > > + seq_puts(m, "\n"); > > + } > > } > > } > > seq_puts(m, "\n"); > > Maybe you can remove the blank lines in this case by moving the last > seq_puts() inside the if loop. The blank lines are not really needed > without the associated locks_after information. Yeah, I agree. Thank you. Regards, Xiongwei > Cheers, > Longman >