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;
Subject: Re: "BUG: MAX_LOCKDEP_ENTRIES too low" with 6979
 "&type->s_umount_key"
To:     Qian Cai <cai@lca.pw>, Peter Zijlstra <peterz@infradead.org>,
        Will Deacon <will@kernel.org>, Ingo Molnar <mingo@redhat.com>
Cc:     David Howells <dhowells@redhat.com>,
        Alexander Viro <viro@ZenIV.linux.org.uk>,
        linux-fsdevel@vger.kernel.org,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
References: <F430E503-F8E9-41B6-B23E-D350FD73359B@lca.pw>
From:   Waiman Long <longman@redhat.com>
Organization: Red Hat
Message-ID: <e8c6d3af-3045-0a37-5e9e-bfd60c09f97d@redhat.com>
Date:   Sat, 16 May 2020 21:15:55 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.4.1
MIME-Version: 1.0
In-Reply-To: <F430E503-F8E9-41B6-B23E-D350FD73359B@lca.pw>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On 5/15/20 1:21 AM, Qian Cai wrote:
> Lockdep is screwed here in next-20200514 due to "BUG: MAX_LOCKDEP_ENTRIES too low". One of the traces below pointed to this linux-next commit,
>
> 8c8e824d4ef0 watch_queue: Introduce a non-repeating system-unique superblock ID
>
> which was accidentally just showed up in next-20200514 along with,
>
> 46896d79c514 watch_queue: Add superblock notifications
>
> I did have here,
>
> CONFIG_SB_NOTIFICATIONS=y
> CONFIG_MOUNT_NOTIFICATIONS=y
> CONFIG_FSINFO=y
>
> While MAX_LOCKDEP_ENTRIES is 32768, I noticed there is one type of lock had a lot along,
>
> # grep  'type->s_umount_key’ /proc/lockdep_chains | wc -l
> 6979

The lock_list table entries are for tracking a lock's forward and 
backward dependencies. The lockdep_chains isn't the right lockdep file 
to look at. Instead, check the lockdep files for entries with the 
maximum BD (backward dependency) + FD (forward dependency). That will 
give you a better view of which locks are consuming most of the 
lock_list entries. Also take a look at lockdep_stats for an overall view 
of how much various table entries are being consumed.

Cheers,
Longman