All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
To: Xin Long <lucien.xin@gmail.com>
Cc: network dev <netdev@vger.kernel.org>, davem <davem@davemloft.net>,
	Hannes Frederic Sowa <hannes@stressinduktion.org>
Subject: Re: [PATCH net] bridge: a netlink notification should be sent whenever those attributes change
Date: Sat, 5 Mar 2016 20:43:07 +0100	[thread overview]
Message-ID: <56DB36CB.2010407@cumulusnetworks.com> (raw)
In-Reply-To: <CADvbK_eiSQFT9uKfJZf_8omcFyiVuh+XbnywzC2wszxqPuThjQ@mail.gmail.com>

On 03/05/2016 03:44 PM, Xin Long wrote:
> On Thu, Mar 3, 2016 at 8:29 PM, Nikolay Aleksandrov
> <nikolay@cumulusnetworks.com> wrote:
>>
>> This is incorrect because you don't have rtnl here, bridge device sysfs
>> options take care of rtnl only on per-option basis and they obtain and
>> release it themselves, so you won't have rtnl held when you call
>> netdev_state_change. While I agree that this is needed, a larger change
>> would be necessary for br_sysfs_br.c.
> Sorry, I can't follow you, cause I didn't see any held in dev_ioctl, like:
> ipip6_tunnel_ioctl
>     ipip6_tunnel_update
>         netdev_state_change
> 
> why sysfs have to hold rtnl ?
> 

See the comment above dev_ifsioc:
/*
 *      Perform the SIOCxIFxxx calls, inside rtnl_lock()
 */
static int dev_ifsioc(struct net *net, struct ifreq *ifr, unsigned int cmd)
{
...
it is usually called like:
                       rtnl_lock();
                       ret = dev_ifsioc(net, &ifr, cmd);
                       rtnl_unlock();
And also you cannot be calling netdevice notifiers without RTNL. So in any
case you do need it here as well, in fact you'll surely hit the ASSERT_RTNL();
in call_netdevice_notifiers_info if you do so, thus I'm not sure how this
patch was actually tested.

>> Off-topic: I've been looking into factoring out the bond option API and reusing
>> it here as it already has all of this handled, but I won't have time to finish
>> it before the next merge window, so if you fix the issue here I'm okay with
>> this as interim solution.
>>
>> Cheers,
>>  Nik
>>

  reply	other threads:[~2016-03-05 19:43 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-03 12:16 [PATCH net] bridge: a netlink notification should be sent whenever those attributes change Xin Long
2016-03-03 12:29 ` Nikolay Aleksandrov
2016-03-05 14:44   ` Xin Long
2016-03-05 19:43     ` Nikolay Aleksandrov [this message]
2016-03-06  6:08       ` Xin Long

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=56DB36CB.2010407@cumulusnetworks.com \
    --to=nikolay@cumulusnetworks.com \
    --cc=davem@davemloft.net \
    --cc=hannes@stressinduktion.org \
    --cc=lucien.xin@gmail.com \
    --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 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.