[LTP] [PATCH 1/1] proc01: Whitelist /proc/fs/nfsd/nfsv4recoverydir

[Chuck Lever III]

> On Apr 15, 2024, at 1:35 PM, Jeff Layton <jlayton@kernel.org> 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@suse.cz> wrote:
>>> 
>>> /proc/fs/nfsd/nfsv4recoverydir started from kernel 6.8 report EINVAL.
>>> 
>>> Signed-off-by: Petr Vorel <pvorel@suse.cz>
>>> ---
>>> 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