Received: by 2002:a05:6a10:16a7:0:0:0:0 with SMTP id gp39csp219627pxb; Thu, 12 Nov 2020 01:51:55 -0800 (PST) X-Google-Smtp-Source: ABdhPJxfMK2sySA5IH7voJTcLq5Tj8e3GdUkBpiJmizBhH1DOQNvPYPMptDQ9D1JeaylAbEL9Ijr X-Received: by 2002:a17:906:ae95:: with SMTP id md21mr28411835ejb.425.1605174715603; Thu, 12 Nov 2020 01:51:55 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1605174715; cv=none; d=google.com; s=arc-20160816; b=uCIDb8B0gsy+XJfMWBTmdc+mqX1/XnjpsoGR8jOt0GcZP8I4KBCu7ft49l0hvFFj/C N5UufOme3u8kAM0r5vnrz4HPVXwYBMXEF0tFb/WkCwnB7jtReSBVaIZsm+08Xk7aeERy W/9DT19Bm2DRqbEmLZUPvXvAWV9t1DYO/lNmeT+T2N5B6tDN47cDeQtTNAiki7857U3K 3zqq+JaHZiFO5H5jpQqdHwlcK0z5c3ndlUiNG06U8eMEIq2XiV1orOVYM7+ebyWC68qW Z2w4ydkZoifVw4fWEKyOOuUlvoniLcHOzqdiIo0F2PEFQ9XRBLSiJu5Lg/Qi3ziwlx+s J8Bg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=pxSfDl+TYE2bHqZ4pzw/baNh8xBHzWZNQ3y4VnkvYpA=; b=KUNbIbUk51LTNOFOou3FTucZGiSux84faBr/tSwlbsPCbrHfhP+400fN0lKmpb6Wz2 eIX9lqzJDoiGruIZ+5DLqbkAOjOfKilycSJ50KU+9COgjCjsg6r9xdtDWEnNhXdwYSDy ghPBiMae44Si6kAtkoUI7t+AYV1CPFM0fx5/VLwlryX0BTw9cq9Z0eoP9bsWC6X2becW +KJTKSHEy1YmXfX3Spc7ciKgnPexNe2WGe9pHM1v8Hb+jiAUZcvSjVxBO81luVB1KI1e 6PfldEu2KjfNR07TTXV0CFyyKvGY2SgQoFn35eqjsvc69aFWLM29x7X46jypkAyHKfss BNXw== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id p14si3431275eju.470.2020.11.12.01.51.32; Thu, 12 Nov 2020 01:51:55 -0800 (PST) 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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727646AbgKLJrz (ORCPT + 99 others); Thu, 12 Nov 2020 04:47:55 -0500 Received: from lgeamrelo12.lge.com ([156.147.23.52]:41582 "EHLO lgeamrelo11.lge.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1725979AbgKLJrz (ORCPT ); Thu, 12 Nov 2020 04:47:55 -0500 Received: from unknown (HELO lgeamrelo01.lge.com) (156.147.1.125) by 156.147.23.52 with ESMTP; 12 Nov 2020 18:47:53 +0900 X-Original-SENDERIP: 156.147.1.125 X-Original-MAILFROM: byungchul.park@lge.com Received: from unknown (HELO X58A-UD3R) (10.177.222.33) by 156.147.1.125 with ESMTP; 12 Nov 2020 18:47:53 +0900 X-Original-SENDERIP: 10.177.222.33 X-Original-MAILFROM: byungchul.park@lge.com Date: Thu, 12 Nov 2020 18:46:32 +0900 From: Byungchul Park To: Ingo Molnar Cc: torvalds@linux-foundation.org, peterz@infradead.org, mingo@redhat.com, will@kernel.org, linux-kernel@vger.kernel.org, tglx@linutronix.de, rostedt@goodmis.org, joel@joelfernandes.org, alexander.levin@microsoft.com, daniel.vetter@ffwll.ch, chris@chris-wilson.co.uk, duyuyang@gmail.com, johannes.berg@intel.com, tj@kernel.org, tytso@mit.edu, willy@infradead.org, david@fromorbit.com, amir73il@gmail.com, bfields@fieldses.org, gregkh@linuxfoundation.org, kernel-team@lge.com Subject: Re: [RFC] Are you good with Lockdep? Message-ID: <20201112094631.GD14554@X58A-UD3R> References: <20201111050559.GA24438@X58A-UD3R> <20201111105441.GA78848@gmail.com> <20201112061532.GA14554@X58A-UD3R> <20201112085114.GC14554@X58A-UD3R> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20201112085114.GC14554@X58A-UD3R> User-Agent: Mutt/1.5.21 (2010-09-15) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Nov 12, 2020 at 05:51:14PM +0900, Byungchul Park wrote: > On Thu, Nov 12, 2020 at 03:15:32PM +0900, Byungchul Park wrote: > > > If on the other hand there's some bug in lockdep itself that causes > > > excessive false positives, it's better to limit the number of reports > > > to one per bootup, so that it's not seen as a nuisance debugging > > > facility. > > > > > > Or if lockdep gets extended that causes multiple previously unreported > > > (but very much real) bugs to be reported, it's *still* better to > > > handle them one by one: because lockdep doesn't know whether it's real > > > > Why do you think we cannot handle them one by one with multi-reporting? > > We can handle them with the first one as we do with single-reporting. > > And also that's how we work, for example, when building the kernel or > > somethinig. > > Let me add a little bit more. I just said the fact that we are able to > handle the bugs one by one as if we do with single-reporting. > > But the thing is multi-reporting could be more useful in some cases. > More precisely speaking, bugs not caused by IRQ state will be reported > without annoying nuisance. I bet you have experienced a ton of nuisances > when multi-reporting Lockdep detected a deadlock by IRQ state. Last, we should never use multi-reporting Lockdep if Lockdep works like the current code because redundant warnings caused by IRQ state would be reported almost infinite times. I'm afraid you were talking about it. Thanks, Byungchul > For some cases, multi-reporting is as useful as single-reporting, while > for the other cases, multi-reporting is more useful. Then I think we > have to go with mutil-reporting if there's no technical issue. > > Thanks, > Byungchul