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;
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From:   Qian Cai <cai@lca.pw>
Mime-Version: 1.0 (1.0)
Subject: Re: "BUG: MAX_LOCKDEP_ENTRIES too low" with 6979 "&type->s_umount_key"
Date:   Sun, 17 May 2020 07:12:33 -0400
Message-Id: <06E43DA0-9976-4D44-AC72-5ED8A7022FA3@lca.pw>
References: <e8c6d3af-3045-0a37-5e9e-bfd60c09f97d@redhat.com>
Cc:     Peter Zijlstra <peterz@infradead.org>,
        Will Deacon <will@kernel.org>, Ingo Molnar <mingo@redhat.com>,
        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>
In-Reply-To: <e8c6d3af-3045-0a37-5e9e-bfd60c09f97d@redhat.com>
To:     Waiman Long <longman@redhat.com>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk


> On May 16, 2020, at 9:16 PM, Waiman Long <longman@redhat.com> wrote:
>=20
> 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. I=
nstead, check the lockdep files for entries with the maximum BD (backward de=
pendency) + FD (forward dependency). That will give you a better view of whi=
ch locks are consuming most of the lock_list entries. Also take a look at lo=
ckdep_stats for an overall view of how much various table entries are being c=
onsumed.

Thanks for the hint. It seems something in vfs is the culprit because every s=
ingle one of those triggering from path_openat() (vfs_open()) or vfs_get_tre=
e()

When the system after boot, lock_list entries is around 10000. After running=
 LTP syscalls and mm tests, the number is around 20000. Then, it will go all=
 the way over the max (32700) while running LTP fs tests. Most of the time f=
rom a test that would read every single file in sysfs.

I=E2=80=99ll decode the lockdep file to see if there is any more clues.=