Re: [PATCH 07/14] sunrpc: add a generic netlink family for cache upcalls

[Chuck Lever]

On 3/19/26 3:20 PM, Chuck Lever wrote:
> On 3/19/26 3:19 PM, Jeff Layton wrote:
>> On Thu, 2026-03-19 at 15:14 -0400, Chuck Lever wrote:
>>> On 3/16/26 11:14 AM, Jeff Layton wrote:
>>>
>>>> diff --git a/fs/nfsd/netlink.c b/fs/nfsd/netlink.c
>>>> index 4e08c1a6b3943cda5b44c2b64bcf3a00173a08db..81c943345d13db849483bf0d6773458115ff0134 100644
>>>> --- a/fs/nfsd/netlink.c
>>>> +++ b/fs/nfsd/netlink.c
>>>> @@ -59,7 +59,7 @@ static const struct genl_split_ops nfsd_nl_ops[] = {
>>>>  		.cmd		= NFSD_CMD_THREADS_SET,
>>>>  		.doit		= nfsd_nl_threads_set_doit,
>>>>  		.policy		= nfsd_threads_set_nl_policy,
>>>> -		.maxattr	= NFSD_A_SERVER_MAX,
>>>> +		.maxattr	= NFSD_A_SERVER_FH_KEY,
>>>>  		.flags		= GENL_ADMIN_PERM | GENL_CMD_CAP_DO,
>>>>  	},
>>>>  	{
>>>
>>> This hunk is clearly not related to adding "a generic netlink family for
>>> cache upcalls". Should I apply it instead to the appropriate FH-signing
>>> patch, which is still in my nfsd-testing branch?
>>>
>>
>> I noticed that too. I think this is due to a change in the ynl tool.
>> The new way seems more correct since the "*_MAX" value is fluid.
>>
>> If you wanted, we could just regenerate the files with the new tool and
>> commit those changes first and then layer the new stuff on top.
> 
> I checked the tool, it hasn't changed.
I think "NFSD: Add a key for signing filehandles" introduced this
anomaly, so I've gone back to that patch and re-ran the tool. This was
the only change that was generated, so I applied it and pushed it to
nfsd-testing.


-- 
Chuck Lever