Received-SPF: pass (google.com: domain of linux-nfs+bounces-2478-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249;
Precedence: bulk
MIME-Version: 1.0
Message-ID: <trinity-db4c718f-d59d-4de4-bf45-96ad98ca2362-1711471819632@msvc-mesg-gmx122>
From: Jan Schunk <scpcom@gmx.de>
To: Chuck Lever III <chuck.lever@oracle.com>
Cc: Jeff Layton <jlayton@kernel.org>, Neil Brown <neilb@suse.de>, Olga
 Kornievskaia <kolga@netapp.com>, Dai Ngo <dai.ngo@oracle.com>, Tom Talpey
 <tom@talpey.com>, Linux NFS Mailing List <linux-nfs@vger.kernel.org>,
 "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Aw: Re: [External] : nfsd: memory leak when client does many file
 operations
Content-Type: text/plain; charset=UTF-8
Importance: normal
Sensitivity: Normal
Content-Transfer-Encoding: quoted-printable
Date: Tue, 26 Mar 2024 17:50:19 +0100
In-Reply-To: <51CAACAB-B6CC-4139-A350-25CF067364D3@oracle.com>
References: <trinity-068f55c9-6088-418d-bf3a-c2778a871e98-1711310237802@msvc-mesg-gmx120>
 <E3109CAA-8261-4F66-9D1B-3546E8B797DF@oracle.com>
 <trinity-bfafb9db-d64f-4cad-8cb1-40dac0a2c600-1711313314331@msvc-mesg-gmx105>
 <567BBF54-D104-432C-99C0-1A7EE7939090@oracle.com>
 <trinity-66047013-4d84-4eef-b5d3-d710fe6be805-1711316386382@msvc-mesg-gmx005>
 <6F16BCCE-3000-4BCB-A3B4-95B4767E3577@oracle.com>
 <trinity-ad0037c0-1060-4541-a8ca-15f826a5b5a2-1711396545958@msvc-mesg-gmx024>
 <088D9CC3-C5B0-4646-A85D-B3B9ACE8C532@oracle.com>
 <trinity-77720d9d-4d5b-48c6-8b1f-0b7205ea3c2b-1711398394712@msvc-mesg-gmx021>
 <51CAACAB-B6CC-4139-A350-25CF067364D3@oracle.com>
UI-OutboundReport: notjunk:1;M01:P0:mn/q4lFkgaE=;t+wfUvvKeQdfFjicqwysIYlwxNi
 dnq8kAYz1bFtfCNe3oGI+7+yVAUZIajHYCUNS0O5pZqQaeIwS2iUD5N/3MNN5luYEQsVfGSC9
 NhFSIh4pjneOwFYQh42Z1fRncY2Vu5TZYLFlCIwM9c1kohOrvOXWyLi1oJzCncEnpT9MNENNP
 WQ3HH2UNb6ikB4cY8NtbxwxDplLCnDMbU5Dz6EusO/5cMdvoJGI6JJXLNZBN9jPccbZSrao4X
 YMiWapJdyYymfW79fwAqwPDK3yGCuhVBsZ7T5o2wgVdPYxnqfSmBHkbXg9POJJhxXhIvC8UcZ
 rdtwqq9rzPAvL/CJtx9KBXqQNMgeRvU5r6AF+k1s4PES1LjjvRcITO3DwvdYyj9Hs1KxZjrWd
 FmsHgEYfGFVEebEc4awq33tFOEzNGNKRvtbCcEBO77oZxL2Qn/IDJ9tOu0HGHmaX/hBTahAWG
 hS8KF3AXDx6Kg2aCrJdeoluJEzPse3lMOM8uJG1BrV0UcIWWJHdmjVV6hom/BsnM6twm7ucra
 uykhFharzj2xDp0O1FRPYPbAh4suYlyIQQdK4P92sF2Ki52sCkXp7mxGI+zF4h2Sn5Emggqgo
 aUFM7VVcQrlSGU6SADYMTrgXPp/YNOiLOH/PXX+ai+/kceOLn3P3zCcDE5Jr8aE2sScKIQkNK
 ZxsWeaItBClj9u0/WzcGLAVan0NdlanlTJbaBKPDZXnlQoj9Yq5lQaYxKUI9jKw=

Thanks, I do some tests with DEBUG_KMEMLEAK enabled and git bisect now=2E

> Gesendet: Montag, den 25=2E03=2E2024 um 21:36 Uhr
> Von: "Chuck Lever III" <chuck=2Elever@oracle=2Ecom>
> An: "Jan Schunk" <scpcom@gmx=2Ede>
> Cc: "Jeff Layton" <jlayton@kernel=2Eorg>, "Neil Brown" <neilb@suse=2Ede>=
, "Olga Kornievskaia" <kolga@netapp=2Ecom>, "Dai Ngo" <dai=2Engo@oracle=2Ec=
om>, "Tom Talpey" <tom@talpey=2Ecom>, "Linux NFS Mailing List" <linux-nfs@v=
ger=2Ekernel=2Eorg>, "linux-kernel@vger=2Ekernel=2Eorg" <linux-kernel@vger=
=2Ekernel=2Eorg>
> Betreff: Re: [External] : nfsd: memory leak when client does many file o=
perations
>=20
>=20
>=20
> > On Mar 25, 2024, at 4:26=E2=80=AFPM, Jan Schunk <scpcom@gmx=2Ede> wrot=
e:
> >=20
> > I am building my own kernels, but I never tried kmemleak, is this just=
 a Kconfig option?
>=20
>   Location:
>     -> Kernel hacking
>       -> Memory Debugging
> (1)     -> Kernel memory leak detector (DEBUG_KMEMLEAK [=3Dn])
>=20
>=20
> > What do you mean with "bisect between v6=2E3 and v6=2E4"?
>=20
> After you "git clone" the kernel source:
>=20
> $ git bisect start v6=2E4 v6=2E3
>=20
> Build the kernel and test=2E If the test fails:
>=20
> $ cd <your kernel source tree>; git bisect bad
>=20
> If the test succeeds:
>=20
> $ cd <your kernel source tree>; git bisect good
>=20
> Rebuild and try again until it lands on the first broken commit=2E
>=20
>=20
> > Everything including v6=2E4 is OK, the problem starts at v6=2E5=2E
>=20
> I misremembered=2E Use "$ git bisect start v6=2E5 v6=2E4" then=2E
>=20
>=20
> > I also looked at some code already but there are huge changes to mm th=
at happened in v6=2E5 and v6=2E6 so for me it is heavy to compare it with o=
lder versions to find one or more commits that may cause the issue=2E
>=20
> Bisection is a mechanical test-based process=2E You don't need
> to look at code until you've reached the first bad commit=2E
>=20
> --
> Chuck Lever
>=20
>