All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
To: Hangbin Liu <liuhangbin@gmail.com>
Cc: netdev@vger.kernel.org, Dmitry Vyukov <dvyukov@google.com>,
	syzbot <syzbot+de73361ee4971b6e6f75@syzkaller.appspotmail.com>,
	David Miller <davem@davemloft.net>
Subject: Re: [PATCH net] bridge: check iface upper dev when setting master via ioctl
Date: Fri, 27 Apr 2018 11:33:06 +0300	[thread overview]
Message-ID: <e104d5be-5d97-f583-7193-b01f42c29fb4@cumulusnetworks.com> (raw)
In-Reply-To: <20180427013102.GJ20683@leo.usersys.redhat.com>

On 27/04/18 04:31, Hangbin Liu wrote:
> Hi Nikolay,
> 
> Thanks for the comments.
> On Thu, Apr 26, 2018 at 05:22:46PM +0300, Nikolay Aleksandrov wrote:
>>> Not all upper devs are masters. This can break some setups.
> 
> Ah, like vlan device.. So how about
> 
> +	if (netdev_master_upper_dev_get(dev))
>   		return -EBUSY;

That should be fine, yes.

> 
>>>
>>>
>>
>> Also it's not really a bug, the device begins to get initialized but it
>> will get removed at netdev_master_upper_dev_link() anyway if there's
>> already a master. Why would it be better ?
> 
>> It's clearly wrong to try and enslave a device that already has a master
>> via ioctl, rtnetlink already deals with that and the old ioctl interface
>> will get an error, yes it will initialize some structs but they'll get
>> freed later. This is common practice, check the bonding for example.
> 
> Bonding use netdev_is_rx_handler_busy(slave_dev) to check if the slave
> already has a master, which is another solution.

Some masters don't use rx_handlers and the bonding fails at linking them
as a master which is still fine, it cleans up after the error like the bridge.

>>
>> If anything do the check in the ioctl interface (add_del_if) only and
>> maybe target net-next, there's really no bug fix here. IMO it's not
> 
> What if someone do like
> 
> while true; do brctl addif br0 bond_slave &; done
> 
> I know this is stupid and almost no one will do that in real world.
> But syzbot run some similar test and get warn from kobject_add_internal()
> with -ENOMEM. That's why I think we should fix it before allocate any
> resource.
> 
> What do you think?

The bridge code is only a symptom of what happened, that warn was placed to
warn people against doing stupid things - it was literally in the commit message
of some kobject patch. As long as the resources involved are cleaned up and it's
returned to the bridge to cleanup after itself, it should be fine.
  
You can add the check if you feel like it, I don't have an
objection against failing earlier. My main concern was the netdev_has_any_upper
usage which can break some setups.

Cheers,
  Nik

> 
> [1] https://syzkaller.appspot.com/bug?id=3e0339080acd6a2a350a900bc6533b03f5498490
> 
> Thanks
> Hangbin
> 

  reply	other threads:[~2018-04-27  8:33 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-26 13:56 [PATCH net] bridge: check iface upper dev when setting master via ioctl Hangbin Liu
2018-04-26 14:00 ` Nikolay Aleksandrov
2018-04-26 14:22   ` Nikolay Aleksandrov
2018-04-27  1:31     ` Hangbin Liu
2018-04-27  8:33       ` Nikolay Aleksandrov [this message]
2018-04-27 12:59 ` [PATCHv2 " Hangbin Liu
2018-04-28 10:06   ` Nikolay Aleksandrov
2018-04-30  1:08   ` David Miller

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=e104d5be-5d97-f583-7193-b01f42c29fb4@cumulusnetworks.com \
    --to=nikolay@cumulusnetworks.com \
    --cc=davem@davemloft.net \
    --cc=dvyukov@google.com \
    --cc=liuhangbin@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=syzbot+de73361ee4971b6e6f75@syzkaller.appspotmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.