[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <9211971b-a392-4568-b147-d7e97c69ca54@fiberby.net>
Date: Sat, 13 Sep 2025 23:14:33 +0000
From: Asbjørn Sloth Tønnesen <ast@...erby.net>
To: Jakub Kicinski <kuba@...nel.org>
Cc: "Jason A. Donenfeld" <Jason@...c4.com>,
"David S. Miller" <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>,
Paolo Abeni <pabeni@...hat.com>, Donald Hunter <donald.hunter@...il.com>,
Simon Horman <horms@...nel.org>, Jacob Keller <jacob.e.keller@...el.com>,
Sabrina Dubroca <sd@...asysnail.net>, wireguard@...ts.zx2c4.com,
netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH net-next v3 08/13] tools: ynl-gen: only validate nested
array payload
On 9/13/25 12:27 AM, Jakub Kicinski wrote:
> On Thu, 11 Sep 2025 20:05:01 +0000 Asbjørn Sloth Tønnesen wrote:
>> +int ynl_attr_validate_payload(struct ynl_parse_arg *yarg,
>> + const struct nlattr *attr, unsigned int type)
>> +{
>> + return __ynl_attr_validate(yarg, attr, type);
>> +}
>
> Why not expose __ynl_attr_validate() to the callers?
> I don't think the _payload() suffix is crystal clear, we're still
> validating attr, _payload() makes it sound like we're validating
> what's inside attr?
I didn't wanna call __ynl_attr_validate() directly, as the only __ynl_*
function in ynl-priv.h is __ynl_attr_put_overflow(), and that is only
used in other static functions within that file. I agree, that _payload()
might not be the best given that we currently don't look deeper than
validating that the length a bit, so maybe _length() would have been
better.
In v4, I have changed it to just expose __ynl_attr_validate() in
ynl-priv.h, and changed ynl_attr_validate() to an inline function.
Powered by blists - more mailing lists