On 24.05.24 18:09, Chuck Lever III wrote: >> On May 24, 2024, at 7:16 AM, Linux regression tracking (Thorsten Leemhuis) <regressions@xxxxxxxxxxxxx> wrote: >> On 21.05.24 12:01, Jeff Layton wrote: >>> On Tue, 2024-05-21 at 11:55 +0200, Paul Menzel wrote: >>>> Am 19.04.24 um 18:50 schrieb Paul Menzel: >>>> >>>>> Since at least Linux 6.8-rc6, Linux logs the warning below: >>>>> >>>>> NFSD: Unable to initialize client recovery tracking! (-110) >>>>> >>>>> I haven’t had time to bisect yet, so if you have an idea, that’d be great. >>>> >>>> 74fd48739d0488e39ae18b0168720f449a06690c is the first bad commit >>>> commit 74fd48739d0488e39ae18b0168720f449a06690c >>>> Author: Jeff Layton <jlayton@xxxxxxxxxx> >>>> Date: Fri Oct 13 09:03:53 2023 -0400 >>>> >>>> nfsd: new Kconfig option for legacy client tracking >>>> >>>> We've had a number of attempts at different NFSv4 client tracking >>>> methods over the years, but now nfsdcld has emerged as the clear winner >>>> since the others (recoverydir and the usermodehelper upcall) are >>>> problematic. >>> [...] >>> It sounds like you need to enable nfsdcld in your environment. The old >>> recovery tracking methods are deprecated. The only surviving one >>> requires the nfsdcld daemon to be running when recovery tracking is >>> started. Alternately, you can enable this option in your kernels if you >>> want to keep using the deprecated methods in the interim. >> >> Hmm. Then why didn't this new config option default to "Y" for a while >> (say a year or two) before changing the default to off? That would have >> prevented people like Paul from running into the problem when running >> "olddefconfig". I think that is what Linus would have wanted in a case >> like this, but might be totally wrong there (I CCed him, in case he >> wants to share his opinion, but maybe he does not care much). > > That's fair. I recall we believed at the time that very few people > if anyone currently use a legacy recovery tracking mechanism, and > the workaround, if they do, is easy. > >> But I guess that's too late now, unless we want to meddle with config >> option names. But I guess that might not be worth it after half a year >> for something that only causes a warning (aiui). > > In Paul's case, the default behavior might prevent proper NFSv4 > state recovery, which is a little more hazardous than a mere > warning, IIUC. > > To my surprise, it often takes quite some time for changes like > this to matriculate into mainstream usage, so half a year isn't > that long. We might want to change to a more traditional > deprecation path (default Y with warning, wait, default N, wait, > redact the old code). Well, that would help anybody that already ran "make olddefconfig" with a kernel that has 74fd48739d04, as they now have NFSD_LEGACY_CLIENT_TRACKING unset in their .config -- at least unless we rename that option and make it default to Y; but it would help everybody that updates from the latest longterm kernel to a future kernel that would contain a change like you outlined. Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat) -- Everything you wanna know about Linux kernel regression tracking: https://linux-regtracking.leemhuis.info/about/#tldr If I did something stupid, please tell me, as explained on that page.
