On Mon, Apr 15, 2024 at 01:43:37PM -0400, Jeff Layton wrote: > On Mon, 2024-04-15 at 17:37 +0000, Chuck Lever III wrote: > > > > > 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. > > > > Does it? Where are these rules written? > > What should we have it do now when read and written? Maybe EOPNOTSUPP > would be better, if we can make it just return an error? > > We could also make it just discard written data, and present a blank > string when read. What do the rules say we are required to do here? The best I could find was Documentation/process/stable-api-nonsense.rst. Tell you what, you and Petr work out what you'd like to do, let's figure out the right set of folks to review changes in /proc, and we'll go from there. If no-one has a problem removing the file, I'm not going to stand in the way. -- Chuck Lever
