From: Vitaly Kuznetsov <vkuznets@redhat•com>
To: Eric Dumazet <eric.dumazet@gmail•com>
Cc: Andrew Lunn <andrew@lunn•ch>,
network dev <netdev@vger•kernel.org>,
"David S. Miller" <davem@davemloft•net>,
Eric Dumazet <edumazet@google•com>,
Stephen Hemminger <stephen@networkplumber•org>
Subject: Re: [PATCH RFC net-next] net: Allow name change of IFF_UP interfaces
Date: Thu, 10 Aug 2017 12:01:46 +0200 [thread overview]
Message-ID: <87poc3wxkl.fsf@vitty.brq.redhat.com> (raw)
In-Reply-To: <1502355817.4936.9.camel@edumazet-glaptop3.roam.corp.google.com> (Eric Dumazet's message of "Thu, 10 Aug 2017 02:03:37 -0700")
Eric Dumazet <eric.dumazet@gmail•com> writes:
> On Thu, 2017-08-10 at 10:41 +0200, Vitaly Kuznetsov wrote:
>> Andrew Lunn <andrew@lunn•ch> writes:
>>
>> >> I understand the 'legacy' concern but at the same time we don't want to
>> >> have aftificial limitations too. Name change, in particular, doesn't
>> >> happen 'under the hood' -- someone privileged enough needs to request
>> >> the change.
>> >>
>> >> Can you think of any particular real world scenarios which are broken by
>> >> the change?
>> >
>> > How about:
>> >
>> > man 8 dhclient-script
>> >
>> > The interface name is passed in $interface to the scripts. Do we get
>> > the old name or the new name? I suspect scripts are going to break if
>> > they are given the old name, which no longer exists.
>>
>> Yes but why would anyone change interface name while dhclient-script is
>> running? Things will also go wrong if you try bringing interface down
>> during the run or do some other configuration, right? Running multiple
>> configuration tools at the same moment is a bad idea, you never know
>> what you're gonna end up with.
>>
>> As I see it, checks in kernel we have are meant to protect kernel
>> itself, not to disallow all user<->kernel interactions leading to
>> imperfect result.
>>
>> (AFAIU) If we remove the check nothing is going to change: udev will
>> still be renaming interfaces before bringing them up. In netvsc case
>> users are not supposed to configure the VF interface at all, it just
>> becomes a slave of netvsc interface.
>
> Are we sending an event if device name is changed ?
>
We are - rtnetlink_event() does the job. We, however, don't have a
special IFLA_EVENT_* for name change and end up with IFLA_EVENT_NONE.
> If yes, your patch is fine.
>
> If not, daemons would not be aware the need to refresh their view of the
> world.
Yes but AFAIU daemons may need to do the same refresh when the interface
is down too (and, hopefully, they do it already).
--
Vitaly
next prev parent reply other threads:[~2017-08-10 10:01 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-09 10:42 [PATCH RFC net-next] net: Allow name change of IFF_UP interfaces Vitaly Kuznetsov
2017-08-09 12:29 ` 吉藤英明
2017-08-09 15:05 ` Vitaly Kuznetsov
2017-08-09 16:10 ` Andrew Lunn
2017-08-10 8:41 ` Vitaly Kuznetsov
2017-08-10 9:03 ` Eric Dumazet
2017-08-10 10:01 ` Vitaly Kuznetsov [this message]
2017-08-10 14:13 ` Andrew Lunn
2017-08-10 15:24 ` Vitaly Kuznetsov
2017-08-10 16:27 ` Andrew Lunn
2017-08-10 16:33 ` Vitaly Kuznetsov
2017-08-10 16:48 ` David Miller
2017-08-10 16:55 ` David Ahern
2017-08-10 17:16 ` Stephen Hemminger
2017-08-11 9:01 ` Vitaly Kuznetsov
2017-08-10 14:10 ` Andrew Lunn
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=87poc3wxkl.fsf@vitty.brq.redhat.com \
--to=vkuznets@redhat$(echo .)com \
--cc=andrew@lunn$(echo .)ch \
--cc=davem@davemloft$(echo .)net \
--cc=edumazet@google$(echo .)com \
--cc=eric.dumazet@gmail$(echo .)com \
--cc=netdev@vger$(echo .)kernel.org \
--cc=stephen@networkplumber$(echo .)org \
/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