[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAMArcTWs3wzad7ai_zQPCwzC62cFp-poELn+jnDaP7eT1a9ucw@mail.gmail.com>
Date: Sun, 29 Sep 2019 17:31:15 +0900
From: Taehee Yoo <ap420073@...il.com>
To: Johannes Berg <johannes@...solutions.net>
Cc: David Miller <davem@...emloft.net>,
Netdev <netdev@...r.kernel.org>, linux-wireless@...r.kernel.org,
Jakub Kicinski <jakub.kicinski@...ronome.com>,
j.vosburgh@...il.com, vfalico@...il.com,
Andy Gospodarek <andy@...yhouse.net>,
Jiří Pírko <jiri@...nulli.us>,
sd@...asysnail.net, Roopa Prabhu <roopa@...ulusnetworks.com>,
saeedm@...lanox.com, manishc@...vell.com, rahulv@...vell.com,
kys@...rosoft.com, haiyangz@...rosoft.com,
Stephen Hemminger <stephen@...workplumber.org>,
sashal@...nel.org, hare@...e.de, varun@...lsio.com,
ubraun@...ux.ibm.com, kgraul@...ux.ibm.com,
Jay Vosburgh <jay.vosburgh@...onical.com>,
Cody Schuffelen <schuffelen@...gle.com>, bjorn@...k.no
Subject: Re: [PATCH net v4 00/12] net: fix nested device bugs
On Sun, 29 Sep 2019 at 04:20, Johannes Berg <johannes@...solutions.net> wrote:
>
>
> > VLAN, BONDING, TEAM, MACSEC, MACVLAN, IPVLAN, VIRT_WIFI and VXLAN.
> > But I couldn't test all interface types so there could be more device
> > types which have similar problems.
>
> Did you test virt_wifi? I don't see how it *doesn't* have the nesting
> problem, and you didn't change it?
>
> No, I see. You're limiting the nesting generally now in patch 1, and the
> others are just lockdep fixups (I guess it's surprising virt_wifi
> doesn't do this at all?).
virt_wifi case is a little bit different case.
I add the last patch that is to fix refcnt leaks in the virt_wifi module.
The way to fix this is to add notifier routine.
The notifier routine could delete lower device before deleting
virt_wifi device.
If virt_wifi devices are nested, notifier would work recursively.
At that time, it would make stack memory overflow.
Actually, before this patch, virt_wifi doesn't have the same problem.
So, I will update a comment in a v5 patch.
>
> FWIW I don't think virt_wifi really benefits at all from stacking, so we
> could just do something like
>
> --- a/drivers/net/wireless/virt_wifi.c
> +++ b/drivers/net/wireless/virt_wifi.c
> @@ -508,6 +508,9 @@ static int virt_wifi_newlink(struct net *src_net, struct net_device *dev,
> else if (dev->mtu > priv->lowerdev->mtu)
> return -EINVAL;
>
> + if (priv->lowerdev->ieee80211_ptr)
> + return -EINVAL;
> +
> err = netdev_rx_handler_register(priv->lowerdev, virt_wifi_rx_handler,
> priv);
> if (err) {
>
Many other devices use this way to avoid wrong nesting configuration.
And I think it's a good way.
But we should think about the below configuration.
vlan5
|
virt_wifi4
|
vlan3
|
virt_wifi2
|
vlan1
|
dummy0
That code wouldn't avoid this configuration.
And all devices couldn't avoid this config.
I have been considering this case, but I couldn't make a decision yet.
Maybe common netdev function is needed to find the same device type
in their graph.
>
>
> IMHO, but of course generally limiting the stack depth is needed anyway
> and solves the problem well enough for virt_wifi.
>
>
This is a little bit different question for you.
I found another bug in virt_wifi after my last patch.
Please test below commands
ip link add dummy0 type dummy
ip link add vw1 link dummy0 type virt_wifi
ip link add vw2 link vw1 type virt_wifi
modprobe -rv virt_wifi
Then, you can see the warning messages.
If SET_NETDEV_DEV() is deleted in the virt_wifi_newlink(),
you can avoid that warning message.
But I'm not sure about it's safe to remove that.
I would really appreciate it if you let me know about that.
> johannes
>
Powered by blists - more mailing lists