From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752458AbdJTHa4 (ORCPT ); Fri, 20 Oct 2017 03:30:56 -0400 Received: from mail-wr0-f194.google.com ([209.85.128.194]:54588 "EHLO mail-wr0-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752248AbdJTHay (ORCPT ); Fri, 20 Oct 2017 03:30:54 -0400 X-Google-Smtp-Source: ABhQp+RRzffGai6xsMGf0vUYuS1d8FEk9M/b0dW6OBoRvwOD7dgB9RZoQ5TSvmU7txNzzafLhiVbgA== Date: Fri, 20 Oct 2017 09:30:50 +0200 From: Ingo Molnar To: Thomas Gleixner Cc: Bart Van Assche , "linux-kernel@vger.kernel.org" , "peterz@infradead.org" , "linux-mm@kvack.org" , "byungchul.park@lge.com" , "kernel-team@lge.com" Subject: Re: [PATCH v2 2/3] lockdep: Remove BROKEN flag of LOCKDEP_CROSSRELEASE Message-ID: <20171020073050.nyaqynbbkeltr7iq@gmail.com> References: <1508392531-11284-1-git-send-email-byungchul.park@lge.com> <1508392531-11284-3-git-send-email-byungchul.park@lge.com> <1508425527.2429.11.camel@wdc.com> <1508428021.2429.22.camel@wdc.com> <1508444515.2429.55.camel@wdc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Thomas Gleixner wrote: > That would just make the door open for evading lockdep. This has been > discussed when lockdep was introduced and with a lot of other 'annoying' > debug features we've seen the same discussion happening. > > When they get introduced the number of real issues and false positives is > high, but once the dust settles it's just business as usual and the overall > code quality improves and the number of hard to decode problems shrinks. Yes, also note that it's typical that the proportion of false positives *increases* once a lock debugging feature enters a more mature period of its existence, because real deadlocks tend to be fixed at the development stage without us ever seeing them. I.e. for every lockdep-debugged bug fixed upstream I'm pretty sure there are at least 10 times as many bugs that were fixed in earlier stages of development, without ever hitting the upstream kernel. At least that's the rough proportion for locking bugs I introduce ;-) So even false positives are not a problem as long as their annotation improves the code or documents it better. Thanks, Ingo From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f71.google.com (mail-wm0-f71.google.com [74.125.82.71]) by kanga.kvack.org (Postfix) with ESMTP id 5DA8C6B0038 for ; Fri, 20 Oct 2017 03:30:54 -0400 (EDT) Received: by mail-wm0-f71.google.com with SMTP id u78so4510267wmd.13 for ; Fri, 20 Oct 2017 00:30:54 -0700 (PDT) Received: from mail-sor-f65.google.com (mail-sor-f65.google.com. [209.85.220.65]) by mx.google.com with SMTPS id u50sor153229wrf.57.2017.10.20.00.30.53 for (Google Transport Security); Fri, 20 Oct 2017 00:30:53 -0700 (PDT) Date: Fri, 20 Oct 2017 09:30:50 +0200 From: Ingo Molnar Subject: Re: [PATCH v2 2/3] lockdep: Remove BROKEN flag of LOCKDEP_CROSSRELEASE Message-ID: <20171020073050.nyaqynbbkeltr7iq@gmail.com> References: <1508392531-11284-1-git-send-email-byungchul.park@lge.com> <1508392531-11284-3-git-send-email-byungchul.park@lge.com> <1508425527.2429.11.camel@wdc.com> <1508428021.2429.22.camel@wdc.com> <1508444515.2429.55.camel@wdc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: owner-linux-mm@kvack.org List-ID: To: Thomas Gleixner Cc: Bart Van Assche , "linux-kernel@vger.kernel.org" , "peterz@infradead.org" , "linux-mm@kvack.org" , "byungchul.park@lge.com" , "kernel-team@lge.com" * Thomas Gleixner wrote: > That would just make the door open for evading lockdep. This has been > discussed when lockdep was introduced and with a lot of other 'annoying' > debug features we've seen the same discussion happening. > > When they get introduced the number of real issues and false positives is > high, but once the dust settles it's just business as usual and the overall > code quality improves and the number of hard to decode problems shrinks. Yes, also note that it's typical that the proportion of false positives *increases* once a lock debugging feature enters a more mature period of its existence, because real deadlocks tend to be fixed at the development stage without us ever seeing them. I.e. for every lockdep-debugged bug fixed upstream I'm pretty sure there are at least 10 times as many bugs that were fixed in earlier stages of development, without ever hitting the upstream kernel. At least that's the rough proportion for locking bugs I introduce ;-) So even false positives are not a problem as long as their annotation improves the code or documents it better. Thanks, Ingo -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org