Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751264AbdI3GDT (ORCPT ); Sat, 30 Sep 2017 02:03:19 -0400 Received: from alln-iport-1.cisco.com ([173.37.142.88]:46945 "EHLO alln-iport-1.cisco.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750724AbdI3GDR (ORCPT ); Sat, 30 Sep 2017 02:03:17 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C9AgDUMs9Z/5JdJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1yBUi6ddYFUIpg+CoU7AoQzVwECAQEBAQECayiFGAEBAQECATg?= =?us-ascii?q?CPwULCxguPBsGDoopBQioQ4tDAQEBAQEBAQEBAQEBAQEBAQEBAR+DLYICgVGCI?= =?us-ascii?q?IJyhF6GGQWST45glniFbosFSJRbAhEZAYE5V4EOeBWFYxyCB4drgTIBgQ8BAQE?= X-IronPort-AV: E=Sophos;i="5.42,456,1500940800"; d="scan'208";a="10727420" Date: Fri, 29 Sep 2017 23:03:04 -0700 From: Govindarajulu Varadarajan To: Bjorn Helgaas CC: Peter Zijlstra , , , , , , , Subject: Re: [PATCH 4/4] lockdep: make MAX_LOCK_DEPTH configurable from Kconfig In-Reply-To: <20170929162332.GA15567@bhelgaas-glaptop.roam.corp.google.com> Message-ID: References: <20170927214220.41216-1-gvaradar@cisco.com> <20170927214220.41216-5-gvaradar@cisco.com> <20170928092600.qvehxzikcjr65hvw@hirez.programming.kicks-ass.net> <20170929162332.GA15567@bhelgaas-glaptop.roam.corp.google.com> User-Agent: Alpine 2.20 (LNX 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII"; format=flowed X-Originating-IP: [10.24.76.29] X-ClientProxiedBy: xch-aln-002.cisco.com (173.36.7.12) To XCH-RCD-012.cisco.com (173.37.102.22) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1105 Lines: 26 On Fri, 29 Sep 2017, Bjorn Helgaas wrote: > On Thu, Sep 28, 2017 at 04:51:46PM -0700, Govindarajulu Varadarajan wrote: >> On Thu, 28 Sep 2017, Peter Zijlstra wrote: >> >>> On Wed, Sep 27, 2017 at 02:42:20PM -0700, Govindarajulu Varadarajan wrote: >>>> Make MAX_LOCK_DEPTH configurable. It is set to 48 right now. Number of >>>> VFs under a PCI pf bus can exceed 48 and this disables lockdep. >>>> >>>> lockdep currently allows max of 63 held_locks. >>> >>> But why a config knob? Why not just raise the number to 64 >>> unconditionally? And is that sufficient; you only state 48 is >>> insufficient, you don't actually state the VF limit. >>> >> >> I did not want to change the default configuration for everyone. >> >> I will change it 63 unconditionally in v2 and resubmit the series. > > I'm not happy about having to increase MAX_LOCK_DEPTH based on a > number of VFs. I haven't had time to look at the locking strategy > you're proposing, but it just doesn't feel right to have to take 50+ > locks for one operation. I agree. I have sent V2 where we dont lock 50+ device_lock. Please have a look.