From: Jiri Pirko <jiri@resnulli•us>
To: David Ahern <dsahern@gmail•com>
Cc: Jamal Hadi Salim <jhs@mojatatu•com>,
davem@davemloft•net, netdev@vger•kernel.org,
xiyou.wangcong@gmail•com, eric.dumazet@gmail•com,
mrv@mojatatu•com, simon.horman@netronome•com,
alex.aring@gmail•com
Subject: Re: [PATCH net-next v11 1/4] net netlink: Add new type NLA_BITFIELD_32
Date: Fri, 28 Jul 2017 16:55:36 +0200 [thread overview]
Message-ID: <20170728145536.GE1857@nanopsycho> (raw)
In-Reply-To: <886e9fe5-d523-4841-1a81-e5671447933a@gmail.com>
Fri, Jul 28, 2017 at 04:19:06PM CEST, dsahern@gmail•com wrote:
>On 7/28/17 7:51 AM, Jamal Hadi Salim wrote:
>> On 17-07-25 10:41 AM, David Ahern wrote:
>>> On 7/23/17 7:35 PM, Jamal Hadi Salim wrote:
>>>> In the most basic form, the user specifies the attribute policy as:
>>>> [ATTR_GOO] = { .type = NLA_BITFIELD_32, .validation_data =
>>>> &myvalidflags },
>>>>
>>>> where myvalidflags is the bit mask of the flags the kernel understands.
>>>>
>>>> If the user _does not_ provide myvalidflags then the attribute will
>>>> also be rejected.
>>>
>>> No other netlink attribute has this requirement.
>>
>> This is the first one where we have to inspect content. We add things
>> when we need them - as in this case.
>
>Sure, the validation is required. My argument is that the validation
>should be done where other attributes are validated -- inline with its
>use. Nothing about this new bitfield says it must have a generic
>validation code.
>
>>
>>> Users of the attributes
>>> are the only ones that know if a value is valid or not (e.g, attribute
>>> passing a device index) and those are always checked in line.
>>
>> It doesnt make sense that every user of the API has to repeat that
>> validation code. Same principle as someone specifying that a type is
>> u32 and have the nla validation check it. At some point we never had
>> the u32 validation code. Then it was factored out because everyone
>> repeats the same boilerplate code.
>
>Every user of an attribute that uses a device index must verify the
>device index is valid. The same code is repeated over and over.
This is something different. You don't have NLA_IFINDEX. If you'd have it,
might make sense to do validation on Netlink level. Ofc this is highly
hypothetical. But in Jamal's case, there is indeed NLA_BITFIELD32 and
this attribute type itself assumes some format. Therefore the validation
on Netlink level makes sense here. At least that is how I feel it.
>
>Now you are suggesting to have 1 attribute whose content is validated by
>generic infra and the rest are validated inline by the code using it. I
>believe it is wrong and going to lead to problems.
next prev parent reply other threads:[~2017-07-28 14:55 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-24 1:35 [PATCH net-next v11 0/4] net sched actions: improve dump performance Jamal Hadi Salim
2017-07-24 1:35 ` [PATCH net-next v11 1/4] net netlink: Add new type NLA_BITFIELD_32 Jamal Hadi Salim
2017-07-24 11:14 ` Jiri Pirko
2017-07-25 11:14 ` Jamal Hadi Salim
2017-07-24 11:18 ` Jiri Pirko
2017-07-25 11:15 ` Jamal Hadi Salim
2017-07-25 14:41 ` David Ahern
2017-07-28 13:51 ` Jamal Hadi Salim
2017-07-28 14:08 ` Jiri Pirko
2017-07-28 14:19 ` David Ahern
2017-07-28 14:55 ` Jiri Pirko [this message]
2017-07-28 15:04 ` Jamal Hadi Salim
2017-07-28 15:13 ` David Ahern
2017-07-28 21:55 ` Jamal Hadi Salim
2017-07-24 1:35 ` [PATCH net-next v11 2/4] net sched actions: Use proper root attribute table for actions Jamal Hadi Salim
2017-07-24 1:35 ` [PATCH net-next v11 3/4] net sched actions: dump more than TCA_ACT_MAX_PRIO actions per batch Jamal Hadi Salim
2017-07-24 11:27 ` Jiri Pirko
2017-07-25 11:22 ` Jamal Hadi Salim
2017-07-25 11:33 ` Jiri Pirko
2017-07-25 12:34 ` Jamal Hadi Salim
2017-07-25 12:37 ` Jiri Pirko
2017-07-28 13:41 ` Jamal Hadi Salim
2017-07-28 14:12 ` Jiri Pirko
2017-07-28 14:52 ` Jamal Hadi Salim
2017-07-28 14:57 ` Jiri Pirko
2017-07-28 15:08 ` Jamal Hadi Salim
2017-07-28 15:45 ` Jiri Pirko
2017-07-28 22:10 ` Jamal Hadi Salim
2017-07-29 7:19 ` Jiri Pirko
2017-07-29 11:21 ` Jamal Hadi Salim
2017-07-24 1:35 ` [PATCH net-next v11 4/4] net sched actions: add time filter for action dumping Jamal Hadi Salim
2017-07-24 11:34 ` Jiri Pirko
2017-07-25 11:27 ` Jamal Hadi Salim
2017-07-25 11:34 ` Jiri Pirko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170728145536.GE1857@nanopsycho \
--to=jiri@resnulli$(echo .)us \
--cc=alex.aring@gmail$(echo .)com \
--cc=davem@davemloft$(echo .)net \
--cc=dsahern@gmail$(echo .)com \
--cc=eric.dumazet@gmail$(echo .)com \
--cc=jhs@mojatatu$(echo .)com \
--cc=mrv@mojatatu$(echo .)com \
--cc=netdev@vger$(echo .)kernel.org \
--cc=simon.horman@netronome$(echo .)com \
--cc=xiyou.wangcong@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox