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]
Date:   Mon, 12 Jun 2017 07:10:56 -0400
From:   Jamal Hadi Salim <jhs@...atatu.com>
To:     Jiri Pirko <jiri@...nulli.us>
Cc:     davem@...emloft.net, netdev@...r.kernel.org,
        xiyou.wangcong@...il.com, eric.dumazet@...il.com,
        simon.horman@...ronome.com, mrv@...atatu.com
Subject: Re: [PATCH net-next v10 1/4] net netlink: Add new type NLA_FLAG_BITS

On 17-06-12 06:34 AM, Jiri Pirko wrote:
> Sun, Jun 11, 2017 at 08:37:25PM CEST, jhs@...atatu.com wrote:
>> On 17-06-11 01:38 PM, Jamal Hadi Salim wrote:
>>> On 17-06-11 09:49 AM, Jiri Pirko wrote:
>>>> Sun, Jun 11, 2017 at 01:53:43PM CEST, jhs@...atatu.com wrote:
>>>>> From: Jamal Hadi Salim <jhs@...atatu.com>
>>>
>>>
>>>>> This patch also provides an extra feature: a validation callback
>>>>> that could be speaciliazed for other types.
>>>>
>>>> s/speaciliazed/speciliazed/
>>>>
>>>
>>> Will fix.
>>>
>>>
>>>>>
>>>>> [ATTR_GOO] = { .type = MYTYPE,
>>>>>             .validation_data = &myvalidation_data,
>>>>>                 .validate_content = mycontent_validator },
>>>>
>>>> Indent is wrong. (Does not matter really in desc, but anyway)
>>>>
>>>
>>> I cant find out how it got indented that way; my source
>>> or email dont show it as such (but really doesnt matter).
>>>
>>>
>>>> Suggested-by: Jiri Pirko <jiri@...lanox.com>
>>>>
>>>
>>> Will add.
>>>
>>>>
>>>>> ---
>>>>> include/net/netlink.h          | 11 +++++++++++
>>>>> include/uapi/linux/rtnetlink.h | 17 +++++++++++++++++
>>>>> lib/nlattr.c                   | 25 +++++++++++++++++++++++++
>>>>> 3 files changed, 53 insertions(+)
>>>>>
>>>>> diff --git a/include/net/netlink.h b/include/net/netlink.h
>>>>> index 0170917..8ab9784 100644
>>>>> --- a/include/net/netlink.h
>>>>> +++ b/include/net/netlink.h
>>>>> @@ -6,6 +6,11 @@
>>>>> #include <linux/jiffies.h>
>>>>> #include <linux/in6.h>
>>>>>
>>>>> +struct nla_bit_flags {
>>>>> +    u32 nla_flag_values;
>>>>> +    u32 nla_flag_selector;
>>>>> +};
>>>>
>>>> I don't understand why you redefine the struct here. You already have it
>>>> defined in the uapi: struct __nla_bit_flags
>>>>
>>>> Just move this (struct nla_bit_flags) to the uapi and remove
>>>> __nla_bit_flags ?
>>>>
>>>
>>> I am not sure that will compile since the type is defined in netlink.h
>>> Also, note: uapi uses _u32 and kernel uses u32 as types i.e it is pretty
>>> common approach; i will try to move it to uapi and keep that uapi
>>> format. If it doesnt compile without acrobatics I will keep it as is.
>>>
>>
>> It doesnt compile - I could move it to linux/netlink.h but it seems
>> so out of place.
>> so i will keep things as is for now unless you can think of something
>> else.
> 
> First of all, makes no sense to put this struct "struct __nla_bit_flags"
> into rtnetlink.h uapi file. This is generic netlink stuff, not specifict
> to rtnetlink.
> 
> I believe that this struct should go into:
> include/uapi/linux/netlink.h
> 
> struct nla_flag_bits {
> 	__u32 nla_flag_bits_values;
> 	__u32 nla_flag_bits_selector;
> };
> 
> Then you can use it from userspace and everywhere in kernel.
> 
That file seems to be very out of place for this stuff.

> Btw, I find it very odd that enum containling NLA_* like NLA_U32 and
> others is not part of uapi file and is rather defined in
> include/net/netlink.h. Any idea why?
> 

NLA_XXX are kernel side types.  They are part of net/netlink.h which is
not uapi accessible.
David Ahern has submitted a patch to move all those defines to iproute2.
Will make sense to move these to a uapi/linux/netlink-types.h but that
is waay beyond the scope of this patch set.

cheers,
jamal

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ