linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Johannes Berg <johannes@sipsolutions.net>
To: Taehee Yoo <ap420073@gmail.com>
Cc: "David Miller" <davem@davemloft.net>,
	Netdev <netdev@vger.kernel.org>,
	linux-wireless@vger.kernel.org,
	"Jakub Kicinski" <jakub.kicinski@netronome.com>,
	j.vosburgh@gmail.com, vfalico@gmail.com,
	"Andy Gospodarek" <andy@greyhouse.net>,
	"Jiří Pírko" <jiri@resnulli.us>,
	sd@queasysnail.net, "Roopa Prabhu" <roopa@cumulusnetworks.com>,
	saeedm@mellanox.com, manishc@marvell.com, rahulv@marvell.com,
	kys@microsoft.com, haiyangz@microsoft.com,
	"Stephen Hemminger" <stephen@networkplumber.org>,
	sashal@kernel.org, hare@suse.de, varun@chelsio.com,
	ubraun@linux.ibm.com, kgraul@linux.ibm.com,
	"Jay Vosburgh" <jay.vosburgh@canonical.com>,
	"Cody Schuffelen" <schuffelen@google.com>,
	bjorn@mork.no
Subject: Re: [PATCH net v4 00/12] net: fix nested device bugs
Date: Tue, 01 Oct 2019 09:39:07 +0200	[thread overview]
Message-ID: <1b17084d8649bab347b952231d9312b7fb7307f4.camel@sipsolutions.net> (raw)
In-Reply-To: <CAMArcTWs3wzad7ai_zQPCwzC62cFp-poELn+jnDaP7eT1a9ucw@mail.gmail.com> (sfid-20190929_103128_233294_188E5AB3)

On Sun, 2019-09-29 at 17:31 +0900, Taehee Yoo wrote:

> virt_wifi case is a little bit different case.

Well, arguably, it was also just missing this - it just looks different
:)

> 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.

OK, sure.

> 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.

Good point, so then really that isn't useful to check - most people
won't try to set it up that way (since it's completely useless) and if
they do anyway too much nesting would be caught by your patchset here.

> 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.

I don't think it's worthwhile just to prevent somebody from making a
configuration that we think now is nonsense. Perhaps they do have some
kind of useful use-case for it ...

> 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.

Hmm, I don't see any warnings. SET_NETDEV_DEV() should be there though.
Do you see the same if you stack it with something else inbetween? If
not, I guess preventing virt_wifi from stacking on top of itself would
be sufficient ...

johannes


  reply	other threads:[~2019-10-01  7:39 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-28 16:48 [PATCH net v4 00/12] net: fix nested device bugs Taehee Yoo
2019-09-28 16:48 ` [PATCH net v4 01/12] net: core: limit nested device depth Taehee Yoo
2019-09-28 19:36   ` Johannes Berg
2019-09-29 11:05     ` Taehee Yoo
2019-10-01  7:11       ` Johannes Berg
2019-10-01 13:53         ` Taehee Yoo
2019-10-01 13:57           ` Johannes Berg
2019-10-01 18:23             ` Taehee Yoo
2019-10-10 10:19   ` Sabrina Dubroca
2019-10-12 11:42     ` Taehee Yoo
2019-09-28 16:48 ` [PATCH net v4 02/12] vlan: use dynamic lockdep key instead of subclass Taehee Yoo
2019-09-28 16:48 ` [PATCH net v4 03/12] bonding: fix unexpected IFF_BONDING bit unset Taehee Yoo
2019-09-30 20:48   ` Jay Vosburgh
2019-09-28 16:48 ` [PATCH net v4 04/12] bonding: use dynamic lockdep key instead of subclass Taehee Yoo
2019-09-28 16:48 ` [PATCH net v4 05/12] team: use dynamic lockdep key instead of static key Taehee Yoo
2019-09-28 16:48 ` [PATCH net v4 06/12] macsec: use dynamic lockdep key instead of subclass Taehee Yoo
2019-09-28 16:48 ` [PATCH net v4 07/12] macvlan: " Taehee Yoo
2019-09-28 19:14   ` Johannes Berg
2019-09-29  8:03     ` Taehee Yoo
2019-10-01  7:25       ` Johannes Berg
2019-10-05  9:13         ` Taehee Yoo
2019-10-07 11:41           ` Johannes Berg
2019-10-08  8:13             ` Taehee Yoo
2019-10-21 16:00             ` Taehee Yoo
2019-09-28 16:48 ` [PATCH net v4 08/12] macsec: fix refcnt leak in module exit routine Taehee Yoo
2019-09-28 16:48 ` [PATCH net v4 09/12] net: core: add ignore flag to netdev_adjacent structure Taehee Yoo
2019-09-28 16:48 ` [PATCH net v4 10/12] vxlan: add adjacent link to limit depth level Taehee Yoo
2019-09-28 16:48 ` [PATCH net v4 11/12] net: remove unnecessary variables and callback Taehee Yoo
2019-09-28 19:42   ` Johannes Berg
2019-09-28 16:48 ` [PATCH net v4 12/12] virt_wifi: fix refcnt leak in module exit routine Taehee Yoo
2019-09-28 18:57   ` Johannes Berg
2019-10-07 11:22   ` Sabrina Dubroca
2019-10-08  6:53     ` Taehee Yoo
2019-09-28 19:20 ` [PATCH net v4 00/12] net: fix nested device bugs Johannes Berg
2019-09-29  8:31   ` Taehee Yoo
2019-10-01  7:39     ` Johannes Berg [this message]
2019-10-05  9:40       ` Taehee Yoo

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=1b17084d8649bab347b952231d9312b7fb7307f4.camel@sipsolutions.net \
    --to=johannes@sipsolutions.net \
    --cc=andy@greyhouse.net \
    --cc=ap420073@gmail.com \
    --cc=bjorn@mork.no \
    --cc=davem@davemloft.net \
    --cc=haiyangz@microsoft.com \
    --cc=hare@suse.de \
    --cc=j.vosburgh@gmail.com \
    --cc=jakub.kicinski@netronome.com \
    --cc=jay.vosburgh@canonical.com \
    --cc=jiri@resnulli.us \
    --cc=kgraul@linux.ibm.com \
    --cc=kys@microsoft.com \
    --cc=linux-wireless@vger.kernel.org \
    --cc=manishc@marvell.com \
    --cc=netdev@vger.kernel.org \
    --cc=rahulv@marvell.com \
    --cc=roopa@cumulusnetworks.com \
    --cc=saeedm@mellanox.com \
    --cc=sashal@kernel.org \
    --cc=schuffelen@google.com \
    --cc=sd@queasysnail.net \
    --cc=stephen@networkplumber.org \
    --cc=ubraun@linux.ibm.com \
    --cc=varun@chelsio.com \
    --cc=vfalico@gmail.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).