netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: David Ahern <dsahern@gmail.com>
To: Kirill Tkhai <ktkhai@virtuozzo.com>, netdev@vger.kernel.org
Cc: davem@davemloft.net, daniel@iogearbox.net,
	jakub.kicinski@netronome.com, ast@kernel.org,
	linux@rasmusvillemoes.dk, john.fastabend@gmail.com,
	brouer@redhat.com
Subject: Re: [PATCH] net: Fix device name resolving crash in default_device_exit()
Date: Thu, 21 Jun 2018 09:28:21 -0600	[thread overview]
Message-ID: <5e4b9ecd-e7f5-87e4-2b45-2aaaca125442@gmail.com> (raw)
In-Reply-To: <84f7019b-c1cb-9851-2ece-aa2e16d8d297@virtuozzo.com>

On 6/21/18 4:03 AM, Kirill Tkhai wrote:
>> This patch does not remove the BUG, so does not really solve the
>> problem. ie., it is fairly trivial to write a script (32k dev%d named
>> devices in init_net) that triggers it again, so your commit subject and
>> commit log are not correct with the references to 'fixing the problem'.
> 
> 1)I'm not agree with you and I don't think removing the BUG() is a good idea.
> This function is called from the place, where it must not fail. But it can
> fail, and the problem with name is not the only reason of this happens.
> We can't continue further pernet_operations in case of a problem happened
> in default_device_exit(), and we can't remove the BUG() before this function
> becomes of void type. But we are not going to make it of void type. So
> we can't remove the BUG().

You missed my point: that the function can still fail means you are not
"fixing" the problem, only delaying it.

> 
> 2)In case of the script is trivial, can't you just post it here to show
> what type of devices you mean? Is there real problem or this is
> a theoretical thinking?

Current code:

# ip li sh dev eth2
4: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP
mode DEFAULT group default qlen 1000
    link/ether 02:e0:f9:46:64:80 brd ff:ff:ff:ff:ff:ff
# ip netns add fubar
# ip li set eth2 netns fubar
# ip li add eth2 type dummy
# ip li add dev4 type dummy
# ip netns del fubar
--> BUG
kernel:[78079.127748] default_device_exit: failed to move eth2 to
init_net: -17


With your patch:

# ip li sh dev eth2
4: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP
mode DEFAULT group default qlen 1000
    link/ether 02:e0:f9:46:64:80 brd ff:ff:ff:ff:ff:ff
# ip netns add fubar
# ip li set eth2 netns fubar
# ip li add eth2 type dummy
# for n in $(seq 0 $((32*1024))); do
  echo "li add dev${n} type dummy"
  done > ip.batch
# ip -batch ip.batch
# ip netns del fubar
--> BUG
kernel:[   25.800024] default_device_exit: failed to move eth2 to
init_net: -17


> 
> All virtual devices I see have rtnl_link_ops, so that they just destroyed
> in default_device_exit_batch(). According to physical devices, it's difficult
> to imagine a node with 32k physical devices, and if someone tried to deploy
> them it may meet problems not only in this place.

Nothing says it has to be a physical device. It is only checking for a name.

> 
>> The change does provide more variability in naming and reduces the
>> likelihood of not being able to push a device back to init_net.
> 
> No, it provides. With the patch one may move real device to a container,
> and allow to do with the device anything including changing of device
> index. Then, the destruction of the container does not resilt a kernel
> panic just because of two devices have the same index.
> 
> Kirill
> 

  reply	other threads:[~2018-06-21 15:28 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-14 12:38 [PATCH] net: Fix device name resolving crash in default_device_exit() Kirill Tkhai
2018-06-14 17:11 ` David Ahern
2018-06-15  9:44   ` Kirill Tkhai
2018-06-17 18:58     ` David Ahern
2018-06-18 11:21       ` Kirill Tkhai
2018-06-18 11:26         ` Kirill Tkhai
2018-06-20  8:57           ` Kirill Tkhai
2018-06-20 17:15             ` David Ahern
2018-06-21 10:03               ` Kirill Tkhai
2018-06-21 15:28                 ` David Ahern [this message]
2018-06-22  8:36                   ` Kirill Tkhai

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=5e4b9ecd-e7f5-87e4-2b45-2aaaca125442@gmail.com \
    --to=dsahern@gmail.com \
    --cc=ast@kernel.org \
    --cc=brouer@redhat.com \
    --cc=daniel@iogearbox.net \
    --cc=davem@davemloft.net \
    --cc=jakub.kicinski@netronome.com \
    --cc=john.fastabend@gmail.com \
    --cc=ktkhai@virtuozzo.com \
    --cc=linux@rasmusvillemoes.dk \
    --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 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).