> On Apr 15, 2024, at 1:35 PM, Jeff Layton <jlayton@xxxxxxxxxx> wrote: > > On Mon, 2024-04-15 at 17:27 +0000, Chuck Lever III wrote: >> >>> On Apr 15, 2024, at 1:21 PM, Petr Vorel <pvorel@xxxxxxx> wrote: >>> >>> /proc/fs/nfsd/nfsv4recoverydir started from kernel 6.8 report EINVAL. >>> >>> Signed-off-by: Petr Vorel <pvorel@xxxxxxx> >>> --- >>> Hi, >>> >>> @ Jeff, Chuck, Neil, NFS devs: The patch itself whitelist reading >>> /proc/fs/nfsd/nfsv4recoverydir in LTP test. I suspect reading failed >>> with EINVAL in 6.8 was a deliberate change and expected behavior when >>> CONFIG_NFSD_LEGACY_CLIENT_TRACKING is not set: >> >> I'm not sure it was deliberate. This seems like a behavior >> regression. Jeff? >> > > I don't think I intended to make it return -EINVAL. I guess that's what > happens when there is no entry for it in the write_op array. > > With CONFIG_NFSD_LEGACY_CLIENT_TRACKING disabled, that file has no > meaning or value at all anymore. Maybe we should just remove the dentry > altogether when CONFIG_NFSD_LEGACY_CLIENT_TRACKING is disabled? My understanding of the rules about modifying this part of the kernel-user interface is that the file has to stay, even though it's now a no-op. -- Chuck Lever
