From: Michal Kubecek <mkubecek@suse.cz>
To: netdev@vger.kernel.org
Cc: Roopa Prabhu <roopa@cumulusnetworks.com>,
Jiri Pirko <jiri@resnulli.us>, David Miller <davem@davemloft.net>,
Jakub Kicinski <jakub.kicinski@netronome.com>,
David Ahern <dsahern@gmail.com>,
Stephen Hemminger <sthemmin@microsoft.com>,
dcbw@redhat.com, Andrew Lunn <andrew@lunn.ch>,
parav@mellanox.com, Saeed Mahameed <saeedm@mellanox.com>,
mlxsw <mlxsw@mellanox.com>
Subject: Re: [patch net-next rfc 3/7] net: rtnetlink: add commands to add and delete alternative ifnames
Date: Fri, 30 Aug 2019 16:49:34 +0200 [thread overview]
Message-ID: <20190830144934.GQ29594@unicorn.suse.cz> (raw)
In-Reply-To: <CAJieiUgGY4amm_z1VGgBF-3WZceah+R5OVLEi=O2RS8RGpC9dg@mail.gmail.com>
On Fri, Aug 30, 2019 at 07:35:23AM -0700, Roopa Prabhu wrote:
> On Wed, Aug 28, 2019 at 10:26 PM Michal Kubecek <mkubecek@suse.cz> wrote:
> >
> > On Wed, Aug 28, 2019 at 09:36:41PM -0700, Roopa Prabhu wrote:
> > >
> > > yes, correct. I mentioned that because I was wondering if we can
> > > think along the same lines for this API.
> > > eg
> > > (a) RTM_NEWLINK always replaces the list attribute
> > > (b) RTM_SETLINK with NLM_F_APPEND always appends to the list attribute
> > > (c) RTM_DELLINK with NLM_F_APPEND updates the list attribute
> > >
> > > (It could be NLM_F_UPDATE if NLM_F_APPEND sounds weird in the del
> > > case. I have not looked at the full dellink path if it will work
> > > neatly..its been a busy day )
> >
> > AFAICS rtnl_dellink() calls nlmsg_parse_deprecated() so that even
> > current code would ignore any future attribute in RTM_DELLINK message
> > (any kernel before the strict validation was introduced definitely will)
> > and it does not seem to check NLM_F_APPEND or NLM_F_UPDATE either. So
> > unless I missed something, such message would result in deleting the
> > network device (if possible) with any kernel not implementing the
> > feature.
>
> ok, ack. yes today it does. I was hinting if that can be changed to
> support list update with a flag like the RTM_DELLINK AF_BRIDGE does
> for vlan list del.
What I wanted to say is that it would have to be done in a way that
would make current kernel (or even older, e.g. one with no strict
attribute checking at all) reject or at least ignore such request,
not delete the device.
Michal
next prev parent reply other threads:[~2019-08-30 14:49 UTC|newest]
Thread overview: 76+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-19 11:00 [patch net-next rfc 0/7] net: introduce alternative names for network interfaces Jiri Pirko
2019-07-19 11:00 ` [patch net-next rfc 1/7] net: procfs: use index hashlist instead of name hashlist Jiri Pirko
2019-07-19 11:00 ` [patch net-next rfc 2/7] net: introduce name_node struct to be used in hashlist Jiri Pirko
2019-07-19 16:29 ` Stephen Hemminger
2019-07-19 19:17 ` Jiri Pirko
2019-07-19 20:26 ` Stephen Hemminger
2019-07-20 7:15 ` Jiri Pirko
2019-09-13 9:52 ` Jiri Pirko
2019-08-08 4:34 ` kbuild test robot
2019-07-19 11:00 ` [patch net-next rfc 3/7] net: rtnetlink: add commands to add and delete alternative ifnames Jiri Pirko
2019-07-20 3:58 ` Jakub Kicinski
2019-07-20 7:20 ` Jiri Pirko
2019-08-09 4:11 ` Roopa Prabhu
2019-08-09 6:25 ` Jiri Pirko
2019-08-09 15:40 ` Roopa Prabhu
2019-08-09 15:46 ` Michal Kubecek
2019-08-10 13:46 ` Roopa Prabhu
2019-08-10 15:50 ` Michal Kubecek
2019-08-10 19:39 ` Roopa Prabhu
2019-08-11 22:10 ` Michal Kubecek
2019-08-12 15:21 ` Roopa Prabhu
2019-08-12 15:43 ` Michal Kubecek
2019-08-09 16:14 ` David Ahern
2019-08-10 6:30 ` Jiri Pirko
2019-08-12 1:34 ` David Ahern
2019-08-12 1:37 ` David Ahern
2019-08-12 8:31 ` Jiri Pirko
2019-08-12 15:13 ` Roopa Prabhu
2019-08-12 21:43 ` Jakub Kicinski
2019-08-13 0:29 ` David Ahern
2019-08-13 6:53 ` Jiri Pirko
2019-08-13 6:51 ` Jiri Pirko
2019-08-12 15:40 ` Stephen Hemminger
2019-08-12 16:23 ` Roopa Prabhu
2019-08-13 6:55 ` Jiri Pirko
2019-08-12 16:01 ` David Ahern
2019-08-13 6:56 ` Jiri Pirko
2019-08-26 16:09 ` Jiri Pirko
2019-08-26 16:55 ` Jakub Kicinski
2019-08-26 21:46 ` David Ahern
2019-08-26 22:15 ` Jakub Kicinski
2019-08-26 22:18 ` David Miller
2019-08-26 22:24 ` David Ahern
2019-08-26 22:25 ` David Miller
2019-08-27 0:17 ` David Ahern
2019-08-27 5:09 ` Michal Kubecek
2019-08-27 7:08 ` Jiri Pirko
2019-08-27 8:22 ` David Miller
2019-08-27 9:35 ` Jiri Pirko
2019-08-27 15:14 ` Roopa Prabhu
2019-08-28 7:07 ` Jiri Pirko
2019-08-29 4:36 ` Roopa Prabhu
2019-08-29 5:26 ` Michal Kubecek
2019-08-30 14:35 ` Roopa Prabhu
2019-08-30 14:47 ` David Ahern
2019-08-30 17:04 ` Jiri Pirko
2019-08-30 14:49 ` Michal Kubecek [this message]
2019-08-30 17:03 ` Jiri Pirko
2019-09-12 11:59 ` Jiri Pirko
2019-09-13 8:21 ` Jiri Pirko
2019-09-13 14:50 ` Jiri Pirko
2019-08-27 4:55 ` Michal Kubecek
2019-08-27 13:43 ` David Ahern
2019-08-10 6:32 ` Jiri Pirko
2019-07-19 11:00 ` [patch net-next rfc 4/7] net: rtnetlink: put alternative names to getlink message Jiri Pirko
2019-07-20 3:59 ` Jakub Kicinski
2019-07-20 7:17 ` Jiri Pirko
2019-07-19 11:00 ` [patch net-next rfc 5/7] net: rtnetlink: unify the code in __rtnl_newlink get dev with the rest Jiri Pirko
2019-07-19 11:00 ` [patch net-next rfc 6/7] net: rtnetlink: introduce helper to get net_device instance by ifname Jiri Pirko
2019-07-19 11:00 ` [patch net-next rfc 7/7] net: rtnetlink: add possibility to use alternative names as message handle Jiri Pirko
2019-07-20 3:59 ` Jakub Kicinski
2019-07-20 7:22 ` Jiri Pirko
2019-07-19 11:03 ` [patch iproute2 rfc 1/2] ip: add support for alternative name addition/deletion/list Jiri Pirko
2019-07-19 11:03 ` [patch iproute2 rfc 2/2] ip: allow to use alternative names as handle Jiri Pirko
2019-07-19 16:31 ` [patch net-next rfc 0/7] net: introduce alternative names for network interfaces Stephen Hemminger
2019-07-19 19:16 ` 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=20190830144934.GQ29594@unicorn.suse.cz \
--to=mkubecek@suse.cz \
--cc=andrew@lunn.ch \
--cc=davem@davemloft.net \
--cc=dcbw@redhat.com \
--cc=dsahern@gmail.com \
--cc=jakub.kicinski@netronome.com \
--cc=jiri@resnulli.us \
--cc=mlxsw@mellanox.com \
--cc=netdev@vger.kernel.org \
--cc=parav@mellanox.com \
--cc=roopa@cumulusnetworks.com \
--cc=saeedm@mellanox.com \
--cc=sthemmin@microsoft.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).