All of lore.kernel.org
 help / color / mirror / Atom feed
From: Moni Shoua <monisonlists@gmail.com>
To: Roland Dreier <rdreier@cisco.com>
Cc: netdev@vger.kernel.org, Jay Vosburgh <fubar@us.ibm.com>,
	OpenFabrics General <general@lists.openfabrics.org>
Subject: Re: [ofa-general] Re: [PATCH V5 2/11] IB/ipoib: Notify the world before	doing unregister
Date: Mon, 24 Sep 2007 15:56:46 +0200	[thread overview]
Message-ID: <46F7C21E.1000204@gmail.com> (raw)
In-Reply-To: <adar6kpwdax.fsf@cisco.com>

Roland Dreier wrote:
>  > The action in bonding to a detach of slave is to unregister the master (see patch 10).
>  > This can't be done from the context of unregister_netdevice itself (it is protected by rtnl_lock).
> 
> I'm confused.  Your patch has:
> 
>  > +		ipoib_slave_detach(cpriv->dev);
>  >  		unregister_netdev(cpriv->dev);
> 
> And ipoib_slave_detach() is:
> 
>  > +static inline void ipoib_slave_detach(struct net_device *dev)
>  > +{
>  > +	rtnl_lock();
>  > +	netdev_slave_detach(dev);
>  > +	rtnl_unlock();
>  > +}
> 
> so you are calling netdev_slave_detach() with the rtnl lock held.
> Why can't you make the same call from the start of unregister_netdevice()?
> 
> Anyway, if the rtnl lock is a problem, can you just add the call to
> netdev_slave_detach() to unregister_netdev() before it takes the rtnl lock?
> 
>  - R.
> 

Your comment made me do a little rethinking.
In bonding, device is released by calling unregister_netdevice() that doesn't 
take the rtnl_lock (unlike unregister_netdev() that does). I guess that this made me 
confused to think that this is not possible. So, I guess I could put 
the detach notification in unregister_netedev() and the reaction to the notification 
in the bonding driver would not block.
However, I looked one more time at the code of unregister_netdevice() and found out that
nothing prevents from calling unregister_netdevice() again when the notification NETDEV_GOING_DOWN
is sent. I tried that and it works.
I have a new set of patches without sending a slave detach and I will send it soon.

Thanks for the comment Roland. It makes this patch simpler.

I'd also like to give a credit to Jay for the idea of using NETDEV_GOING_DOWN notification
instead of NETDEV_CHANGE+IFF_SLAVE_DETACH. He suggested it a while ago but I wrongly thought that
it wouldn't work.

  reply	other threads:[~2007-09-24 13:56 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-09-20 13:33 [PATCH V5 0/11] net/bonding: ADD IPoIB support for the bonding driver Moni Shoua
2007-09-20 13:39 ` [ofa-general] [PATCH V5 1/11] net/core: add a netdev notification for slave detach Moni Shoua
2007-09-20 13:40 ` [PATCH V5 2/11] IB/ipoib: Notify the world before doing unregister Moni Shoua
2007-09-20 16:20   ` [ofa-general] " Roland Dreier
2007-09-23  7:55     ` Moni Shoua
2007-09-23 16:34       ` Roland Dreier
2007-09-24 13:56         ` Moni Shoua [this message]
2007-09-20 13:41 ` [ofa-general] [PATCH V5 3/11] IB/ipoib: Bound the net device to the ipoib_neigh structue Moni Shoua
2007-09-20 13:42 ` [PATCH V5 4/11] IB/ipoib: Verify address handle validity on send Moni Shoua
2007-09-20 13:43 ` [ofa-general] [PATCH V5 5/11] net/bonding: Enable bonding to enslave non ARPHRD_ETHER Moni Shoua
2007-09-20 13:45 ` [PATCH V5 6/11] net/bonding: Enable bonding to enslave netdevices not supporting set_mac_address() Moni Shoua
2007-09-20 13:58 ` [ofa-general] [PATCH V5 7/11] net/bonding: Enable IP multicast for bonding IPoIB devices Moni Shoua
2007-09-20 14:00 ` [ofa-general] [PATCH V5 8/11] net/bonding: Handlle wrong assumptions that slave is always an Ethernet device Moni Shoua
2007-09-20 14:02 ` [ofa-general] PATCH V5 9/11] net/bonding: Delay sending of gratuitous ARP to avoid failure Moni Shoua
2007-09-20 14:04 ` [PATCH V5 10/11] net/bonding: Destroy bonding master when last slave is gone Moni Shoua
2007-09-20 14:06 ` [PATCH V5 5/11] net/bonding: Enable bonding to enslave non ARPHRD_ETHER Moni Shoua
2007-09-20 14:07 ` [PATCH 11/11] bonding: Optionally allow ethernet slaves to keep own MAC Moni Shoua

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=46F7C21E.1000204@gmail.com \
    --to=monisonlists@gmail.com \
    --cc=fubar@us.ibm.com \
    --cc=general@lists.openfabrics.org \
    --cc=netdev@vger.kernel.org \
    --cc=rdreier@cisco.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.