From: Michal Kubecek <mkubecek@suse.cz>
To: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
Cc: Johannes Berg <johannes@sipsolutions.net>,
linux-wireless@vger.kernel.org, netdev@vger.kernel.org,
Johannes Berg <johannes.berg@intel.com>
Subject: Re: [PATCH 1/2] netlink: add NLA_REJECT policy type
Date: Thu, 13 Sep 2018 23:27:42 +0200 [thread overview]
Message-ID: <20180913212742.GC3876@unicorn.suse.cz> (raw)
In-Reply-To: <20180913193004.GF4590@localhost.localdomain>
On Thu, Sep 13, 2018 at 04:30:04PM -0300, Marcelo Ricardo Leitner wrote:
> On Thu, Sep 13, 2018 at 10:46:02AM +0200, Johannes Berg wrote:
> > From: Johannes Berg <johannes.berg@intel.com>
> >
> > In some situations some netlink attributes may be used for output
> > only (kernel->userspace) or may be reserved for future use. It's
> > then helpful to be able to prevent userspace from using them in
> > messages sent to the kernel, since they'd otherwise be ignored and
> > any future will become impossible if this happens.
>
> I don't follow, what's the issue with simply ignoring such attributes?
A bit artificial example but I can't come with somethin better at the
moment: let's say newer kernel and iproute2 allow something like
ip link del <condition1> <condition2>
and you run new ip with older kernel which only supports <condition1>.
You don't really want kernel to silently ignore the second condition.
Or e.g. when adding a netfilter rule, you wouldn't want kernel to ignore
parts of the rule it does not understand.
I must admit I'm not sure if there is really need for having reserved
attributes with netlink. Maybe e.g. when we want to share part of
(numeric) attribute types between different message types. Anyway, we
have the same problem with attributes higher than maximum; NLA_REJECT
wouldn't help with this but the discussion also touched the topic.
> > Add NLA_REJECT to the policy which does nothing but reject (with
> > EINVAL) validation of any messages containing this attribute.
> > Allow for returning a specific extended ACK error message in the
> > validation_data pointer.
>
> This has potential to create confusion because we can't use it on
> {output,reserved} attributes that are already there (as we must always
> ignore them now) and we will end up with a mix of it.
We can return -EINVAL even now, we just need to add a check after
nla_parse() wrapper returns, e.g. here: (lines 314-320)
https://github.com/mkubecek/ethnl/blob/master/kernel/0019-ethtool-implement-SET_PARAMS-message.patch#L314
It would be easier and IMHO cleaner if I could simply list these "read
only attributes" with NLA_REJECT policy for "set" request.
Michal Kubecek
next prev parent reply other threads:[~2018-09-14 2:39 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-13 8:46 [PATCH 1/2] netlink: add NLA_REJECT policy type Johannes Berg
2018-09-13 8:46 ` Johannes Berg
2018-09-13 8:46 ` [PATCH 2/2] netlink: add ethernet address policy types Johannes Berg
2018-09-13 11:58 ` Michal Kubecek
2018-09-13 11:58 ` Michal Kubecek
2018-09-13 12:02 ` Johannes Berg
2018-09-13 12:12 ` Michal Kubecek
2018-09-13 12:16 ` Johannes Berg
2018-09-13 12:24 ` Michal Kubecek
2018-09-13 12:24 ` Michal Kubecek
2018-09-13 12:46 ` Johannes Berg
2018-09-13 12:46 ` Johannes Berg
2018-09-13 16:03 ` Michal Kubecek
2018-09-13 19:41 ` Marcelo Ricardo Leitner
2018-09-13 20:39 ` Michal Kubecek
2018-09-17 7:45 ` Johannes Berg
2018-09-13 10:49 ` [PATCH 1/2] netlink: add NLA_REJECT policy type Michal Kubecek
2018-09-13 11:25 ` Johannes Berg
2018-09-13 11:25 ` Johannes Berg
2018-09-13 12:05 ` Michal Kubecek
2018-09-13 19:20 ` Marcelo Ricardo Leitner
2018-09-13 20:43 ` Michal Kubecek
2018-09-13 19:30 ` Marcelo Ricardo Leitner
2018-09-13 21:27 ` Michal Kubecek [this message]
2018-09-13 21:58 ` Marcelo Ricardo Leitner
2018-09-17 9:38 ` Johannes Berg
2018-09-17 9:38 ` Johannes Berg
2018-09-17 20:17 ` Marcelo Ricardo Leitner
2018-09-18 12:34 ` Jamal Hadi Salim
2018-09-18 12:34 ` Jamal Hadi Salim
2018-09-18 12:39 ` Johannes Berg
2018-09-18 12:55 ` Jamal Hadi Salim
2018-09-18 12:57 ` Johannes Berg
2018-09-18 13:12 ` Jamal Hadi Salim
2018-09-18 16:42 ` Johannes Berg
2018-09-13 22:59 ` David Miller
2018-09-17 9:39 ` Johannes Berg
2018-09-17 9:39 ` Johannes Berg
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=20180913212742.GC3876@unicorn.suse.cz \
--to=mkubecek@suse.cz \
--cc=johannes.berg@intel.com \
--cc=johannes@sipsolutions.net \
--cc=linux-wireless@vger.kernel.org \
--cc=marcelo.leitner@gmail.com \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.