NFSD: Unable to initialize client recovery tracking! (-110)

NFSD: Unable to initialize client recovery tracking! (-110)

[Paul Menzel]

Dear Linux folks,


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.


Kind regards,

Paul

Re: NFSD: Unable to initialize client recovery tracking! (-110)

[Paul Menzel]

#regzbot ^introduced: 74fd48739d04

Dear Jeff,


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@kernel.org>
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.

     As a case in point, the recoverydir backend uses MD5 hashes to encode
     long form clientid strings, which means that nfsd repeatedly gets 
dinged
     on FIPS audits, since MD5 isn't considered secure. Its use of MD5 
is not
     cryptographically significant, so there is no danger there, but 
allowing
     us to compile that out allows us to sidestep the issue entirely.

     As a prelude to eventually removing support for these client tracking
     methods, add a new Kconfig option that enables them. Mark it deprecated
     and make it default to N.

     Acked-by: NeilBrown <neilb@suse.de>
     Signed-off-by: Jeff Layton <jlayton@kernel.org>
     Signed-off-by: Chuck Lever <chuck.lever@oracle.com>

  fs/nfsd/Kconfig       | 16 +++++++++
  fs/nfsd/nfs4recover.c | 97 
+++++++++++++++++++++++++++++++++------------------
  fs/nfsd/nfsctl.c      |  6 ++++
  3 files changed, 85 insertions(+), 34 deletions(-)

`NFSD_LEGACY_CLIENT_TRACKING` is not set:

     # CONFIG_NFSD_LEGACY_CLIENT_TRACKING is not set


Kind regards,

Paul

Re: NFSD: Unable to initialize client recovery tracking! (-110)

[Jeff Layton]

On Tue, 2024-05-21 at 11:55 +0200, Paul Menzel wrote:
> #regzbot ^introduced: 74fd48739d04
> 
> Dear Jeff,
> 
> 
> 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@kernel.org>
> 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.
> 
>      As a case in point, the recoverydir backend uses MD5 hashes to encode
>      long form clientid strings, which means that nfsd repeatedly gets 
> dinged
>      on FIPS audits, since MD5 isn't considered secure. Its use of MD5 
> is not
>      cryptographically significant, so there is no danger there, but 
> allowing
>      us to compile that out allows us to sidestep the issue entirely.
> 
>      As a prelude to eventually removing support for these client tracking
>      methods, add a new Kconfig option that enables them. Mark it deprecated
>      and make it default to N.
> 
>      Acked-by: NeilBrown <neilb@suse.de>
>      Signed-off-by: Jeff Layton <jlayton@kernel.org>
>      Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
> 
>   fs/nfsd/Kconfig       | 16 +++++++++
>   fs/nfsd/nfs4recover.c | 97 
> +++++++++++++++++++++++++++++++++------------------
>   fs/nfsd/nfsctl.c      |  6 ++++
>   3 files changed, 85 insertions(+), 34 deletions(-)
> 
> `NFSD_LEGACY_CLIENT_TRACKING` is not set:
> 
>      # CONFIG_NFSD_LEGACY_CLIENT_TRACKING is not set
> 
> 

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.

-- 
Jeff Layton <jlayton@kernel.org>

Re: NFSD: Unable to initialize client recovery tracking! (-110)

[Linux regression tracking (Thorsten Leemhuis)]

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@kernel.org>
>> 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).

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).

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.

Re: NFSD: Unable to initialize client recovery tracking! (-110)

[Jeff Layton]

On Fri, 2024-05-24 at 13:16 +0200, Linux regression tracking (Thorsten
Leemhuis) 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@kernel.org>
> > > 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).
> 
> 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).
> 
> 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.
> 

We simply changed the default in the Kconfig. That does not constitute
a regression, IMO. Why on earth would we continue to default enable an
option that we intend to deprecate in the near future?
-- 
Jeff Layton <jlayton@kernel.org>

Re: NFSD: Unable to initialize client recovery tracking! (-110)

[Chuck Lever III]

> On May 24, 2024, at 7:16 AM, Linux regression tracking (Thorsten Leemhuis) <regressions@leemhuis.info> 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@kernel.org>
>>> 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).


--
Chuck Lever

Re: NFSD: Unable to initialize client recovery tracking! (-110)

[Linux regression tracking (Thorsten Leemhuis)]

On 24.05.24 18:09, Chuck Lever III wrote:
>> On May 24, 2024, at 7:16 AM, Linux regression tracking (Thorsten Leemhuis) <regressions@leemhuis.info> 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@kernel.org>
>>>> 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.

Re: NFSD: Unable to initialize client recovery tracking! (-110)

[Jeff Layton]

On Fri, 2024-05-24 at 16:09 +0000, Chuck Lever III wrote:
> 
> 
> > On May 24, 2024, at 7:16 AM, Linux regression tracking (Thorsten
> > Leemhuis) <regressions@leemhuis.info> 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@kernel.org>
> > > > 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).
> 

I've no objection if you want to do that.

I'm more concerned about Paul's setup though. Paul, what distro are you
running that starts nfsd (and presumably, mountd, etc.), but doesn't
bother starting nfsdcld?

Reenabling this for now is an OK workaround, but we need to understand
where these setups are coming from, and probably do some sort of
outreach to get them working properly.
-- 
Jeff Layton <jlayton@kernel.org>

Re: NFSD: Unable to initialize client recovery tracking! (-110)

[Chuck Lever III]

> On May 29, 2024, at 9:13 AM, Jeff Layton <jlayton@kernel.org> wrote:
> 
> On Fri, 2024-05-24 at 16:09 +0000, Chuck Lever III wrote:
>> 
>> 
>>> On May 24, 2024, at 7:16 AM, Linux regression tracking (Thorsten
>>> Leemhuis) <regressions@leemhuis.info> 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@kernel.org>
>>>>> 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).
>> 
> 
> I've no objection if you want to do that.
> 
> I'm more concerned about Paul's setup though. Paul, what distro are you
> running that starts nfsd (and presumably, mountd, etc.), but doesn't
> bother starting nfsdcld?
> 
> Reenabling this for now is an OK workaround, but we need to understand
> where these setups are coming from, and probably do some sort of
> outreach to get them working properly.

Getting a root cause first seems prudent. I will hold off changes
for a bit.


--
Chuck Lever

Re: NFSD: Unable to initialize client recovery tracking! (-110)

[Paul Menzel]

Dear Jeff, dear Chuck, dear Thorsten,


Thank you for your responses, and sorry for not replying earlier.

Am 29.05.24 um 15:13 schrieb Jeff Layton:
> On Fri, 2024-05-24 at 16:09 +0000, Chuck Lever III wrote:

>>> On May 24, 2024, at 7:16 AM, Linux regression tracking (Thorsten
>>> Leemhuis) 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@kernel.org>
>>>>> 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).
> 
> I've no objection if you want to do that.
> 
> I'm more concerned about Paul's setup though. Paul, what distro are you
> running that starts nfsd (and presumably, mountd, etc.), but doesn't
> bother starting nfsdcld?
> 
> Reenabling this for now is an OK workaround, but we need to understand
> where these setups are coming from, and probably do some sort of
> outreach to get them working properly.

Thank you for the explanation. Due to historical reasons we maintain our 
own distribution MarIuX64 [1] and currently run Linux 5.15.x and 6.6.x. 
Installing nfsdcld is no problem, but it would have been nice to make 
this clearer in the error message, so people without being NFSD experts 
getting this message, knew what to do right away. Maybe:

NFSD: Unable to initialize client recovery tracking! (-110) Is nfsdcld 
running? Otherwise enable NFSD_LEGACY_CLIENT_TRACKING.


Kind regards,

Paul


[1]: https://github.molgen.mpg.de/mariux64/bee-files/
[2]: https://github.molgen.mpg.de/mariux64/bee-files/pull/3111