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: <dfb07217-0b0b-426f-974a-76b81eca3935@6wind.com>
Date: Fri, 23 Feb 2024 16:07:34 +0100
From: Nicolas Dichtel <nicolas.dichtel@...nd.com>
To: Jakub Kicinski <kuba@...nel.org>
Cc: davem@...emloft.net, 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 à 15:35, Jakub Kicinski a écrit :
> On Fri, 23 Feb 2024 14:51:12 +0100 Nicolas Dichtel wrote:
>>> +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
>> ?
> 
> I like to have the helpers written out 🤷️
> I really hate the *_encode_bits macros in the kernel, maybe I'm
> swinging to hard in the opposite direction, but let me swing! :)
No problem :)
Anyway, after the patch #2, the code in different ;-)

> 
>>>  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?
> 
> YNL uses the kernel __{s,u}{8,16,32,64} types everywhere.
> These were an exception because they were following libmnl's types.
Ok.