On Thu, Nov 07, 2024 at 09:22:39AM +0800, yangerkun wrote: > > > 在 2024/11/6 21:35, Chuck Lever 写道: > > On Tue, Nov 05, 2024 at 07:03:14PM +0800, Yang Erkun wrote: > > > From: Yang Erkun <yangerkun@xxxxxxxxxx> > > > Add nfs4_openowner_unhashed to help found unhashed nfs4_openowner, and > > > break nfsd4_open process to fix this problem. > > > > > > Cc: stable@xxxxxxxxxxxxxxx # 2.6 > > > > Hi - > > > > Questions about the "stable@" tag: > > > > - You refer above to a leak of nfsd_file objects, but the nfsd_file > > cache was added in v5.4. Any thoughts about what might be leaked, > > if anything, in kernels earlier than v5.4? > > From the above analysis, actually openowner is leaked, and all object > associated with it has been leaked too, include nfsd_file, and openowner > seems already been there since 2.6.... Before v5.4, openowners are leaked. After, openowners and nfsd_file objects are leaked. Got it. > > - Have you tried applying this patch to LTS kernels? > > I have not try to apply this to LTS, what I think is all kernel after 2.6 > has this bug... Understood. Is "2.6" a guess, or do you know of a specific kernel version where this problem started to appear? Generally if a problem goes back far enough or there isn't sufficient evidence about where the problem started, we don't want a "# xx.yy" annotation. I expect the stable folks will pull this fix into LTS kernels automatically, and I have nightly CI running on all of those. That can catch problems with applying recent fixes to old code bases, but it ain't perfect. -- Chuck Lever
