netdev - Re: [PATCH net-next 01/15] tools: ynl: give up on libmnl for auto-ints

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <5ec74f4d-5dbd-4c2d-ab11-d00b0208b138@6wind.com>
Date: Fri, 23 Feb 2024 14:51:12 +0100
From: Nicolas Dichtel <nicolas.dichtel@...nd.com>
To: Jakub Kicinski <kuba@...nel.org>, davem@...emloft.net
Cc: netdev@...r.kernel.org, edumazet@...gle.com, pabeni@...hat.com,
 jiri@...nulli.us, sdf@...gle.com, donald.hunter@...il.com
Subject: Re: [PATCH net-next 01/15] tools: ynl: give up on libmnl for
 auto-ints

Le 23/02/2024 à 00:56, Jakub Kicinski a écrit :
> The temporary auto-int helpers are not really correct.
> We can't treat signed and unsigned ints the same when
> determining whether we need full 8B. I realized this
> before sending the patch to add support in libmnl.
> Unfortunately, that patch has not been merged,
> so time to fix our local helpers. Use the mnl* name
> for now, subsequent patches will address that.
> 
> Signed-off-by: Jakub Kicinski <kuba@...nel.org>> ---
>  tools/net/ynl/lib/ynl-priv.h | 45 ++++++++++++++++++++++++++++--------
>  1 file changed, 36 insertions(+), 9 deletions(-)
> 
> diff --git a/tools/net/ynl/lib/ynl-priv.h b/tools/net/ynl/lib/ynl-priv.h
> index 7491da8e7555..eaa0d432366c 100644
> --- a/tools/net/ynl/lib/ynl-priv.h
> +++ b/tools/net/ynl/lib/ynl-priv.h
> @@ -125,20 +125,47 @@ int ynl_exec_dump(struct ynl_sock *ys, struct nlmsghdr *req_nlh,
>  void ynl_error_unknown_notification(struct ynl_sock *ys, __u8 cmd);
>  int ynl_error_parse(struct ynl_parse_arg *yarg, const char *msg);
>  
> -#ifndef MNL_HAS_AUTO_SCALARS
> -static inline uint64_t mnl_attr_get_uint(const struct nlattr *attr)
> +/* Attribute helpers */
> +
> +static inline __u64 mnl_attr_get_uint(const struct nlattr *attr)
>  {
> -	if (mnl_attr_get_payload_len(attr) == 4)
> +	switch (mnl_attr_get_payload_len(attr)) {
> +	case 4:
>  		return mnl_attr_get_u32(attr);
> -	return mnl_attr_get_u64(attr);
> +	case 8:
> +		return mnl_attr_get_u64(attr);
> +	default:
> +		return 0;
> +	}
> +}
> +
> +static inline __s64 mnl_attr_get_sint(const struct nlattr *attr)
> +{
> +	switch (mnl_attr_get_payload_len(attr)) {
> +	case 4:
> +		return mnl_attr_get_u32(attr);
> +	case 8:
> +		return mnl_attr_get_u64(attr);
> +	default:
> +		return 0;
> +	}
>  }
mnl_attr_get_uint() and mnl_attr_get_sint() are identical. What about
#define mnl_attr_get_sint mnl_attr_get_uint
?

>  
>  static inline void
> -mnl_attr_put_uint(struct nlmsghdr *nlh, uint16_t type, uint64_t data)
> +mnl_attr_put_uint(struct nlmsghdr *nlh, __u16 type, __u64 data)
Is there a reason to switch from uint*_t to __u* types?

>  {
> -	if ((uint32_t)data == (uint64_t)data)
> -		return mnl_attr_put_u32(nlh, type, data);
> -	return mnl_attr_put_u64(nlh, type, data);
> +	if ((__u32)data == (__u64)data)
> +		mnl_attr_put_u32(nlh, type, data);
> +	else
> +		mnl_attr_put_u64(nlh, type, data);
> +}
> +
> +static inline void
> +mnl_attr_put_sint(struct nlmsghdr *nlh, __u16 type, __s64 data)
> +{
> +	if ((__s32)data == (__s64)data)
> +		mnl_attr_put_u32(nlh, type, data);
> +	else
> +		mnl_attr_put_u64(nlh, type, data);
>  }
>  #endif
> -#endif